sz81 (gnu/linux) not supporting hires?

[RetroTechie]

Just compiled & ran sz81-2.2.0 on Debian testing. For Debian users, "apt-get install build-essential libsdl1.2-dev" should put most (if not all) required dependencies in place.

Tried the 25thanni demo and Rock Crush game, both worked fine!

Previously I switched between EightyOne (under Wine) and xz81, mostly depending on regular ZX81 software or hi-res stuff. Looks like this may become my resident ZX81 emulator instead!

[RetroTechie]

Did some further tests. For starters, I'd like to see a smaller border again like in previous versions (320x240 or a multiple of that). Or even better: a way to set border size.

Perhaps the idea is to show everything that may appear outside the regular ZX81 display area. But reality is that all screen lines / all pixels on a screen line may not be visible on real hardware either, if they fall outside the area that makes it onto the phosphor of a CRT tube... (or equivalent effect on LCD screens). For the bulk of ZX81 software, a 400x300 default gives too much whitespace in the border.

On a related note: Alt + R switching of window size causes v2.2.0 to segfault (this works fine on previous versions). I tried a few different compiler optimization flags (-O2, -Os, -O0), this made no difference afaict. I tried restoring previous version's behavior by copying back & forth a few bits of code in various source files. Got to a point where program ran and Alt + R switching / menu's etc worked, but no "K" cursor in sight no matter what I tried. I'm no C coder so gave up on that...

For the rest, I like this emulator a lot! Seems to handle 'difficult' ZX81 software better than previous versions. System used:
Up-to-date Debian "testing"
GCC version 4.9.3
libsdl 1.2.15
Linux kernel 4.0.0-2-amd64

[olofsen]

Thank you for your feedback Yes indeed, my idea was to see everything, to know what is happening, and I chose 400x300 because it was the closest standard, but perhaps 320x240 is still sufficient. I will have a look at the borders, Alt-R, and a website for my exploratory versions. Just a start is here: http://rullf2.xs4all.nl/sz81/index.html. But first there is an issue of jitter - the number of tstates per frame is much more variable with the EightyOne core than with the old core, and sound and printing seems to be affected by that, because these currently assume a fixed number per frame as reference. The number of tstates per scanline may be variable, but the effect sometimes adds up. Even the number of tstates per scanline in the screen is variable; I think because the "207 counter" as discussed on this forum is always free running - it is not reset by the INT ACK, and then a countdown may be reached just in the different instructions of the paths in the INT routine. This seems not too important, because the HSYNC is also determined by how much the scanline is filled. Solving this will take some time

[olofsen]

The VSYNC sound in EightyOne seems also affected by this jitter, so it is unchanged for now. But with the fix for printing, VSYNC sound sounds differently Alt-R should now work, but still based on 400x300. The site contains the latest version.

[olofsen]

Resetting the "207 counter" with INT ACK instead of VSYNC needed a rewrite of EightyOne's zx81_do_scanline() routine, which is available in version 2.3.0 at the above link. The information from zx80nut and Andy Rea on this forum was used as a guide. Some goals were that Andy's "zxtest" (http://sinclairzxworld.com/viewtopic.php?f=6&t=685) would work, and that the speed would be close to that of the unmodified ZX81 - Carlo's "clckfreq" now gives 99.9%.

[dr beep]

Thank you for your feedback Yes indeed, my idea was to see everything, to know what is happening, and I chose 400x300 because it was the closest standard, but perhaps 320x240 is still sufficient. I will have a look at the borders, Alt-R, and a website for my exploratory versions. Just a start is here: http://rullf2.xs4all.nl/sz81/index.html. But first there is an issue of jitter - the number of tstates per frame is much more variable with the EightyOne core than with the old core, and sound and printing seems to be affected by that, because these currently assume a fixed number per frame as reference. The number of tstates per scanline may be variable, but the effect sometimes adds up. Even the number of tstates per scanline in the screen is variable; I think because the "207 counter" as discussed on this forum is always free running - it is not reset by the INT ACK, and then a countdown may be reached just in the different instructions of the paths in the INT routine. This seems not too important, because the HSYNC is also determined by how much the scanline is filled. Solving this will take some time

You might need a wider screen.
viewtopic.php?f=6&t=1725#p17833

[olofsen]

The FullHD81 demos work perfectly (The screen is still 400x300.)

[PokeMon]

The maximum visible area on a tv line is 52us for a PAL signal (a bit less for NTSC) which would allow to show maximum 338 pixel.
I never saw an application showing more than 320 pixels in a row.
In the vertical there are 310 lines generated while a TV expects 25 lines "vertical blanking period" - so maximum available to display would be 285 lines.
But I think there are many lines not shown on TV - so more than 256 lines won't be shown from many TVs while NTSC has less visible lines with 262 lines while blanking period would be 20 lines - so maximum 242 lines.

As 320x240 is quite a standard (half VGA) this would be a good resulting resolution.

See:
http://www.kolumbus.fi/pami1/video/pal_ntsc.html

[olofsen]

Thank you, yes you're right PokeMon. The present version also gives sync artefacts outside the 320x240 area (although these are also interesting). Bodo's "testbild" is an example that may give an image outside that area with the 5,6,7,8 keys - it seems even in the hsync if that would not be blanked

[PokeMon]

Bodo's "testbild" is an example that may give an image outside that area with the 5,6,7,8 keys - it seems even in the hsync if that would not be blanked

Yes - but if you have a normal TV there is picture information lost while moving too much left/right or top/bottom. I have a broadcast monitor which displays as much as possible (more than general TVs which often do overscan). So you can only adjust 1 or 2 pixels left/right on a regular video interface (not emulator).