skip to content

evv42's webpage

hi there, this is evv42's webpage !

skip to article list

software projects

every piece of code i want to share is on that git thingie that i host

some cool stuff:

contact

see also


funni cartoon rabbitcrappyspeccy: a zx spectrum on breadboards that tries its best 02.02.2026 nsc800 chip close-upall you never wanted to know about the NSC800 10.09.2025 togepi figureunsorted hyperlink dump 23.06.2025 sram chipsimpler breadboard computers using battery-backed SRAM 08.06.2025 avatar sketch"art" 01.06.2025 (last updated) stack of floppy driveswriting pc-98 disks with an ibm pc 09.05.2024 old ikea lampbooks 18.08.2025 (last updated) bookworm lainwanted software 08.02.2024 nano:ztaghyperlinks 27.11.2023 (last edited) webpage logo, i guessthis website 17.02.2023

end of list

boo

crappyspeccy: a zx spectrum on breadboards that tries its best

[top]

I always wanted a sinclair computer but can't really afford the weirdly horrendous prices they command.

I got a broken ZX81 a long while ago but never was able to make it work. Since then, i got around trying to make my own ZX computer at home but the 80/81 suffer from being quite complex due to trying to get the Z80 CPU to do as much as possible.

what is a speccy ? a miserable pile of memory

The big lines of the ZX Spectrum architecture are relatively simple: a 16K ROM, a 256x192 framebuffer with simple colour attributes, some RAM (16 or 48 KiBs), an input port for the keyboard and tape input, an output port for the tape output and speaker.

The secret sauce resides in the ULA, a medium-scale custom chip that interfaces the standard components with the DRAM to achieve a cheap machine that's more powerful and easier to program than sinclair's previous iterations.

The original hardware is notable from having been cloned to death, mainly in eastern europe which machines either outright cloned the ULA chip or replaced it with the many discrete logic chips it substitutes.

Getting an ULA is pricey on a good day and the discrete equivalent relies on DRAM and uses too many counters and multiplexers to be an afternoon project to build on two breadboards. So, how can we make less with less ?

if you can't do it you can use the *hum hum* z80 features

The Z80 is quite a featureful processor that has many tricks up its sleeve to make medium-complexity systems a bit easier to make.

Among them is DMA, accomplished by the /BREQ and /BACK signal pair, which allow the system bus of the Z80 to be put in high-impedance and the CPU to be stalled for other devices to assume control and do tasks that'd be quite annoying for the CPU to accomplish.

magical video processor

The motorola MC6847 (a.k.a. Video Display Generator or VDG) is a very versatile video chip that shines among all the others by its sheer simplicity and high function integration. It got quite popular in a wide variety of home computers, mostly throughout the 1980s. Some personal picks would be the acorn atom (6502), the vtech laser 200 and nec pc-6000 (Z80) and the dragon 32 (6809).

The chip takes a 3.58 MHz clock and controls itself entirely using 8 input signals that can either be controlled through some simple circuitry or preset to have either a text/semigraphic display using the integrated character generator or an external one, or a more straightforward framebuffer approach.

At its core, the chip is based around a 256x192 framebuffer that it can use as is, or at lower resolutions, adding some colour capabilities along the way.

now, the curses

These were the two informations that triggered the following horrors, upon initial reading of basic information about the ZX spectrum.

Before engaging in what would definitely end up being a many-days project, i did want to confirm that there wasn't anything subtle i missed about this architecture (foreshadowing), so i did set up a very basic emulator using the knowledge i gathered about the machine.

garbled bootup screen

The first image did speak for itself, and it turns out that the framebuffer is not linear for some reason but interlaced. Thankfully, wikipedia has a quite detailed article about the ZX spectrum graphics for some reason, and it's explained in simple terms how the interlacing works: the A5, A6 and A7 lines are inverted with the A8, A9 and A10 lines.

After swapping that in software we end up with a more familiar screen:

normal bootup screen

The keyboard routines in rom need the triggering of the maskable interrupt which is wired to the display vertical sync (*1), and with that we have a working minimal system, so let's build it !

(*1) The signal as-is would pose a problem due to IRQ being level-triggered on the Z80, you want circuitry to account for that, ask me how i know !

the schematics, explained

schematics for the crappyspeccy

It's relatively straightforward. the data bus goes to the data bus, the address bus goes to the address bus, with the slight twist to the 6847 to account for the interlaced framebuffer.

The /MS input from the 6847 will receive the inverted /BACK from the 6847 so that the chip only gets access to the bus when the Z80 yields it. as a consequence of the Z80 placing the bus in a high impedance state and the 6847 lacking proper signaling circuitry to address the memory, we'll place some high value resistors along some signals to force the memory into giving the information the VDG needs to display video.

The Z80 simply being on the same bus as the 6847 without any isolation does have the major drawback of the latter getting most of the time to display the framebuffer.

To accommodate for this, we'll use the horizontal sync signal (/HS) (*2) as the primary way to get the bus available for the Z80. The second signal that'll be ANDed (so ORed in negative logic) to it will be variably wired depending on how we want to distribute the time between the CPU and VDP. Here's some combinations that can be used:

  1. to VCC, gets ignored
  2. to GND, the CPU gets all the time
  3. to A14, the CPU gets all the time (mainly) while it's accessing the ROM, notably gets ignored in HALT mode
  4. floating/time split, the VDP and CPU gets an equal share on average, on the display the information looks covered in snow

The third signal to be ANDed will be the /IORQ signal, this allows for timings to get just accurate enough for a tape to be loaded in the third mode if the program uses the ROM routines to load (that is, it doesn't use a "fast" loader)

Since we're using a single memory chip for holding both the ROM and the RAM, we may want some mechanism to protect the ROM from getting erased by a rogue program that'd try to write to it (see my article on battery-backed SRAM for more info)

You'll need a 32KiB SRAM for a 16K spectrum and a 64KiB SRAM for a 48K one, the larger SRAM usually have the advantage of having a active-high chip enable signal that can be used as protection with the reset circuitry

The analog circuitry is a mess and the seasoned designer can probably do a better job but it does work properly enough, most of the time. Getting the tape input to work was a pain.

There is three sections in the schematics with multiple circuit options, depending on what features and complexity you want the system to have. The 16K variant can barely be built on two breadboards, the 48K one definetly needs three unless you combine the logic into a single array chip (that's a story for another time).

(*2) We could use also use the /FS signal of the 6847, but it isn't regular unlike the /HS one

keyboard

For testing, i used a random matrix i had laying around that had absolutely no correspondence. Then, i made a proper keyboard using a 20x15cm single sided PCB, cut in half vertically and in four horizontally, soldered 8 wires to each zone, then soldered 5 buttons to each zone and wired the other sides together in concentric "U" shapes to replicate the original ZX spectrum matrix.

Here's what it looks like:

a cheap excuse of a keyboard

And this is the key labels to print and stick to the plate (300 DPI):

the text overlay to glue to the pcb

It's not the best design by far but it's functional enough and was made with stuff i already had.

so, how good is that

Aside from the aforementioned timing issues, there's the issue of colour. The ZX Spectrum can assign any of ~16 colours for both the background and foreground values for each block of pixels. For the most part, it does not impact the usability of programs, with the notable exception of ones which use palette swapping tricks, like most of the tetrises for instance.

The general usage of the timing "modes" is as follows:

Mode 1 allows for a proper display at the expense of speed.

Mode 3 is a compromise that allows for a mostly correct display while inside BASIC and allows for loading games from tapes which are using the ROM routines.

For games which use a "fast" loader located in RAM, Mode 2 allows for the most accurate timings to hopefully load the program correctly, at the expense of being unable to see anything on the display (the LEDs on the output ports would be the only indication of the program loading or not).

Mode 4 is a catch-all mode for using loaded programs that, depending of which option you used, varies from flickery to very "snowy". It allows for playing games at a usable but slightly slower pace, which is the best you're gonna get on this machine.

but what about games

Here's some which i tried, that are notable enough to be at the end of this article.

16K Superchess (1983, 16K)

A basic chess game that works well, except for the pieces being undistinguishable.

Crabs (1982, 16K)

Your funky pac-man clone, usable in mode 4. Uses the speaker for funny sounds. Fun to play for a bit.

Minesweeper (1992, Softhouse Ltd, 48K)

Loads fast, controls are a bit unintuitive but remappable. Usable in modes 1, 3 and 4. It's minesweeper.

Samurai Warrior: The Battles of Usagi Yomiji (1988, 48K)

A cuuuuuuute game that looks neat. Runs in mode 4.

Elite (1985, 48K)

I can't get this game to load at all, sadly.

[top]

all you never wanted to know about the NSC800

[top]

It all started with a seemingly simple question: Who made the first CMOS Z80 ?

From what i knew back then, there were three contenders:

What i concluded is that NEC and Toshiba both released their version somewhere around 1984, and Zilog announced theirs in their 1985 databook.
While searching i did find a Japanese document that described the lineage of the Z80 chip and mentioned a chip that somehow managed to skip my radar until now.

aside: compatibility between the various CMOS Z80s

The Toshiba and Zilog CMOS Z80 both have a lower power sleep feature which puts the CPU in a µA range power consumption when their clock is stopped provided a specific sequence whereas the NEC one does not, and may not like its clock being stopped according to the datasheet.


da NSC800

Enter National Semiconductor with their NSC800, announced in 1980. It's a CMOS microprocessor (using technology that's comparable to HC logic) that's entirely software compatible with the Z80. It is obscure enough to lack a Wikipedia article and instead is only summarily mentioned in the Z80 page.

It's unclear what NS wanted to achieve by half-cloning two of their competitors using then-new technology but the result wasn't as successful as the later CMOS Z80s proved to be.

Part of it's obscurity is certainly due to its many, many caveats:

For those caveats, the chip provides some features that were lacking on the Z80:

It's also of interest that this chip was produced for a very long time (up until at least 1997), long enough that the latest datasheet is available as a proper PDF that's not just a scan.

using the thing

Using that chip in lieu of a Z80 is not as simple as one might think by skimming through the datasheet.

The timing is similar but not identical, the IO/M line for instance is asserted at the same time as the address and thus can't be used as a trigger as with the Z80's MREQ and IORQ. Regaining such signaling can be done by ANDing the RD and WR signals and gating the IO/M line with the result.

The clock driver is of the finicky kind and can have trouble starting up if the resistor and capacitors aren't just right.

For what it's worth the four 2.5MHz parts i've got all happily will run at 4MHz and more at 5V.

Implementation of the new maskable interrupts is done via a IO-mapped write only register (ew) at address 0xBB, that also includes a normally set flag for INTR

miscellaneous info and some speculations

Early NSC800 documentation mentions the possibility of running the chip at up to 12 volts for more performance, while later documentation gives a 2.4 to 7V range.
It seems perhaps the higher voltages caused issues either with the chip itself or with designers using parts that didn't like the higher voltage signaling.

There's a pretty interesting report from the NASA website that takes a look at three samples of the ceramic NSC800 and goes into details about how the chip works.
Of interest is the mention that each of their samples contained a different die revision, the last one also being a size shrink.
The naming scheme suggests that there was a bunch of them on the 1980-1983 period and the siliconprawn die shot of the chip is yet another die revision.

[top]

simpler breadboard computers using battery-backed SRAM

[top]

Typical bradboard computer designs include two types of memory arrays for the CPU to read that have different properties: a read-only memory (ROM) containing the program and a random-access memory (RAM) containing the program variables.

The ROM (typically EPROM, EEPROM or NOR Flash) isn't usually writiable or re-writable, even though some types are to some extent. This is partly because the writing signaling of those isn't suitable for temporary storage and the number of write cycles those can withstand is limited.

The RAM (typically SRAM (*1) ) doesn't allow for keeping the data when no power is applied to it, which is a problem when you want to remove the chip for programming.

There's nothing preventing applying a separate isolated power source directly to the SRAM to allow for somewhat long-term storage, and thus significantly simplify the wiring and cost of a breadboard computer.

(*1): Unless using a Z80, which can interface easily to a pseudo-static RAM (XRAM/PSRAM).

alternatives

commercial modules

Some memory manufacturers (Dallas, ST to name the big ones) made and are still making memory modules that consist of a low-power SRAM chip, protection circuitry and a lithium button cell. Those modules are unfortunately quite expensive new and some sellers put a shipping restriction on these due to the lithium cell.

Also, those modules protection circuitry can have a significant start-up time when powered-on which should be taken into account if using them as main memory.

It it also noteworthy that some of these modules integrate a real-time clock (RTC) for timekeeping applications.

FRAM

Ferroelectric RAM (FRAM) is a type of memory that keeps its contents without the presence of power and has most of the properties of SRAM. It is roughly an order of magnitude more expensive than the equivalent SRAM new.

A constraint of these is that they don't support subsequent reads without reasserting the Chip Enable (/CE) signal, that is, you can't leave that singal low on the breadboard computer.

how-to

The minimal setup consists of an SRAM chip, two diodes, a power source (for example, a CR2032 in a holder) and a high value resistor (typ. 100Kohms).

A way of wiring it is to solder the negative lead of the power source to the VSS of the SRAM, the positive lead of the power source to the VCC of the SRAM through a diode.
Solder the resistor between a Chip Enable (/CE or CE) signal and either VCC or VSS so that the chip stays unasserted.

Finally, on the breadboard, add a diode to isolate the 5V rail from the battery backed SRAM.

example picture showing a Mosel MS6264CLL with the modifications on a breadboard

Here's some notes on caveats you may encounter:

low-power SRAM

You want to be sure that the SRAM chip can be safely maintained at a low voltage/amperage if using a power source like a lithium cell. A clear indicatior of that is a -L or -LL marking on the chip, though other CMOS SRAM can also have suitable characteristics.

In any case, it is advised to check the datasheet of the particular used chip.

Old NMOS/PMOS SRAM (most 2114 chips, early 16Kx8 SRAM) aren't very suitable for that.

programming SRAM

The TL866 series of programmers supports the following commercial modules from Dallas which algorithms can be used to program battery-backed SRAM:

- DS1220, for programming 16Kx8 SRAM (typically 6116)
- DS1230AB, for programming 64Kx8 or 256Kx8 SRAM (typically 6164, 6264, 62256) (*2)

(*2): There is a DS1225 module which would be suitable for 6164/6264 except that pin 26 isn't wired on those, and the TL866 doesn't assert that pin as a result. See the "funny scripts" section for examples on how to handle those using the DS1230 algorithms.

protecc the SRAM contents

You need a suitable circuitry that'll ensure that the breadboard computer won't do spurious writes at power-on and power-down. This can be accomplished, for example, with voltage watchdog chips such as the TL7705, MCP100 or a simple microcontroller with brown-out detection.

the easy option: 6x64 SRAM

The 6164/6264 and compatible SRAM are well-suited for that approach due to the presence of an active-high Chip Select (CS2) signal. On those, this signal can be wired directly to the /RESET signal to ensure protection of the stored data.

SRAM without positive logic enable

On SRAM without a positive logic enable, you can combine either the Write Enable (/WE) or Chip Enable (/CE) signal with the reset signal using an appropriate logic chip. Make sure that the logic chip is able to assert high the signal for long enough to actually protect the SRAM's data. A pull-up resistor can help with that.

data retention

You can expect data retention figures of more than 20 years with a -L rated 6164/6264 and a 220mAh CR2032.

funny scripts

Here is example shell scripts that can be used to program a 6164/6264 SRAM with the DS1230AB algorithm of the TL866:

#!/bin/sh
# read a 6164/6264
minipro -p "DS1230AB(RW)" -r /tmp/8ko
dd if=/tmp/8ko of="${1}" bs=8K skip=1 count=1
exit 0

#!/bin/sh
# write a 6164/6264
dd if=/dev/zero bs=8K count=1 | LC_ALL=C tr "\000" "\377" > /tmp/8kff
cat /tmp/8kff $1 > /tmp/8ki
minipro -p "DS1230AB(RW)" -w /tmp/8ki -s && exit 0
exit 1
[top]

"art"

[top]

Here's some random stuff i've drawn (hover for a brief description):

nei from phantasy star 2 lisa from bubblegum crisis chestnut-haired amber-grey-eyed character with a grey-blue and red sweater doing a :/ face of sorts a crudely drawn swedish shark, with the word 'same' a dark-skinned gold-haired girl with a red and purple sweater and a beret looking at the viewer with a quite determined stare and a 3 mouth pixel art of a blonde witch (i guess) with golden eyes wearing a blue-green cloak on top of a red shirt

writing pc-98 disks with an ibm pc

[top]

Disclaimer 0: This assumes you're familiar with the NEC PC-98 family of computers. For information on this, I would recommand you to read this post on Wyatt's Blog.

Disclaimer 1: This is only useful if you don't have a flux writer (like a greaseweasle for example).

Disclaimer 2: You can also write a floppy by using your PC-98 itself, if you can easily transfer data to it.

crash course

The designers of the PC-9801 architecture (that is, the people at NEC) initially chose a simple approach for dealing with Sony's then new 3.5 inch (90 millimeters) diskette format: they didn't.

That is, in the PC-98 world, a 3.5 inch drive can behave the same way as a 5.25 inch one. This had the main consequence of most games and software being distributed on what is commonly called the "1.2 MB format" (in reality, 1232 KiB).

This is different from the one used in the IBM PC world, which is exactly 1200 KiB (more on that later).

Since the interfacing was initially identical, the other consequence from this is that the spindle motor of those early 3.5 inch PC-98 drives rotated at a speed of 360 RPM, to match the speed of the 5.25 inch drive.

When the people at NEC later decided on adding support for the concurrent DOS/V format (which rotates at a speed of 300 RPM), they used a way to allow the drives to change speed on the fly to allow both formats to be read (it is unclear if this originated from NEC, as others Japanese computers of the era used the same approach).


3-mode floppy drives

The industry standard way of changing the speed of the spindle motor of a 3.5 inch floppy drive is by using pin 2 on the 34-pin interface (this pin is usually called "density").

In this regard, most floppy drives are not created equal, as only a fraction of those can actually change the rotation speed of the spindle motor.
Here is an exaustive list of drives (made by testing units that I have) with the various states of support for that feature:

Full support without any modifications:
- NEC FD1231T
- NEC FD1231M
- Mitsumi D353M3D-5000 (probably other variants)
- Teac FD-235HG (A103-U5 variant, probably others)

Support with hardware modifications on some exemplaries:
- Sony MPF920 (put solder on pad marked SH1 on the PCB)
- Alps DF354 (put solder on pad marked either MS2 or SW2 on the PCB)

Unsupported (may be possible with extensive modifications:
- Panasonic JU-257A606P
- Newtronics (Mitsumi) D359T7 (this one is hell to disassemble, so i didin't)

aside: 3-mode IBM compatible motherboards ?

A lot of people who messed with the BIOS setup of their computer in the 2000s will remember an option that was named "3-mode floppy support" in it.

Well, this option was meant for allowing Japanese users of Windows to have a way of reading and writing (but not formatting) their PC-98 floppies in the era when both types of machines were common.

The way it worked was by a custom floppy drive interface driver (some were supplied in the japanese releases of windows, some others were pre-installed by the OEM) that changes the way the operating system talks to the Super I/O chip on the motherboard.

Since it's very limited in its functionality and it's very hard to setup properly (tried on different motherboards, it does not want to work), I decided against using that, and preferred another method.


an imperfect but easy way of writing disks

"if you force 360RPM via hardware, couldn't you make it treat the drive like a 5.25" drive and have it work?"

This idea from Wyatt was the missing piece in the puzzle to solve this (very specific) problem.

The ingredients you will need for this recipe are:

- A 3-mode compatible 3.5 inch floppy drive
- A IBM compatible machine with a floppy interface
- A Windows 2000 or later installation that works on this machine
- Some images in the D88 format (if not, you can convert them with the tools here)
- The SAMdisk utility and the fdrawcmd.sys floppy driver
hardware preparation

Short pin 2 of your floppy drive to ground. Using a soldered wire is preferred, but you can also use a jumper (or switch) and extend the others floppy pins by soldering a male header with a female one like this:

modification picture

Before doing modifications, double-check that the ground point you're using is actually connected to ground. Some drives for example does not connect pin 1 to ground, which makes the jumper method useless.

software usage

In the BIOS setup of your computer, modify the drive type of the one you installed to "5.25 inch, 1.2MB".

Install the fdrawcmd.sys driver using the instructions provided on the website, and copy the SAMDisk executable to a known location.

Then, you can test if your drive modification was sucessful by using the following command (with a floppy in the drive):

    SAMdisk rpm a: (or b: if the drive is the second one)

If everything worked fine, the software should report a speed of approximatively 360RPM.

To write a disk, use the following command:

    SAMdisk [disk_image.d88] a: (or b: if the drive is the second one)

You can also image a disk with the following command:

    SAMdisk a: [disk_image.d88] (or b: if the drive is the second one)

See the documentation on the website for additional options.


additional thoughts

Since the fdrawcmd.sys part of this software is open-source, it should be possible to write a piece of software that would handle the many formats that the PC-98 floppy images uses.

[top]

books

[top]

Here are some (most) of the books that I've read, ordered by reading date.
Electronics books and mangas are excluded from the list, I have too many of them to list and I don't remember when I first read them.
I've written the English titles when available.

childhood:
- Microsoft Windows 95, 1998 New Edition, Warren Bates
- Building a PC for Dummies, Mark L. Chambers
- UNIX for Dummies, 4th edition, John R. Levine, Margaret Levine Young
- Linux for Dummies, 4th edition, Dee-Ann LeBlanc
- MS-DOS 5 utile, Daniel Rougé
adulthood:
- The Lord of the Rings, J.R.R. Tolkien (vol. 1 only)
- Introduction à Ada, Pierre Le Beux, Second Edition
- Sword Art Online, Reki Kawahara (vol. 5 and 6 only)
- The C Programming Language, Brian Kernighan, Dennis Ritchie
- Haruhi Suzumiya, Nagaru Tanigawa (12/12 vol.)
- Curiosities of Lotus Asia, Jun'ya Ōta "ZUN"
- Shakugan No Shana, Yashichiro Takahashi (1/22 vol.)
- Kino's Journey, Keiichi Sigsawa (16/23 vol.)
- Higehiro, Shimesaba (2/5 vol.)
- The CMOS Cookbook, Don Lancaster, Second Edition
- The TTL Cookbook, Don Lancaster
currently on the reading stack:
- Structure and Interpretation of Computer Programs, Second Edition, Harold Abelson, Gerald Jay Sussman, Julie Sussman
- The Apothecary Diaries vol. 1, Natsu Hyūga

Some notes:
All of my computer science books came from thrift stores.
Availability of light novels in a language other that Japanese can be abysmal. Kino and Shana only have the firsts volumes officialy translated in English, have long been out of print, and will probably ever be.

[top]

wanted software

[top]

I'm currently looking for a copy of the following software. If you have any information on it, please get in touch.

- NEC PC-UX or PC-UX/V for PC-98
- Any complete copy of any version (CD and floppies) of Debian(98), the PC-98 version of Debian.

this website

[top]

I had this really dumb idea of creating a webpage that would be contained in only one file. Here are some random thoughts and obstacles I ran through while doing this:

This will absolutely backfire one day.

There is no menu to design.

Images. They are encoded in base64, and I had to make compromises on quality to keep the file sizes small and thus the html file somewhat readable:

-Mostly JPEGs in low quality (favicon for example is so small PNG is more efficient)
-Monochrome images
-Smallest resolution acceptable

exampleHere is a 4KB JPEG example.
One compromise I didn't make was to use arhitmetic-coded JPEGs. stb-image.h and old browsers hates them, and the size loss wasn't that interesting.
As a side-effect, this webpage lacks colour. Except links.

this page was spellcasted at time 1770411022