Here is a picture of Tiny302 posted earlier with the addition of a seven-segment/LED/switch display. The display is compatible with the simulated hardware display in Sim68K so the software that runs in simulation will run on this hardware. It is a memory-map implementation so there are actual 8-bit latches resides in memory locations as documented in the EASy68K Help. The LED and 7-seg displays are power hogs, drawing about 15-20mA per segment so it consumes over an amp @5V when it is fully lit. The challenges are using drivers that can source the required current, yet not too powerful to require current limiting resistors everywhere. I used a stack of 3 silicon diodes to raise the output voltage of HC drivers (74HC273 & 74HC240) to over 3V which begins to limit its output currents--it is not a textbook design, but does work.
This design is probably meant for pc board. It is pretty tedious to hand wire all these connections. I thought about using Altera's 7128S CPLD, but there are more connections than can be fitted in a 84PLCC and current drive capability is an issue, so discrete TTLs on pc board is probably the right implementation.
Half way into wiring the board, I thought of another way of doing this that's quite a bit simpler in logic and interconnects. It requires the CPU to drive each 7-segment display in rapid succession and relies on persistence of vision to blend them into one solid image of eight 7-segment display. It does not need connection into actual address & data buses so I can use the 82C55 peripheral chip on the repurposed 68302 SBC to drive the simplified hardware display. That should be an interesting project next.
I found a couple MC68302 in PGA package buried in my junk piles. So I constructed a more rugged Tiny302 prototype to experiment with. It is certainly a better looking prototype. It is the same design with 8-bit wide data bus using 128Kx8 Flash and 128Kx8 RAM so the existing monitor/debugger runs on it as is. Running at 16MHz with zero-wait memory, it's performance is roughly that of a 8MHz 68K with 16-bit wide bus. Except for a few SMT bypass caps, this is a thru-hole design, down to a dozen or so of discrete carbon resistors. I plan to build EASy68K's 7-segment/LED/push button hardware on the remaining prototype area using the same thru-hole component technology.
The schematic of the prototype is done using a very old tool, IVEX's Windraft. IVEX is no longer in business, but I've purchased the license for both schematic and board layout tools a long time ago. Windraft seems to run OK in Windows Vista, but the version of Winboard I have needs to run on older WIndows operating system. If anyone knows how to get Winboard to run in newer Windows, please let me know.
The board grew larger. I've had memory diagnostic errors and I thought it may due to noisy 5V so I added a 5V power plane to beef up the 5V power. It turned out it was due to a faulty documentation of the 128K static RAM. Two of the pin assignments were incorrect! Once that was corrected, the memory diagnostic passed. I also added a RS232 transceivers to interface with the serial port--the funny looking connector at the right edge of the board mates with pin 2, 3, and 7 of a serial cable.
The software development went well. It currently is running a monitor/debugger of my own design. It does the basic file load, memory read & write, breakpoint and trace functions. It also has a RAM/Flash remap command so Flash is mapped to high memory while RAM mapped to $0. With that I'm able to load a modified Tutor v1.3 and see it running. So I guess I'm done with the board. I'll pour epoxy over the surface mount parts to keep them from shorting.
Below is a screen shot of Tiny302 booting up; a help menu of the monitor/debugger; remap command ('sw') to swap RAM and Flash; load the modified Tutor; and Tutor help output.
A quick hand sketched schematic show there are only about 60 address + data + control connections, 25 power/ground, and about 15 hardware configuration connections. The address/data/control connections can be reduced to 30 if the RAM and flash are stacked together, piggy-back fashion, since so many RAM and flash signals have the same pin assignment and share the same connections.
I have 128K RAM and flash in DIP package, but I don't have 68302 in PGA. You can buy them off eBay for under $20, but I thought I'll try with a quad flat pack 68302 that I removed from a 68302-based SPX-MPU board. (I removed all components so I can reverse engineer the pc board connections). The lead spacing of the QFP is 25 mil, so I have to work under a microscope and it will take more than an evening to wire 60 or so connections to the QFP.
I want to have a solid digital ground, so all components are mounted on a single-sided 2"x5" copper board, copper foil up. Most of the copper foil is digital ground except areas carved out for other signals such as pads for the piggy-back RAM and flash. The piggy-back RAM/flash is soldered to the board because I need solid mechanical support to insert and remove the flash multiple times.
The QFP 68302 is glued to the board, dead-bug fashion. Ground leads are bent down toward the copper foil for short ground connections and Vcc leads bent toward the center where a 5V ring will be constructed. A third of way into wiring, after ground/power were connected and all hardware configuration finished, I connected the 16MHz oscillator and power up the CPU with oscillator. I can see chip select 0 puts out 8 successive pulses to fetch reset vector and system stack and repeat every 1 millisecond. That means the CPU is probably OK, even though I'd treated it rather badly when removing with a heat gun. Soldering 60 or so connection to the QFP 68302 was challenging and it did take more than an evening. I know I can do it 10 years ago and I'm glad I still can do it. Nevertheless I'll stick with the PGA package on the next iteration!
This is the finished board. It can fetch reset vector and execute an endless loop of NOP so flash is working. I'll need to test the RAM next and then bring up a simple bootloader.