A 1993 Sega Genesis studio in a browser tab

It is a desk in a games studio, late. A beige 486 with a 14-inch colour display, a small TV with rabbit ears, a Genesis with its lid off, a grey box with red lights between them. The manuals are stacked under the lamp, the corkboard holds VDP register notes, and two sticky notes on the monitor say SCSILINK 390 and BACKUP! before SNMAKE.

The room is lit by one lamp and the two screens⁸, and the TV really lights the desk with whatever the Genesis is drawing. Marble Zone turns the wood purple. With nothing downloaded, the TV shows black, not snow⁹: the console is on and driving the screen, it just has nothing to draw yet.

A 3D room is usually a few steps from the real colours. Film-style tone mapping, the trick that makes a lamp-lit room look right, pushes saturated blues toward lavender, and Sega’s blues are as saturated as blues get. So each screen corrects for it before the tone mapper sees it, and the sky behind Sonic 1’s title reaches the TV within 4 levels of the ROM¹⁰. Switch the correction off and the same sky picks up 28 levels of green and washes out.

The monitor is a curved tube, and you can use it. Pull the chair in and the mouse works the 486 through the glass: each click is traced onto the curved surface and the barrel distortion undone¹¹, so every corner of the 720×400 text screen lands within a pixel.

The PC is a 486DX2-66 with 8 MB of RAM, and it starts the way they did. The memory count climbs to 08192KB, “Hit <DEL> if you want to run SETUP” waits a moment, and the BIOS ID string sits along the bottom of the screen: a 1992 AMIBIOS, release 11/11/92¹². Then the System Configuration box.

The CMOS clock says Monday, December 6, 1993¹, and it moves on one day for every day that passes outside.

Programs on the 486 charge their work to its clock, and its disk to the disk’s speed. A 6 MB file takes Brief about seven seconds to open¹³, as it would have. The TURBO button on the case is the one concession: press it and the 486 runs as fast as your computer can. A real turbo button only switched between full speed and a slower mode for old software, so the receipt marks ours as invented.

It boots MS-DOS 6.0. CONFIG.SYS loads HIMEM 3.09 and EMM386 4.45¹⁴, and AUTOEXEC.BAT starts SMARTDRV 4.1, the mouse driver, DOSKEY, the network and SCSILINK, each printing its own banner. Mistype a line in CONFIG.SYS and DOS tells you in its own words.

Those words are the real ones. Every message comes from the 03-10-93 binaries², which is why DIR prints 204173312 bytes free with no commas: 6.0 had no thousands separators. MEM uses 6.0’s column layout, not 6.2’s wider one. And every program on C: is its real size¹⁵, COMMAND.COM’s 52925 bytes included, so DIR, MEM and CHKDSK all add up.

A studio’s source code didn’t live on one programmer’s disk. It lived on the Novell server down the hall, and AUTOEXEC.BAT joins it. The NE2000 card’s driver loads, then IPX, then the NetWare shell, NETX v3.32, dated 930217³. LOGIN SAL runs the system login script, the server says “Good evening, SAL.”, and F: becomes STUDIO\SYS:, the shared drive with everyone’s work on it.

Both drives cost what they cost. Every read and write is charged its transfer time¹⁶: the IDE disk streams about a megabyte a second, F: about 600 KB, close to what people measured on period machines. SMARTDRV caches C: and never the network, so a file read twice from C: is free the second time, and one on the server never is.

The server is also where the 1993 studio meets 2026. The Sonic disassemblies on GitHub use long file names with spaces, and DOS 6 only knows eight letters and three. NetWare 3.12 had an answer: OS2.NAM¹⁷, a long-name space on the server, with Novell’s own rules for the short name DOS sees.

Novell’s rules cut a long name to eight letters, and number the ones that collide: THISISTH, THISIST0, THISI001. That is what DOS sees, while programs on the 486 can open the real names, so the tree on F: matches GitHub byte for byte. Your browser fetches the repository straight from GitHub, and the site never hosts it. Sonic 1’s disassembly comes in as 951 files, 34.7 MB, in 9.2 seconds.

In the room, an import starts at a box of 3½-inch disks marked SOURCE¹⁸, sitting on the Console Interface. Click it and a card opens: pick one of the three Sonic disassemblies or paste any GitHub URL, and watch the files land on F:. It never writes over a folder that’s already there. The card is the room’s one modern surface, and it looks modern on purpose.

Take the lid off a Genesis and there are two computers inside. A Motorola 68000 runs the game. A Zilog Z80 runs the sound from its own 8 KB of RAM. Between them sits the VDP, Sega’s video chip, with 64 KB of video memory of its own.

Both processors are ours, and both have been run through SingleStepTests, a public suite of single-instruction tests, every last one of them. The 68000 passes 317,500 of 317,500⁵, with exact cycle counts and its bus reads and writes in the right order. The Z80 passes 1,604,000 of 1,604,000¹⁹. The 68000 core runs 252 million cycles a second, the Z80 447 million T-states, so a whole console costs your browser very little.

The VDP is where Sonic lives, and Sonic games lean on it hard. They change the palette halfway down the screen and split it in two. Our YM7101 handles the tricks the games really use²¹: Labyrinth Zone’s water turns the palette on the very scanline its interrupt fires on, Sonic 2’s two-player mode runs in interlace at 320×448, and Sonic 3 & Knuckles renders its title and Angel Island right. The whole console, VDP included, runs a frame of Sonic 1 in about 2 ms, an eighth of the 16.7 ms a frame lasts.

The Genesis sound is a Yamaha YM2612, six channels of FM synthesis, plus a PSG for square waves and noise, which Sega’s manual calls a Texas Instruments 76489 and which is built into the VDP²². The Z80 drives both, running the game’s sound driver from its 8 KB of RAM while the 68000 gets on with the game. The YM2612 is a hard chip to get right, and its quirks are part of the music.

So ours was checked against Nuked-OPN2, an emulator traced from the chip’s die⁶, used only as an oracle and never shipped. Seven recordings went through both: the SEGA chant, Green Hill, Labyrinth, Emerald Hill, Casino Night, the Sonic 3 & Knuckles title and Angel Island. Every channel and both outputs match on every sample.

Matching the samples isn’t enough on its own, because sound drivers don’t just write to the chip, they wait on it. They spin on its busy flag and its two timers, so both are exact to the cycle²³: busy rises two chip cycles after a write, as it does on the die.

Then the sound leaves the chips, and a real Genesis colours it on the way out. The studio’s console is a model 1, so the output goes through the model 1’s analog path²⁴: the discrete YM2612’s ladder effect, a first-order low-pass at 2.84 kHz, and the PSG mixed in at the level the board gives it.

Picture a Genesis dev kit and you probably picture a cartridge in the slot. That is the SNASM2 GENerator, and it is a 1995 product²⁵. In autumn 1993 a studio did something more drastic. It opened the console, pulled the Motorola 68000 out of its socket and seated the SNASM pod in its place. A ribbon ran from the pod to a grey box from Cross Products: the Console Interface.

The box stands in for the cartridge. Cross Products sold it with 1, 2, 4 or 8 MB of static RAM, and this studio’s has 4 MB²⁶, enough for Sonic 3 & Knuckles. Battery-backed RAM sits above it at $400000, and the link software keeps the top kilobyte of it for itself.

It has four red LEDs: ACTIVE, WR PROT, PWR ON and DC PWR. At power-on WR PROT lights for about a second²⁷ beside the two power lights. ACTIVE flickers while the link moves data, and while a downloaded game runs all four stay lit: the image is write-protected, the way a cartridge’s ROM is.

The PC reaches the box over SCSI. AUTOEXEC.BAT loads the ISA card’s driver with SCSILINK 390²⁸, the PC is SCSI ID 6, and the Genesis answers as target 7, which is why every download command on the desk ends in t7:.

A download takes as long as it did then, at 300 KB a second²⁹. Sonic 1 is on the TV in about two seconds, Sonic & Knuckles on its own, 2 MB, in about seven, and all 4 MB of Sonic 3 & Knuckles in about fourteen.

The debugger gets into the game through code the link puts on the console. That code owns the 68000’s exception vectors 2 through 9 and 32, and a game had to execute trap #0 regularly, usually in its vertical-blank handler. A game that didn’t couldn’t be stopped³¹: press Esc in the debugger and nothing happened. We kept that. Breakpoints still work³², because a breakpoint is an ILLEGAL instruction written over your code.

When the debugger does stop a game, only the 68000 stops. The VDP keeps the frozen frame on the TV, the Z80 keeps running the sound driver, and any FM note that was held keeps sounding³³.

It doesn’t have to stop the game to change it. With Sonic 1 running, SNBUG68K’s Memory window goes to $FFF760, the word the game reads for Sonic’s top speed. Type 1800 over the 0600³⁴, and the next time he runs, he runs four times as fast.

Code was written in Brief, the programmer’s editor of the day, white text on a blue screen. This is Brief 3.1, from 1991. SNASM fitted itself into it: Alt+F9 for the SNASM menu, Alt+F10 to make, Ctrl+F10 to debug³⁶.

The Sonic games themselves come from the fan disassemblies, which turn the retail ROMs back into labelled, commented source. They build with the AS macro assembler and p2bin, so the studio has both, rewritten from scratch in TypeScript. They don’t approximate the originals. They rebuild all four games byte-identical to retail⁷.

Underneath that, every one of the 68000’s 60,000-odd encodings assembles back to the same bytes³⁷, and the Kosinski and Saxman compressors the games use match the real tools byte for byte.

And they build on the 486, in its time. Brought in through the SOURCE box, Sonic 1 builds at F:\S1DISASM with the repo’s own build.lua, lua.exe, asw.exe and p2bin.exe, through SNMAKE, in about three minutes with TURBO off³⁸, the assembler running at the speed its own benchmark gives a 486DX2-66³⁹. The scripts only reach for their Windows tools when they see two lines in AUTOEXEC.BAT⁴⁰, so the studio’s has them, under a REM saying why.

A built ROM still has to reach the console. That takes one line at the DOS prompt, SNGRAB S1BUILT.BIN /R⁴¹, which sends it down the cable and starts it. SNGRAB speaks the manual’s command-file language too, and SNTEST checks the card line by line and reports “PC card address is 0x390”.

In 1993 the documentation was paper, and the team worked with it open beside the keyboard. Four books sit under the lamp: the SNASM2 user’s manual from Cross Products, Sega’s Genesis Software Manual, Motorola’s M68000 Programmer’s Reference Manual and the MS-DOS 6 User’s Guide. Pick one up and it opens in your hands. The pages turn, the tabs take you to a chapter, and the cross-references work.

They are set the way their publishers set them. Sega’s manual is in Helvetica⁴², because the scans are. And they are right where it matters to a programmer: the VDP register pages are right to the bit⁴³. Mode register 2 has DISP, IE0, M1 and M2 where the hardware has them, H40 needs RS0 and RS1 set together, and every page carries the footer CONFIDENTIAL and PROPERTY OF SEGA. The MOVE examples in the Motorola book encode to the real bytes.

The scans they were checked against are not on this site. They live in public archives such as Sega Retro.