ULA talkings

[PokeMon]

I have a question to our ULA devlopers because I am developing something which needs detailed understanding of the ULA/CPU co-work.
I know 2 developers on the board here, maybe have more.

Wilf Rigter has a very good tutorial but think he maybe wrong in the point of timing.

The detailed sequence of operations for each character byte is shown in FIG 6 and described as follows:

1. Each character code (CHR$) byte in DFILE is addressed by the CPU PC, on the rising edge T2 data is loaded from DFILE into the ULA: bits 0-5 into a 6 bit ULA address latch while bit 7 is loaded into 1 bit ULA video invert latch

2. On the falling edge of T2, the ULA forces all CPU data lines to zero.

3. On the rising edge of T3 the low data lines are interpreted by the CPU as a NOP instruction.

4. During T3/4, the CPU executes the Refresh cycle and ROM address lines are generated with I register on A9-A15, the ULA 6 bit character code register on A3-A8, and the ULA modulo 8 line counter on line A0-A2.

5. On the falling edge of T4, pattern data from the ROM is loaded into ULA video shift register and 8 video pixels are shifted out at 6.5MHz

http://www.user.dccnet.com/wrigter/inde ... torial.htm

My ZX81 has memory chip uPD2114LC-1 which is compatible to the uPD2114L-1 which I found a datasheet in the internet.
Guess C comes from the CMOS version. 2114 series has 4 parts with different (maximum) access times.
2114L 450ns
2114L-1 300ns
2114L-2 250ns
2114L-3 200ns
2114L-5 150ns

So in my ZX81 Issue 3 board I have RAM with 300ns.
The datasheet of Zilog has a timing with valid address data on the address bus with maximum 110ns.
So data at RAM could not be expected safely before 410ns after rise of T1.

In this case it is not recommended (if you are on the safe site) to read data with rising edge of T2 which Wilf is writing about because its just about 300ns.
So I would say, data is catched by the ULA with falling edge of T2 (after 450ns). Maybe the offered NOPs to CPU are done with the same edge or with in the half of between falling edge of T2 and rising edge of T3. This could be done on the half easily as clock for CPU is generated by ULA from double 6.5 MHz clock.

I wonder how could Wilf find out when ULA reads the data. I think he can only guess when it's clocked into ULA register.
Just wondering how it could work with 300ns memory chips.

So as you spend many days and nights with this stuff (Andy and RetroTechie) I think you know an answer.

[Andy Rea]

Hi Pokemon,

In my ULA i test for video conditions on the falling edge of T2, if the conditions are met then a 'force nop' signal is latched for the next 2 half cycles, the leading edge of the 'force nop' signal is used to 'clock' the current data bus into the 'char code' latch, and it's state is used to drive the data lines low. but becuase of propgation throught the chip, only in the order of 15ns, the data has safely been latched before data lines are driven low.

Andy

[RetroTechie]

The relevant time delay is "address stable AND chip selected" until "output data read".

AFAIK address lines are stable roughly at rising edge of Z80 T1 cycle, and RAM chips are selected with /MREQ going low (=shortly after falling edge T1). Grant's scope investigations showed that the character code is read (latched) by the ULA somewhere between falling edge of T2 and rising edge of T3 (and a NOP forced onto the bus immediately after). That gives the RAM chips at least 1 full clock cycle access time, perhaps minus some logic delays. @ 3.25 MHz a clock cycle is >300 ns, so no problem.

For the graphic data itself, the memory chip select follows /MREQ going low (shortly after falling edge T3) but is active longer than /MREQ - roughly until end of T4 (=rising edge of T1). Again this gives at least 1 full clock cycle access time (probably closer to 1.5 cycle). So both slow ROMs (regular ZX81 software) and slow RAM (true hi-res software) should be okay.

In my ULA design the character code is latched @ falling edge T2, and the NOP-forcing starts at virtually the same time. With a CPLD this is both correct and safe thing to do. Maybe timing is different in Wilf Rigter's ZX97Lite design, but since that's a clone you can probably be sure there's faster (EP)ROM / RAM chips in it - unlike an ULA replacement which might need to work with original ROM/RAM chips.

[PokeMon]

The relevant time delay is "address stable AND chip selected" until "output data read".

The thing is, that /CS or /OE is fast enough and not critical.
Full access time appears after change of address lines as timing of datasheet.
Old manuals specify 110ns at least for the slowest CPU version (4 MHz) after begin of T1 cycle.
This delay is decreasing on fast CPU versions.
Maybe the 4 MHz are today faster due to new production process but to be compatible with older versions from 1980s you have to calculate always worst case timing to be on the safe side.

Anyway good to hear that your ULA reads data same as Andys (and as Ferranti I think) on the falling edge of T2.
So my new hardware will be compatible to the new ULAs.

[PokeMon]

One more question, the ULA uses an internal 3 bit line counter for addressing the ROM during character output to select the lines of display.
I wonder how this internal line counter is synchronized (reset) for start of video display.

Is it done with this sequence ?

Code: Select all

        OUT     ($FD),A         ; (11) Stop the NMI generator.

        JP      (IX)            ; (8) forward to L0281 (after top) or L028F

[Andy Rea]

NMI must be stopped, out ($fd),a or similar out instruction

then :-
IN A,($FE) ; start Vsync pulse ( an active Vsync resets the Character Line counter)

.
.
. some code...
.
.
then :-

OUT ($FF),A ; stops the Vsync pulse ( and releases the character line counter )

Regards Andy

[PokeMon]

OUT ($FF),A ; stops the Vsync pulse ( and releases the character line counter )

Regards Andy

Okay - thanks.
That means that the margin values 31 or 55 are not random choosen - have to be a multiple of 8 -1 (1 for sync in first horizontal line between NMI and CPU before display output starts). Am I right ?

[Andy Rea]

Under normal conditions yes your right, when the video genration routines kicks in the d-file starts with a Halt, this first Scanline is the -1 line, so the next scanline (active d-file portion) is scanline 0, and the character line counter = 0.... and so on.

Of course it's possible to reset the character line counter, with carefully constructed code, but you need to be quite precise with your timing.

Andy