Ruud's Commodore Site: 65816-in-PC Home Email

65816-in-PC





What is it?

A PC ISA card that contains a 65816, some I/O, RAM and ROM. The PC acts as the terminal and drive station(s) for this "65816 system".
For those who are not familar with the 65816, it is the 16-bit version of the well known 6502. Later I also created a 6502-in-PC.

State: Schematics, board and PCB. No BIOS yet.


Background

I can imagine that your first question is "WHY ISA ???". The ISA bus is obsolete and so why putting effort in such a thing. The answers are easy:
- Older PCs, for example Commodore PCs like the PC20-II, are part of my hobby as well. So, A) I have enough of them and B) I can combine two CPUs in one project.
- Why not PCI (-Express)? The answer is very simple: I have no idea how to do it for the PCI bus. It will most probably need a FPGA or another fancy IC and these are out of my scope. So ISA it is.

Roland Leurs created the ATOM-in-PC which is a real "6502-in-PC". I devoted some thoughts to it to use it for myself but so far it only have been ideas. Main reason: if I want to put effort in such a project, I prefer it to be my own one.


The hardware

The first idea was to use the ATOM-in-PC as base but I already was thinking of a ROM disk and to make a long story short, why not using a 65816? This solved at least the problem of handling vast amounts of ROM and RAM.

Roland used three 32 KB SRAM ICs. Using one 512 KB SRAM not only saves a lot of space but gives us much more RAM.

Roland uses a 6522 to communicate with the 8255 connected to the ISA slot. But creating a small PCB based on a 6522 and an 8255 proofed to be a hell of a job. So I replaced it with a 8255. The main advantage: I can partly copy the layout of the PCB of. CP/M 3.0 for the PC.
But dropping the 6522 means I lack a timer. But that was solved by adding an interrupt and letting the PC take care of the timing.

Roland uses a GAL for selecting the 8255 for the PC. This limits the choice for the user to only eight pre-programmed addresses. I chose for a 74LS688/DIP switch combination, already proofed in other projects, which gives us a choice out of 256 addresses.


Keyboard and screen

It should be clear now that this system does not have its own keyboard and screen. So what about displaying text or reading the keyboard? The routines that send characters to the screen now send it to the 8255 together with some codes to tell the PC where to place it on its screen. The routine that reads the keyboards now asks the PC if a key has been pressed.


The schematic

I'm going to use a GAL of course but staring at a GAL won't explain how it really works. So here is the IC version:


At the top-left you find the PC part: the ISA slot, the 74LS688 8-bit comparator, a DIP switch and a 8255. The 688 and DIP switch enables to select an address for the 8255. A reasonable good choice is $320.

The 8255 for the PC is connected to the 8255 for the 65816 part. The interconnections are straight: not only simple to draw in the schematic but also in the PCB. Four of the eight lines op port C have been connected to LEDs through a 7406 inverter. Main reason: to have some visible debug possibilities. Both 8255s are resetted by the PCs. IC10E, a 74LS04 inverter, inverts the signal and resets the 65816.

IC2, a 74ALS573 8-bit latch, takes care of generating the address lines A16..19. A20..23 are not needed. The needed pulse to generate it, PHI1, is generated by IC4B, a 74LS04 inverter. IC4C generates PHI2.

An oscillator generates a clock frequency of 8 MHz. a 74LS393 counter, IC6, creates the frequencies 4, 2 and 1 MHz from it. JP2 enables the user to select a suitable frequency for the 65816 system.

The RAM and ROM have been connected to the 65816 in a normal way, no weird details. The 8255, IC5, is an Intel IC and therefore needs a separate read (RD) and write (WR) line. These two are generated by IC3A, a 74LS139 2-to-4 demultiplexer. The 65816's R/W line determines which output, Y1 or Y3, becomes active but only if PHI2 is (H).

The biggest challenge is the selection of the RAM, ROM and I/O. One idea is to be able to run the BASIC 4.0 of the Commodore 8032. This BASIC runs in ROM but I have no intention to populate this system with the needed ROM, the idea is too load it in RAM and then run it.
The I/O of the 8032 is situated in the range $E800..$EFFF so this will be the case here as well.
We have to have ROM, we cannot avoid that. The question is, do we need 4 or 8 KB? I'm going for 4 KB but don't forget: we are dealing with a GAL and reserving 8 KB of the range for ROM is peanuts.
This will give us a mapping that wil look like this:
  $000000 - $00E7FF             RAM
  $00EE00 - $00EFFF             I/O for the 8255 
  $00F000 - $00F7FF             RAM, maybe ROM
  $00F800 - $00FFFF             ROM
 
  $010000 - $07FFFF             RAM 

  $080000 - $0FFFFF             ROM 
IC3B, a 74LS139 2-to-4 demultiplexer, takes car of generating the main CS signals for the RAM and ROM. Within the upper 32 KB of the first 64 KB of RAM, IC9, a 74LS154 4-to-16 demultiplexor, takes care of generating the signals for the I/O and ROM. Address line A15..18 plus the OR gates IC11A, B, C, D and inverter IC4E take care of enabling the 154.
The idea is simple: as long as the I/O or ROM aren't selected within those 32 KB, RAM it is. The I/O and ROM signal are NANDed, IC12a, a 74LS00, in the first place. If one of these two signals is selected, the NAND gate outputs a (H). This output is ORed with the original RAM select line using IC14A, a 74LS32 OR gate.
The moment ROM is selected, output 15 of the 154 becomes (L). This signal is ANDed, IC13A 74LS08, with the original ROM signal. At that moment the address range $8F000..$8FFFF is mapped to $0F000..$0FFFF.
Note: if 4 KB of ROM is not enough, we will take 8 KB. That is just a matter of reprogramming the GAL.

Next feature is "write through". As said before I want to implement the BASIC of the CBM 8032but I don't want to pin point me to that. The idea is to start with a menu that gives us a choice of what we want to start up. The idea is to load the wanted ROM into RAM, switch to RAM and start the new system. But that means we have to fill the RAM under ROM with data as well.
During a write the R/W signal is inverted using pin 5 of NAND IC12B, thus becoming (H), and ORed, IC14B, with the signal coming from pin "15" of the 154 thus disabling it. The effect is that the RAM is enabled at this moment.

The last feature is the ability to switch from ROM to RAM. The idea is simple: don't only disable the signal coming from pin "15" of the 154 dring a write, but also disable it during a read. Therefore we need an I/O signal: PC7 of the 8255. This signal is fed to input 5 of NAND gate IC12B and disables the signal coming from pin "15" of the 154 more permanent.


The GAL version

Schematic:


Board:



Moving the I/O to Bank 8?

While writing this page I got this idea about moving the I/O to Bank 8. The reason for this idea is compatibility. Or better, the lack of it. We must face the facts: the I/O is completely different and programs writing/reading directly to/from the original I/O simply won't work. Or even worse, programs writing to the original I/O could mess up our 8255! So moving the I/O outside Bank 0 will avoid this problem because programs meant for the CBM 8032 won't have any instructions that can access Bank 8.
The advantage of having the I/O in Bank 0 is that it can be accessed by the 68512 in 6502 mode. When running, for example, BASIC 4 of the CBM 8032, we don't have to go to 65816 mode every time when we want to access the8255.

The result:
Originally not every output pin of the GAL was occupied. I thought I needed them to cut equations in half if they got to many terms. But things worked out fine and the two outputs remained left over. The I/O of the CBM 8032 ranges from $E810..$E88F. Of course things are mirrored between $E900 and $EFFF. But AFAIK decent programs only use the official addresses because you otherwise run the risk of activating the wrong I/O. Adding the address lines A9 and A10 to the GAL now limits the I/O range to $EE00..$EFFF. I dare to say that the problem of reprogramming the 8255 by accident has been solved.
But I still had a look at using Bank 8 and adding these two address lines limits the I/O from $80000 to $801FF. But the best was, in the end I only have to change one line in the equations to change the I/O range.


Communication between the 65816 system and PC

Here I can be very short: after the reset of the 65816 and when both systems know that the other system is present, it is the 65816 that initializes every action. The only thing the PC does is waiting for the 65816 to send a command.





Having questions or comment? You want more information?
You can email me here.