JOric

Comments, problems, suggestions about Oric emulators (Euphoric, Mess, Amoric, etc...) it's the right place to ask. And don't hesitate to give your tips and tricks that help using these emulations in the best possible way on your favorite operating system.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: JOric

Post by Chema »

Nice! Congratulations!
User avatar
ibisum
Wing Commander
Posts: 1643
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: JOric

Post by ibisum »

This is a great thread - so much to learn!
User avatar
dreamseal
Officer Cadet
Posts: 62
Joined: Sat Mar 17, 2018 6:14 pm

Re: JOric

Post by dreamseal »

dreamseal wrote: Thu Apr 19, 2018 9:51 pmIncidentally, it still has a VIC 20 keyboard for the graphical popup keyboard. I really must create an Oric one for it.
I've been working on fixing the above outstanding issue. I thought I'd have a go at designing an Oric-like keyboard using this online keyboard layout editor that I discovered a couple of years ago:

http://www.keyboard-layout-editor.com

I came up with the following, which seems fairly close:

http://www.keyboard-layout-editor.com/# ... :2;&=FUNCT

I took a screen shot of that and am currently using it for the pop up keyboard. Since the emulator is mainly targeting Android, where the portrait view is one of the options, such a keyboard image would need to be vertically scaled for a couple of reasons. One of these is due to there being black space to fill. So I doubled the height. The other reason is that making the keys higher makes it a bit easier to hit the right key when you're typing. I've noticed that the built in Android soft popup keyboard that comes with Android itself also has the keys higher than they are wide. It seemed to make sense to do the same. So the end result currently looks something like this (snapshot is from desktop version, which launches looking the same as Android but with resolution half what my phone uses in each direction, my phone being 1080x1920 for portrait):
joric_portrait_with_keyboard.png
To be honest, there's probably some more work to be done to make that image scale better. The smaller writing isn't so clear when at half size like this. Looks a lot better on my phone though. Let's see if I can can take a phone screenshot...
joric_android_screenshot.png
Click on that image to get the close up.

It's worth noting that I've been playing around with the aspect ratio of the Oric text window. Up until now, I took the 240x224 image, scaled it to be a 4:3 ratio, and then scretched it again so that the edges of the text window were right on the edges of the phone screen. I didn't see any point showing black strips down the sides. But I realised that this means that some pixels are different sizes than others. The only way to make them all the same size is to scale them by whole numbers in each direction. So the image above from my phone shows a width of 1080 pixels, but the text window part is only 240x4=960 pixels wide, which leaves 60 pixels of black on each side. Even though the image is a bit smaller, it looks a bit nicer with the pixels all the same size.

I'm undecided at this point on which way to go, because its nice to have the image full up more of the phone screen (when in portrait mode), but to have some pixels 4 pixels in width and a few 5 pixels in width might look a bit strange. Not so obvious in games, but in the text screen it probably is noticeable.

I'm also undecided about whether to use the same multiplier in each direction. On my phone it is currently drawing each Oric pixel as 4x4. I could change it to be 4x3 so that the aspect ratio looks a bit closer to a TV screen, but that increases the black space between the Oric screen and the keyboard, and part of me thinks its nicer to fill more of the screen. I noticed that Oricutron uses the same multiplier in both directions, so maybe its okay and is what people are used to.

Of course not every Android phone has the same resolution as my phone. Some have higher, some have lower, and some have a different ratio of width to height. It will stretch if it needs to. Its currently designed to stretch such that the pixels are all the same size if the width is a multiple of 270, which 1080 is. I might need to make it a bit smarter so that the black strips change in size depending on the detected dimensions of the phone screen. Its either that or go back to stretching the text window to fill the whole width.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: JOric

Post by Chema »

In my opinion it is a good idea to always keep the original Oric aspect ratio (with its rectangular pixels) or, at least, a perfect squared pixel. But stretching the image without keeping the aspect ratio would look horrible, I think.

I'd prefer to have the widest screen possible, correct aspect ratio, and whatever black borders are needed at top and bottom. But that may be just me :)
User avatar
dreamseal
Officer Cadet
Posts: 62
Joined: Sat Mar 17, 2018 6:14 pm

Re: JOric

Post by dreamseal »

If it had to stretch to fill the width, then it would stretch downwards such that it would keep whatever aspect ratio its trying to maintain. It's already doing that, in fact in desktop mode you can adjust the size of the window to whatever rectangular shape you want and it maintains the aspect ratio of the text window.

To clarify, are you saying Chema that you'd prefer not to have the black borders on the left and right, and that you wouldn't mind if the individual pixels have slightly different widths and heights as a result of filling that available space and maintaining the correct aspect ratio? I was leaning a bit that way as well.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: JOric

Post by Chema »

Mmmm I think I misunderstood you... It is not that I don't want black borders on the screen sizes. I was just stating that I would rather see the original Oric's rectangular pixels (Oricutron can do that) with its aspect ratio (I think it is 5:4 on the usual 4:3 TV screen), than perfectly squared pixels; and keep it while adapting the screen size...

In the worst case perfectly squared pixels would also do.

Maybe that is exactly what you are already doing :? Sorry if I did not understood.
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: JOric

Post by ThomH »

I'd also vote in favour of maintaining the proper aspect ratio, especially when you consider the pixel densities of modern Android devices, and the direction that pixel density continues to head.

In Clock Signal I apply a discreet lowpass filter to suppress some of the resulting aliasing; have you considered something like that? There's a bunch of maths to come up with filter coefficients, but then it's just performing an appropriately-weighted sum for each output pixel.
User avatar
dreamseal
Officer Cadet
Posts: 62
Joined: Sat Mar 17, 2018 6:14 pm

Re: JOric

Post by dreamseal »

Chema wrote: Thu Apr 26, 2018 8:03 am Mmmm I think I misunderstood you... It is not that I don't want black borders on the screen sizes. I was just stating that I would rather see the original Oric's rectangular pixels (Oricutron can do that) with its aspect ratio (I think it is 5:4 on the usual 4:3 TV screen), than perfectly squared pixels; and keep it while adapting the screen size...
Is it definitely 5:4? I've tried switching to that and it does look about right. I think I'll leave it like that for now.
Chema wrote: Thu Apr 26, 2018 8:03 am Maybe that is exactly what you are already doing :? Sorry if I did not understood.
Sorry, I think it was the way I asked the question that was confusing. It was more like two questions in one. I was asking both about matching the original machine's aspect ratio, but also about whether having some pixels bigger than others (due to scaling) would be okay. After seeing Thom's answer above, I realised there was a simple way to solve the "different sized pixels" issue. The default filter set on the libgdx Textures is Nearest, but simply changing this to Linear makes the result look a lot nicer (i.e. smoother).
User avatar
dreamseal
Officer Cadet
Posts: 62
Joined: Sat Mar 17, 2018 6:14 pm

Re: JOric

Post by dreamseal »

ThomH wrote: Thu Apr 26, 2018 2:35 pm In Clock Signal I apply a discreet lowpass filter to suppress some of the resulting aliasing; have you considered something like that? There's a bunch of maths to come up with filter coefficients, but then it's just performing an appropriately-weighted sum for each output pixel.
Thanks Thom. As noted in my answer to Chema above, your mention of a filter made me take a closer look at what libgdx provides out of the box, and simply setting a Linear filter on the Texture used ends up looking pretty good.

Edit: Added new screen shot from Android below:
joric_android_screenshot_2.png
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: JOric

Post by Dbug »

The easiest way to visualize the aspect ratio is with the good old:

Code: Select all

HIRES:CURSET 120,100,3:CIRCLE 99,1
Makes it obvious that the circles are squished :D
User avatar
dreamseal
Officer Cadet
Posts: 62
Joined: Sat Mar 17, 2018 6:14 pm

Re: JOric

Post by dreamseal »

Interesting. That circle is squished in the opposite direction than what I was expecting. If we're certain that that circle would be perfectly round on the original Oric connected to a 4:3 TV screen, then I'll adjust it until this circle is perfectly round.
Screenshot_20180428-110131.png
Edit: Okay, I tried that and ended up back with perfectly square pixels. It seems that that CIRCLE command draws a perfectly round circle only if the pixels are square. Does this sound right?
User avatar
dreamseal
Officer Cadet
Posts: 62
Joined: Sat Mar 17, 2018 6:14 pm

Re: JOric

Post by dreamseal »

Dbug wrote: Sat Apr 28, 2018 8:02 am Makes it obvious that the circles are squished :D
I think I misunderstood what you meant by this. Do you mean that it is expected that the circles are squished?

Edit: Having had a look at some photos found online of the Oric BASIC screen running on various 4:3 CRTs, and doing a few measurements and calculations on those images, it does appear that the pixel aspect ratio is very close to 5:4. So that is what I had it set to in my most recent screenshot above showing the squished circle.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: JOric

Post by Dbug »

Yes, a real Oric on a real 80ies TV screen would see squished circles, that's how it should be :D
ThomH
Flying Officer
Posts: 238
Joined: Thu Oct 13, 2016 9:55 pm

Re: JOric

Post by ThomH »

Yep: PAL is idiomatically taken to have 52μs of visual information horizontally and be 287.5 lines vertically.

Given the 4:3 ratio, a perfectly-square pixel would have to last (3/4) * (52/287.5) ~= 0.135652173913μs.

The Oric outputs pixels for 40μs and includes 240 of them. So each actually lasts 40/240 ~= 0.166666666667μs.

Therefore each is 0.166666666667/0.135652173913 ~= 1.22863247863 times as wide as it is tall.

Or, without decimals: (40/240) / ( (3/4) * (104/575) ) = (1/6) / ( (312/2300) ) = 2300/1872 = 575/468 times as wide as tall.

But real-life TVs are rarely perfectly adjusted, so you can bet it was 1.2 for at least somebody. Pick the TV you want to emulate.
User avatar
dreamseal
Officer Cadet
Posts: 62
Joined: Sat Mar 17, 2018 6:14 pm

Re: JOric

Post by dreamseal »

Thanks @ThomH. I actually managed to follow all of that. I must say I'm really impressed with the level of detail that you take your emulation to. I was impressed when I first read your posts many months ago back in the VIC 20 Denial forums, and have been impressed again seeing and reading what you've done with the Oric emulation.

I know that horizontal blanking is usually about 12μs for PAL, so 52μs of visual information makes sense. Obviously not all of that is visible even though its visual. When I did some visible measurements on my old CRT TV back in 2003, there were only about 204 pixels across the screen for the VIC 20. That's quite a bit less than the total visual information for the line. And for the number of lines actually visible on that CRT, it was only about 270 even though the number of vertical blanking lines was only 9 for the VIC 20, which would have meant something like 33 lines that are not visible but not in the vertical blanking area so are actually in the visual area.

This evening I was thinking about the Oric and its black and blanking areas. The text window is obviously not all of the visual information. There is also a lot of black visual information, to the top, left, right and bottom, as the black border. I had out my Picoscope this evening, with it connected to the composite output signal on the Oric, and its obviously impossible to distinguish between the blanking level and the black level. Sync is quite a bit lower than black/blanking, but trying to spot where the "visual" information starts is impossible given the black borders that the Oric has. I could kind of guessimate it though. The horizontal sync is easy to spot and is maybe slightly over 4μs, which is as per the PAL standard. The PAL standard also says the front porch is something like 2μs (or maybe a bit under), and if the total horizontal blanking is about 12μs, then that leaves about 6μs (or maybe a bit above) for the back porch. I was able to measure the total combined "black/blanking" area of a line on the Oric as being about 24μs (which is pretty obvious given the text window is 40μs). So 24-12=12μs of black border, with what looks like perhaps 7μs of right hand black border and about 5μs of left hand black border. Given my experience back in 2003 checking the VIC 20 on a 4:3 CRT TV screen, some of that black border on each side is not visible, but obviously some of it is because we can clearly see a black border the whole way around the text window. Usually for the Oric it appears as if the right hand "visible" black border is something like twice as big as the left hand "visible" black border. Looking at some online images of the Oric running on a CRT (I don't have a CRT these days), the "visible" left hand border is usually about 2-3 columns and the "visible" right hand border about 5-6 columns. So that could mean up to 2 columns of visual black border on each side that isn't visible.

It probably makes no difference on the Oric, but I was also thinking about the internal horizontal and vertical counters within the ULA this evening and wondering what values they might have at the various points where vertical and horizontal blanking and syncs begin and end. I know that Mike Brown has produced some timing diagrams with accompanying text to describe his thoughts on what might be happening, but it seems likely the horizontal and vertical counter values shown on the diagrams would not match the actual values within the chip. I think in his text he mentions that its easier to think of the counters as starting at various points, for example at the top and left of the text window, but I'd say it's likely that the vertical counter will at least have counted the black border lines prior to that, and if its anything like the VIC 20, then it would have also counted the vertical blanking lines (although the VIC might be unusual with regards to the vertical blanking lines appearing at the "top" with regards to the vertical counter; I really have no idea though). One thing that is certain though is that the vertical blanking area shown on those Oric video timing diagrams is much bigger than the actual vertical blanking area. It looks like the diagram is including the top and bottom black borders as well. The same is true of the horizontal blanking, i.e. the black borders are included. It probably makes no difference though given that the black borders can't be changed at all, so it is as if the blanking areas have been extended. It probably doesn't really matter at what vertical counter value vertical blanking starts, or at what horizontal counter value horizontal blanking starts. Its more about the timing isn't it, i.e. the time between syncs, and the relative position of syncs within the blanking periods, and the positioning of the colour burst within the horizontal blanking area in relation to the horizontal sync. The TV doesn't really care about what your counter values are, so it could be implemented in a variety of ways, where one implementation might have the vertical blanking on Line 1 like the VIC has it, but another might have it towards the end of the vertical counters values, and yet another could have it when the vertical counter is something obscure like 109 (although that's unlikely). On the VIC where the vertical counter value is exposed in a memory mapped register, it does make a difference how the counters are handled, but on the Oric I guess it doesn't really matter if we're not emulating exactly what the ULA is doing with its counters.
Post Reply