Timing on ROM expansion port / ROMOEH

[fuasn]

Hi all,
i'm currently trying my first steps with hardware on QL (basically tinkering...) and decided to go for the rom expansion port (not the expansion port on the left). What i basically tried is to use a PIC (PIC18F27K42 @ 64mhz) and wired up A0-A15, ROMOEH and D0-D7, then in the PIC simply check (continuously) if ROMOEH is high and then if the address lines are between 0xC000 and 0xFFFF, put some bytes on the databus (kind of simulating a rom with a PIC). I'm having minerva installed (Tk2 disabled) if that makes a difference, no further expansion.

So here's my issue:
As long as i don't drive the databus, there is no issue (but i can't deliver any data then).
When i drive the databus, i get some ram-check errors from minerva (assume at least that's the ram-check). Depending how early i check if ROMOEH is still high (to get back to high impedance) i get consistent errors or just sometimes errors (well quite often actually) ...

My assumption is that this is timing related, also should mention that i had to use a 75hc595 SHR for the databus as i run out of pins, which makes it of course much slower, but i'm putting everything to the SHR latch before enabling the SHR outputs, then in a loop wait as long as ROMOEH is high, then disable SHR output again.

Thus my question to the guru's here:
Does anyone know about the timing here ? how long will ROMOEH be high for a read-cycle, ie how much time do i have to deliver on the databus ? Or someone know's where this is documented, i couldn't find anything regarding that until now. Is it even realistic to do that with that simple software approach (no gal's) including the SHR ?

Or anyone thinks that's not related to timing at all ?

[Peter]

You need a buffer that immediately goes High-Z when ROMOEH becomes inactitve.
Or a much faster microcontroller that under all circumstances does this within about 30 ns.

[fuasn]

thx @peter,

puh, 30ns is quite tight.

[Peter]

I wrote 30 ns, because that is a typical "Chip Enable High to Output Hi-Z" time of ROMs.
In practice, somewhat higher delay should also work, but I don't have time for a calculation.

[Pr0f]

My best advice would be to look at the access times for a EPROM of 250ns as a worst case and aim for 120ns as a best case - as most of the ROM cartidges that were plugged into the back of the QL would have a 27128 chip in them. I am not sure at what point the ZX8301 asserts DTACK to terminate the bus cycle for a ROM access, but the earliest this would happen is on S3/4 of the 68008 bus cycle - there are nominally 8 cycles in the access, and at 7.5MHz that's about 530ns for the complete S0-S8 sequence.

[fuasn]

thx Pr0f,
i guess i'll try if i could statically set something on the SHR and just drive the databus as long as ROMOE is high to see if it would work if i would not have to shift-out, access the mcu ram and so on. if you say 250ns would be the worst case, and 120s best, i could imagine the PIC cycle's are enough if i don't have to shift anything to the SHR, just as a test.
i'm also thinking a bit about the PIC's CLCs, maybe they can help in some way to reduce cycles until output, will see (or some atf20v10 gal i have). my "application" would be some way of a serial i/o between the PIC and the QL. If it doesn't work out i anyhow wanna try the "real" expansion slot. not sure about all the lines there however until now.

[Pr0f]

It's a great pity they took away the parallel slave port device from the PIC range, as that made this kind of thing relatively easy.

[Peter]

if you say 250ns would be the worst case, and 120s best, i could imagine the PIC cycle's are enough if i don't have to shift anything to the SHR, just as a test.

Prof probably meant that you should look into datasheets of EPROMs with such access times. And not that these large turn-off delays were allowed.

[Pr0f]

if you say 250ns would be the worst case, and 120s best, i could imagine the PIC cycle's are enough if i don't have to shift anything to the SHR, just as a test.

Prof probably meant that you should look into datasheets of EPROMs with such access times. And not that these large turn-off delays were allowed.

Indeed - these speeds quoted are the "access time", which includes several timing parameters, address lines are expected to be stable before the ROMOEH get's driven high, and as soon as that happens you should think about getting the data presented on the QL's data bus ready for the ROMOEH to go low - this is when the data will be latched by the processor

[Peter]

[...] this is when the data will be latched by the processor

Yes, but wrong data from the access itself is the smaller problem here. Apparently the microcontroller does not release the data bus quick enough after the access is over, driving output vs. output. Which can even do physical damage in the long run.