Page 1 of 14

Houston, we have an image!

Posted: Sat Nov 05, 2011 6:40 am
by RetroTechie
As some of you may have read, I'm having a go at creating an ULA replacement, using an XC9572 CPLD. Tonight I made another important step forward: I produced an image on my TV!

First I added some logic for software Vsync control, but since that isn't (directly) used for any ULA output pin: how to test? Therefore decided to add a few counters & logic to decode a certain value range in those counters. One for horizontal, reset by Hsync & clocked by 3.25 MHz. And one for vertical, reset by Vsync & clocked by Hsync. Then a simple AND gate to produce a signal that basically should be '1' in a rectangular area (roughly upper left corner).

Next a gate to mix the sync signals into composite sync, and after a back-of-the-envelop calculation, hooked up a cinch connector using just 2 of the CPLD's I/O pins + 2 resistors. And guess what: an image! :D Stable, bright white rectangle, crisp edges around it, with a deep black background. Still nowhere near a full ULA replacement, but this result is important because:
  • It shows that the software Vsync generation works.
  • It shows that method for mixing the sync signals works & TV is able to lock onto both horizontal, and vertical sync.
  • That crude video out using just 2 resistors works, producing correct voltage levels for sync, black & white.
  • And I now have a nice 'channel' through which I can display signals (like what's picked up from databus etc).
For those interested: I used 180 Ohms resistor on CPLD output that carries black/white signal, 330 Ohms on the composite sync output. Other side of those resistors tied together & presto: composite video. Didn't bother to do any exact voltage measurements, but keeping the CPLD's output characterics in mind, voltages levels should be around 0V, 0.4V and 1.2V for sync level, black level & white, respectively. No series capacitor or transistor buffer in this output... 8-)

To do:
  • Line counter that goes 0..7, and output that at the right time to A0~A2 lines.
  • Grab character code from databus @ the right time, and output that shortly after to some more address lines.
  • Feed-NOP-to-Z80 circuitry.
  • Grab graphics data output by the ROM @ yet again the right time.
  • Shift those bits out serially (piece of cake when the rest is done).
  • Some minor bits like keyboard inputs, inverted video etc.

Re: Houston, we have an image!

Posted: Sat Nov 05, 2011 9:36 am
by sirmorris
Congratulations!

You must be very proud :)

Re: Houston, we have an image!

Posted: Sat Nov 05, 2011 9:56 am
by Andy Rea
Excellent, it's a great feeling whne you achieve a big step like this.

Regards Andy

Re: Houston, we have an image!

Posted: Sat Nov 05, 2011 10:35 pm
by PokeMon
RetroTechie wrote: For those interested: I used 180 Ohms resistor on CPLD output that carries black/white signal, 330 Ohms on the composite sync output. Other side of those resistors tied together & presto: composite video. Didn't bother to do any exact voltage measurements, but keeping the CPLD's output characterics in mind, voltages levels should be around 0V, 0.4V and 1.2V for sync level, black level & white, respectively. No series capacitor or transistor buffer in this output... 8-)
Congratulations, very nice.
You think your CPLD can do the job with the 180 Ohm resistor for long time ? You should expect the signal to be finished with a 75 Ohm resistor to GND, which will produce of maybe 20mA peaks on ULA, on a blank screen for about 75% of time which is a steady load of about 15mA. Maybe it is better to use a simple driver/transistor for output.

no worries...

Posted: Sun Nov 06, 2011 5:04 am
by RetroTechie
PokeMon wrote:You think your CPLD can do the job with the 180 Ohm resistor for long time ?
Ehm... YES. I have some experience with this CPLD family by now, read the datasheets, application notes (which basically say the thing to watch is overall device heat dissipation), and I've done the math. This is high speed logic so the outputs can drive some current. Btw these outputs don't start out at 5V (even unloaded!), and with this load you can expect them to sink to some 3~3.5 volts.

In active area, white (and Csync signal not active = high there), say you get 3.5V output voltage on both pins. That's 180 & 330 Ohm in parallel, in series with 75 Ohm load. Giving 1.37V output voltage, with (3.5-1.37)/180 = 12mA current supplied through the 180 Ohm resistor (another 6.5mA supplied through the 330 Ohm resistor). Adding (5-3.5V)*18mA = 27mW to the CPLD's power dissipation.

Nothing to worry about. And even if I do manage to kill an output this way, I could just re-route the signal to one of the other 68 I/O's... :lol:

Don't think I would use this for a 'production' version, but for development purposes it's fine.

Houston, we have another image!

Posted: Thu Nov 10, 2011 10:14 pm
by RetroTechie
Progress! I've managed to replace ULA's A3' output. :D I've been looking a lot at the scope picture on this page by Grant, but vexed by the question of when exactly ZX81 ULA grabs character code from the databus.

You see, in the ZX80 RAM sits on the other side of resistors that separate databus signals. The logic can force NOPs on Z80 side of those, while RAM still outputs character code on other side of those resistors. This leaves a (relatively) wide time window in which you can grab (latch) that character code.

But in the ZX81, ULA directly connects to Z80 databus, with ROM and RAM (containing DFILE) on the other side of the resistors. As soon as ULA forces a NOP on the D0~D7 signals, character code on there is gone. This make grabbing that character code much more time-critical. If you grab it too early, RAM hasn't had enough time to output the correct data (in theory RAM access time only starts from when /MREQ goes low) & you get 1's and/or corrupt data. Grab it too late, and you get 0's since ULA has started forcing the NOP.

Tried grabbing bit 0 of the character code on falling edge of T2 (while /M1 and /MREQ are low) - close, but no cigar. Then the rising edge of T2 - again close, but no cigar. Then used 6.5 MHz signal in various ways to try & grab that bit halfway a CPU clock high, or CPU clock low period (yeah I'm aware ULA's clock output is inverted on its way to Z80). Some interesting results, but again no cigar. :evil:

Finally I routed (/M1 and /MREQ) signal through an external RC delay, and used that to clock D0 into a flipflop (temporarily using /RFSH to output grabbed data onto A3' pin). This did the job, but only within a very narrow range of RC: with C=180 pF, R needed to be in 680-850 Ohm range (dunno exact delay, it depends on the CPLD's I/O characteristics). Which confirms to me there's a very small time window to grab correct character code from the databus.

Anyway, I think this was about the hardest part to get right & other things on the TODO-list are less time-critical... So in terms of difficulty, I might be over the hill. :D Meanwhile, my '2nd video output' is slowly starting to look like a normal screen - mostly white border, black screen with white 8x8 blocks depending on character that's there.

Doing all this with ULA still attached makes some steps more difficult than necessary - but it also makes sure that my logic is doing the same things @ the same time the ULA does them. And you have a functional ZX81 at all times, while taking small, known-working steps.

To be continued...

Re: Houston, we have an image!

Posted: Thu Nov 10, 2011 10:23 pm
by Andy Rea
told you it was tricky... Congratulations :)

it can be done without resorting to external RC networks, drop me a PM if you want some pointers.

Regards Andy

Re: Houston, we have another image!

Posted: Thu Nov 10, 2011 10:53 pm
by RetroTechie
Yeah I know - this is one part which would have been easier without original ULA running side-by-side. Point is I'm inputting 6.5 MHz into that ULA, but can't say for sure what ULA does with it internally until it comes out as /CPUCLK - read: the clock signals I have available inside the CPLD aren't exactly synchronized with ULA's internal clock transitions.

If the CPLD was the sole part generating all signals, I would have more freedom in moving signal transitions back or forth - right now I don't have that 'wiggle room'.

Thx for the offer but I'm good... ;) It's all part of producing something you understand ! Again my 1st priority is get rid of original ULA - @ that point things should get easier.

Re: Houston, we have an image!

Posted: Fri Nov 11, 2011 12:31 am
by zx80nut
Hi RetroTechie.

You have an interesting issue there.
The ZX80 has connections either side of the resistors, so can grab even though the data bus has been driven low...
Hmm....
Go on, Andy, put us out of our misery ;)

Re: Houston, we have an image!

Posted: Fri Nov 11, 2011 12:43 am
by Andy Rea
it's all about timing....