Help with ZX81 loading screen for new emulator

[kpalser]

Folks,

I have questions about the generation of the ZX81 loading screen. Apologies for the following long winded background:

I have been writing on and off an emulator since 2010. It differs from many in that the module/class to display the video is driven only by the three state video output (1v white level, 0.5v black level, 0V sync pulse). The other emulator modules pass changes to the state along with the number of clock cycles between changes. The object is simple: Accurately simulate the computer including the hires programs. Details like the TR1 circuit and the back porch period in the display code are taken into account. The most complicated aspects seem to be achieved - see the attached Forty Niner screenshot.

forty2.png (12.47 KiB) Viewed 4806 times

However, there are two points where emulator is falling down:
1) The loading screen, where the activity is restricted to the top of the screen
2) And the prematurely terminated top video line on hires programs (see the Forty Niner screen shot)

Focusing on the loading screen issue, I have traced the problem down to sync signal being generated so long that screen code interprets it as requiring a vertical retrace after just a few rows in a video frame. The list following is an excerpt from trace of successive sync pulses during the loading of Forty Niner. Each value is the number of cycles the video output is at the sync level.

11,11,27,11,11,11,16,11,11,11,16,11,11,11,16,11,11,11,16,11,11,11,16,11,11,11,16,11,11,11,16,11,11,11,16,11,11,11,16,11,11,11,16,11,11,11,16,11,11,11,16,19,11,16,16,4726

The ULA is constantly generating a horizontal retrace sync that lasts for 16 cycles (see [1] point 1). The majority of the entries in the above list are 11 cycles from the instructions IN and OUT (see the ROM assembly listing below). Other values (i.e 27, 19) are when the horizontal sync signal and signal created by the INs and OUTs overlap. The final long pulse results in a premature vertical retrace so all the loading video activity is restricted to the top of the screen.

Relevant ROM listing (see [2] for more info):

Code: Select all

L0350    0350 LD_A_BYTE
             0352 IN	; TURN ON SYNC
             0354 OUTA	; TURN OFF SYNC - 11 cycles
             0356 RRA
             0357 JR_NC
             0359 RLA
             035A RLA
             035B JR_C L0385
             035D DJNZ L0350
L0385    0385 PUSH_DE
             0386 LD_E_BYTE
L0388    0388 LD_B_BYTE
             038A DEC_E
             038B IN
             038D RLA
             038E BIT7
             0390 LD_A_E
             0391 JR_C L0388
             0393 DJNZ
             0395 POP
             0396 JR_NZ
             0398 CP_BYTE
             039A JR_NC
             039C CCF
             039D RL_C
             039F JR_NC L034E

Once it leaves the loop part at L0350 there is no longer a regular OUT to turn off the sync pulse. Hence the long pulse which eventually gets turned off when the emulator returns back to L0350.

The emulators video class expects a sync pulse of at least 15 cycles to trigger a horizontal retrace and 1235 cycles for a vertical retrace (values taken from [3]). Attached are a couple of screen shots, one showing the screen output if 15 cycles is used to determine the horizontal retrace. The second screenshot with activity on more rows occurs when the threshold is lowered to 11 cycles.

loading15.png (7.9 KiB) Viewed 4806 times

loading11.png (8.09 KiB) Viewed 4806 times

Question:
- What is wrong with my logic? Can anyone provide more information on the typical range of ZX81 sync values produced during loading and how the CRT display would interpret them?

Refs:
[1] - how-the-zx81-nmi-sync-works-my-10-point ... &sk=t&sd=a
[2] - http://www.wearmouth.demon.co.uk/zx81.htm
[3] - http://nocash.emubase.de/zxdocs.htm#zx8 ... laytimings

[Andy Rea]

A while ago now i cobbled together an emulator ( sadly no longer exsists ) but what i did with regards to the display was thus....

after a vertical retrace, another vertical retrace could only be accepted after a preset time had passed say 19.5ms and over, each time a new vertical retrace was accepted the timer started again.

a similar resolve was used for horizontal retrace but instead of a timer using clock cycles since last horizontal retrace and accept a new one say anywhere from 190 cycle onwards.

probably not perfect, but it worked for me.

Andy

[PokeMon]

Here I posted sample screens for LOAD and SAVE on a CRT television.
viewtopic.php?f=7&t=1153

During LOAD you have no vertical sync but horizontal syncs are quite shorter (about 20-35us) than a normal horizontal sync (64 us).

The TV has own timers for horizontal and vertical periods slower than the syncs as standard. This is like a PLL which is coupled on the horizontal and vertical sync. So if there is no sync at all they will display a full picture anyway. I would say the internal timers are 5-10% slower (67-70us, 14-14.8 kHz horizontal) and (21-22ms, 45-47.5 Hz). If a sync is found the signal is tried to be synchronized, if no sync at all it is running with its default speed.

[kpalser]

Thank you both for your replies. The information is just what I needed. I'll update my code this weekend and add the new images to this topic.

A quick question: When a CRT display receives a sync pulse in the middle of video that is too short to trigger a horizontal retrace, would I be correct in outputting black pixels instead for these cycles?

Andy when you say your emulator no longer exists, what happened? Accidentally wiped?

Thanks again

[PokeMon]

Yes, if the sync pulse is quite out of range it will be displayed as a black stripe on screen.
So about 4 chars width, 5us is approx. 4 chars or 32 video clock cycles long (derived from 6.5 MHz).
That's why there is a scrambling pattern on screen during load.

When a CRT display receives a sync pulse in the middle of video that is too short to trigger a horizontal retrace, would I be correct in outputting black pixels instead for these cycles?

By the way, the HSYNC is not to short, it is just out of time. So has to occur in the beginning period of a new scanline.
I think my TV triggers about 2 or 3 pixels only. Maybe the internal timing is stronger, but anyway picture is synced fully after max. 1 frame I think.

Lets make an example. The sync is in the middle but a sync is only done if it is 2 or 3 pixels (1us) within the free running (slower) internal timer. So syncs during active video are displayed on the screen as small black lines (sync level is below black level - so sync is always black). As the internal timer is slower, the video sync is moving every scanline from left to right and maybe after 30,40 or 50 scanlines it should be in the sync "window" and will be used as sync as long as it is in the specification. If it is out of specification it will be moving around again.

[Andy Rea]

Yes like Pokemon says, display black if a sync occurs that is either in the wrong place or too short to trigger a *real* sync...

Well the emulator was a bit of a personal challenge, it ran everything i could at throw at it, nut ultimately i kind of lost interest when it came to the mundane things, and general tweaking to make thing nice, then i had a hard drive crash and a fair bit of work was lost, i still have some of the older source code

[1024MAK]

The original 100% analogue CRT TV's had free running oscillators for both the horizontal (line) and vertical (field/frame) systems. Both were designed to lock to a "in range" sync signal in the received video signal [much as PokeMon says]. Also as the horizontal (line) oscillator powered a transformer (the LOPT - line output transformer) which provided some important power supply feeds, this had to be kept operational.

The performance and timing values very much depended on the design of the circuits. CRT type monitors also used similar circuits, but normally the lock-in range was slightly less.

Hence when no valid signal was received, a CRT TV tuned to a unused UHF channel will display a full screen of noise ("snow" or "static").

Mark

[kpalser]

Again thanks for all your replies. So in summary (quick visual at the end of my lunch hour):

overview.png (29 KiB) Viewed 4736 times

As the shortest sync period that the IN/OUT instructions can generate is 11 processor clock cycles (22 video clock clock cycles), programatically generated pulses always have a length sufficient to generate a HSYNC as long as they overlap a couple of pixels into the sync window.

The continuous stream of 16 clock cycle ULA syncs pulses would normally fall into the window. But when the programatically generated syncs get there first the pattern is disrupted we start to get the loading screen. At this point the ULA syncs often are outside the window and either the internal timer or the programatically generated sync pulses generate the sync retrace.

Have I understood correctly?

[PokeMon]

Yes it looks quite good so far as you explained in your drawing.

[kpalser]

Thanks to the replies on this thread I finally got something that resembles a loading screen.

load1.png (11.17 KiB) Viewed 4633 times

load2.png (8.89 KiB) Viewed 4633 times

They don't quite match up to Pokemon's sample screens viewtopic.php?f=7&t=1153, but then I suspect there were some minor variations for sync pulse windows in CRT displays over the years so trying to get an almost perfect match will always be folly. Maybe the next step for authentity would be simulating a decay curve of the phosphor.