Houston, we have an image!

[PokeMon]

Also /RFSH is not /M1 inverted even though it may look that way in the small time window above.

I know the datasheet from ZILOG and all timing diagrams. Of course is /RFSH not really inverted /M1 just as simple to describe regarding your picture and of course I know that /RFSH is used only during second half of /M1 cycle.

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.

/RFSH go down about 130ns when T3 start - in datasheet given as signal (21) "clock up to refresh down delay"
address data is valid about 110ns when T3 starts - in datasheet given as signal (6) "clock up to address valid delay"
The nop code for the CPU is read exactly when T3 starts (clock going up and data has to be valid 35ns prior and about 85ns after) - signals (14) (15) (16)

So there is no overlap of these signals. From the timing diagrams it is assured that refresh address is valid when /RFSH goes down and this happens after data (NOP) is read. Anyway this NOP is overridden from the ULA and the normal ROM is active during this time. The datasheet describes in section refresh that the refresh address is valid when /RFSH and /MREQ are down together but this seems to be a little bit imprecise. The timing diagrams go more in detail.

Anyway I could try to just extend the /MREQ during /RFSH and not activate the ROM the full refresh time but I think this is not really sufficient for the ROM to present the data read from ULA (character table). /MREQ is only short period low, timing diagram says about 220 ns - signal (11). I have not much information about the ROM (ZCM38818P from Motorola for example) about access time. I think it maybe has an access time of 300ns but not really sure about it. So maybe it is not long enough. Okay when I extend the signal about 100ns more it could get into that time range.

So the point is that I don't know how /ROMCS is generated internally during normal opcode fetch and thought it maybe is activated when /M1 go down. Address is valid same way as for refresh (same timing delays of 110ns for address and 130ns for /M1). Because the ULA want to read data from ROM when clock go down in the middle of T2. So data has to be valid after 308ns - 85ns delay of /MREQ so this is only about 220ns.

So maybe the problem is more about that point when creating /ROMCS only with /MREQ.

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.

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:

I know that ROM is mirrored in address area $8000-$BFFF or at least for $8000-$9FFF. Anyway, due to ROM activated from $8000 upwards memory can not work there. That's the reason for my post, you remember I asked for a way to disable ROM in this area ?

I don't think it's suitable to just have one "select signal" for ROM and RAM and just decide which you want with the address value. As I know from the traces from zx80nut, the ROMCS is extended during video display in refresh phase but NOT during normal opcode fetch. I think there is a reason for that because it would be easier to always extend this signal. On the other hand, just deriving /ROMCS from /RAMCS did not work either. And I don't want to make a complex address decoder logic for the ROM in my RAM extension, I just want to avoid to be present when A15 high with minimum effort. Maybe a R/C combination could work. I will try out.

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

I am using a 128k static RAM but only wired as 32k RAM. Adresses from A0-A14 are connected only. So the upper 16k RAM is selected first (with A14 high) from $4000-$7FFF and the lower 16k RAM is selected after (with A14 low) from $8000-$BFFF. Anyway it worked before when /ROMCS created without extending it with /RFSH - but it was not very stable.

So my last question again, what is typicall access time of ROM used by Sinclair and is it possible that ROM is activated when /M1 go down ?
Because the time for reading from /MREQ down to clock down during T2 (when ULA samples ROM data) is only about 220ns ???

[RetroTechie]

And I don't want to make a complex address decoder logic for the ROM in my RAM extension, I just want to avoid to be present when A15 high with minimum effort.

Should be simple enough. I think you have basically 2 strategies to choose from:

• Disable the internal ROM always, except when it should output data. Which may involve re-creating a 'copy' of internal /ROMCS.
• Disable the internal ROM only when the external RAM outputs data.

Really I have no idea what's the easiest choice, what path produces the simplest logic, or what works most reliable. But it should be obvious that above choices may produce different logic, and differences in how well it works.

Another tip: you may want to get this disable-internal-ROM logic correct first, until you have a system that a) works 100% reliable, the same as a factory ZX81, and b) no ROM data to be found in 8000-BFFFh area. And only then work out how to get RAM working there. That way the "disable internal ROM" and "make external RAM work" become 2 independent problems you can solve separately.

I don't think it's suitable to just have one "select signal" for ROM and RAM and just decide which you want with the address value. As I know from the traces from zx80nut, the ROMCS is extended during video display in refresh phase but NOT during normal opcode fetch. I think there is a reason for that because it would be easier to always extend this signal.

You're missing the point here. In my ULA clone, /ROMCS also is only extended during DFILE execution. But the important thing: exact same timing is applied to /RAMCS in that case. /ROMCS follows /MREQ for regular instruction fetches (and normal read/writes). The same goes for /RAMCS. Point being: I make no distinction between /ROMCS and /RAMCS timing-wise, that's decided by "DFILE execution or not". Whatever timing tricks are applied to /ROMCS (or not!), are also applied to /RAMCS. Address line(s, well just A14 in my case) only decide which of the two goes active.

This makes that whenever you have regular ZX81 display working reliable, true Hi-Res (=pixel data from RAM instead of ROM in the case of regular ZX81 display or pseudo Hi-Res) will also work. Added bonus is that /ROMCS and /RAMCS never overlap. It's just a way of producing these signals, that's easier to modify when you want to change the memory map.

Maybe a R/C combination could work. I will try out.

If you check out Sinclair's 16K RAM pack schematic, you'll see there's some RC delays in there. Necessary for timing /RAS-multiplexer-/CAS sequence, but also has the effect that /CAS (effectively a chip select) is trailing behind /MREQ and /RD signals. Maybe that doesn't matter, maybe it does.

Also keep in mind that original memory chips are rather slow. Response to a /CS change will take some time (and there's trace capacitance). Newer memory chips may enable/disable much faster. Which is usually what we want, but can also be the cause of problems. Again: might not matter. But a good thing to keep in mind.

[PokeMon]

• Disable the internal ROM always, except when it should output data. Which may involve re-creating a 'copy' of internal /ROMCS.
• Disable the internal ROM only when the external RAM outputs data.

Really I have no idea what's the easiest choice, what path produces the simplest logic, or what works most reliable. But it should be obvious that above choices may produce different logic, and differences in how well it works.

I thought a little bit more about it and found it is better to only disable the internal /ROMCS when not desired instead of recreating.
In that case it would work better with some other external solutions (compatibility) which override /ROMCS for their needs, for example to provide add on ROM code or fully replaced ROM. These would maybe disable /ROMCS fully or partly and could be more compatible. If I create a complete own /ROMCS signal it might collidate with /ROMCS provided by another "party".

[PokeMon]

Today I made it. Now RAM works at $8000-$BFFF with just disabling internal ROM when A15 high.
So maybe was a little bit confused last time during several unsuccessful tries.
Before I had disabled ROM always when enabled RAM but this wasn't successful, maybe due to enable RAM during full refresh period.

Maybe there is a collision between enabling ROMCS from ULA first and disabling it when RAM selected which could give short enable pulses which possibly could confuse ROM during further access.

Now I enable RAM with A14 or A15 high and either /MREQ or /RFSH.
Works perfect and no "extension" of /RAMCS neccessary because it is enabled during whole /RFSH period too.
ROMCS is untouched except disabled by pulling it high when A15 high.

[sirmorris]

Congratulations!

[PokeMon]

Yes but now the next construction site is ahead.

I have to train my ZX81 to enable all RAM during RAM test to avoid manually Poking 16389,192.

[Paul]

So you only need to patch one bit in the ROM
Too bad you need to pull it high instead of low. That would be much easier.
The question also is wether you want to be able to select wether you want ramtop to be 128 Or 192 by pressing a key while booting. That would be a nice gimmick specially if it s compatible with the selection of the rom by pressing a key.
Once you are at it, you could detect wether you want ram from 8 to 40k or from 16 to 48k.

[PokeMon]

It's both more simple and more complex same time.
You don't need a changed ROM at all.
You just need to disable ROMCS for a short moment when reading address $0005.
Then the internal pullups of databus will take action and deliver $FF instead of $7F or the Z80 will understood LD BC,$FFFF instead of LD BC,$7FFF and do a full RAM test from $FFFF to $4000 backwards and forwards.

I try to use as less components as necessary - maybe use a NE555 triggered with RESET and appropriate R/C values.
Could use a counter as well but needs some additional logic.
I am thinking of it.

I don't want to use a GAL and I don't want to use a switch for that purpose.

[PokeMon]

I decided to post my latest ZX80 problem here as it would maybe get more attention from the hardware people and ULA specialists.

I have some problem with one RAM type 6116 in my ZX80CORE (ZX80 replica board) which causes display problems.

zx80core_memtest2k1_s.jpg (80.17 KiB) Viewed 3584 times

This is the resulting screen:

zx80core_memtest2k3_s.jpg (231.51 KiB) Viewed 3584 times

So the problem is:
The bad displayed lines are not always displayed bad, depending on screen content. Could be other lines as well, could be no lines at all like the following result screen when entering PRINT USR(16514):

zx80core_memtest2k2_s.jpg (153.93 KiB) Viewed 3584 times

And there are no problems when using follwing RAMs instead:

6262 (8k x8)
62256 (32k x8) 16k available/usable only
2114 (1k x4)

I thought it could be a timing problem because the 6116 is quite slower with 120ns access time while 6264 or 62256 have 70ns. But I think it couldn't be a matter of 50ns more or less as the 2114 RAMs are much slower (use 450ns version with no problems at all). Of course they are different controlled because they do not have an /OE input, only /CS.

The /OE is or-wired with two schottky diodes (BAT46). Maybe this could cause timing problems, not 100% sure.

As the ULA / FPGA friends here did a lot of work (andy,retrotechie) they maybe know this behaviour and what part of timing is wrong or where to screw to correct the timing. I use original ZX80 logic/schematic except using other ROMs and RAMs.

So when the picture is bad like it is sometimes, is it wrong content in the shift register or maybe access problem of the rom character generator or what do you think ?`

[PokeMon]

Here is a part of schematic controlling ROM / RAM access.
R94 changed from 10k to 3k3
R95 changed from 2k2 to 1k
both changes with no result

schematic.jpg (97.16 KiB) Viewed 3585 times

And the complete schematic attached if needed.

ZX80CORE - Schematic.pdf

(260.17 KiB) Downloaded 261 times