Although the CPU, ROM, and RAM were simple enough to get running, I struggled quite a bit more with the DUART. I assumed it would be simple enough to port my glue logic and software from Mackerel-08, but there are a lot of moving parts in the 8-to-16-bit transition that all need to change at once. Testing just the hardware or just the software in isolation isn't really possible.
The first hurdle was proving that the DUART was connected correctly and that it could be addressed at the appropriate memory addresses. I thought I was making my life easier when I set up some memory-mapped LEDs in the CPLD. Eventually this was extremely useful, but only after I remembered to add the RW pin to the decoding logic for it. This issue and my general inexperience with Verilog cost a few hours of debugging time, but eventually the serial port was screaming `AAA...`.
With a working serial port, my attention turned to software. I've already got a bootloader/monitor tool for Mackerel-08 that works well, so I started porting that to the new board. The two big changes going from the 68008 to the 68010 are a new memory map and the 16-bit wide ROM. The memory map is simple enough - just copy the .scr files from Mackerel-08 and modify the ROM and RAM locations to match up with the address decoding in the CPLD.
Since each ROM chip is only 8-bits wide, but they are both addressed simultaneously by the CPU, the resulting binary code needs to be split in half. The simple way to do this is using `objcopy`. I updated the Makefile to do this:
%-upper.bin: %.bin
$(OBJCOPY) --interleave=2 --byte=0 -I binary -O binary $< $@
%-lower.bin: %.bin
$(OBJCOPY) --interleave=2 --byte=1 -I binary -O binary $< $@
I found an example of this on Lawrence Manning's blog. He's built a few different 68k machines and I've learned a lot reading through his posts about them.
While I was making changes to the Makefile, I added support to build all of the existing code for either Mackerel-08 or Mackerel-10. There are a few #ifdefs in the C code to handle the differences in hardware, but most of the heavy lifting is done by the Makefile itself.
A working serial port and a working bootloader meant I no longer had to pull and flash two ROM chips for every code change. I could use the serial bootloader and load code directly into RAM. Note to self: ZIF sockets would have been worth the extra board size and cost on a first prototype. My fingers are sore from pulling the ROMs so many times.
The final subsystem left to debug was interrupt handling. I ported the GAL logic from Mackerel-08 into Verilog for the CPLD and I set up all the pin mappings. Annoyingly, as soon as I enabled interrupts at all, the system would immediately receive one and jump to the unhandled user interrupt exception handler. After carefully checking the Verilog and C code, I realized that the DUART's IRQ output was always low (i.e. active). It turns out that I forgot to put a pullup on that line in Mackerel-10. Mackerel-08 has one and the datasheet specifies one as well. With the pullup in place, the vectored interrupts from the DUART were working just as they do on Mackerel-08.
With that small bodge in place, Mackerel-10 is fully tested. It functions just as well as Mackerel-08 minus some RAM and storage. The next step is to start implementing a DRAM controller!
Once I was happy that the 68010 was working, I had to push my luck and try this adapter for the MC68SEC000 that I made. It's designed to be a drop-in replacement for the DIP-64 processor. I assembled this adapter using the drag soldering method and plenty of liquid flux. I manually cleaned up a handful of bridges and scrubbed the excess flux away with alcohol then soap and water. I'm quite happy with the end results. I am even happier that it functions just fine slotted into Mackerel-10.
The icing on the cake is the insane clock speed. I was running the 68010 at its full 10 MHz rating, but this 20MHz-rated SEC CPU actually ran perfectly for me at 40 MHz! I didn't do exhaustive testing at this speed, but the monitor ran just fine and the memory and DUART seemed to have no issues keeping up. This definitely warrants some stress testing and I still plan to design around the 68010 primarily, but I am really looking forward to seeing how uClinux runs at 40 MHz and how far I can push the speed (40 MHz is the fastest oscillator I currently have on hand).
This adapter PCB is available on Github: https://github.com/crmaykish/adapters-and-breakout-boards/tree/main/MC68SEC000-to-DIP-64
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
I can't put my finger on it but something about this board smells fishy. ;-)
Are you sure? yes | no