Hallo allemaal,
The text. Please, enjoy. I'l return to the @#$#@! decoding of my signals for
the PC-card :)
OZ-CARD
For CBM-Hackers: any comment is welcome. ### means your comment or help is
apreciated, please.
What is it?
The original idea was to devellop a PC ISA-card to replace the processor of
any Commodore which enables a user to use the full power of a PC in service
for this Commodore. What about a C64 with a Pentium 3 - 450 MHz processor?
During develloping this version other possibilities appeared by adding some
extra hardware. IMHO the OZ-CARD can emulate the REU and, with a little bit
of luck (= fast PC), even a SCPU!
It takes only 27 common available IC's unless anyone compresses the logic
into a FPGA. The card can be connected to your C= by means of a flatcable in
two ways:
- by 40-pin connector which replaces the CPU
- connecting it to the cartridge port (only C64/128 for the moment)
The above idea is not new. It originates from 1991 but it never worked out
right for two reasons: 1) the 80286-12 was too slow for this 2) I had an
error in my design which I didn't notice untill some days ago (May 2001).
Credits go to Nick Coplin "http://www.64hdd.com/" because the discussions
with him revealed the error and he is in fact the originator of the
cartridge-version.
The idea is quite simple: replace the processor by a bunch of buffers,
latches and gates and let the CPU of the PC glue everything together. Is a
PC fast enough? IMHO, yes. If a PC can emulate a complete C64 including the
VIC-II videochip, it certainly must be able to handle a standalone
processor.
But there is a catch: an hardware emulation requires a lot of transfers to
the logic involved: about four bytes every micro-second. I/O in a PC is
slow, the maximum is 1 I/O per microsecond. So we'll use memory mapped I/O.
We also use asynchronous communication: the ISA-bus is never connected
directly to the C64 at any given time; all communication is done through
latches.
As you probably noticed, I mentioned the ISA-bus. What about VLB or PCI? VLB
is outdated and rare. For PCI you need special chipsets, connectors and more
advanced tools to create a card. The card must be etched, handwiring is
because of the involved speeds out of the question. This project must be
kept in reach of hobbyists.
### is above true about special chipset?
Theory and hardware - interface towards the C=
To explain everything I'll use the 6510, the CPU of the C64, as example of
the CPU to be replaced by the PC. For explaining the cartridge mode, I'll
use the REU.
The 6510 has a 16-pin addressbus, an 8-bit databus, an 8-bit onboard I/O
port, 6 inputs: CLK0, RDY, IRQ, NMI, AEC and RESET, and two outputs: CLK2
and R/W.
The expansion slot has a 16-pin addressbus, an 8-bit databus, 5 inputs: IRQ,
NMI, DMA, EXROM and GAME, and 8 outputs: Reset, CLK2, BA, R/W, IO1, IO2,
ROML and ROMH.
The addressbus can be emulated by four 74ALS573 8-bit latches. For every 8
addressbits one for outputting the data, one for reading it again. Why a 573
and not a 541 or equivalent for reading the data? A 573 can be piggybacked
on top of the other. It does not match perfectly but this is more simple the
cross-wiring a lot of lines.
Remark: the 573's used to read the contents of the addresbus are not used to
read the contents of the output-573's. Whenever data is written to these
573's, a copy should be left in memory as well. If this data is needed, it
is much faster to read the data from memeory then from the input-573's.
The databus can be emulated by two 74ALS573 8-bit latches using the same
construction as above.
The outputs are enabled through a 273 (see below). To prevent a premature
output the signal coming from the 273 is inverted first. This assures
tristated buses after a reset of the PC. This is certainly needed when used
as a cartridge version.
Two AND-gates enable the AEC-signal to tristate the buses as well.
Advantage: no software command needed to tristate these buses when AEC
becomes active. Theoretically AEC cannot occur when R/W is (H). So when the
emulator behaves as it should, no command to set the R/W-bit is needed
either (see below).
The emulation of the onboard I/O port is a little bit more difficult. We'll
need one 573 for emulating the DDR, data-direction-register ($0000).
An other 573 is used to generate the data for the DR, data-register ($0001).
Eigth 125 buffers are used to output the data. Wether the 125 is an output
or not, is controlled by the 573 of the DDR. We need a 540, octal invertor,
to convert the output of the 573 to the needed inputs for the 125. A 541 is
used to read the data.
Although eight 125 buffers are used, it depends on the CPU to be replaced
how may pins actually are connected to Commodore.
### what about Plus4 behaviour
Remark: the emulation part can be left out if the OZ-CARD is only to be used
for CPU's without onboard port or if the OZ-CARD is only to be used as
cartridge version.
We need a latch to generate our own R/W signal. A 273 is used as this IC has
a Clear-input. As the C64 already supplies a R/W-line the one of the
cartridge version has to be disabled in one or another way. My solution is
to use a 7406, OC-invertor. The Clear-input of the 273 makes sure this
output won't hinder the CPU when used as cartridge version. A 4K7 resistor
makes sure R/W is (H) when not used in processor mode.
### Good idea??? otherwise I'll need TWO extra IC's :(
For the processor version CLK2 is generated out of CLK0 by delaying it with
a left over AND-gate.
### I used the delay because I needed it when replacing the 6510 with a
65816. But I cannot see any reason to use a delay at all.
IRQ, NMI and RDY are latched using a 573. This 573 is clocked by CLK2. CLK2,
AEC and Reset can be monitored directly using one half of a 244.
The NMI input of a 65xx is edge sensitive. so I placed a flipflop made out
of two 74F00 NAND-gates between the real input and the above 573 to detect
these edges. Once we have noticed the presents of a NMI, we can clear the FF
using one of the outputs of the 154 decoder (see below).
The expansion slot has more signal to be monitored, R/W, IO1, IO2, ROML and
ROMH. R/W is connected to the 573, The rest is monitored through the second
half of the 244. A cartridge can generate five other signals: EXROM, GAME,
IRQ, NMI and DMA. This is done using the last five outputs of the 273 in
combination with 7406 OC-invertors.
To have as less as I/O operations as possible, we'll combine some registers
to 16-bit registers:
out in
reg. D0..7 D8..15 D0..7 D8..15
-------------------------------------------
0: A0..7 A8..15 A0..7 A8..15
2: D0..7 R/W, etc D0..7 RDY, NMI, etc.
4: DDR - Iox... -
8: DR - DR -
A: NMI - - -
To save some hardware, I deny 8-bit operations. IMHO they are not needed
anyway. The CPU even needs more time to read an upper-byte, D8..15, then a
whole word! Advantage, in case of a databus-read, detecting CLK2 has gone
(L) means that the read data automatically resides in the lower-byte of the
read word.
About detecting CLK2 goes (L): the above indicates I'll use polling the
registers to find out about this event. Using interrupts is impossible. Most
PC's can handle only 1 I/O every 2 microseconds. An hardware interrupt
ALWAYS involves one I/O to clear a flag inside the 8259 which simply means
that 1 Mhz is much too fast to be used as interrupt source.
But disabling the hardware interrupt does not mean we are unable to do
anything else with the PC. The PC can poll the Keyboard-interrupt once a
while to see if the user wants its attention. If that is the case, it is up
to the programmer to decide what happens in that case.
One thing is clear: forget Windows :)
#### Linux ????
Theory and hardware - interface towards the PC
The BALE line of the ISA-bus tells the card when there is a valid A17..23 on
the bus. So we need a 573 to trap this info. A 74LS682, an 8-bit
comperators, is used to see if the address represents the first most
significant of our card. If so, then MEMCS16 must be pulled (L) to signal
the CPU that it will deal with a 16-bit card. I know, only checking from A17
on means a 128 KB range and we only need 5 words. But don't forget, I didn't
design the bus.
This 128K-range is another reason to design the card as a 16-bit one. The
VGA-card alone defines the complete range from $A0000 to $E0000 as a 16-bit
area. Writing to a 8-bit card won't cause problems (think of an extra
MGP-card), but reading does. So to be able to survive in a 16-bit
enviroment, the OZ-CARD has to be a 16-bit card itself as well.
The next thing we have to do is some extra decoding. Although I personally
dislike mirroring because you automaticcally shut the door for other
devellopers, I stopped after A10. The PC searches for external EPROMS in
pieces of 2K. So our 1K won't consume unnecessary memory. Decoding the rest
would cost me an extra 688. You're free to use it.
At the end of the "train" a 74LS154 does the actual selecting of all the
buffers and latches.
Use of the processor version:
The first use is very obvious: the PC can emulate the 6510. This can be very
useful in debugging programs etc. But one could go a step further. The PC
could emulate the use of certain hardware which can be connected to the
cartridge port like the REU or even the SCPU. It is just a matter of looking
at the address the 6510/PC is handling at that moment.
An other way to use the processor version is to use it parallel to the
original CPU as logic analyser or for realtime debugging. This use explains
the jumper as CLK2 is generated by the CPU itself.
Use of the cartridge version:
The first design was purely meant to replace the CPU and lacked certain
features like being unable to read the addresslines. Pull DMA (L) to
disactivate the CPU and connect BA to the original RDY-input. The behaviour
of AEC could be emulated by software.
During the discussions around the pro's and cons I made a mistake but that
mistake lead eventually to the final version.
At this point this version was only capable of outputting addresses. But
what if it was able to read them and other lines as well? Throw some other
bits in and we can emulate EXROM, GAME etc. as well.
The idea is very simple: the PC reads the addressbus and handles
accordingly. Assume we want to emulate the REU. Seeing R/W is (L), IO2 is
(L) and the address is $DF01, the PC knows it has to store the byte in its
equivalent for register 1. Especially in this case it then has to check
wether has to start a DMA or not.
IMHO we can emulate a lot of carts, ranging from some "only EPROM" to more
sophisticated as the Final Cartridge III or the CP/M-cart for the C64. And
maybe, repeat maybe, we can emulate the SCPU. What about that? :)
### the 20 MHz worries me a little bit. A faster machine probably could
handle it. But faster machines often have no ISA-bus anymore. Especially for
this reason I would be happy if somebody could think of another interface
which still is "available" for the common hobbyist.
Groetjes, Ruud
http://Ruud.C64.org
-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tml.hut.fi.
Archive generated by hypermail 2.1.1.