You don’t mention 74HCT for a reason?
ACT and HCT inputs are TTL-level compatible to allow an LS device to drive a CMOS device. If everything is CMOS (which it should be in new designs) there's no need to use ACT or HCT. Incidentally, 74ABT logic, despite the name, is CMOS. It features single nanosecond performance and high drive strength. You'd only use it if you were trying to take a 65C02 or 65C816 all the way up to 20 MHz.
Most of you are advising me to use an ‘816. I’m open to that suggestion, but I have some concerns.
We have answers...mostly.
First of all, banking would be just a nice addition, certainly not a necessity (to me at least).
A bit of technical pedantry: "banking" in the 65C816 sense is nothing like what you would see in a C-128. The C-128 was dependent on the actions of the 8722 MMU and the PLA (which was most of the C-128's glue logic) to select one 64KB bank or the other, maintain a common area at low RAM, and map ROM and I/O in or out as needed. The ability to configure a common area was
de rigueur as without it, bi-directional cross-bank transfers were all but impossible (BASIC would not have been able to run). Also, the C-128's kernel had to write some ISR front-end code into both RAM0 and RAM1 to assure that the 8502 would have a place to land when an interrupt occurred. That code had to push the registers, read the MMU configuration at $FF00 and push it, and then write $00 to $FF00 to map in the kernel ROM. It was a complicated and somewhat fragile arrangement with which I got very familiar back when I professionally programmed that machine.
In contrast, the 65C816 can address a full 24 bits of RAM with minimal glue logic (a 74AC573 or 74ABT573 latch to drive A16-A23 from D0-D7 and an out-of-phase clock to gate the '573) and without the need for common RAM areas. Several ways are available to access the entire 16MB space without any special steps, including using a 24 bit direct page (aka zero page) pointer. When an interrupt hits, the '816 will go back to (program) bank $00 to fetch the ISR vector and start executing the ISR without the rest of the hardware having to do anything special. When the ISR RTIs, the '816 will return to the bank in which it was executing when the interrupt hit, again without the system logic having to do anything special. That is all in stark contrast to the hoop-jumping done by the C-128, and is much simpler than trying to make a 65(c)02 address more than 64KB.
That said, you aren't obligated to use the A16-A23 address component at all, and can completely ignore it like I did with my POC V1 units. As long as the glue logic is correctly implemented, the '816 will pretend it only knows about a 16 bit address bus and will behave like a 65C02 on a big dose of steroids. You can run the '816 in emulation mode (the default at power-on or reset) until you get comfortable with your system, and then start exploring native mode and 16 bit programming. Once you get some experience under your belt with this hardware you can design version two with A16-A23 decoding hardware and rig up as much RAM as you want.
I’ll be using a Gameduino for VGA out. At startup, I have to write a charset to it.
You'd do that in your reset handler. That's basic I/O. What are you going to use to read a keyboard?
I’ve started to read the ‘816 datasheet and it looks rather impressive.
That's because it has more features than the 65C02. Don't let it scare you. Ninety percent of the assembly language is the same. The other ten percent is where the '816 really differentiates itself from the 'C02.
I’d really like to include a 6581 SID and a 8580 SID, they have to be in there! However, it would be silly to run the whole system with 1MHz. Can they be implemented if the system is running on a higher clock (2,4, or 8MHz.)? I’m pretty sure that PHI2 of the SID has to be (around) 1MHz. What about R/W? I will make a variable clock with a selection register and run it at 1MHz. while using the SID. But that’s not so elegant. Does R/W operate at 2 MHz. at “FAST MODE” on the C128? Does any one of you have a SID in your SBC? I know the KIWI has. It runs at 10MHz but has an E output.
That's not going to be a trivial thing to implement. The usual method of interfacing a slow peripheral device to a fast system is to use wait-states to temporarily halt the MPU. When the MPU is wait-stated by asserting (negating) the RDY input, it stops execution of the current instruction and holds all signals that it is driving in the state they were in when the wait-state started. The wait-state gives the slow device enough time to respond to inputs and do what it is supposed to do. Upon release of RDY, the MPU will resume execution of the current instruction.
Unfortunately, none of the NMOS versions of the 6502 (including the C-128's 8502) will respond to RDY when the current operation is a write. This shortcoming was addressed in the C-128 by implementing a hardware feature referred to as clock-stretching, resulting in all accesses to the I/O block ($D000-$DFFF) occurring at an effective 1 MHz rate, no matter the MPU frequency. Clock stretching temporarily increases the effective clock period to one microsecond during actual chip access, which allowed Commodore to use the 6581 without alteration (also true for the two 6526 CIAs).
As both the 65C02 and 65C816 will halt on a write cycle when RDY is asserted, you can use wait-states to access the SID. The device's Ø2 input would have to be phase-synced with the MPU's Ø2 clock so when the MPU is wait-stated on a SID access the latter's clock is in a high state. You could do this with cascaded flip-flops to divide the MPU's Ø2 clock to 1 MHz. The flops would have to be very fast to avoid having the SID's clock get significantly out of phase with the MPU's clock. I envision that you'd have to use programmable logic to achieve all this. Attempting to do it with discrete logic will likely result in too many cascaded propagation delays.
Aside from the timing issues, getting a 6581 (NMOS) or 8580 (HMOS) operating on a bus driven by a CMOS MPU will present a problem or two. As is typical of devices of that era, the SID has weak fanout, so direct connection to a data bus full of other hardware may not work, forcing you to use an octal transceiver to "boost" the SID's output. I don't know if anyone has tried such a thing, so you might be breaking new ground here.
Another concern are MOUSER’s ridicules shipping costs (20 euros). I’m living in the south of the Netherlands near the German border, so I could order from both countries.
€20 does seem steep for shipping small parts that weigh a fraction of a kilogram. Perhaps some forum members who live in your area could offer suggestions on obtaining parts.
I understand for higher clock speeds I need either AC logic or CPLD.
The fastest discrete logic available today is 74ABT. Some gates are as fast as 3ns. Unfortunately, 74ABT isn't available in all logic types, so your next bet is 74AC. You can use 74HC if you don't plan to ramp up the clock too much. A simple system with 74HC might be able to make it to 8 MHz, but that 125ns cycle time will be getting tight. You have to keep in mind that the MPU is doing stuff on both halves of the clock cycle and that read/write access occurs only during Ø2 high. That's 62.5ns at 8 MHz. I've "stress tested" my POC unit at 15 MHz (without access I/O) and know that it wouldn't be able to run that fast with 74HC logic.
PLDs are available at 10ns and faster, which is a pin-to-pin prop time (internal gate prop times are not additive in the usual sense). A reasonable system can be built around a 10ns GAL, such as a 22V10, with the GAL handling I/O decoding and wait-states. You'll run out of resources with a GAL if you get much more complicated. That's where a CPLD becomes attractive.
My “bug vendor” has only 18 different AC chips and some of them are SMD at 1.27mm pitch.
1.27mm (0.050 inches), also referred to as SOIC, can be hand soldered. My POC V1.1 unit has an SOIC SRAM and SOIC form of the MAX-238 transceiver. The SRAM has J-leads and the MAX-238 has "butterfly" leads. Despite the close pitch, my not-so-steady hands and less-than-sterling eyesight, I was able to solder both without any trouble. I discuss the technique on my
POC website. There are also some videos on U-Toobe that
illustrate various techniques.
CPLD wise I’m a total beginner. Just knowing that it can replace TTL and is pretty fast. I’m building a simple CPLD parallel port programmer and a test board with an XC 9572XL PC44 at the moment.
A CPLD is just a whole lot of gates in a single die, so if you understand the use of discrete logic, you are half way to getting a CPLD to work for you. The languages used to program CPLDs (CUPL, VHDL, etc.) do most of the hard work for you.
So for my first SBC I’d skip some steps and experiences.
I and others around here always advise first-time builders to exercise restraint in developing a homebrew computer. Trying to incorporate too many features and/or an idiosyncratic memory map into the design almost guarantees that the unit with be DOA on first power-up and difficult to debug. In other words, it's best to learn how to pilot a single-engine light plane before stepping into the cockpit of a 747 or A380.
Edit1: found BDD's POC schematics. Nice!
Excellent. My website is due for more updating but time has not allowed me to do a long burn on it. The schematics you found, however, contain the hardware bug-fixes that corrected timing issues that popped up in the initial unit (V1.0).
-----------------------
Edit: I attached the schematics for POC V1.1, which are more up to date that the schematics you found. As I said, I need to update the website. I omitted the SCSI host adapter schematic.
-----------------------
- POC V1.1: Memory Map
- POC V1.1: Microprocessor Interface
- POC V1.1: RAM, ROM & I/O
- POC V1.1: External Interface
