#logisim

Bus Translation

Through the 1990s, home computers made a slow transition from 5 volt logic to 3.3 volt logic (and continued down from there). The PowerPC 403, introduced in 1994, is a good example of this transitionary period. The CPU core itself runs at 3.3V, but it supports both 3.3V and 5V logic.

Since 3.3V peripherals are more common today, my plan was to use this as an opportunity to start making that shift from 5V to 3.3V myself. My initial minimal functional build used 3.3V ROM and RAM. And my plan was to use an FPGA (3.3V I/O) for generating video and interfacing with an SD card (also 3.3V I/O).

Then I found some fun new old stock video chips on eBay, and a poll on Discord encouraged me to lean in hard with the S3 ViRGE — a 5V part. My 3.3V ROM & RAM are not going to appreciate the 5V signals coming from the data bus on the ViRGE, so I'll need some level-shifting bus transceivers. This will section off my data bus into a 3.3V bus and a 5V bus.

Being an embedded processor, PowerPC 403GA has a lot of nice features for making it easy to interface with peripheral chips. But I'll be using the ViRGE chip configured for VESA Local Bus — a bus that is pretty tightly coupled with the Intel 386/486 bus. Most control signals between the two should be compatible, but I will need some additional glue logic to handle the VLB Address Strobe & Ready signals as well as logic to enable the level-shifting bus transceivers. So ultimately I'll end up with the 3.3V PPC403 bus and something approximating the 5V VLB.

I have a spare ATF22V10C programmable logic device that should work well for the minimal glue logic I'll need to connect my 3.3V bus to my 5V bus. These Atmel PLDs are programmed with CUPL, a minimal logic description language I've only used once before on my Wrap030 8-port serial card. It's not terribly difficult, but does require some detailed knowledge of the inner workings of the PLD's logic cells (for instance, I had to rework my logic after realizing all registers share the same reset & preload signals).

I used logisim to help plan out what logic I needed. The Address Strobe generation was the trickiest part; I needed to make sure it would only be asserted for one clock cycle at the beginning of the bus transaction. After a few revisions, I had something that would compile without error. I even learned how to use WinSim, the PLD simulator companion to WinCUPL.

Everything looked right in the simulation, but there are some quirks in how active-low signals are handled in CUPL and in WinSim. I wasn't entirely sure I had gotten my signal polarity configured properly. Simulations are great, but sometimes nothing will quite beat hard testing with a row of switches and a small forest of LEDs.

At human testing speeds of sub-1Hz, everything looks to be working as expected!

🎉 Applied for my Associates in Science today && had ramen! 🎊

This is a small step for my long term goals but either way it’s a fun step somewhere new.

Things may never go the way you plan and your goals could always change. Do what’s best for you, in the time of your life that is right.

Finally making some progress on the 6502 homebrew front panel logic.  I tested a half-sized version of the address access/increment logic, then drew out a more detailed view on paper for the full sized version.

I’ve also simulated the data entry/access/alteration logic for a single bit.  Now I’m testing/debugging it in meatspace, with real chips. 

I’m learning a few things:

I’m not all that skilled in wiring up actual 7400 series logic chips

Theory and practice aren’t as close as I expected here

I can still make progress and figure out what I’m doing wrong

Don’t reverse the polarity on a chip, then touch it.  You will burn yourself.

Logisim is cool

Never leave an input floating

On to the Next Problem

I finally have RAM working properly. I had to remove support for interrupts from the UART to free up enough I/O pins in my glue CPLD, but byte- or word-length writes to RAM no longer overwrite adjacent bytes. Both BASIC and TSMON are now able to initialize completely and reach their first user prompts.

Unfortunately, that is all they do. The system does not respond to user input.

I double-checked my wiring and ACIA initialization data. I even removed the MAX232 level-shifter and used a USB-TTL serial adapter. When I send serial to the UART Rx pin, it never sets the Receive Data Register Full bit in the status register.

I threw together a quick test program to read and output the values of all of the ACIA registers. The Command and Control registers always report back their correct values, the Status register never changes, and the Rx Data register is always $00.

I reread the R6551 data sheet over and over, trying to see what I might have missed. Eventually I did notice a small note:

NOTE: The specified maximum cycle time for the signal on [Phi2] is 40µs. This specification must be observed to prevent loss of data

When I was building out my glue logic, I couldn't think of a way to synchronize a bus cycle with a 1MHz Phi2 clock, so I decided to not have a running Phi2 clock. Instead, I used Phi2 like a data strobe, only asserted when the CPU read from or wrote to the ACIA. Based on that note however, it is possible that the 6551 uses the Phi2 clock for more than just bus transactions. So I sat down and finally figured out how to synchronize a bus transaction with a running Phi2 clock.

I started with a clock divider that divides the 25MHz system clock by 32 to produce a Phi2 clock that's just under 1MHz. I used the falling edge of the Phi2 clock to latch the internal ACIA-enable signal and start up a state machine that handles proper timing for the ACIA chip-select and CPU !DSACK0 signals. This ensures that no matter what point in the Phi2 cycle the CPU starts a bus transaction with the ACIA, the ACIA will be activated with proper setup time before the next falling edge of Phi2, and the CPU will not end the bus transaction too early due to receiving !DSACK0 before the ACIA can produce or latch data.

I started by solving the K-maps for the state machine, then built it out in Logisim to make sure it would work like I expected. Then I moved into Quartus to program it for the CPLD. Running the simulations in Quartus I was able to see that I was activating !DSACK0 too early, and the CPU would have ended the bus cycle some 120ns before the falling edge of Phi2. Update the state tables, re-solve the K-maps, update the logic, recompile, re-run the simulation. Everything looks good, time to re-program the CPLD.

The new logic works! Phi2 runs its constant sub-1MHz cycle, and the UART transmits serial data just like it should.

But still nothing from the Rx Data Register.

At this point, there really is only one thing I haven't tested. I pulled out the logic analyzer and attached it directly to the Tx/Rx pins on the UART.

The logic analyzer confirmed that valid serial data was making its way from the terminal, through the MAX232 level shifter, and on to the UART'S Rx pin.

And somehow the UART still doesn't pick it up.

Generating Errors ... In a Good Way

I finally have a functional bus error generation circuit. Now if the program attempts to access an invalid address, the computer will time out and assert !BERR. This will generate a Bus Error Exception, which the program can catch and deal with appropriately. In the case of TSBug, a bus error will output the contents of the CPU registers for debugging.

I started designing this circuit in Logisim so I could make sure it ran as expected in simulation before I even started trying to build it on a breadboard. I was able to reduce it do to a minimal chip count - only adding a 74′74 dual D flip-flop, and a 74′08 AND gate to the computer, and using a couple spare inverters and a buffer for the !BERR signal.

The circuit worked just as expected on the breadboard. I soldered it into place and ... it didn’t work. I removed the CPU from the board and tested the circuit manually with switches and LEDs and it worked as expected. Replaced the CPU and it didn’t work. 

It didn’t make any sense. It worked just fine with the CPU when I first tested it on the breadboard, so why did it not work now? I pulled out the continuity tester and verified everything matched the schematic multiple times. It just didn’t make sense.

Finally, I pulled out the logic analyzer, moved the 74′74 onto a breadboard so I could monitor each of its signals, and stared at the waveform diagrams for far longer than I care to admit. 

In the end, the answer was painfully obvious. On the breadboard I had grabbed a spare 70′04 inverter for testing. When I soldered the circuit into place, I used a couple extra inverters on the 40106B Hex Schmitt Trigger I was using for the Reset circuit, since it was closest. The 40106B simply wasn’t fast enough to keep up with !AS. Worst-case propagation delay for the 40106B is 280nS versus only 25nS for the 74HCT04 I had tested with on the breadboard.

So, I upgraded. Instead of the old 40106B I had used because it was what I had on hand, I now have a 74HCT14 to run the reset circuit and to provide the two extra inverters for the bus error generator. Now !BERR works, reset still works, and I didn’t even have to break out the soldering iron to fix it.

I’ve been able to revise the simulated circuit a bit and solve some issues.  I have a RAM model that actually matches the way my RAM will work in meatspace.  I’ve reduced the chip count for a full 8-bit data bus from 18 to 14 total chips by swapping out the AND gates for buffers.  

Panel | RAM |  Examine   0      |  0     |   0   1      |  1     |   1   1      |  0     |   1  <- should be a 0   0      |  1     |   0  <- should be a 1

I’ve also alleviated one of the problems where pressing Examine would favor the panel over the RAM, specifically when the RAM had a 1, and the panel had a 0.  Now I need to do the same for the inverse. 

Panel | RAM |  Examine   0      |  0     |   0   1      |  1     |   1   1      |  0     |   1  <- should be a 0   0      |  1     |   1

Problem Solved, in theory.