We took a little detour into the world of the Interak’s VDU system and have a reasonable approximation of the VDU-2K, LKP1 and PCG cards working on the Raspberry Pi Pico (handling display, keyboard and user character set).

BBZ80

My homebrew BBZ80 machine (an RC2014-bus compatible computer I’ve been slowly building) has an Amstrad CPC 464 style memory map at the moment. I haven’t really posted much about that past the original couple of posts; but in short it’s based around the RC2014 bus, has a Z80A running at 4Mhz, 32K ROM (upper and lower), and 64K RAM. It uses the CPC’s RMR paging system:

Address	Page	RAM	ROM
$0000-3FFF	0	RAM0	ROM0
$4000-7FFF	1	RAM0	X
$8000-BFFF	2	RAM1	X
$C000-FFFF	4	RAM1	ROM1

I have set all this up using GAL22V10 which implements part of the Amstrad’s RMR logic. The BBZ80 has two cards, a 32K ROM card and a 64K RAM card (with 2x 32K SRAM chips). The ROM card has the GAL on it and has two signal lines connected to the RAM card; RAM0_CS and RAM1_CS.

Aside from the CPC-like memory map, I’m actually pretty close to being able to call my BBZ80 machine an Interak-like machine apart from one detail - the Power-on ROM (PROM). I covered it more completely last time, but let’s recap.

Power-on ROM

The PROM functionality is designed to map a ROM into the $0xxx address range, leaving it there until IN A,($FF) is called. It’s designed to act as a boot ROM, often just copying itself to RAM and warm-restarting the machine. In order to recreate the Interak on the RC2014 bus we’ll have to implement this feature as it’s a little different to other systems.

Original Interak PROM

This one has two parts; a permanent 4K ROM at page $E (e.g $E000-$EFFF) and a temporary mirroring into the rest of the readable address space.

The basic logic for driving the chip select lines would be:

    if [/MREQ]:
        if [/WR]:
            if [a15]:
                /RAM1_CS = active
            else:
                /RAM0_CS = active
        if [/RD]:
            if [PROM]:
                /ROM_CS = active        # ROM temporarily mapped everywhere
            else:
                if [a15-a12] == %1110:  # ROM permanently mapped to $Exxx
                    /ROM_CS = active
                else if [a15]:
                    /RAM1_CS = active
                else:
                    /RAM0_CS = active

The address lines A11-A0 would be wired up to the ROM, any other spare would be pulled low (or high, depending on how the ROM would be flashed).

The /PROM signal would be active on boot - an /IORQ /RD (and/or /WR) to $FF would deactivate this.

The logic here would be:

    if [/IORQ]:
        if [PROM]:
            if [a7-a0] == %11111111:
                PROM = inactive
    if [/RESET]:
        PROM = active

New School Interak PROM

Further analysis of the new new community version of the PROM circuit made me realise I missed a key detail; the PROM isn’t mapped to $0000, it’s physically located there and can occupy up to 32K. The PROM disable system unmaps the entire ROM from the address space.

This gives us a boot-time memory map of:

Address Range	Description
$0000-$3FFF	Boot ROM (lower 16K)
$4000-$7FFF	Boot ROM (upper 16K, or mirror of lower 16K)
$8000-$FFFF	RAM

Logic-wise, it’s pretty simple:

    if [/MREQ]:
        if [/WR]:
            if [a15]:
                /RAM1_CS = active
            else:
                /RAM0_CS = active
        if [/RD]:
            if [a15]:
                /RAM1_CS = active
            else:
                if [PROM]:
                    /ROM_CS = active        # ROM temporarily mapped < $8000
                else:
                    /RAM0_CS = active

The new school system also reacts to any I/O request (any port, any direction) and unmaps the ROM until the next reset.

    if [/IORQ]:
        PROM = inactive

Once unmapped, the ROM is totally unavailable to the system until the computer is reset. I guess in principle it’s similar to the original, but in practice it does make a difference.

As I mentioned previously, ZYMON won’t work with this system as it jumps to a location in page $E and then calls the unmap logic whilst the program counter is still in that page. On a new school system this will crash because it has the effect of ripping the rug away from under the processor, leaving it sat in uninitialized RAM. Likewise, on an original system the newer CFBOOT ROM doesn’t work properly as it expects the ROM to be paged out from page $E and there to be RAM there.

Implementing a PROM

So what do we need to do to make a ROM card that supports the PROM functionality?

The primary choice we have to make is whether we’re trying to support the original Interak system, which has 4K of ROM permanently at $E000, or the new one which maps in a 16 or 32K ROM and completely unmaps it when the PROM is turned off?

I played about with the logic using circuitjs and came up with some logic which should support both systems via the use of a SPDT switch.

This circuit is very likely non-optimal; I created it with the gates I have to hand rather than what’s the perfect choice.

I decided that the full decode of $FF probably isn’t worth it for the PROM; so duplicated the logic of the new variant in that any /IROQ signal turns off the PROM.

One of the quirks of my BBZ80 machine is that I have the RAM split across two 32K chips; this was largely because they were what I had to hand. It does make the RAM select signal a little awkward but I’ll have to live with it until I redesign the board around a bigger RAM.

Mistakes were made

I built a quick & dirty prototype board from the above logic and found a fatal flaw (and no it’s not the wiring!).

The /ROM_CS always activated on the “classic” select regardless of /RD status. This meant it would be impossible to write to RAM as the ROM was always paged in. Doh! I’d even written out the logic, I just forgot to account for it when laying out the logic gates.

For the new school mode they totally ignore upper RAM whilst PROM is active, so it doesn’t matter.

It should be easily fixed by adding an OR gate to /RD after the /ROM_CS_ORIGINAL signal before the switch. Unfortunately for me and my non-optimized circuit, it means adding yet another IC to the board. Ah well, it is a prototype after all. When this eventually works, I’ll like look at consolidating a few things into single cards (RAM, ROM and mapping, for example). It might even be more sensible to collapse all of this into a GAL as I did with the BBZ80’s mapper.

Wrap up

With a PROM mapper card for the BBZ80, I should be in a position to try and boot ZYMON one of the original Interak monitors. We’ll explore this another time.