Before responding to your question,
MarkI wanted to verify my implementation of PokeMon's circuit is OK. Having scoped it a bit, I'm not so sure it's behaving as intended.
Quick theory recap:
Code: Select all
00.. .... .... .... ROM 0000
01.. .... .... .... RAM 4000 - normally the onboard 1K
10.. .... .... .... ROM 8000 - normally the unused shadow ROM, so this is what to detect
11.. .... .... .... RAM C000 - shadow of 4000, where M1 cycle triggers forced NOPs while reading real "opcodes" as video data
OK now on to testing. This was on the modified ZX81 with the K cursor just sat there i.e. nothing is being asked of the 16K RAM pack that is in essence just sat there powered up presumably refreshing a whole load of nothing.
Here the upper yellow trace is pin 2 i.e. A14 off the board, while the lower cyan trace is pin 3 i.e. /A15 off the board. If you mentally invert the cyan one, these signals seem to be following each other i.e. either both inactive (reading ROM?) or both active (reading RAM for video). This makes sense given that the computer isn't running a program: that would provoke more non-video use of RAM i.e. yellow changing, cyan not.
The the result generated by the 74LS02 (which remember is a NOR IC - if both inactive then active, otherwise inactive) is as follows:
This isn't right: the yellow line in the lower image should be flat inactive because when just sat there with a K there is no attempt to access the RAM pack memory at $8000..$BFFF i.e. there's no "10.." like in the above table.
When I did further scope analysis, there seems to exist a moment when both inputs are logical 0 due to:
- A 0 from the slightly delayed rising edge of /A15, the output of NOR gate b which is an inverter of the falling edge of A15 i.e. when going from shadow RAM to RAM. This line is busy of course because while sat there with just a K on the screen, the video system is still busy.
- A 0 from the falling edge of A14 i.e. when going from RAM (shadow or normal) to ROM.
This is way beyond my electronics expertise. How to get rid of the spurious output please?
That being said, I had a moment of inspiration (something Mark wrote earlier I think) and ran my simple program in FAST mode...
Code: Select all
10 POKE 32768,2
20 PRINT PEEK 32768
30 GOTO 10
With this, I got nice waveform outputs as expected from the whole system - yay. (I also got a screen-full of 255s
) And this makes sense. In FAST mode there's no video so there's none of those pesky edges listed above causing the spurious edge. Yes this is a kludge, however I'm being transparent about it!
Requested signals off RAM pack ULA IH035E:
- Pin 9 = inbound A14 from this circuit is as expected - in FAST mode, it's active when accessing 32768. So this signal is behaving as expected i.e. it occasionally goes HIGH representing that access to 32768.
- Pin 14 = select signal to the 74LS157. When not running the program, this signal is busy active/inactive - makes sense if nothing else for the refreshing going on. When the program is run, there is also busy active/inactive. However when pin 9 is HIGH, select is LOW for the entire pulse i.e. selecting A8/A7/A10/A9 as the lower 4 bits. It doesn't however flick over to HIGH to multiplex the other half of A1/A0/A3/A2 in.
- Pin 15 = CAS... my nemesis. No matter whether the program is running or not, it just floats high.