I’ve been continuing my exploration of the Interak Computer System as part of my effort to emulate it. Emulating this thing is somewhat tricky as there was no real “standard” configuration; the Interak was designed to be hacked on and customised by the owner meaning that there are quite a few bits that can vary.
I’ve decided that there’s a few main “targets” for emulation:
- ZYMON2 (32/64 column) cassette based system
- DMON (32/64 column) disk based system
- CP/M (80 column) compact flash based system
The first two are “original” ZYMON/DMON-based Interak systems from the 1980’s, the latter is based on the work of the current enthusiast community.
It’s worth looking at the differences between the two groups, which I’ll refer to as “Original” and “New School” from herein.
| System Component | Original System | New School System |
|---|---|---|
| RAM Pages | 16 x 4K switchable slots | 64K contiguous |
| VDU | Z80-based, 32 or 64 columns hardware switchable | 6845 CRTC-based, typically 80 columns |
| VUD | RAM R/W by main system, mapped via slots | RAM mirrored from main system, cannot be read from board |
| Power-on-ROM (PROM) | Port $FF read, disables | Any port read disables |
| PROM | Not unmapped from ROM page | Unmapped from ROM page |
| Storage | Tape or Disk, separate cards | Compact Flash integrated on Z80 card |
RAM
Let’s start with the RAM. It’s relatively minor, but it does have a few knock-on impacts in other areas.
Back in the day RAM was relatively expensive and required several ICs. Home computers would typically come in 16K, 32K, 48K or 64K variants (before software controllable banking pushed to 128K and beyond). The Interak was initially sold with 2114 SRAM, which were 1024 x 4bit ICs. These were paired up to make 8-bits, and then grouped up to form 4K banks. Each 4K bank (or slot) was formed from 8 ICs, which took up a lot of space and would have cost a fair bit to get to 64K.
The Interak accounted for this by organizing its memory map into DIP-switchable 4K slots, allowing the user to put RAM anywhere they wanted and then turn off the slots they were using for other things.
In 1985 Greenbank Electronics began selling the DRM-64 card, which was a full 64K of cheaper 8 x 4564 DRAM ICs. This also had the DIP-switchable 4K slot scheme to be compatible with existing systems.
The New School variants come with 64K as standard (a single 128K SRAM chip) and do not support the DIP-switchable 4K slots.
PROM
The Interak has a “power on ROM” (aka PROM) feature that mirrors the ROM the lower address page. This allows the ROM (typically at $E000) to be visible at system boot (e.g address $0000) so the Z80 can execute meaningful code. The PROM is typically designed to copy itself or other “boot” code into $0000 and then cold restart. Most PROM code I’ve seen so far does a cold start check to figure this out.
One the PROM has done its thing it then pages itself out and reboots. The Original Interak and New School variants have a slightly different set of behaviours here.
The first is that on the Original system, the ROM was mappable into any ofthe 4K slots and thus the PROM jumper could be configured. This isn’t present in the new school systems, which always use $E000. I presume that $E000 was so ubiquitous as a start address that it was barely ever remapped, thus it makes sense to hard code it for newer systems.
The second behaviour was more perplexing to me and was initially deduced via emulating an old school boot PROM (ZYMON) and a new school PROM (CFBOOT). The behaviour is this; on the Original systems, unmapping the PROM’s mirroring (aka disabling the PROM) would leave the original PROM in place at $E000. e.g if you read $E000 you’d get ROM code back. On the new school systems, disabling the PROM mapping would physically unmap the ROM from the address space, revealing the RAM underneath. So a read to $E000 would yield RAM and not ROM.
I presume this was done to a) give full access to the 64K RAM and b) the PROM typically copied itself to RAM on boot anyway, so there was no reason to keep it around after boot.
Unfortunately this appears to mean that old ROMs such as ZYMON don’t work on the newer system and the newer CFBOOT won’t work on the new school systems.
The third and final difference is that the Original system has two methods to disable the PROM. A IN A,($FF) would unmap the PROM until the next reset and I believe that a OUT ($FF),A would unmap the PROM until the next power cycle. The ROM card full decodes the $FF port and only reacts to that.
However on the new school systems, any IORQ will disable the PROM mapping until the reset. It doesn’t matter which port is used, and whether it’s RD or WR. The CFBOOT PROM still uses IN A,($FF) by convention only, but it doesn’t really need to.
Update: 20th Jan 2023
Further analysis of the new-school PROM circuit made me realise I missed a key detail here; 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 give us a boot-time memory map of:
| Address Range | Description |
|---|---|
| $0000-$3FFF | Boot ROM (lower 16K) |
| $4000-$7FFF | Boot ROM (upper16K, or mirrored) |
| $8000-$FFFF | RAM |
VDU
The VDU is the last of the major differences. Whilst both Original and New School use a memory-mapped screen (typically at $F000), the way the screen is output differs significantly.
The original system uses a Z80 to create the timing signals and TTL logic to update the various character/line and pixel counters. There is a switch to toggle between 32 column and 64 column mode; but the software has no way of knowing this. As a result, there were two versions of programs like ZYMON/DMON to display in each mode.
The new-school system features a VDU-3 card which uses a 6845 CRTC IC to drive the display. As a result, it needs to be configured before use to tell the chip what format the screen is in. This is done via two ports $E6 and $E7 to control the CRTC register select and register value. Newer software uses this to create an 80-column display mode and support a hardware cursor. As a result, the older software won’t work on the new VDU-3 unless it’s been pre-configured to the 32 or 64 column mode by the PROM (or patched to do so). Naturally, the 80 column wide software won’t work on the older cards that only support 64 or 32 columns.
The next difference between the original VDU cards and the new school VDU-3 is interesting from an electronics point of view, but shouldn’t make much difference for users. The VDU-3 card watches for writes to the $Fxxx range and mirrors them into its internal RAM. If you remember, the system is designed to have the full 64K RAM mapped in, so writes happen to both the VDU’s RAM and the system RAM. As a result of this, the VDU card does not respond to RAM reads from the screen, that is handled by the system itself which has a mirror of that same data.
The original system was mapped into the address space as a slot, so it was fully responsible for both writes and reads to & from the RAM it managed.
Storage
This is largely due to the march of time, but the new school systems now support Compact Flash based disks under CP/M. This wasn’t possible on the original hardware at the time as they didn’t exist :)
Curiously though, the new school systems locate the CF card on the same PCB as the Z80 processor, likely due to signal noise from longer traces. So the new systems have a different CPU board to the original.
The older systems have disk support and tape support; I haven’t investigated this too much yet - so will save this for a later post.
Wrapping up
When it comes to emulating / recreating the Interak, one has to be aware of these two major variants and the incompatibilities between the two. The reality is that whilst the systems are essentially the same, there’s enough variance in the original and new school hardware that has impact on the software that runs on it.