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!
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
Linux kernel 4.0.0-2-amd64
You might need a wider screen.olofsen wrote: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
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.
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).olofsen wrote: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