rhombus

Soon I will be adding keyboard and an LCD to make this a self contained unit. There are quite a few older style LCDs, mostly monochrome, but I will likely opt for something newer which has color. 8-bit parallel LCD interfaces tend to be very similar, physically at least, so I don't feel too bad about using a modern panel because I can always switch it out to something ancient whenever I like with minimal code changes.

The issue of the keyboard is a different story. I looked around to see how other 68k family boards work with keyboards, but I really couldn't find much. Most newer 68k designs end up using a microcontroller such as an Arduino to feed the keyboard data into a UART. Besides not being retro, such a solution is also not very elegant in my opinion. It is an easy solution, however, but I'm not too keen on easy. What to do?

As luck would have it, I stumbled across an old Intel N8042 in my vast collection of deadtech. Intel and Motorola on the same board? Yeah, this is pushing all of my buttons... it needs to happen.

After discovering another mistake in the original application note, I resolved the issue with _IACK generation and the MC68901 came to life on the timer side. Unfortunately with an 8-bit timer, it is really unlikely that I'll get the accuracy needed for timekeeping, but I can do some basic multitasking now.

Thanks Motorola guy.

See if you can spot the problem...

Turns out that little interrupt mask was a thing...

ANDI.W  #$F0FF,SR
ORI.W   #$0300,SR

YAY... so now after _IRQ is driven low by the MC68901, the CPU responds by driving _IPEND low, and within an instruction's time, just like the document claims, the CPU sets FC0, FC1, and FC2 high to indicate CPU space (FC0 usually is the inverse of FC1).

So now what? Well, I'm not getting an _IACK on the MC68901. _DS is being asserted by the CPU, but the MC68901 won't supply the needed vector and subsequent _DTACK assertion unless _IACK and _DS are both asserted. :( Looks like a bug in my CPLD code.

Time to investigate. Bear with me folks, this stuff is all new to me. I'm one of those "learn to swim by jumping into the shark tank" types...

I have configured the MC68901 TimerA and it is driving the _IRQ line low. The logic analyzer output shows the results of enabling the timer after configuring the interrupt registers...

The _IRQ line is tied to _IPL2 on the 68020 along with a 3K pull-up resistor. _IPL0 and _IPL1 are pulled high. Not even getting _IPEND on the CPU to go low. Think it's time to double-check the interrupt mask, LOL. I'm going to feel stupid if this is the only thing holding me up.

Taking a very short break while I try to get Lee Davidson's wonderful EhBASIC interpreter running on my board. Not going to completely stop developing since I'll be creating TRAP code, etc. which will be useful in the future. I expect that this will take 2 or 3 days tops. This will also serve as a test to determine what functionality is lacking.

Once this is done, I'll go back to adding features, most notable, a way to load S-Record data over the serial port.

As far as new hardware is concerned, I'll either work on a video display + keyboard input, or I'll work on trying to interface an old SID sound chip that I have and see if I can get some good ol' 8-bit audio going.

Got memory dump working!

I posted a youtube video after getting the RAM sizing code implemented. The board properly detects the 32K SRAM part. Arduino Mega in the video is attached via a 6-pin ICSP header and is only providing power. Astute viewers will note the lack of a TX line going to the UART... this is because my ROM monitor doesn't actually handle input yet. :D

Next step will be a memory exerciser for the RAM. I already test the first 1K (where stack/vector table resides), but I needed to size the RAM prior to testing the remaining addresses.