Houston, we have an image!

[PokeMon]

Here I have some scope pictures attached with comments.
First I have to say that I was right in my guess, that RAMCS is not set low when MREQ goes low but directly when A15 is high and M1 is low.
At least during video display routine (I did not check during normal RAM access).
This gives a timing advantage.

IMG_3757k.jpg (180.67 KiB) Viewed 9376 times

IMG_3758k.jpg (165.71 KiB) Viewed 9378 times

IMG_3759k.jpg (162.32 KiB) Viewed 9377 times

[PokeMon]

In the picture below you can see RAMCS during video display routine, which is exactly identical to A15 (inverted) or M1, so it's a logical OR with inverted A15 signal. This reflects the problem with executing code in upper memory area above 0x7fff and the so called M1 modification to fix it.

The last picture shows the dataline D0 which gives a good idea of what's happening. The slow rise of D0 is caused of the 10k resistors with unwanted capacities of about 10 to 20 pF which gives a T of 100 to 200 ns. The point when D0 goes low is the point when data on the RAM is ready and valid which will pull to low very fast. So the access time is someting between 250 and 270 ns. This means data is ready to read. Unfortunately you cannot see when ULA pull the signal low in this picture because it is already low.

IMG_3761k.jpg (152.89 KiB) Viewed 9366 times

IMG_3762k.jpg (159.85 KiB) Viewed 9365 times

[PokeMon]

No wonder I had so much trouble pinning down the exact moment to grab the data - this would be so much easier if original ULA is gone & you can determine yourself what happens on the bus, and when. Also these new scope pix seem to suggest that /RAMCS indeed uses /MREQ signal.

I don't know where you can see this on the pictures of Grant because he did not show the RAMCS signal.
And it's really not interesting if the original ULA forces data lines low, give it up to read something and then forces it low again.
The CPU reads the opcode with rising edge of T3 and datasheet shows that this signal has to be valid 35ns ago. Nobody counts what is 100 or 200 ns before, especially the CPU does it not.

I think it's very easy to adapt the character reading because you don't have to rebuild the old ULA timing but can do your own timing.
So I would just read data from RAM with rising edge of T2 and pull data lines low with falling edge of T2.
Or if you can use the 6,5 MHz clock could read in the second half of T2 high and pull down in the second half of T2 low.
I wouldn't do anything with resistors and capacitors to delay signals.

[zx80nut]

I've knocked up a quick circuit so that I can trigger the scope on the active display part only - an LM1881 triggering a simple R/C slope, with a dual comparator used as a window comparator on this ramp output. The output of the window comparitor is then anded with the csync out on the LM1881 so that I only get HSYNCS on the active part of the display. This can then trigger my scope (which is a delayed sweep) to pick up the active NOP execution on the DFILE.

I've also captured the ZX81 ROM CS and RAM CS during this.

I'll upload these cleaned scope pics tomorrow (much too late now).

Sneek preview here...

OpcodeFetch.jpg (44.13 KiB) Viewed 9331 times

As you can see, with this narrowed window on the triggering of the scope, the traces are now clean.
Top trace - Data at ROM/RAM
2nd trace - NOP'ed data at CPU (you can clearly see the double NOP when compared to top trace)
3rd trace - RAM CS
4th trace - ROM CS

The grid is the same as my previous pic (centre line start of T3, each grid is half a T-state), if you want to match these up to the T-states. However, I will do a full annotated pic and upload it.

Bye for now.

Grant.

[RetroTechie]

I don't know where you can see this on the pictures of Grant because he did not show the RAMCS signal.

I was guesstimating based on /MREQ low -> databus changing delay (assuming ULA logic responds quickly). Looks +/- 100 ns, which wouldn't be unreasonable response time for a RAM chip. If A15 is used to decode /RAMCS signal (and not /MREQ), then there's much more time for the RAM to respond - and perhaps ULA captures data earlier too & this 'bump' in forced NOP-period is a 'glitch' that isn't actually used to grab data.. ? Who cares as long as you grab correct data...

I wouldn't do anything with resistors and capacitors to delay signals.

Totally agree... as soon as original ULA is gone, it should be much easier to try changes like in what's discussed here. Right now I'm just using whatever hacks help me get rid of original ULA as soon as possible, in order to get to that point. The only other route is ditch ULA right now, which would force me to design / test the remaining logic on a non/half-functional ZX81. Don't feel like doing that (but that's really just personal preference). Or I could grab eg. Andy Rea's Verilog code as a shortcut. Which I want to avoid - the more I do piece by piece myself, the better understanding I get of the whole...

So I would just read data from RAM with rising edge of T2 and pull data lines low with falling edge of T2.

I'm tending to try & use the same clock edge (eg. falling edge T2) for that purpose. Like I said, a modern CPLD or FPGA can clock in data with practically 0 hold time. So if you start forcing NOPs onto the databus at the same moment, the grabbed data is long captured & safe by the time databus logic levels actually change.

Or if you can use the 6,5 MHz clock could read in the second half of T2 high and pull down in the second half of T2 low.

I prefer to use clock edges of the actual Z80 clock, as it avoids the need for double-frequency clock signals. Probably doesn't matter much, but IMHO the fewer (clock) signals a design depends on, the better.

[zx80nut]

Hi.
I've now updated the real ZX80/81 timing pics
http://home.micros.users.btopenworld.co ... ePics.html
Please refresh your browser page to see latest (it will show "Last update: 12th November 2011" near the top)

Regards.

Grant
http://home.micros.users.btopenworld.com

[PokeMon]

OpcodeFetch.jpg

As you can see, with this narrowed window on the triggering of the scope, the traces are now clean.
Top trace - Data at ROM/RAM
2nd trace - NOP'ed data at CPU (you can clearly see the double NOP when compared to top trace)
3rd trace - RAM CS
4th trace - ROM CS

The grid is the same as my previous pic (centre line start of T3, each grid is half a T-state), if you want to match these up to the T-states. However, I will do a full annotated pic and upload it.

Hi Grant,

thanks for your pic but is this a ZX80 or ZX81 scope picture ?
I have a difference in RAMCS (measured on a ISS3 board).
In your picture RAMCS is about 1,5 clock cylce, in my scope picture I have exactly 2 clock cycles, T1 and T2.
So I wonder how your scope can be different.

By the way I checked your website and maybe I can not see the NOP forces on the databus because I have an empty DFILE with only HALT instructions and the K cursor in line 24. I just measured after startup with 1K version. I didn't build any trigger logic, just triggered on A15 high which is not very accurate but gives a good look whats happening on the bus because A15 is only high during display period.

[zx80nut]

Hi.
These are ZX81 traces from an issue 1 PCB.
The DFILE is fully expanded (a screen full of characters on a 1K machine), and I am running FAST mode (don't need to now that I am using an LM1881 circuit to block non-display areas).

The lines above and below the active display area are blocked from display on the oscilloscope using the LM1881 / ramp / window comparator circuit that I knocked up.
...haven't tried using A15, but that is an interesting/good/easier idea

The scope timebase is locked onto the hsync from the active display lines, and delay-swept to pick up the NOP execution area of the screen.

BTW. This board is running R E A L L Y S L O W L Y this evening - has the server been upgraded to 16K ?

RAM CS shouldn't be just on address - should also be when MREQ is low, which is what is happening on my machine. Maybe there is a change made for Issue 3 - I will need to open up one of my other ZX81's to check.
[Edit: 13th Nov - no change, same as issue 1 - see below]

Regards.

Grant.

[zx80nut]

I've just checked an issue 3 ZX81 ULA and the scope pictures are the same as the issue 1 ZX81 ULA.

Pokemon, please check if you are checking the correct pin. RAM CS is definitely, 100%, as shown above for both issue 1 and issue 3 boards.

The double-NOP, RAM CS and ROM CS are identical between issue 1 and 3, so there doesn't appear to be any ULA changes in this area between the two versions.

Regards.


Grant.
http://home.micros.users.btopenworld.com

[PokeMon]

Hmmm. Checked it again.
I don't know why but now it's like Grant described.
I think the timing could work anyway with reading data on rising edge of T2 but timing is very strong.