ZX81 ULA-in-a-CPLD

[commie]

Hi Pokemon,

I personally don't think it is glitches, I have read Retrotechie design report and it seems perhaps( I could be wrong) the design is incomplete which is a great shame because it works so well in fast mode. I have cross referenced the design with Grant Searl's zx80 slow mode adapter and they are more or less exactly the same.

Well, thanks for your input anyhow, I basically have a zx80 with an 8k upgraded rom.

Cheers
commie

[PokeMon]

So then - what happens in detail ?
As you said it is working in FAST mode. How do you enter FAST mode from system startup ? Usually it tries to switch on SLOW mode by default after RAM test. Did you force it anyway ? And what happens when you enter SLOW mode exactly ?

[mrtinb]

I personally don't think it is glitches, I have read Retrotechie design report and it seems perhaps( I could be wrong) the design is incomplete which is a great shame because it works so well in fast mode.

I was sure RetroTechie's ULA in XC9572 wasn't flawed. That's why I'm implementing it.

[commie]

So then - what happens in detail ?
As you said it is working in FAST mode. How do you enter FAST mode from system startup ? Usually it tries to switch on SLOW mode by default after RAM test. Did you force it anyway ? And what happens when you enter SLOW mode exactly ?

Well, I have to boot with the cpu's nmi pin tied high(disconnected from the cpld), then it boots in fast mode perfectly, lovely crisp stable picture. If the cpu nmi pin is connected to the cpld nmi pin and try a reboot then the picture goes completely crazy, I can see the cpld nmi pulses on my scope, they look good and are not a continuous stream but appear in bunches, per frame perhaps. Although my system is currently on breadboard, I first built it with a stock ula and got the whole thing working, this done I exchanged the stock ula for the Atmel cpld and went from there.

I really can't understand what is wrong, I confirmed and cross referenced Retrotechie's work with other discrete ula circuits and they all agree with Retrotechies cpld design. I just don't get it.

With any zx81, if you desire it boot into fast mode automatically then just disconnect the nmi pin from the cpu and tie the cpu's nmi pin high. What you then get is a zx80 with floating point basic(8k rom), indeed in the early eighties this was sold as an up grade for zx80 owners.

[PokeMon]

Yes - I know all that stuff and the ROM contents of ZX80 and ZX81 and display routines quite well. If you can load programs you could try to load power basic which allows to do IN and OUT instructions from BASIC (use Shift-H for ** and the OUT).
http://www.swatosch.de/zx81/

This way you could start up in FAST mode while keeping NMI pin high and try
**OUT 254,0 for switching NMI on and **OUT 253,0 for switching it off.
Just to see if there is an issue with switching NMI off and maybe a wrong or missing connection of address line A1 which is used for NMI purpose only. A0 must be connected correctly as you wouldn't be able to get keyboard input when doing IN A,(254).

Just a guess but try to worth if you want this to investigate further.

[RetroTechie]

Can I just make it clear, everything works perfectly, the picture is rock steady there are no glitches or hic ups on the screen, all the scope waveform's look good no glitches. In fact, it's working so good (..)

Well done commie! When screen output etc is all working, you're 99% there. Also gives me a warm fuzzy feeling in my belly...

However, does anyone know what the differences are between fast and slow modes?, I know that the nmi is used in slow mode, what changes take place in the zx81's hardware/software?.

Like PokeMon said, in slow mode the NMI generator is turned on/off under software control (a few times per frame iirc). ZX80 doesn't support that as the NMI generator is missing. And with NMI generator disabled, ZX81 is basically a ZX80 with newer ROM.

I've implemented the zx81 ula in an Atmel ATF1504 (plcc44) cpld and its working great except for one feature, that is it doesn't work in slow mode only fast mode with the nmi pin strapped high. When I connect the nmi I get garbage on the screen, but the nmi pulses are active as seen on my scope.

When you get garbage on screen, does machine keep running? For example, can you still type things and see keywords etc appear on screen? Or maybe execute commands/previously entered program? Or garbage on screen as in "machine stops responding"?

With NMI's being generated, there's 2 things to check:
* Whether NMI generation can be turned on & off under software control (or you have NMI's always which wouldn't be right)
* At what point in time exactly those NMI's are generated. The Z80 responds to NMI's at certain point(s) during processing instructions. If (for example) the NMI arrives 1/2 clock cycle too early or too late, that might be the problem.

If you are wondering how I sqeezed it all in plcc44, well the oscillator and flip flop(3.25MHz) are external and drive only the z80 whilst 6.5MHz osc. is fed into the cpld where the 3.25MHz and /3.25MHz are derived in the cpld.

Aiiii... so you may have timing differences between 3.25 MHz clock edges inside the CPLD, and clock edges the Z80 sees? That might be bad. Or not. Dunno. In my CPLD design I put both 3.25 MHz signals on global clock pins of the CPLD, meaning flip-flops clocked by the same clock edge are clocked with minimal time difference. No chance that a slightly early update of one flip-flop causes another flip-flop to be clocked with the wrong data. With 'next round of updates' a 1/2 clock cycle down the line...

I have read Retrotechie design report and it seems perhaps( I could be wrong) the design is incomplete (..)

Nah... that disable-NMI's-as-if-on-a-ZX80 feature looked too simple at the time. And I hadn't tested that with a ZX80 ROM. Therefore wasn't 100% sure that feature was complete/working as intended. And stated such in the docs.
With NMI generator enabled as on a ZX81, things are 100% working and I was unable to find any software that worked different than on a ZX81 with Sinclair ULA. Timing-sensitive demo's, stuff that writes in the border area etc included. Doesn't mean my CPLD design behaves exactly like a Sinclair ULA! But does mean the software/on screen effect is the same.

[PokeMon]

The Z80 responds to NMI's at certain point(s) during processing instructions. If (for example) the NMI arrives 1/2 clock cycle too early or too late, that might be the problem.

I don't think that this is a problem as NMI is an asynchronous input and sampled at the rising edge of the last instruction cycle. If that point is missed, it will be sampled at the last cycle of the next instructions cycle. It is triggered with the falling edge of an NMI during an internal flip flop in the CPU but it is accepted (checked) only at the last machine cycle of any instruction. Minimum NMI pulse is 60 ns as stated in the data sheet from Zilog - so will not be missed anyway, only executed a bit later than occurred.

It might be that the NMI pulse is maybe generated wrong internally while porting the design. Could be that the NMI pulse is not a single pulse with 5us length every 64us (until switched off for display generation) or the NMI can not be stopped at all. I would check that if you have an oscilloscope while turning NMI pin of CPU high but you could measure how the signal is and if switch on/off is working. Both situations are problematic, nested NMI's and NMI's during video display routine. I guess there is something wrong.

If the NMI is not synchronized there could be garbage at the screen which is going better from top to down of picture with a normal TV. The question is indeed, does the ZX81 reacts on keystrokes or not.

[commie]

This way you could start up in FAST mode while keeping NMI pin high and try
**OUT 254,0 for switching NMI on and **OUT 253,0 for switching it off.

As I understand you?, I think I've already tried something similar, with the nmi tied high boot up then connect the nmi then type 'slow' mode in basic and on the screen and it crashes same as trying to boot with nmi connected same result.

Just to see if there is an issue with switching NMI off and maybe a wrong or missing connection of address line A1 which is used for NMI purpose only. A0 must be connected correctly as you wouldn't be able to get keyboard input when doing IN A,(254).

I checked and rechecked a0, a1 connections- they appear to be good.NMI definitely switch on/off alright because you get the hsync 5uSec pulses on the nmi pin as viewed on a scope.

[commie]

Aiiii... so you may have timing differences between 3.25 MHz clock edges inside the CPLD, and clock edges the Z80 sees? That might be bad. Or not. Dunno. In my CPLD design I put both 3.25 MHz signals on global clock pins of the CPLD, meaning flip-flops clocked by the same clock edge are clocked with minimal time difference. No chance that a slightly early update of one flip-flop causes another flip-flop to be clocked with the wrong data. With 'next round of updates' a 1/2 clock cycle down the line..

Hi Retrotechie, a warm welcome to you and your awesome ula design.


There are some differences that I was forced to make to get the design to work as far as I have, namely fast mode only and like you have said...'I'm 99% there

Let me try and highlight these differences:

1. I don't have chip enable (ce) on my latches or counters, with the character latch you provide a specific gate for this purpose. I chain d f/f's together to produce a latch, and activate it with a low to high transition on the clocks inputs. However, what I did was 'and' the clk and enable_latch signals and it appears to work.

2. Again, with your hsync generator, your syncro counters have 'chip enable'(ce), it looks like an ls161 ttl counting scheme?, so what I did was, second syncro counter is clocked with tc(terminal count) from the first syncro counter which is clocked with 3.25MHz cpu clock. The hsync/back_porch and reset logic remain the same except on your back_porch you are gating tc?, I removed it.

3.Bit 8(d7) of the char latch feeds into the video shift register as the 'invert' video signal. During porting the design and taking it up to fast mode working state, I noticed the 'inverted K' was inverted? so I inverted this signal in the shift register logic which corrected the inversion. However, due to a lack of pins, I had to combine luminescence with csync, it gives a good picture on a lcd monitor with 2x diode drop and straight into the monitor, gives rock solid picture.

4.Okay, here's where I fall down, I gambled on splitting the clocks between the z80 and my cpld due to pin constraints. I have a 6.5MHz resonator oscillator feeding a /2 d_f/f whose output is 3.25MHz which feeds the z80 clock, the former 6.5MHz clock is fed into my cpld and 3.25MHz is derived in the cpld itself. So yeah, there could be a problem here and I have yet to devise an experiment to see if it's a problem?
However, there shouldn't be any issues since the cpld is good to about 75MHz and my z80 is a 20 MHz speed grade(tried slow z80 to resolve my problem - no-go), so 3.25MHz is horse carts for today's chips.

Thanks everyone for trying to resolve my problem.
Cheers for now
Commie

[PokeMon]

This way you could start up in FAST mode while keeping NMI pin high and try
**OUT 254,0 for switching NMI on and **OUT 253,0 for switching it off.

As I understand you?, I think I've already tried something similar, with the nmi tied high boot up then connect the nmi then type 'slow' mode in basic and on the screen and it crashes same as trying to boot with nmi connected same result.

No - I mean leave NMI high at input of CPU, try IN/OUT and measure what is going out from the CPLD WITHOUT connecting NMI. Just to measure. This way you can test NMI while leaving in FAST mode with IN/OUT BASIC instructions (via Powerbasic) without system crash. It is difficult to measure when connected as it will crash your system. So typing in SLOW will not bring up the stuff to your scope as it will crash and results in unpredictable behavior.

It would be interesting to see what happens when switching NMI on and off if this brings your system to crash even if NMI is not connected and so NMI can not occur from sight of the CPU. Up to you - just a proposal if you are interested in solving this problem. If not, is okay for me.