Some observations from my block diagram / schematic capture exercises that I thought I'd share:
1) IO Processor (IOP)
We discussed using the second DUART channel for some misc IO activities. I like this concept, and recently discovered that there was another homebrew 68K project (check out the Kiwi computer at http://www.ist-schlau.de/
- it's nearly matching what I'm after in almost all respects, and then some!! Awesome!)
I propose that the IOP and handle at a minimum: satisfying the 68K power-on-reset requirements (RESET and HALT pulled low for at least 100ms), a manual reset switch interface, and a real-time clock (RTC) interface.
My motivation for this proposal:
Certainly the reset circuitry is easy enough - the proven 555 timer, some OC gates or NPN BJT for the inversion and drive of HALT and RESET...but this all can be done with a uC and still handle other tasks. There are so many RTC solutions that it could be helpful to "abstract" the RTC via the IO Processor (IOP). I'll probably use the DS1302, because I know them and have them on-hand already. The DS1302, like many RTC chips, is not really so nice to bit-bang with a uC - in this case, it has a bidirectional data line that needs to be broken into DI and DO.
I envision the IOP being a "slave" to the 68K - send a command for RTC info, send another command to set RTC, send a command to RESET the 68K, etc.
I'll add a PS/2 keyboard interface feature to my own IOP - sure, not everyone needs this, but it's easy enough to do, and I want it, so I'll do it. I can fit all this into a (close your eyes, Mark!) a PIC16F688 in its cute little 14 pin package with internal 8 MHz oscillator. I'll for sure make the PIC code available to anyone that's interested once I complete it.
2) SD Card support
I was waffling a bit on whether to put the SD card SPI interface on the other side of the serial IO processor (e.g. PIC, ARM, whatever) or map it directly into 68K address space. I've opted for the latter, it should work out to be much faster, and simplify the command protocol within the IOP. I propose a simple 8-bit r/w port - so the 68K can bit-bang the SD card SPI signals. Bit banging can be made a bit easier by making the port r/w (i.e. written bits can be read-back). Easy to include the SD card Write Protect and Card Detect status bits in the readback latch, also. A spare bit from the write latch can be used for an LED for "SD card in use" indicator. A 3.3V LDO VREG is required (SD is 3.3V) and using HCT 245 for readback and LVC 574 for write latch makes the 5V/3.3V translation a breeze.
3) PIA interface
A lot was said on this. I'm going to map the PIA into 6800 peripheral space. The main objection to this was that that more modern 68K devices do not have the 6800 interface. The WDC 65C21 can be interfaced asynchronously, or some programmable logic can be employed to provide the missing 6800 interface (e.g. some steering logic around a 74HCT646 latched xcvr is really all it takes). I'll go the latter route if/when I get to the 68EC020 SBC.
At the risk of re-opening an old wound - I've found a stash of Z80 CIO chips (like the 6821 PIA, but more timers and supports vectored INT's and INT chaining!) that *appear* that they could interface to the 68K without too much hassle - anyone have any experience with making Zilog Z80 peripherals play nice with the 68K? These are $9 from mouser in the USA, for example, so not so much more expensive than the 65C21 PIA from WDC, but much more capable. I'm happy to drop this subject if we're all OK with the 6821 (or Mark's work-alike enhanced 6821 PIA circuit).
4) Interrupt strategy
The 68008 in DIP48 supports only 3 interrupt levels - 2,5, and 7.
I think that the DUART should be level 7 (it's the "host port", after all) and obviously support vectored INTs.
I think that the PIA should be level 2 (if it get an INT at all) and (naturally) autovectored (note, if Z80 CIO is used, this could be vectored also)
I think that the interrupt level 5 should be reserved for "future expansion" - I imagine that Lee will want to use LVL5 for a PIT and I think Mark and I would use it for an MFP, for example.
Of course, a non DIP 68008 and other 68K uC devices have all 7 levels available, so this is really a constraint only for us that want to use these darn DIP48 68008's.
I'll plan to use an Altera MAX7000 series EPM7128 in PLCC84 package. I've got about 21 free pins, and I'm sure I'm fine in terms of macarocells. These are parts I know and own, so that's why I use them.
6) other peripherals
My TMS9918/V9938 video and 6581 SID sound and other IO will be on a second board, interconnected via some sort of "standardized" bus (Mark had some suggestions towards this, that I need to review). I think that the standard needs to be electrically defined, but I don't expect any sort of "physical" standard to be adhered to.
7) DUART clock generation
I'll assume a packaged 29.4912 MHz oscillator for a "fast" CPLD clock (for internal states) and then divide this by 8 internally to obtain the 3.6864 MHz clock required by the DUART. I'm tempted to also divide 29.4912 MHz by 3 to get 9.8-ish MHz for the 68K. Anyone know if the 68K would needs CPUCLK to have a 50% duty cycle? I'd like to get a ~10 MHz CPUCLK to produce a ~1 MHz ECLK to make the 6581 SID chips happy. Worst case I'll toss down another oscillator, but I would prefer to avoid having two asynch clocks running amok inside the CPLD.
8 ) bus arbitration
I really like Mark's suggestion about a "helper" MCU to master the bus...but I'm not going to bite on that right now. It doesn't really have any effect on BIOS design, anyhow, so it's pretty transparent to EASy68K compatibility. So, I'm going to pull BR high with a resistor and leave that temptation for later...
I know that there are a zillion ways to accomplish the stuff I rambled on about here - but I'm very interested in hearing from others with helpful hints and suggestions, and also some feedback on the proposal for the IOP functionality, SD card interface, and the possible replacement of 6821 PIA with Z80 CIO. (flames cheerfully accepted on the last point)