Houston, we have an image!

Any discussions related to the creation of new hardware or software for the ZX80 or ZX81
Post Reply
User avatar
RetroTechie
Posts: 379
Joined: Tue Nov 01, 2011 12:16 am
Location: Hengelo, NL
Contact:

Houston, we have an image!

Post 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.
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Re: Houston, we have an image!

Post by sirmorris »

Congratulations!

You must be very proud :)
User avatar
Andy Rea
Posts: 1606
Joined: Fri May 09, 2008 2:48 pm
Location: Planet Earth
Contact:

Re: Houston, we have an image!

Post by Andy Rea »

Excellent, it's a great feeling whne you achieve a big step like this.

Regards Andy
what's that Smell.... smells like fresh flux and solder fumes...
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post 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.
User avatar
RetroTechie
Posts: 379
Joined: Tue Nov 01, 2011 12:16 am
Location: Hengelo, NL
Contact:

no worries...

Post 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.
User avatar
RetroTechie
Posts: 379
Joined: Tue Nov 01, 2011 12:16 am
Location: Hengelo, NL
Contact:

Houston, we have another image!

Post 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...
User avatar
Andy Rea
Posts: 1606
Joined: Fri May 09, 2008 2:48 pm
Location: Planet Earth
Contact:

Re: Houston, we have an image!

Post 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
what's that Smell.... smells like fresh flux and solder fumes...
User avatar
RetroTechie
Posts: 379
Joined: Tue Nov 01, 2011 12:16 am
Location: Hengelo, NL
Contact:

Re: Houston, we have another image!

Post 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.
zx80nut
Posts: 108
Joined: Mon May 23, 2011 2:10 pm
Location: A bit north of Cardiff, Wales.
Contact:

Re: Houston, we have an image!

Post 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 ;)
User avatar
Andy Rea
Posts: 1606
Joined: Fri May 09, 2008 2:48 pm
Location: Planet Earth
Contact:

Re: Houston, we have an image!

Post by Andy Rea »

it's all about timing....
what's that Smell.... smells like fresh flux and solder fumes...
Post Reply