Ethernet Gateway

The CP/M emulator runs real Z80 — or 8080, see cpm_cpu — .COM software against an emulated CP/M 2.2, with a virtual Hayes modem the guest can dial out through.

Two separate features in this gateway both say “CP/M”, and it is worth being clear which is which before reading on:

Reaching it: from the main menu choose K — CP/M System. The emulator is enabled by default (cpm_emu_enabled); the drive folders transfer_dir/CPM/A … P are created on first launch, and the bundled EGT8080 terminal is placed on drive A: at the same time — in both its builds, EGT8080.COM and EGT8080.COM.

Getting your own files onto a drive: the drives are ordinary folders, so in the gateway's File Transfer menu change directory to CPM/A and upload there — the file is on drive A: the moment it lands, no import step. EGT8080 can also fetch one over the virtual modem from inside the emulator. The emulator's HELP says both.

The drives are shared between sessions. Each session gets its own CPU and its own 64 KB, but one set of folders serves all of them, so two people in the emulator see the same files. A session entering while another is already inside is told so. Writing is protected: a file one session is writing is claimed until it closes the file or leaves, and another session's write, erase or rename of that file is refused rather than interleaved — which is what would otherwise happen, since the BDOS here opens the host file per record. The refusal reaches the guest as an ordinary CP/M failure, so expect a program to report something like DISK OR DIRECTORY FULL: that is the only code CP/M's create call has. Reads are deliberately not locked, so two people can share a library of .COM files freely.

All cpm_emu_* keys live in egateway.conf and are editable from all three config UIs (telnet, web, GUI).

cpm_emu_uart defaults to a live port rather than off because it is the port most CP/M software here expects, and it is what EGT8080 defaults to — so the emulator and its terminal agree out of the box. That is a deliberate widening: with a port selected, guest code can open a socket with ATDT. An operator who does not want that sets cpm_emu_uart = off; peer dialling additionally requires allow_peer_dial.

The built-in commands at the A> prompt. Anything else is treated as a program name and loaded as name.COM from the current drive.

A .dsk image can be mounted on any drive A:–P:. The drive then reads and writes the CP/M filesystem inside the image instead of its folder under CPM/.

Mounting hides a drive folder; it does not touch it. The folder's files are exactly where they were and come back the moment the image is unmounted.

Naming, and why an unnamed image is read-only

Put images in CPM/images inside the transfer directory. Name one <format>_<anything>.dsk — the format token, an underscore, then whatever you like:

ibm3740_cpm22.dsk
altairhd_cobol.dsk

An image named this way mounts read-write without further ado. But you do not have to rename anything. An image with no prefix is identified by inspection and mounts read-write too, provided its CP/M filesystem checks out — because no two formats here are the same size, so the size names the format outright and the only real question is whether the file holds that filesystem at all. The whole directory is read and checked: every allocation block inside the disk, no block claimed by two files, every record count matching the blocks it claims.

An image that does not check out still mounts, but read-only, and says what was wrong. That matters more than it sounds: plenty of disks are 256,256 bytes without being CP/M — a UCSD p-System disk is one. Reading them is safe and usually what you want; writing to them is not. Renaming with a prefix is an override that skips the inspection, not a requirement.

Two things bound that override, because it is the one path that mounts read-write without looking inside. A prefix cannot make a file the wrong size into a disk: the size must still be the format's, and for a while it only had to be at least that, so a 625,920-byte Cromemco double-density image called ibm3740_… was accepted and read as a 256,256-byte single-density one — writable, with its directory landing mid-track. And the size is not required to be exact: anything short of one whole record over is a trailer, which is real — three images in the standard Altair set are their format's size plus 96 bytes, and demanding an exact match refused them on the file length before their directory was ever read.

A mount is also forced read-only when the image file is read-only on the host, or when its CP/M directory arrives damaged — an entry naming a block off the end of the disk, one claiming directory space, or two files sharing a block. In that last case the gateway deliberately does not repair anything: guessing which file really owns a shared block is how a backup gets destroyed. The mount screens say which of the three reasons applies.

Formats

Every entry was measured from a real image rather than transcribed from a table. altair8 was withdrawn for months because its directory read correctly while file content past the first half of a track did not; it is back because a booted Altair was made to read its own disk out over the virtual modem, which gave an exact answer where every earlier check could only score a guess. That measurement, the two skew tables and the sector-checksum formulas are written up in the Disk Format Reference. CPM/images/readme.txt carries the same format list, generated from the same source, along with what to rename an Altair-Duino or IMSAI disk to.

Not every .dsk is a CP/M disk

Altair DOS, Altair Disk BASIC, Time Sharing BASIC and UCSD p-System disks use their own filesystems. They are common in the same collections, and mounting them either fails outright or shows no files — which is correct, not a fault. Those disks are for booting, where the disk's own operating system does its own filesystem work and ours never has to understand the layout.

Mounting

Changes take effect immediately, in every session, and are written to cpm_mounts so they survive a restart. A drive somebody is currently using cannot have its disk changed; the screens show which drives are in use and why.

Mounting gives you one drive with our BDOS underneath. Booting hands the whole machine to the disk: 64 KB of memory, a MITS 88-DCDD floppy controller, a MITS 88-HDSK hard disk controller, an 88-2SIO console and the front-panel sense switches — the disk's size decides which controller it lands on. The disk's own operating system then does everything, including its own filesystem work — which is why booting reaches the disks mounting cannot.

What boots

Twenty-four of the images in the Altair-Duino sample set boot, and twenty-two of those print a sign-on straight away. An image may be an 8-inch floppy (337,568 bytes), a minidisk (76,720) or a 4.9 MB 88-HDSK hard disk (4,988,928) — and every one of the eleven hard-disk images in that collection boots. A short trailer past the last sector is accepted, since several images in circulation carry one.

A programs disk — data rather than a system disk — has no boot sector, and is refused with a message saying so rather than run.

Choosing what CP/M runs

The setting is cpm_boot_image: empty (the default) runs the CP/M emulator, a bare filename in CPM/images boots that disk.

If the disk it names is not there, the emulator runs — deleting an image costs you the boot, not the whole CP/M feature — and the gateway says so rather than leaving you to work it out. Every screen that shows the setting marks it (missing), or (invalid name) when the value could never have named a disk at all, and the log records the fallback once per visit. The disk screens follow suit: their rows go back to naming drives A:–P: instead of the slots of a board nobody is going to get.

Which machine — where the disk finds its console

A booted disk brings its own operating system, and that operating system was written for a particular machine. Most of these disks expect the Altair's 88-2SIO console at 10h/11h, which is the default and what every disk that boots today uses. Some do not, and the symptom is distinctive: the disk loads, reads its sectors, and then goes completely quiet, because it is printing to hardware that is not in the machine and polling a keyboard port that will never answer.

cpm_boot_machine picks the machine. It is on the same screens as CP/M runs above — on telnet, the CP/M settings screen's B now opens a Boot Settings screen holding both.

The machine picks the disk controllers too, not just the console. That is not tidiness: z80pack's device answers on 0Ah–11h, which contains both the 88-DCDD's data register and the 88-2SIO console, and a machine answers disk controllers before its console. Put those boards together and every Altair disk would go silent with its console being answered by a disk controller. It is also what settles a size two boards both claim — 256,256 bytes is an IBM 3740 to the Tarbell and an 8″ SSSD to cpmsim.

The backspace key

Type TESTING into a freshly booted Altair disk, press Backspace four times, and the screen reads TESTINGGNIT. Nothing is broken. Your terminal's Backspace key sends DEL (7Fh), and most of these operating systems read that as a Teletype rubout: they delete the character and then print the character they deleted, so the operator of a printing terminal can see what came off the end of the line. On a screen it just looks wrong.

cpm_boot_backspace decides which byte a booted guest is handed. There is no answer that suits every disk, and this was measured across two whole disk folders rather than reasoned — 38 images that reach a prompt, each booted twice and asked what it echoes:

29 of the 38 erase on BS and 7 on DEL, which is why backspace is the default. The third row is why the setting exists: for CP/M 1.x the rubout is the editing key, and translating breaks something that already worked. A Commodore's own DEL key (PETSCII 14h) is folded to whichever byte the setting names, because no guest in either survey recognises 14h at all — leaving it alone would give a C64 no editing key rather than the disk's own one.

The other drives

A booted guest is handed every mounted image, each in the controller slot its drive letter names — B: is slot 1, C: is slot 2, F: is slot 5. So you can mount several disks, boot one, and copy between them with the guest's own PIP.

What a slot is belongs to the board. On the floppy controllers it is a drive. On the Altair 88-HDSK it is a platter — a Datakeeper drive carries four of them and addresses each by head number — so slots 0–3 are the first drive's four platters, and the screens name them unit 0.1 rather than with a bare number. That is not a detail: Altair Hard Disk BASIC numbers its disks by platter too, so its MOUNT and these slots line up, and the 88-HDSK CP/M's B: is the fixed platter — slot 1.

Three more rules, each with a reason:

• The boot disk is always unit 0, so it is the guest's A:. The bootstrap can load a system from any unit — that was measured — but what it loads comes up as A: and reads unit 0 from then on, so a boot disk parked elsewhere runs against whatever is in unit 0. Anything mounted on A: sits behind the boot disk, and the boot banner says so.
• Writes need two yeses. A mounted disk is writable only if the boot session was opened for writing and the mount itself is writable. The stricter wins.
• A gap between drives will look like a crash. An empty unit on a real 88-DCDD answers nothing at all, so a guest that selects one waits for a head that never loads. Mount A:, B:, C: and F: and then type STAT D: and the session appears to lock up. That is the hardware's behaviour and it is left alone — the boot banner warns about the gaps, and ESC twice still gets you out.

An image no controller here can carry — a Tarbell or Cromemco disk — mounts perfectly well for the emulator but has no board to sit on, and is named and skipped rather than presented as a drive the guest cannot read. Hard disks are not in that category: they have their own controller and boot on it. Floppies and hard disks can be mixed in one booted machine — each goes on its own board, and a board asked for a slot it was never given refuses rather than reading the other one's disk. What a drive letter cannot be is a slot on both boards at once: B: is slot 1 of whichever board took the disk, so a hard disk at B: — the 88-HDSK's second platter — leaves the floppy board's drive 1 empty. Whether the guest can reach both at all is its own BIOS's business, as ever.

The modem inside a booted disk

A booted guest keeps the virtual modem, provided cpm_emu_uart names a pair of ports. A real Altair put its modem on the second port of the 88-2SIO, so altair_2sio2 (0x12/0x13) is the natural choice; comms software under a booted Altair CP/M then finds a UART where it expects one, dials out with ATDT, and can answer an inbound CPM@<ip> call. Three cases cannot work, and the boot banner says which:

The front panel

MITS system software asks the front-panel sense switches on port 0xFF which console board the machine has — 88-SIO, 88-ACR, a 4PIO, or the 88-2SIO. The gateway reports 0x00, which selects the 88-2SIO at 0x10/0x11: the console it actually emulates. This is not a detail. With the port left floating at 0xFF — a valid reading meaning "88-SIO" — Altair DOS booted perfectly and wrote its sign-on to a board that was not there, which looked exactly like a disk that would not boot.

Some disks do not print to a console at all. Two S-100 video cards of the 1970s put their picture in the computer's own memory and gave the program no data port to write to — the Processor Technology VDM-1, a 64×16 character screen at CC00, and the Cromemco Dazzler, a colour picture the program can put anywhere. Software written for either boots here, takes your keystrokes and leaves the session you started it from completely blank. Both are served in the web UI instead, at /vdm, and one session can have both.

Which disks it applies to

The button is offered for every booted session, not only these — sampling costs the guest nothing, so withholding a screen on a guess would only hide one that works. A disk that drives neither card simply shows a blank grid. These are the ones known to paint something:

Everything above except TDISK06 is in the sample-disk download, so the shortest route to a picture is: fetch the disks, set DISK10 to boot, and press VDM / Dazzler.

Using it

1. Turn the web server on (web_enabled, default port 8080) — it is off by default.
2. Boot a disk as usual. If its system tracks drive a VDM-1, the boot banner says so and prints the address to open. There is no such warning for a Dazzler and there cannot be: its two registers are ordinary low port numbers that appear by chance all over a disk's data, so a scan before boot would cry wolf on two images in three. A Dazzler announces itself when the guest switches one on, and the session list marks it then.
3. Open http://<gateway>:8080/vdm, or press VDM / Dazzler — in the configuration page's AI Chat, Browser, Weather & CP/M frame, or in the desktop UI's CP/M More popup, which opens the same page in your browser — and pick the session from the list.
4. Keep typing in your telnet or SSH session. The keyboard is a perfectly ordinary port — 04h/05h on the VDM-1 disks, and a normal serial console on the Dazzler ones — because only the display was ever memory-mapped.

Every booted session offers a screen, not only the ones known to be VDM-1 disks, because sampling one costs the guest nothing: it is a read of the guest's own memory, through its own MMU, with no write, no trap and no change in timing. The list marks the sessions that have actually driven the card, and a session showing whatever happens to live at CC00 says so under the screen rather than leaving you to wonder about the noise.

How much it costs the guest

Nothing, unless somebody is watching. The page asks for a frame roughly every 150 ms and each request produces exactly one snapshot; a session with no viewer checks a single flag as it goes round its loop and copies nothing. There is no timer anywhere, and closing the browser tab ends the cost rather than reducing it.

Which disks the VDM-1 reaches: TDISK04 (CP/M 1.4, VDM VERSION) and altairsim's cpm14-vdm. DISK11's VDM driver lives in a CUTER monitor ROM rather than on the disk, and that ROM is not one the gateway has, so it stays dark. See the disk reference for the write-up.

Typing from the browser

The screen page is a keyboard as well as a window. Click the screen and type: the bytes go to the same place the terminal's do, through the same translation, so the backspace key you chose with cpm_boot_backspace behaves identically from either keyboard. Both keyboards work at once — there is one key queue, exactly as two keyboards wired to one port would share one, so the person at the terminal and the person in the browser can both type. If they type at the same moment their characters interleave, which is what a shared terminal is rather than a fault.

Control keys reach the guest: Ctrl+C to interrupt, Ctrl+S to pause — which is what GDEMO asks for by name. What does not reach it is the ESC ESC exit gesture: ending a session somebody else is sitting at is not a keystroke, so a double escape from the browser arrives at the guest as two escapes and nothing more.

Set cpm_screen_input = false to make the page read-only. The screen stays fully readable either way — watching and typing are different acts and get different answers. The setting is live: it is read per keystroke, so turning it off does not need a restart, and a page left open stops offering a keyboard as soon as it is refused once.

This is also what makes the Dazzler disks usable rather than only watchable: LIFE asks ENTER DATA and GDEMO wants Ctrl+S, and neither needs a joystick.

The Cromemco Dazzler

The first colour graphics card for microcomputers, 1976. It reads its picture out of main memory by DMA — so, like the VDM-1, watching it costs the guest nothing — and it has exactly two registers. Port 0Eh carries an on/off bit and the top seven address bits, so the picture sits on a 512-byte boundary wherever the program put it; port 0Fh is the format. Both are read at every frame rather than once, because software animates the format as well as the picture.

DISK10.DSK in the Altair collection is the Cromemco software library — two dozen programs including KSCOPE (Kaleidoscope), DMATION (Dazzle-mation), LIFE, XLIFE, GDEMO, DAZZPLOT and COLOR. Twelve more images in the collections carry Dazzler programs.

CP/M software prints to a device called LST:, and what it sends is captured and left in your transfer directory as a document you can collect over XMODEM, ZMODEM, Kermit or any of the others — plain text by default, or an OpenDocument file that opens in LibreOffice, Word or Google Docs. Nothing is written until a guest actually prints; cpm_printer = off sends the output to your terminal instead, which is where it used to go and where it cannot be recovered.

Two machines, two routes, one document

This is one of only two settings that reach both CP/M machines — cpm_cpu is the other — and, like that one, they get there by completely different roads.

• The emulator. Our own BDOS and BIOS sit underneath the guest, so the printer is a service: BDOS function 5 (List Output) and the BIOS LIST vector. Every program that prints through the operating system arrives here — WordStar, MBASIC's LPRINT, PIP LST:=FILE.TXT. No hardware is involved and there is nothing to configure beyond turning it on.
• A booted disk. The guest owns the machine and drives a printer board, so the gateway has to be one. Which board is cpm_printer_port; today there is one, the Altair line printer with its data register at 03h.

Where the file goes, and when

Into a printer folder inside your transfer directory — its own folder, so a printer left switched on does not scatter documents through your own files — named PRINT-YYYYMMDD-HHMMSS from this machine's clock. Deliberately not onto a CP/M drive: the printout is for you, not for the guest, and putting it on a drive would hand it back to the guest as a file it could open.

A job ends after five seconds of silence. CP/M has no end-of-print signal — a printer is a stream of bytes with no "close", and on real hardware the person standing there decided the job was finished — so silence is the only signal there is. In the emulator there is a second, exact one: returning to the A> prompt ends the job immediately, so a program that prints and exits does not make you wait out the timeout. A booted operating system never "finishes", so there the five seconds are the whole answer.

Merely initialising a printer does not create a document. Altair Hard Disk BASIC answering LINEPRINTER? C writes a handshake byte to the data port before anything is printed; a job with no printable character in it is dropped rather than written out as an empty file.

The auto-line-feed switch

Real Centronics-type interfaces carried a DIP switch for this, and they carried it because the byte stream genuinely cannot say. A carriage return that returns the head without advancing the paper is how overstrike works — it is how period software makes bold and underline. A carriage return that advances is how a great deal of other software ends a line. Same byte, two meanings, and only the hardware settles it.

So it is settled per board, by measurement. Two LPRINTs from Altair Hard Disk BASIC put ALPHA<CR>BETA<CR> on the wire and nothing else — a bare CR, no line feed anywhere. With the switch off, BETA prints on top of ALPHA and an entire report collapses onto a single line, so altair_c has it on. A CR LF pair sent to that board has its line feed absorbed rather than double-spacing the document, which is what the real interfaces did and what made the switch usable by software that sent both.

The emulator's printer has it off, and that was measured to the same standard: PIP LST:=DEMO.ASM run against the CP/M 2.2 distribution disk sent 2745 bytes carrying 65 CR and 65 LF, and the document that came out matched the source file line for line. So CR LF is what arrives through BDOS 5, and overstrike keeps its meaning there.

What it does not do yet

Bold and underline are real. Period software does not ask for them with an escape code, it overstrikes: WordStar prints the line, returns the carriage with a bare CR, and reprints just the emphasised run at the same columns; underline arrives as a pass of _ over the letters. That is recorded as it lands and comes out as real bold and underline in the .odt — verified by printing from WordStar 3.0 on a booted disk and opening the result in LibreOffice. It is also why cpm_printer_autolf exists: with the switch on, each overstrike pass lands on a line of its own instead of on top of the text. Plain text gains no markup at all.

Three ways a guest can reach the virtual modem, all selected by this one key. Software that pokes a UART wants a port; software that asks the OS wants AUX:; software that asks the firmware wants HBIOS.

The HBIOS entries exist because a good deal of RomWBW software — the QTERM h builds among them — never touches a port at all, so no port address could ever have served it. HBIOS answers only when an hbios_* profile is selected: on any other setting the guest sees the page zero of a plain CP/M 2.2 machine, with no RST 8 vector, and well-behaved software detects its absence and says so rather than hanging.

Single source of truth: src/cpm/uart.rs — config validation and all three UIs enumerate that same list, so this table cannot drift from one UI to another.

EGT8080 (“Ethernet Gateway Terminal”) is this project's own CP/M terminal, written in period assembly. It asks which port it is on instead of shipping one build per machine — and it ships in two builds, one per processor: EGT8080.COM, which runs anywhere, and EGT80.COM, which adds the Z180 ASCI ports an 8080 binary cannot hold.

Every period terminal we tried was built for one machine's serial port — QTERM ships a separate binary per port, IMP8 is an Altair 2SIO build, and KERCPM22's generic overlay has no serial driver at all. Get the pairing wrong and the program is simply silent. EGT8080 asks instead: pick the port from a menu, and it remembers.

It ships inside the gateway binary and is written out whenever it is missing — at every start-up, and again when a session enters the emulator, so a folder deleted while the gateway is running is repaired without a restart. It is then never overwritten — it saves its settings inside its own .COM, so refreshing it would discard your configuration. Deleting the file restores the shipped copy on the next launch, which is the documented way back to a known state.

This used to happen only once somebody entered the emulator. Erasing the transfer directory and restarting therefore recreated the sixteen drive folders with no terminal in any of them — and the loose copies in the transfer directory, whose whole purpose is to reach a terminal without starting the emulator, appeared only after you had started the emulator. Fixed in 0.9.3. Set place_bundled_terminals = false if you keep your own build and would rather a file you deleted stayed deleted.

Two builds, and which one to run

EGT8080.COM is the one to reach for. It runs under cpm_cpu = z80 and = 8080 alike, and on any machine either imitates, because it is written to the 8080's instruction set and the Z80's is a strict superset of it. Start here unless your console is a Z180 ASCI port.

EGT80.COM is the Z80 build, and it exists for one family of ports. A Z180 board — an SC126, and many a RomWBW machine — drives its console from the ASCI channels inside the processor. Reaching them needs IN0/OUT0, and knowing a Z180 is there at all needs MLT BC; all three are ED-prefixed instructions, and on a true 8080 an ED byte is an undocumented CALL — such a probe would not fail, it would jump into the weeds. So those bytes cannot be in a binary that must also run on an 8080, and no amount of care in EGT8080 could serve a Z180 console. That is the whole reason there are two.

Both are placed on drive A: and in the transfer directory — four files, and the reason the second pair exists is so the file-transfer menus can send one to real hardware without starting the emulator. The port menu is the difference: EGT8080 offers the Z80 SIO/2, the 6850 ACIA, the Altair 88-SIO, RomWBW HBIOS and CP/M AUX:; EGT80 offers those and the Z180 ASCI. The 6850 ACIA is in both — if your board has one at a port address, EGT8080 reaches it.

The cost, and why EGT8080 leads. EGT80 is Z80 code: run it with cpm_cpu = 8080 and the machine stops at its first Z80-only opcode. The emulator's sign-on says 8080 selected.  Run EGT8080. under that setting for exactly this reason. On the 8080 build the ASCI entry is still on the port menu and answers “This processor is not a Z180, so it has no ASCI ports” — listing it and refusing beats hiding it, because the operator of a Z180 board learns the family exists and that this is the wrong build for it.

They were one build for part of 0.9.2's cycle. The Z80 build was retired on the reasoning that one binary running everywhere beats two that need choosing between — true of every machine except the Z180, which is the one an SC126 owner has. It came back before 0.9.2 shipped. EGT80.Z80 is the source; EGT8080.Z80 is derived from it by tools/port8080.py, so a change is made once. If you upgraded from an earlier release, your own EGT80.COM is still on drive A: with its settings — placement never overwrites — which is the right outcome: it is the same program.

What the porter does. Everything mechanical: JR→JP, two BIT 7,A, one LDIR, the Z180 probe answering “no” without asking, and the port drivers, which on an 8080 must patch the port address into their own IN and OUT because the 8080 has no register-indirect I/O at all.

What holds the line is tools/check8080.py. The 8080 source is still written in Zilog mnemonics and assembled by the same Z80 assembler — what has to be in the 8080's set is the opcodes emitted, not the words — so the assembler would happily accept a JR and say nothing. The checker reads every instruction and matches it against the 8080's set by form, not by mnemonic, because half the Z80-only instructions share a mnemonic with an 8080 one. That is not theoretical: a census by mnemonic reported “312 JR, two BIT, one LDIR, nothing else” and had missed LD (nn),DE and sixteen IN A,(C)/OUT (C),A. The first build ran perfectly on a Z80 and, on an 8080, executed ED as an undocumented CALL straight into a string constant.

It starts in ASCII mode. An ANSI terminal displays plain ASCII perfectly, so defaulting to ASCII costs that user only colour — Settings → A turns ANSI (and with it colour) on. A plain or PETSCII terminal shows ANSI as litter printed over every screen, which costs that user a program too garbled to find the setting that would fix it. Note this governs escape sequences and colour; the clear-screen dialect is a separate setting (Settings → C), and it defaults to the ADM-3A ^Z to match — the gateway translates that for whichever client is connected, so an ASCII terminal receives no escape byte at all. Pick the ANSI ESC [ 2 J there if you are on real hardware with a modern terminal.

Main menu

Terminal-mode menu — the menu key (^Y by default)

Pressing the menu key inside terminal mode does not hang up, so a transfer can be started mid-call: dial, ask the far end for a file, then fetch it.

Settings is deliberately not on this menu. It used to be, and it did not work: the settings screen drew, but keystrokes were still going to the remote, so nothing could be selected. Press E first — Settings works properly from the main menu, and leaving terminal mode does not drop the line.

Selecting a port — keys from S → P

The top level names machines, not chips, because which chip a board uses is a question only someone who already knows the board can answer. “Other hardware” is the old chip list, one level down, with the free-form address prompts intact.

6 (AUX:) pauses on a “Press any key” note about the missing status call before the pick completes. D sets the gateway default and clears the rest; N selects no port; Q leaves the port unchanged.

EGT8080's five port families, what selects each, and how far each one has been proven.

Why the 88-SIO is its own item rather than an address on the 6850 screen: it is a different board. It reports ready by pulling a bit low, so an 88-2SIO driver aimed at it reads every test inverted and the port looks permanently busy and permanently empty at once. The addresses were never the only difference.

Why the firmware is asked rather than guessed on a Z180: RomWBW relocates the Z180's internal I/O block, so a fixed guess addresses nothing on some boards. EGT8080 asks the firmware where the block is and offers C0 by name for Small Computer Central boards (SC126 and friends), where RomWBW puts it.

A clean-room implementation of the RomWBW HBIOS serial group, written from the published API. Reached by RST 8 with the function in B and the unit in C.

Only present when an hbios_* profile is selected. On any other cpm_emu_uart setting there is no RST 8 vector at all, and every function is refused — so software that checks for RomWBW correctly concludes this is not a RomWBW machine.

The disk / RTC / video counts under SYSGET are refused rather than answered with zero, since a caller would read a successful zero as “none present” and a refusal as “not that kind of machine” — which is the truth here.

What the emulated CP/M 2.2 answers. Guest calls reach the live telnet/SSH session for console work, and a directory-backed filesystem for disk work.

BDOS — console and system

BDOS — disk and file

BIOS jump table

A real jump table is installed, and both the ways a guest reaches it work: calling a table slot, and calling the extracted operand address directly — which is what MBASIC does.

The guest talks to a Hayes-compatible modem through whichever cpm_emu_uart access mode is selected. Both directions work: it dials out, and it can be dialled.

Commands chain left to right, so ATE0Q0V1X4S0=1 works as one line.

Dial targets

Inbound: the emulator is dialable as CPM@ip. The guest sees RING and answers with ATA, or automatically once S0 rings have passed. Only one session claims each call — the take is atomic, so there is no double-answer.

These are the same dial targets the physical serial modem answers; for the full Hayes command set and S-register detail see the AT Command Reference.

Deep-dive reference pages for every protocol and interface, plus the character-set tables and ANSI escape-sequence reference.