Z80 - reading from memory
ZXNet echo conference «hardware.zx»
Hello, All
So I look at the temporary reading memory and grow dumb. I understand correctly that
Can the actual data on the bus be raised by the fall of the third period? A
Can I use front /MREQ + /RD for this? Not enough time, in the Z180 even more.
Hello jdigreze
jdi> Apparently, you understand correctly. And on the front /MREQ and /RD
jdi> this is not worth it, as you risk catching “something” during the transition
jdi> data bus process...
Hmmm... Once again I am convinced that the Japanese did the Z80 good. Thank you.
By the way, as I understand it, all available clones and systems in general are based on Z80
“react” specifically to the decline in T3?
jdi> It is interesting that the command is read along the leading edge of the 3rd clock cycle, and
jdi> reading data from the back...
What else? With M1, roughly speaking, along the front of the third period, the idea begins
refresh. Those. at this point the data bus should be in Z. Another question is what
prevented them from delaying the data on the bus for the moment from the front and to the fall of T3?
Hello icebear
Apparently, you understand correctly. But don’t do this on the /MREQ and /RD fronts
worth it, because you risk picking up “something” during the bus transient process
data... It’s interesting that the command is read on the leading edge of the 3rd clock cycle, and
reading data from the rear...
Hello icebear
I won’t open a new topic, the question concerns reading, both memory and ports
i.v. So, according to DS, when reading from an I/O port, one cycle is automatically entered
waits and actual data are taken off the bus between the fall and
the front of the third period (the third not according to the count, but because the count is T1, T2,
Tw and T3). When reading from memory the same situation occurs (except for 3 cycles
instead of 4, but never mind, differences in the last period play a role). I am so
I think it won’t be scary if the data appears, say, on the fall of T1 on the bus, but
will disappear as T3 declines in both cases (so as not to get confused with the period numbers,
look at the diagrams)? I wouldn't mind adapting it exactly to the drawing from the DS. After all, when
recording data must hang on the bus for a long time.
Hello Ronin
Ron> tell me why you need this?
Ron>
Ron> do you mean you need to simulate the percentage? or the device is correct
Ron> screw ?
Why do they immediately ask “why is this necessary”? You will find out everything in due time :) Secrets
there is none, it’s just too early.
Ron> if the device asks you for data by rd, mreq - just give it out
Ron> immediately after rd,mreq but keep it until T3. percent will grab the T3 cut - you can
Ron> shoot.
Ron> in the datasheet it is shown when the processor is reading, and not when the devices are issuing.
Ron> in between, the guy doesn’t even care what’s going on on the SD - but there
Ron> real data can also be created.
That's what I thought. Those. I'm not completely stupid Pinocchio yet and timings are possible
unload. Cheers and thanks.
Hello icebear
tell me why you need this?
I mean, do you need to simulate the processor? or screw the device correctly?
if the device asks you for data via rd, mreq, give it right away
rd,mreq but hold it until T3. percent will grab the T3 cut - you can shoot.
The datasheet shows when the processor is reading, and not when the devices are issuing. in
in between, the guy doesn’t even care what’s going on there on the SD - but things can happen there
and real data.
Hello icebear
In KAY, data from memory is latched every positive edge of the signal with
frequency 3.5 MHz and are set to the data bus at MREQ=0 RD=0
Hello icebear
In KAY, data from memory is latched every positive edge of the signal with
frequency 3.5 MHz and are set to the data bus via MREQ=0 RD=0 and the CLC signal
processor is in high logical level
Recording occurs CLC=1 CAS=0 MREQ=0 RD=1 in all these cases a signal is generated
WE in memory
Hello hero
her> In KAY, data from memory is latched every positive edge
her> signals with a frequency of 3.5 MHz and are set to the data bus by MREQ=0
her> RD=0
By the time they are exhibited, I’m already finished, thank you. It was mostly unclear to me
when they are removed. There are two bibles from Zilog, one is old, the other is that
which they have now and in both it is written a little differently, or rather
they do not converge in the memory reading diagram (the new one shows that the data
are removed before the difference /MREQ and /RD, in the old one, which is just at the moment of this
difference). The text doesn’t describe this very clearly, I trust the Minsk book
less than the Bible :) This is where the question arose.
Hello icebear
ice> Why do they immediately ask “why is this necessary”? You will find out everything in due time
ice> There is no mystery, it’s just too early.
It’s just that when you know what it’s for, it’s easier to explain. and not out of idle curiosity
:D
Hello Ronin
Ron> damn I just noticed that min time16=0ns !!! (and max is obviously not
Ron> normalized) haha that's how it is.
Well, as soon as /RD was removed - bye bye. And this is exactly how it is depicted in UM.
Although this is not critical for me, I will have time to spare the tire before the end of T3.
Hello Ronin
Ron> read not the user/man um0080.pdf but the crookedly scanned prod/spec ps0178.pdf -
Ron> there in fig.6 pag.25 the times are painted.
This was my second bible
Ron> But why do you need this, I don’t understand - everything is also relative
Ron> decline T3 painted.
Yes, not so. That is why questions arose. UM already has data on the decline in T3
Ok, but in PS the data hangs for some time after this decline. Those. according to PS
the exact moment of T3 decline is the moment when the processor raises the data bus. I
I already figured it out, thanks. By the way, the Z180 has the same bad thing.
Hello icebear
ice> This is not very clearly described in the text, I trust the Minsk book
ice> less than the Bible This is where the question actually arose.
read not use/man um0080.pdf but crookedly scanned prod/spec ps0178.pdf - there on
fig.6 pag.25 times are painted. But why do you need this, I don’t understand - there
everything is also painted regarding the T3 decline.
damn I just noticed that min time16=0ns !!! (and max is obviously not standardized) haha
here's how.
File: time16.gif http://zx.pk.ru/attachment.php?attachmentid=2734
File: fig6pag25.zip http://zx.pk.ru/attachment.php?attachmentid=2733
Hello icebear
ice> Well, as soon as /RD was removed - bye bye. And this is exactly the case at UM
ice> drawn. Although this is not critical for me, keep the tire free until the end of T3
ice> I'll have time.
The percent data is read by the T3 slice, but a hold before removing RD/ is apparently needed (as in PS
drawn). although in practice it is probably not necessary.
The processor cannot remove the data from the SD - it was not he who posted it :)
You can remove them immediately after removing the RD/, or you can wait and smoke (more precisely
this time results from the delay in the elements from RD/ to the Z-buffer
data - and it is non-zero)
Hello jdigreze
jdi> The main thing is to have time to smoke before the leading edge of the next bar ;)
jdi> Most likely the data needs to be “removed” when /RD “goes into hibernation”, i.e.
jdi> "1"
This is exactly what has been done at the moment.
Hello Ronin
The main thing is to have time to smoke before the leading edge of the next beat ;)
Most likely the data needs to be “removed” when /RD “goes into hibernation”, i.e. "1"