Posted on

65816: Build 4 – Current Status – 7/15/2022

Build 4 – Current Specification

As of 7/15/2022, Build 4 has tested successfully with:

  • Both 65C02 and 65C816
  • up to 10 MHz where I started to get display glitches
  • 524k memory. Current configuration:
    • ~457k RAM ($0000-$F7FF, $20000-$7FFFF), 55 ns
    • ~67k ROM ($F800-$1FEFF), 70 ns
    • 256 bytes I/O ($1FF00-$1FFFF)
  • 65C22 VIA ($1FF10, shift register dedicated to PS/2 keyboard)
  • 65C51 ACIA ($1FF20, dedicated to smart display I/O)
  • 74HC logic bank address latch and data bus buffer
  • ATF22V10C PLD address decoder, interrupt logic and inverted clock
  • ATTiny85 (PS/2 keyboard controller)
  • DS1813 power on reset
  • Memory map supports up to 2 more I/O devices ($1FF40, $1FF80)

Notes

  1. I decided to change the memory map, expanding Bank 0 ROM to 2k dedicated for hardware code and read-only data. I liked the idea of totally separating the hardware and Forth related code, with the Forth system only interacting with the hardware system through specific routines. This makes the Forth system more portable by only requiring the operating system to provide a given set of I/O functions. The rest of Bank 0 is divided into 12k segments for 5 Forth instances with the remaining 2k RAM at $00F000 reserved for hardware variables. I moved the I/O page to the end of Bank 1, dedicating all memory above $20000 to expanded RAM. My idea is to have Banks 2-6 dedicated to up to 5 separate Forth instances with the remaining Bank 7 as extra free user RAM.
  2. In an earlier memory map, I was able to get Bank 0 ROM down to 256 bytes. At first, I couldn’t fit the code required within the PLD. I discuss this more here. With a bit of insight, discussed here, I overcame the coding problem I was having.
  3. In testing an earlier memory map, I discovered that the 10 ns ATF22V10C worked just as well in my build as the 7ns version I had been using. Given the tight timing I had been seeing, I thought this might not be possible. However, at this point my operating system is very primitive, so there could still be problems with the 10 ns PLD that aren’t apparent yet.
  4. The current Bank 0 memory map isn’t sufficient to run my 65C02 Forth operating system. I haven’t tested the build with a 65C02 since I expanded RAM.
  5. While the memory map can support 2 more I/O devices, the build can only process interrupt requests from additional ACIAs without modification.
  6. Speed testing was done with 32k of 12 ns RAM. I’ve since expanded RAM with a slower chip rated at 55 ns. It’s likely the performance at 10 MHz will be affected and perhaps even 8 MHz.
  7. The display glitches at 10 MHz could be explained simply by the 70 ns ROM I’m using. But the system seemed to run fine, absent some display glitches at startup, which doesn’t seem like a problem reading from ROM. This could also be explained by ACIA transmitter issues. This could be solved by tweaking the ACIA transmit delay time. Looking at my code it appears I did this when speed testing Build 3. I’m not excited enough about speed testing to be bothered to see if I can get Build 4 to 10 MHz glitch free operation. Maybe a long-term goal. Note that Build 3, which also got to 10 MHz before having some glitches used a 55 ns ROM.
  8. I saw keyboard entry glitches starting at 2 MHz. My PS/2 controller has a built-in delay to accommodate the 65C22 shift register external control requirements which might be causing this. It’s possible I need to tweak this delay with higher clock speeds. My code doesn’t note this though. I don’t recall if this code predates my Build 3 speed testing. For now, I’ll assume this can be fixed by adjusting the PS/2 controller code and leave it at that.
  9. Speed testing was done with the clock oscillator off board, resulting in a slightly longer clock line than the reference build. This is because Build 4 takes a half-can clock oscillator, but I only have these in 1 MHz and 1.8432 MHz. (7/15/2022 note: I realize now that I can just turn a full can oscillator on its side and rewire to allow me to test other speeds.)

Going Forward

I’m going to start modifying my Forth operating system to support access to the expanded memory. I think this will be fairly straightforward. Accommodating interrupts is the only wrinkle I’ve read about. The problem is the 65816 doesn’t save or restore the bank address byte on an interrupt. This could cause problems depending on how the expanded memory is used. I’ll have to think about that a bit.

To start, I’ll probably just use expanded ROM for storing Forth code that I’m testing. I currently store Forth code in my smart display’s SD card, but for testing it’s easier to just burn it into the ROM. Having a sizable addition to ROM is great for this. I was greatly constrained by the Build 3 memory map in this respect.

Longer-term Goals

I want to start modifying my Forth code to take advantage of the 65816. Right now it’s just running 65C02 code in emulation mode.

Attempt to resolve glitches when operating at 10 MHz including those associated with PS/2 keyboard input. If successful, try for higher speeds. I didn’t have the parts to do this with my Build 3 testing, but if I get the speed bug again this could be fun.

All that will probably keep me busy for the summer. I’ll keep the Build 4 status updated in this post as I reach major milestones.

Working with Expanded ROM (from: 5/5/2022)

Based on the troubles I’ve seen others have, at the start I was wondering if I would ever get the 65816 version of Build 4 working, at least without major changes to what should be a fairly basic build. Today, I successfully tested the expanded ROM in Build 4, which of course requires a correctly working bank address latch. It was a bit of a bumpy road to get to this point, but I’ve accomplished my goal of creating a basic breadboard 65816 system using a 74HC based bank address latch and data bus buffer.

As an added bonus, Build 4 can still be used with the 65C02. Just reverse the change discussed in this post, remove the 74HC573 and ground address lines A16 and A17. I’m not sure that it’s even necessary to remove the 74HC573, but I suppose it’s better not to ground those pins when the chip is trying to drive them high. Probably wouldn’t help the build’s current draw either.