Saturday, 28 December 2024

Freebee Fremium Production Release

I've spent a week or so of my holidays getting the Freebee Fremium design ready to go out. I am hoping that the changes I've made to speed up video RAM access work without a further respin, so have done all the little clean-up bits that one does in moving from prototype to production. Most of the changes are subtle, intended to improve buildability, such as:

  • Adding part descriptiors under all the ICs, and in lovely inverse font too.
  • Moving the two keyboard scanning ICs up just a little, to give a bit more gap to the keyboard stabilisation bar.
  • Cleaning up the designators for the jumpers, so they're from A-Y across the board, making them a lot easier to find.
  • Integrating a tiny speaker on the PCB.
  • Adding a QR code with a link to the design files.
  • Rationalising the number of decoupling capacitors, plus moving 100nF ones to spots where they'll do the most good.

In terms of actual changes to the way the machine works, we have:

  • The improvements to CPU video access, as discussed previously.
  • Bringing the BSTB and BRDY signals from the PIO out to the GPIO connector in addition to the ASTB and ARDY signals plus port A0-A7. This subtle change allows using the GPIO connector as a high-speed synchronous bidirectional port, using PIO mode 2. I've got this idea for plugging things (generally involving an Arduino Nano) into the GPIO port that allows such things as super fast USB comms with a computer, SD card interface, etc etc. However as the Arduino Nano is sure to be obsoleted in about five minutes and become impossible to get, I don't want to design that onto the main board.
  • Allowing the machine to invert VSYNC, by simply changing the video starting address in the CRTC (much as is done for small fonts). This gives us the ability to pretend our video is EGA rather than CGA. Without changing our dot clock to 16.257 MHz we can't make full EGA resolution, but we do (I think!) have enough video speed at 13.5 MHz to do a 466 x 350 (58 x 25 characters with an 8 x 14 font). This is actually kinda special, as this means the pixels are pretty close to square.
  • A caps lock LED. I just connected this to LV6, an unused port bit.

There's also a couple of small mechanical changes, mainly around pushing the DIN connector back a few millimetres to get it in line with the D connectors. This necessitated making the PCB a bit bigger, and adding small notches to clear the tabs either side of the DIN connector on the Microbee case. I suspect that Applied Tech originally planned to do just this, but the cost of putting the notches in to the PCB put a kaibosh on that, and instead they just moved the DIN connector back into the case a bit.

A couple of screen grabs of the 3D model:

And the schematic pages:

Design files are on my google drive.

Here's the first one mostly assembled. I've had to steal a few ICs from the prototype, and have made a Digikey order for replacements. Mouser didn't have the 9 pin video connector in stock, so hence Digikey. I've decided to go with Gateron brown keyswitches, as whilst the Cherry MX blue ones feel divine to type with, they're shockingly noisy, meaning I can't play with it late at night. Now that I'm writing software for it I need to be able to use it in the wee hours. The brown ones still have a tactile feel, but without the click noise. I'm resisting the (strong) urge to rip other things apart to harvest parts to complete this.

And complete. There are two issues with the board, requiring three bodge wires to make it work. The first is a rookie mistake. Doubling the video RAM access rate means that the eighth slot is now CPU, not character. So using a simple 3 input NAND gate on the clocks to generate a low pulse for load means that it occurs after the character read. We must load the shift register on the /CHCK (seventh) instead. So cut the /LOAD net source (IC46 pin 12) and instead use /CHCK (IC4 pin 9) to drive the /LOAD net.

Additionally, the phase of the dot clock is incorrect relative to load. This didn't matter for the lower speed access, as the character read was enabled in the cycle prior to needing it. Now we've only got one cycle, and need that whole cycle to allow for address setup and read to propogate through the video RAM. By inverting dotclk for the shift register the rising edge of dotclk is now coincident with the end of the /CHCK pulse, giving us ample time for the video read.

And running at an unprecedented 13.5 MHz, using a 20 MHz Z-80, doing video writes and everything.

Saturday, 21 December 2024

Getting Freebee Premium to run at 13.5 MHz

Late model Microbees generally run at a 3.375 MHz CPU clock. The Peter Broughton 512K OS included a scheme for doubling that to 6.75 MHz, which was generally problematic. I really want Freebee to run at either 3.375 or 13.5 MHz - ie a full four times the original speed - selectable by software. On the prototype I was cowardly and included a jumper so that the fast speed could be jumpered to either 6.75 or 13.5 MHz.

Turns out the jumper was a good idea, as I simply can't get video CPU read and writes to work reliably at 13.5 MHz. Everything else works a treat (for example talking to the CRTC and the PIO, plus normal memory reads and writes). Additionally my video arbitration logic stops CPU access until the retrace period, so often there are whopping great 60usec long access times.

I've been working on a scheme for more rapidly swapping from CRTC access to CPU access for the video RAM. It involves doubling the RAM access speed (again!), and inserting a CPU access in between each video access, so screen, cpu, attribute, cpu, colour, cpu, character, cpu etc.

Life is complicated with the Z80 because unlike a 6800 it does accesses across multiple clock cycles. Morover, the accesses are wildly different for opcode fetch and other reads, incuding a requirement that the data is valid on the rising edge of the CPU clock for opcode fetch and falling edge of the clock for data fetch. Go figure.

So here's the scheme I'll be prototyping to make that work. It involves separating reads and writes out. Writes are just done via a straightforward buffer to isolate the CPU data bus and the video RAM data bus, but for reads, we use a register to hold the data from the memory, clocked at the end of the (short) access cycle, and present that data to the CPU data bus for as long as it needs it.

The flip-flops that hold the CPU in wait until the retrace period are gone, and replaced with a straightforward 1 clock wait state generator. This is needed to make the CPU wait long enough for data at 13.5 MHz.

Now to design this into a new PCB. I've ditched a component in the old wait state generator, but added one in the data bus flip-flop, so it should be even in terms of component count.

Saturday, 14 December 2024

Freebee Pi

Just musing for now, but how cool would it be to make a simple board with a Freebee keyboard, space for a floppy controller, normal bee serial and parallel ports, plus power etc., and then just whack a Raspberry pi zero on it to do all the compute magic. Really easy, quick, and cheap to build, and gives the hardware bee experience but using an emulation in the Pi, so it just plugs into any old HDMI display.

And showing how I randomly change directions in stuff like this. I bought a very cool Keychron keyboard recently, ironically with the intention of having soimething I could steal keyswitches from, as it's keyswitches are socketed. It's a cool keyboard (I'm actually using it now). But as well as the socketed keyswitches it does really nice bluetooth, so I can use it anywhere. Of course I pulled it apart and it's got an little processor that does the work with a bluetooth module.

This leads to some inevitable interwebs research, and I found that there's whole libraries of HID (keyboard) stuff that's completely open source. And Adafruit do a phenominally awesome ESP32 "Feather" module that has integrated USBC and Bluetooth, that has all the brains I need. Further wandering around the Adafruits website showed me the Adafruit floppy wing that does a whole floppy interface WITHOUT NEEDING A FLOPPY CONTROLLER! (Please excuse the shouting).

But once I've spliced the floppy interface onto the feather, I haven't got enough GPIO left for my keyboard... What to do? A bit more searching shows the incredibly well supported MCP23S17 16 bit SPI IO expander, which is like a Z80 PIO but with an SPI interface to the processor.

So now the whole direction of the project has changed. What if rather than just doing a Microbee clone in a Raspberry PI, we instead do a PC/Mac/Linux/Whatever peripheral, that can connect via USB or Bluetooth, that gives the host access to Microbee floppies (ala uBeedisk), a Microbee format keyboard, Microbee tape I/O, Microbee compatible serial connector, and even the 15 way GPIO port. Just plug it in (or pair it and get the power from a normal Microbee plug pack), and play. You can use it as a keyboard (I'm that perverse) or run a uBee512 and use it as the keyboard for your emulator...

This is what the board is looking like so far. There was a bit of extra space so I added a second feather device. This can be an OLED display, or sound interface, or really whatever you want. I've tried to limit the use of GPIO as much as possible (using the SPI expanders) so that most of the GPIO pins are free for use by the feather.