The Steckschwein is a homebrew 8bit computer based on the 65c02 CPU.

The Steckschwein in it's current incarnation as single board computer

The Idea

The project began with a simple idea: create an 8‑bit computer that feels like it came straight out of the home‑computer era, yet works comfortably in today’s world. So instead of floppy disks, the system uses SD cards via SPI, blending classic design with modern convenience.

We started by using genuine period‑correct chips to stay as close as possible to the machines of that time. As those components have become harder to find, we’re gradually introducing modern replacements—always with the goal of preserving the original spirit.

The Name

The name “Steckschwein” comes from our breadboard beginnings—Steckbrett in German. With all those unruly wires, the prototypes behaved like little pigs, so the name stuck.

The Specs

ComponentSpecification
CPU65c02-CPU @ 10MHz
Memory512k SRAM / 512k Flash EEPROM
StorageSD-Card (SPI)
Serial (rs232)UART 16550
IOVIA 65c22 (2 Atari Joystick Ports + SPI (bit banged))
VideoV9958
SoundYM3812 (OPL2)
KeyboardPS/2 via ATmega8 over SPI
RTCMaxim DS1306

Further reading and more details on Steckschwein Hardware.

The Story so far

It all started with a NOP. We put a 65C02 CPU on a breadboard and hard‑wired its data bus to $EA — the 6502’s NOP instruction, meaning “no operation.” The address bus was connected to LEDs, and the CPU clock ran at about 1 kHz. The question was simple: would the LEDs show something that looked like binary counting?

The photo series below highlights several milestones from the past years. For more detailed information about our development steps and processes, please visit our Blog.

New boards are here!

Just in time for VCFe 22.0 our new SBC boards have arrived!

Be there at VCFe, when we are assembling the new Steckschwein SBC and have a few beers with us!

Save the date(s): 29.4. - 1.5.2023

ESV München OST, now at
Hermann-Weinhauser-Straße 7
81673 München

Check it out: https://vcfe.org/

VCFe 22.0

Looks like the upcoming VCFe 22.0 will be a feast for the 6502-connoisseur: Andre Fachat will show his MicroPET and his 6502 multitasking operating system “GeckOS”, Armin Hierstetter will show an authentic Apple I replica, and of course we will be there, too, showing our new banking schema and our emulator.

Save the date(s): 29.4. - 1.5.2023

We really are looking forward to a glorious VCFe, which will also be back at the new old location, the sports hall of the ESV München OST, now at

It's a Long Way to the Memory Top, Part II

This one really is a tough one to debug. At first, we suspected the VHDL code for the CPLD as the main error source, as VHDL is not our strongest suit. In fact, the decoder/banking logic is the first thing we ever really did in VHDL (apart from a few simple decoder equations the first days we were playing with GALs).

As it turned out, the VHDL was not the main problem. It sure was quite buggy and the RDY-generator had problems, but overall it was not too far off. Marko even managed to run a memory check over the entire 512k RAM, proving that even the banking logic works. Furthermore, he was able to clock the new board at 16MHz, which is another breakthrough, as a bonus.

It's a Long Way to the Memory Top

In preparation for the build of our new CPU-Board, we purchased two WDC 65c02 in PLCC44 package from some eBay vendor. On arrival, the first interesting thing is the way they were packaged. No anti esd packaging, only a plastic bag, which we found sketchy enough to post on Twitter.

Next, WDC reacted to that tweet, stating that these might be not genuine or be at least very old.

{{/< tweet user=“steckschwein” id=“1532446031127904256” >/}}

512k Ought to Be Enough for Anybody

The biggest limitation of any 8 bit CPU such as our beloved 65C02 is the amount of memory that the CPU can address. With 16 address lines, the addressable memory is maxed out at 64k. All ROM and RAM has to be crammed into there. With the 6502 being a memory mapped architecture, IO devices need their addresses there, too.

In order to expand the amount of usable memory, some trickery is necessary. For example, the developers of the C64 came up with a rather clever hack to cram 20k of ROM and full 64k of RAM and IO area into 64k address space by introducing a register that enables the programmer to switch off the ROM, giving access to the underlying RAM. When the ROM is enabled, writes to the addresses go into the RAM below. We decided to mimic this behaviour in our current implementation of the Steckschwein glue logic.

Loading ASCII sources in EhBasic

Since our implementation of FAT32 now supports reading a file byte for byte, a little rework of the file handling in our version of EhBasic is in order.

In the past, we only could read or write a file as a whole, relative to the location in memory where the according pointer pointed to. We used this in EhBasic to save and load BASIC programs by dumping and reloading it’s binary representation from memory. While this works well, this approach has the major disadvantage that the saved program will be incompatible with other versions of EhBasic or even with our own when the token list is changed, which happens when adding new commands.