But what if you carefully construct a program that runs with both
processors? I know, this doesn't have any practical applications, but
it would be very challenging. The only problem I have here is that I
don't know almost anything about the Z80 instruction timing. I have
seen some opcode lists that might have a column "#clocks", but it is
not enough for this purpose. For instance, the 6502 instruction
inc $d020
($ee $20 $d0 in machine code)
causes the following bus activity, assuming that the instruction is at
$1234 and assuming that $d020 contains $f6:
address data r/w
$1234 $ee r
$1235 $20 r
$1236 $d0 r
$d020 $f6 r
$d020 $f6 w (write the same value back)
$d020 $f7 w (write the modified value)
I have written timing examples like this for all 6502 addressing
modes. Has anyone compiled anything similar for the Z80? Any
pointers are welcome.
Please crosspost your follow-ups at least to comp.sys.cbm, because I
don't subscribe to other groups.
--
Marko Mäkelä <Marko....@HUT.FI>, http://www.hut.fi/home/msmakela/
Helsinki University of Technology, dept. of Computer Science
I did some medium-level work on a C128 years back and I could have sworn
that the docs said that when you activated the Z80 the 6502 kept on running
and was used as an I/O processor. Specifically, the 6502 (8502?) kept
running because it had code that knew how to interact with those intelligent
C64/C128 disk drives and so forth.
This assumed you were running CP/M on the Z80, so maybe it had something to
do with that. Of course, it could also have "frozen" the Z80 when the 6502
was running, and vise-versa for the Z80, but that wasn't what I recall the
docs saying.
- Bill
Marko Mäkelä wrote in message <87yb316...@sranje.tky.hut.fi>...
>>>>>> "Bill" == William J Leary <Bill_...@msn.com> writes:
> ((..omitted..))
>Bill> This assumed you were running CP/M on the Z80, so maybe it had
>Bill> something to do with that. Of course, it could also have
>Bill> "frozen" the Z80 when the 6502 was running, and vise-versa for
>Bill> the Z80, but that wasn't what I recall the docs saying.
>
>Yes, that's it, the other processor is "frozen". User manuals tend to
>simplify things too much. Maybe the writers didn't know how the
>system really works, or they wanted the documents to be easier to
>understand, or whatever.
Even at the time I suspected it had to be something like that. I just
couldn't see them going to the expense to develop what would have basically
have been dual-ported memory. After all, CP/M systems were used to the idea
of committing 100% of their time to I/O while it was going on. If that 100%
was done by stopping the CPU, what difference would it make.
>Anyway, what I'm trying is to write a program that runs simultaneously
>on both processors. I like to try all kinds of "illegal" actions.
>For instance, I have written a 6502 program that runs in the 4-bit
>colour memory of the C64 or C128 -- the upper 4 bits will be
>indirectly supplied by the video chip.
I seem to recall some story someplace about people running programs out of
video memory on a 6502. Might have been an Apple. I'm not sure. I think
you're still going to get conflicted at the data bus level.
Interesting thing to do, though.
- Bill
Marko Makela said :
>Some years ago I played with the Commodore 128's MMU and noticed that
>when you activate the Z80 mode and the C64 mode simultaneously, both
>processors (8502 and Z80) will be activated at the same time. Of
>course this will normally cause a crash, because neither processor can
>fetch meaningful instructions. I assume that the address and data
>busses will be ANDed together, and also the R/-W signal of the 8502
>will be ANDed with the -WR signal of the Z80.
>
>But what if you carefully construct a program that runs with both
>processors? I know, this doesn't have any practical applications, but
>it would be very challenging. The only problem I have here is that I
>don't know almost anything about the Z80 instruction timing. I have
The first person I know of to discuss this is George Taylor.
It is obvious that the pairwise possibilities break down as follows:
NONSENSE 6502 OPCODES/INSTRUCTION = NONSENSE Z80 OPCODES/INSTRUCTION
USEFUL 6502 OPCODES/INSTRUCTION = NONSENSE Z80 OPCODES/INSTRUCTION
NONSENSE 6502 OPCODES/INSTRUCTION = USEFUL Z80 OPCODES/INSTRUCTION
USEFUL 6502 OPCODES/INSTRUCTION = USEFUL Z80 OPCODES/INSTRUCTION
The odds of writing meaningful opcodes/instructions in succession to
BOTH CPU's is inversely proportional to the length of the "program".
But yes, parallel coprocessing is possible! Heh Heh!
XmX
--
Pursuant to US Code, Title 47, Chapter 5, Subchapter II, 227, any
and all nonsolicited commercial E-mail sent to xmi...@eyrie.stanford.edu
or xmi...@eyrie.org is subject to a download and archival fee in the
amount of $500 US. E-mailing denotes unconditional acceptance by both
sender and any organization represented in the aforementioned nonsolicited
commercial E-mail. --->> "By US Code Title 47, Sec.227(a)(2)(B), a
computer/modem/printer meets the definition of a telephone fax machine.
Sec.227(b)(1)(C), it is unlawful to send any unsolicited advertisement to
such equipment. Sec.227(b)(3)(C), a violation of the aforementioned
Section is punishable by action to recover actual monetary loss, or $500,
whichever is greater, for each violation."
XmikeX> The first person I know of to discuss this is George Taylor.
I think that I discussed this with him after I got the idea, but I
never got around to measure the Z80 instruction timing details.
Without a scope (or better, a logic analyzer), it is quite difficult
to guess the timings, since the Z80 has something like 4 memory cycles
for each "efficient cycle". All cycles count, including the memory
refresh cycles the Z80 does (and which are completely wasted on the
C128).
XmikeX> It is obvious that the pairwise possibilities break down as
XmikeX> follows:
[...]
XmikeX> USEFUL 6502 OPCODES/INSTRUCTION = USEFUL Z80 OPCODES/INSTRUCTION
Yes, and in addition to that, you have to make sure that the address
lines and the data lines are almost equal on all cycles, or otherwise
the data will be fetched far away. E.g. if the 8502 wants to access
from $fdff and the Z80 $fe00, the data at $fc00 will be accessed.
Similar ANDing will be performed on writes.
XmikeX> The odds of writing meaningful opcodes/instructions in
XmikeX> succession to BOTH CPU's is inversely proportional to the
XmikeX> length of the "program".
Of course. It took me 2 weeks to write my "dadb" program that runs in
the (4-bit) colour memory and turns the middle of the screen black
when the space bar is pressed, otherwise white. The effective length
of the program is maybe 20-30 bytes, but the real length is 63*312
cycles. :-)
> Marko Makela said :
>
> >Some years ago I played with the Commodore 128's MMU and noticed that
> >when you activate the Z80 mode and the C64 mode simultaneously, both
> >processors (8502 and Z80) will be activated at the same time. Of
> >course this will normally cause a crash, because neither processor can
> >fetch meaningful instructions. I assume that the address and data
> >busses will be ANDed together, and also the R/-W signal of the 8502
> >will be ANDed with the -WR signal of the Z80.
> >
> >But what if you carefully construct a program that runs with both
> >processors? I know, this doesn't have any practical applications, but
> >it would be very challenging. The only problem I have here is that I
> >don't know almost anything about the Z80 instruction timing. I have
>
>
> The odds of writing meaningful opcodes/instructions in succession to
> BOTH CPU's is inversely proportional to the length of the "program".
>
> But yes, parallel coprocessing is possible! Heh Heh!
Actually I recall an article in the old Transactor magazine that
gave an example of how the Z80 could be used as a math co-processor for
the 8502. I never typed in the code so I can't vouch for how well it
worked but at least in theory both chips could be used together.
<Lo...@pconline.com>
St. Paul, Minnesota
"The only true spirituality
is when you first look within yourself
and follow what you find there."
-- Homesteader --
Bill> I did some medium-level work on a C128 years back and I could
Bill> have sworn that the docs said that when you activated the Z80
Bill> the 6502 kept on running and was used as an I/O processor.
Then the docs were wrong. Normally only one of the two processors is
on command. As far as I know, the 8502 is used in the C128 CP/M for
I/O. There's no magic in the processor switching: the currently
active processor will stop right after the store instruction that
activates the other processor. An interesting piece of trivia is that
the C128 is booted up by the Z80. If you examine the RAM at
$ff00-$ffff, you will find the 8502 and Z80 processor switching code
there.
Bill> This assumed you were running CP/M on the Z80, so maybe it had
Bill> something to do with that. Of course, it could also have
Bill> "frozen" the Z80 when the 6502 was running, and vise-versa for
Bill> the Z80, but that wasn't what I recall the docs saying.
Yes, that's it, the other processor is "frozen". User manuals tend to
simplify things too much. Maybe the writers didn't know how the
system really works, or they wanted the documents to be easier to
understand, or whatever.
Anyway, what I'm trying is to write a program that runs simultaneously
on both processors. I like to try all kinds of "illegal" actions.
For instance, I have written a 6502 program that runs in the 4-bit
colour memory of the C64 or C128 -- the upper 4 bits will be
indirectly supplied by the video chip.
>Even at the time I suspected it had to be something like that. I just
>couldn't see them going to the expense to develop what would have basically
>have been dual-ported memory.
In a very ancient BYTE (July 1978, page 60) there was an article about
two Z80's in parallel. Separate LOW Memory, dual port HIGH Memory. All
with a detailed timing-analysis.
Greetings, Holger
Perhaps I am missing the point but this sounds to me just like the
operation of a Z-80 card in the Apple ][ which let the Apple run CP/M.
Since the 6502 takes the bus during one phase of the clock, the Z-80 can
take it (under some conditions) during the other phase.
Best regards,
Art Borg
Marko Mäkelä wrote:
>
> it would be very challenging. The only problem I have here is that I
> don't know almost anything about the Z80 instruction timing. I have
> seen some opcode lists that might have a column "#clocks", but it is
> not enough for this purpose. For instance, the 6502 instruction
>
> inc $d020
> ($ee $20 $d0 in machine code)
>
> causes the following bus activity, assuming that the instruction is at
The # clock cycles listed for the Z80 opcodes should be exact, including
the opcode fetch, processing, and any data fetch/put. I have done quite
a bit of Z80 programming where knowing the exact time for a sequence of
instructions was required, and always got the right results from the
tables. For example, a "4-cycle" instruction (the shortest kind, if
memory serves) takes 1 usec with a 4 MHz clock.
Of course, if the commodore bus asserts HALT, or some such line, and
does something on its own, or changes the clock period, it could take
more real time. Maybe that's what you meant ?
Carl
And my answer is:
I'm looking for the bus timing. Well, as a matter of fact my Z80
opcode reference didn't list the clock cycles for each instruction,
but even if it did, it is not enough. I need to know which addresses
are being read or written on which cycle. As far as I understand, the
Z80 must be reading or writing some address on every cycle, just like
the 6502 does. Or at least it will appear so on the address and data
busses.
For instance, could anybody answer what exactly happens on the bus if
BC=$1234, A=$56 and the instruction LD (BC),A is executed?
We can only guess really, but that one is fairly easy to guess.
time action
0 read opcode
3 a refresh cycle
4 store $56 in $1234
7
A memory access takes 3 cycles (unless the WAIT pin on the Z80 is asserted).
The address is placed on the bus on the trailing edge of the first cycle.
Any data to be written is placed on the bus during the second cycle. It
looks like the data transfer actually takes place on the trailing edge of
the third cycle for normal accesses, but on the leading edge of the third
cycle for instruction fetches - in which case the refresh cycle begins
on the trailing edge of the third cycle and ends on the leading edge of the
fifth.
--
---- Ian Collier : i...@comlab.ox.ac.uk : WWW page (including Spectrum section):
------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html
I'm pretty sure that this is wrong. The Z80 releases the address and
data busses when it's not using them. I think that the logic is as
follows in psuedo-c (most of the logic levels are wrong in this)
mwrite(address,data)
{
while(WAIT|BUSRQ);
MREQ=TRUE;
A0..15=address;
while(WAIT);
D0..7=data;
WR=TRUE;
while(WAIT);
WR=FALSE;
MREQ=FALSE;
}
mread(address)
{
while(WAIT|BUSRQ);
MREQ=TRUE;
A0..15=address;
RD=TRUE;
while(WAIT);
data=D0..7
RD=FALSE;
MREQ=FALSE;
}
>For instance, could anybody answer what exactly happens on the bus if
>BC=$1234, A=$56 and the instruction LD (BC),A is executed?
I'll see if I can get the answer when I get home tonight.
Eric
--
Eric Korpela | An object at rest can never be
kor...@ssl.berkeley.edu | stopped.
<a href="http://www.cs.indiana.edu/finger/mofo.ssl.berkeley.edu/korpela/w">
Click here for more info.</a>
> And my answer is:
>
> I'm looking for the bus timing. Well, as a matter of fact my Z80
> opcode reference didn't list the clock cycles for each instruction,
> but even if it did, it is not enough. I need to know which addresses
> are being read or written on which cycle. As far as I understand, the
> Z80 must be reading or writing some address on every cycle, just like
> the 6502 does. Or at least it will appear so on the address and data
> busses.
I suggest you get hold of the z80 hardware manual, where the bus timing/action is specified, I got my copy for free from the Danish branch of Zilog, you could try that too.
>
> For instance, could anybody answer what exactly happens on the bus if
> BC=$1234, A=$56 and the instruction LD (BC),A is executed?
-Sorry can't tell you, haven't got the manual here...
--
Peter 'NWC' Sorensen
n...@kom.auc.dk
.sig not found
Fail, Crash or Explode?
Or perhaps a more definitive way is to visit www.zilog.com and get the Z80
hardware timing data sheet? That site is ful of interesting .PDF files.
Cliff
I was wrong, The Z80 does hold the address and data lines as long as
no one else requests them. (I used to use a system that used
(MREQ-) as an input to a basic memory controller, I assume as a method of
freeing up the busses more of the time for DMA/etc. Or perhaps for more
symmetry between processor and other memory accessing devices. Thus my
confusion.)
The timing for LD (BC),A (instruction 02h) is...
Clock cycle Address Data Machine Cycle
1 PC ?? M1
2 PC 02h ..
3 R ?? ..
4 R ?? ..
5 BC A MWRITE
6 BC A ..
7 BC A ..
This shows why a Z80 and a 6502 don't work well together if they are
driven at the same clock frequency. For best results the Z80 should
be driven at 4 times the 6502 speed, yet I don't know of any Z80-6502
combo that worked that way. (For those unfamiliar with the Z80, cycles
3 and 4 above are DRAM refresh cycles that run concurrently with the
instruction decode and execute cycles.)
The Z80 samples the BUSRQ- line 1 clock cycle before the end of the
current machine cycle (i.e. 4 or 7 above), and grants the bus (BUSAK-) at
the start of the next clock cycle. When BUSRQ- is released, the next
machine cycle begins at the end of the following clock cycle.
To do real multiprocessing (for a performance increase), each processor
would need to have either some private memory or a cache, as these
processors are very memory intensive. I don't know of any system that
automatically interleaved the processors such that each could run
simultaneously, but I wouldn't be suprised if one existed.
I haven't been there, but I do have Z80 timing diagrams. However, they
don't list what happens for each individual instruction - they only list
what happens in one machine cycle. So, are you saying you can find things
there that _do_ have diagrams for individual instructions?
Don> The datasheets describe how each different bus cycle works
Don> (memory read, write, interrupt acknowledge, etc.).
Are these datasheets downloadable from Zilog's page? I tried to find
Z80 information there, but I couldn't find any technical data, just
the package dimensions and other stuff.
Don> For example, you can examine the contents of register HL during
Don> an "INX H" instruction on an 8085 just by monitoring the 16
Don> address lines :>
Don> You have to decide how much detail you really *need*...
I need all the details, because I'm going to write a program that runs
on the 6502 and on the Z80 simultaneously ("multitasking" on the
Commodore 128). The address and data busses of these two processors
will effectively be ANDed together, and as the 6502 has significantly
less meaningless cycles, it must be clear what exactly happens on
which cycle.
In case someone wonders if writing such a program has any sense, the
answer is "no". But sometimes it is fun to do something that is
considered impossible (i.e. running the same binary on two completely
different processors, and running it simultaneously).
The datasheets describe how each different bus cycle works (memory read,
write, interrupt acknowledge, etc.). There is a breakdown of how each
*instruction* operates (per machine/bus cycle). You use the tabular
instruction data to determine which pieces of the timing diagrams are
pertinent and piece them together for any particular instruction.
Note there are gaps in this approach for some of the "longer" instructions
(when the bus is not active but the lines may in fact be twiddling).
For example, you can examine the contents of register HL during an
"INX H" instruction on an 8085 just by monitoring the 16 address lines :>
You have to decide how much detail you really *need*...
HTH,
--don
>From here the similarities become a little more complicated. The Hitachi
64180 and the Zilog Z180, Z181, Z182, Z280, Z380 and Z382 can have the
DRAM
refresh cycles reduced or removed from the processor's timing, reducing
instruction timing. All of these processor's have different instruction
timing from the "standard" Z80, being dependent on the processor type
and
the processor setup.
For example: A Z8018233 (33MHz Z182) can be set to run at 33MHz clock on
the
data buss (need 25 nanosecond cache memory to keep up with it) or set to
divide the crystal by two (runs on standard 50 nanosecond memory) or use
any
crystal clock input from 0 to 33 MHz. Added to this there is an internal
wait state generator for each of the 1 megabyte ROM and RAM internally
decoded memory domains. The 1 megabyte global memory domains wait states
are
controlled externally (if global memory is required).
The Zilog processors' instruction timing, and the setup effects, are
described in the hardware data sheets on the Zilog web site. Goto
www.zilog.com and download the pdf file/s for the required processor.
I have not checked the other manufactures web sites.
Reading between the lines, if your question relates to generating timing
delays via software, I would say don't. Look for some way of
synchronizing
software by some type of ported hardware timer, a clock chip or a timer
interrupt.
Bob Fulton