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 firstname.lastname@example.org.
Archive generated by hypermail 2.1.1.