Houston, we have an image!

Any discussions related to the creation of new hardware or software for the ZX80 or ZX81
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 »

You only assume that the discrete logic of the ZX80 has been packed into the ULA without any modifications.
I don't assume that at all ! But as they had a working design, then why bother trying to alter much of it with very short timescales?

We could go on forever on this, but I maintain that it is pointless them extending the CS if there is no need and it also fits in with the ZX80 strategy.

But found some more complicate stuff. As studied schematic of ZX80 the Shift/Load is low under following conditions:
"Video display=1" which is build with /HALT=1 & A15=1 & D6=0
/MREQ=1
system clock=0 (the clock to this logic has to be "1" but is mirrored with the system clock of cpu)

This condition can occur 2 times in refresh cycle, during T3 low and during T4 low. During T4 low is sure, but could be during T3 low depending on cpu timings. So not a 100% stable condition in my eyes. And it's not clock based, its simply enabled as long as condition met.
No, it doesn't as you will see my scope pictures for IC9 Pin 1- it ONLY loads once at the start of T1.
http://searle.hostei.com/grant/zx80/zx80ScopePics.html

Grant
User avatar
1024MAK
Posts: 5118
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: Houston, we have an image!

Post by 1024MAK »

If you are interested in the Ferranti ULA's, this is interesting: http://www.worldofspectrum.org/forums/s ... post505141 (World of Spectrum forums).

Mark
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp

:!: Standby alert :!:
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer later in the year.
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

zx80nut wrote: No, it doesn't as you will see my scope pictures for IC9 Pin 1- it ONLY loads once at the start of T1.
http://searle.hostei.com/grant/zx80/zx80ScopePics.html

Grant
I saw that Grant, but couldn't find corresponding hardware in the ZX80 schematics.

As I wrote:

As studied schematic of ZX80 the Shift/Load is low under following conditions:
"Video display=1" which is build with /HALT=1 & A15=1 & D6=0
/MREQ=1
system clock=0 (the clock to this logic has to be "1" but is mirrored with the system clock of cpu)

So pin 1 IC9 is connected to a nand gate.
This does go active low when /MREQ=1, executing video code (pin 6 IC16 buffered during T1/T2 and inverted) and cpu clock low (inverted cpu clock feeded into that nand gate).
I think this circuit arrangement can not produce your scoped picture. :shock:

During refresh and video display, executing video code is steady high during this process.
So IC9 will latch data into shift register when /MREQ=1 (inactive) and cpu clock=0.
Maybe there is someting wrong with the schematic but I am certainly sure that the drawn circuit/logic will not produce this short pulse at that time.
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

Okay - correct it now.
The schematic has in some way a crazy design.
Did miss the R/C combination C11/R25 and the inverters at the inverted flipflop output. :roll:
So this circuit produces a short pulse of about 30ns on risign edge of cpu clock and in that way you are right, data will be loaded into shift register at the beginning of T1 which is the only phase where /MREQ=1 at rising edge of clock.

But still not convinced that this is exactly done in ULA of the ZX81.
So lets continue this discussion when I have tried it out, feeding different data at falling edge T4 and rising edge T1 in the black box (ULA) to see the difference. ;)
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 may or may not be done exactly like that in the ULA but..... tests have shown that pixels shift to the left if video data is loaded into an 8bit shift register sooner that the rising clock edge of T1 of the following m-cycle...

with limited real esate in a what is a fixed array of gates that can be hardwired togther to form a final chip (the ULA) then every non- esential step is going to be removed.

way back when the zx80 was developed they would have been looking at ways of reducing chip count, so every trick they knew would have been employed that includes making the logic hard to follow. and throwing in the odd RC timing constants....

the best way of getting to know the exact in's and outs of the ULA video generation is to build a ula yourself, it's possible to do it with ttl (21 chips i used) GALS 6 + a ttl shiuft register, or CPLD.... by taking the parrallel approach that retrotechie took you can see things work side by side. and can easily compare signals.

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:

Why are bananas yellow?

Post by RetroTechie »

PokeMon wrote:Nobody did explain this at all. What is the reason for not enabling the ROM during /RFSH in same way regardless if video output or not ?
As for the WHY: how would anyone know? (for sure, that is). A "why" is not something you can observe. Perhaps even original designer(s) forgot why they did things the way they did it. IMHO that's a bit like arguing about why bananas are yellow... one can figure out what happens, how it happens, but the why is just speculation (and will likely remain so).
And why and for what is /ROMCS needed during refresh cycle when not outputting video data ?
It isn't. Outside DFILE execution, data that the ROM (or even RAM for that matter) outputs during refresh, isn't read by anything so it goes nowhere.
If it's handled in a different way they could even suppress it.
True. Oh wait, as far as we know that's exactly what happens in a ZX81 (as stated somewhere in the beginning of this thread). :shock:
You only assume that the discrete logic of the ZX80 has been packed into the ULA without any modifications.
True (if one ignores differences between ZX80 and ZX81 logic). However: that particular assumption is very strongly supported by observed behavior. Yes, it's still an assumption (and will remain so until someone decaps a ZX81 ULA and re-creates the logic by following silicon traces). It's also a case of "all evidence points in the same direction". In that way, current understanding of the ZX81 ULA's function is much like a scientific theory: it can't, and won't ever be proven as 100% certain. But you can keep collecting bits of evidence supporting or undermining that theory, and update / refine it as you go. As long as there's much in support & little or nothing to disprove it, accept as "that's how things are". When there's something that clearly disproves the theory: show it.
But there are modifications, not just NMI. For example (..)
Ehm... yes. A ZX81 is not a ZX80, and the logic inside a ZX81 is not (100%) the same as the logic inside a ZX80. We already knew that.
The reason for no /RFSH at ULA pin could be that all other ULA pins needed. And they were not willing to pay for a 42 pin DIP case. :mrgreen:
That would be my guess. IC pins are extremely expensive (even more than custom logic). :P
Okay - correct it now. The schematic has in some way a crazy design. (..) But still not convinced that this is exactly done in ULA of the ZX81.
In a way, the ZX80 works more 'analog' in some places, where plain flip-flop(s) or logic gates will have been used in the ZX81 ULA (at least very likely, as RC delays don't lend themselves well for integration in a custom IC). But in the end, all digital logic is analog too. So the only thing that really matters is the net effect. As long as we don't know exacly what's inside a ULA, the best you can get is not "something that works the same as a ULA", but "something that shows similar external behavior", or "something whose behavior produces the same net result". A 'model' that represents ZX81 ULA function.
Andy Rea wrote:the best way of getting to know the exact in's and outs of the ULA video generation is to build a ula yourself
Well it's a very good way. Personally I'd prefer the "decap & follow silicon traces" method. The decap is doable, but I'd be totally lost at the "follow silicon traces" part... :mrgreen: (I have a microscope, but that's no use if you don't know what you're looking at - bipolar transistor, FET, resistor, via, supply connection, ..., or what -for example- a NOR gate looks like in silicon).
by taking the parrallel approach that retrotechie took you can see things work side by side. and can easily compare signals.
Unfortunately, not quite. Signal transitions will relate to clock edges somehow. Those clock edges are generated inside the ULA by an oscillator, which is inherently an analog circuit. Externally it's possible to observe signals changing as a result of those internal clock transitions, but not exactly when those internal clock transitions occur.

Single-stepping the ULA's clock might fix that. Unfortunately I didn't manage that since the ULA clock pin is not a simple logic input, but a pin that's designed to tie into a ceramic resonator circuit. And if single-stepping the ULA's clock were possible, you'd be observing static behavior (and thus ignoring short delays / dynamic behavior as in full speed operation). So you can do a lot, but ultimately you're still stuck with the "black box" problem. :evil:
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

The reason for all (question about timepoint of reading video char data from ROM) is just to be sure that my memory extension can be designed my way and will work with any ZX81. And as always I don't do it right for myself but plan to bring some memory extensions to the market, similar like Sinclair did with the 16k but without wobbling (which is caused from that memory extension itself and not from the edge connector). And with a nice and small case.

As it works with my Zeddy I want to be sure that it's not a fortunate coincidence. Will go deeper into that question soon but will definetely not develop a new ULA. That's really not my approach.
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

RetroTechie wrote: What's more surprising, is that true hi-res actually works with the SRAM connected as described. Timing-wise I'd expect that to fail. I suspect that @ the time the ULA reads the pixel data, the databus is actually floating but somehow still holds the correct data. Maybe the few pF's trace+input capacitance is enough, and 10K resistors pull the datalines high, but not fast enough to make that read fail... :? :?: If anyone has a better theory: please share! :lol:
Maybe you are right in that point. Today continued with my memory extension and found out, that the picture of a sw-hires is not very stable. When I put it a few minutes in the fridge at -18 degree C it's working shortly. But the more it is getting warm, the less stable is the picture. So I will modify the control that way, that data could be read at rising edge of T1 when using hires and stretching the /CS. :P
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon »

RetroTechie wrote:Hi PokeMon,

Have you checked documentation with my ZX81 ULA project? There's a similar 'scope' picture in it which may explain a lot:

Image
First, there seem to be an error in your timing diagram. I think refresh signal has to be inverted (opposite of /M1).

Today I worked on my external memory extension. Had some trouble when trying to disable the internal (mirrored) /ROMCS for addresses over th first 16kB (disabling from $4000 up).

But first want to discuss the circuit all in all.
So now I have the RAM enabled with following signals:

signal /RAMCS=(!(A14 OR A15) OR (/MREQ AND /RFSH)

CS2=high
/CS1=/OE=/RAMCS

This works fine except the memory is not available above 32k ($8000 up). I have a 32k RAM which should work from $4000-$BFFF. The area $8000-$BFFF is not working due to ROM shadowed in this area. But the RAM access is working very fine with different programs including HIRES from b0d0 like testbild.p or 25thanni.p - so there seem to be no problem from that side.

Regarding disabling /ROMCS I tried first to disable /ROMCS internally and to rebuild it similar to address logic above:

signal /ROMCS=A14 OR A15 OR (/MREQ AND /RFSH)

This doesn't work because the /ROMCS is stretched with this easy logic always (during video display and during normal ROM execution).
When I don't stretch the signal with /RFSH I have sometimes trouble to see a valid picture - that was the situation earlier.

I tried next to disable internal rom only when accessing memory above 32k (A15 high) and leave internal /ROMCS signal for access. This wasn't successfull as I need power to drive the signal up. The LS gates do no deliver much output power in high state so I tried to use a 74HCT gate for it and wired a diode in the connection output to internal /ROMCS. So /ROMCS is disabled when A15 goes high. This didn't work at all - I think it's because the used diode BAT46, think it's not fast enough and there are possibly timing problems then. Maybe also internal capacity or need some time to switch on/off with low currency (about 5 mA I think).

I maybe could try a tristate HCT gate which could deliver the needed power to bring up internal /ROMCS high and which could be simply switched off when not needed. But I am not 100% sure about it and don't have such a tristate gate by now.

Maybe anybody has some idea to disable internal ROM for upper memory (above 32k only).
I am not sure, if the internal ROM is enabled only with /MREQ and extended only during /RFSH. Could be that the internal ROM is enabled during /M1 prior to /MREQ ? I tried to measure it out with my scope but found out, that /ROMCS directly follows /MREQ and also found out that it is extended with /RFSH during video display period. But maybe it's not measured exactly and I triggered only the video display period. Not 100% sure about it.

So maybe anybody has some more ideas to realize switch off mirrored internal ROM.
Thanks.
;)
User avatar
RetroTechie
Posts: 379
Joined: Tue Nov 01, 2011 12:16 am
Location: Hengelo, NL
Contact:

Re: Houston, we have an image!

Post by RetroTechie »

PokeMon wrote:First, there seem to be an error in your timing diagram. I think refresh signal has to be inverted (opposite of /M1).
Nope, "rfsh" in above picture is just a signal internal in my CPLD (actually: "m1_cycle_T3" and "m1_cycle_T4" ORed), not Z80's /RFSH signal. Timing is similar though hence the name. Also /RFSH is not /M1 inverted even though it may look that way in the small time window above.

IIRC, the /RFSH signal isn't very suitable for extending /CS signals, simply because it's too long (roughly 2 clockcycles). Too much opportunities to interfere with other events, like the point where the Z80 samples the opcode (white arrow below "NOP") or address lines changing from Program Counter to bits from I register. That's why I used signal "forced_NOP_T4" for this purpose, which is only 1 clockcycle long, and doesn't go active before /MREQ does.
So now I have the RAM enabled with following signals:

signal /RAMCS=(!(A14 OR A15) OR (/MREQ AND /RFSH)

CS2=high
/CS1=/OE=/RAMCS

This works fine except the memory is not available above 32k ($8000 up). I have a 32k RAM which should work from $4000-$BFFF. The area $8000-$BFFF is not working due to ROM shadowed in this area.
It's not possible that internal ROM and external RAM are enabled simultaneous sometimes, is it? :?: That might explain RAM not working in 8000-BFFFh even though it appears to be selected there?

Note that original ZX81 doesn't decode A15 for /ROMCS and /RAMCS, only A14. So memory behaviour for 8000-FFFFh is an exact mirror of behavior for 0000-7FFFh range. A15 only affects how the ULA interprets what's going on, and if/what data it grabs from the bus. :idea:

What I learned from getting true Hi-Res to work properly on my ULA clone, is this:

Don't regard /ROMCS and /RAMCS as 2 signals that should be independently built from address and control signals. Instead, try to create one "/ROMRAMCS" signal (like output of the OR gate in picture below), and use upper address lines A15, A14, and perhaps A13 (and ONLY those address lines!), to decide which of /ROMCS or /RAMCS gets activated. That way it's easier to change the memory layout, and you avoid /ROMCS and /RAMCS overlapping due to mistakes. See memory decoding in my ULA clone:
Memory_select.png
Memory_select.png (1.76 KiB) Viewed 3052 times
It should be obvious that changing the memory layout, without touching the timing of /ROMCS and /RAMCS that comes out, is easy here. The "stretch" input is this "forced_NOP_T4" signal mentioned above. Probably not easy to recreate in an external RAM extension - I'd try the simplest possible ways to decode /CS signals, and if needed a small capacitor in a strategic place or two... ;) Not an elegant thing to do for an ULA clone, but should be okay for an external RAM pack.

Of course in this case "/ROMCS not active" should read "force /ROMCS signal on edge connector high" so that the internal ROM goes hi-Z.

What RAM chip(s?) are you using, and how do you have highest address lines on those wired?
Post Reply