Thomas on Steckschwein

Software

Mon, 01 Jan 0001 00:00:00 +0000

BIOS

At initial boot time, the ROM bank containing the BIOS is banked in. The BIOS initializes the hardware, such as the UART and the video chip, and tries to load the steckOS loader executable (usually LOADER.PRG) from SD card and executes it. If that fails, the BIOS expects a PRG binary uploaded via XMODEM. UART baud rate and the name of the steckOS loader executable can be configured and are stored in the RTC’s NVRAM.

VCFe25.0

Sun, 03 May 2026 00:00:00 +0000

VCFe25.0 has been awesome, as always. This time, all the talks have been recorded and will be available soon.

The slides for our talk about our ATF150x toolchain are available here

UART: Double Trouble

Mon, 23 Feb 2026 00:00:00 +0000

The DUART TL16c2752 is supposed to be a rather big upgrade to the Steckschwein “core”. Now two serial interfaces, with 64 byte FIFOs each, instead of only one interface with 16 byte FIFOs. Oh, the possibilities. Using one line to explore UART interrupt handling while still having another one to upload code. Cool!

With the 16C2752 being a part of the 16C550 family, we did expect it to be a simple drop in replacement for the latter one. As we all know, happiness is reality minus expectation, and oh boy did things get dreadful!

Prototype with ATF1508 on Breadboard [UPDATE II]

Thu, 14 Aug 2025 00:00:00 +0000

We are going back to breadboarding for designing what will be the base for the new Steckschwein computer core. By “core” we mean CPU, RAM, ROM and the glue logic which will be accommodated in the ATF1508 CPLD. In order to communicate with the outside word, we also count the 16C550 UART as part of the core.

Design goals

Our main design goals are:

Integrate SPI into the CPLD -> DONE
Using a hardware based SPI implementation similiar to Daryl Rictor’s SPI65, but tightly integrated into the CPLD will be an efficient use of the CPLD resources and will provide a much more performant SPI bus as opposed to the current semi-bit-banged solution. This way, it will be much more performant to add more SPI based components such as USB host or networking (see below).
Update: Done! We decided to use Andre Fachat’s SPI implementation from his MicroPET. The main advantage over rolling our own is - it’s already there. Another main advantage over other existing Implementation is that the MicroPET one is pretty small, which is important when CPLD resources are at a premium.
Implement a priorising vectorising interrupt controller
This will improve interrupt handling by assigning a dedicated ISR routine per interrupt source instead of one system ISR.
Update: We are already scratching the limit of the ATF1508. The PLCC84 version we use in our prototype can not handle more pins, so we are unable to add the inputs needed for all the interrupt sources we need. While this is unfortunate, we have not scrapped the idea of an interrupt controller. We might move to the TQFP-100 version at some point, which obviously has more pins.
DUART instead of UART
Replacing our trusty 16C550 with a 16C2752 DUART will provide two serial interfaces without increasing the chip count.
With two serial ports, we will be able to upload programs on one serial port, while observing the output on the other one. Also, a separate upload interface will allow us to explore UART interrupts on the other.

Other changes/optimizations

Other things that will be optimized are:

CPLD Upgrade and new Toolchain

Sat, 19 Jul 2025 00:00:00 +0000

Since we introduced our new banking logic to access 512k RAM, our glue logic is being accommodated by a Xilinx XC9572 (without XL) CPLD. This component has long been deprecated when we started using it. We chose it because it was what we had available. The upgrade path would be the successor family XC95..XL. Those have been rather expensive lately, and finally AMD/Xilinx axed their whole CPLD line in 2024, leaving us at a dead end. Where do we go from here? The market for CPLDs is not exactly growing. Only a few manufacturers are still actively producing them.

Golem.de Podcast featuring Steckschwein

Mon, 09 Jun 2025 00:00:00 +0000

We talked to Martin Wolf from Golem.de about our Project, how it came to be, and of course about our version of Pacman.

Listen to our Episode (in German) here!

Finished moving to codeberg.org

Thu, 08 May 2025 00:00:00 +0000

After we moved this website to Codeberg Pages, we now finished moving our Repositories to www.codeberg.org.

The resources page has been updated with the new URLs.

Our repositories on GitHub will remain available as push mirrors, but may vanish at some point.

Codeberg is a non-profit, community-led effort that provides Git hosting and other services for free and open source projects.

Our talk at VCFe 24.0

Tue, 06 May 2025 00:00:00 +0000

At this year’s installment of the Vintage Computer Festival Europa we talked about how the Steckschwein came to be in its current incarnation. Marko presented his feature complete implementation of Pacman - the only one for 6502 based systems that replicates the look and the behaviour (including bugs) of the original arcade almost completely.

In case you could not attend our talk or even VCFe, you still can download the Steckschwein slides and the Pacman slides.

Save the date - VCFe 24.0

Wed, 16 Apr 2025 00:00:00 +0000

This year’s installment of the Vintage Computer Festival Europa is - again - a special one for us: VCFe 24.0 will be focused around “50 years of 6502”!

So be prepared for lots of 6502 related and also unrelated exhibitions and talks!

We will of course be there, too, presenting Marko’s Pacman implementation - the only one for 6502 based systems that replicates the look and the behaviour (including bugs) of the original arcade almost completely.

We have moved (again)

Sun, 06 Apr 2025 00:00:00 +0000

We have indeed moved again. As of now, our homepage at www.steckschwein.de is no longer being hosted by Github Pages. Instead, we are now being hosted by www.codeberg.org.

Codeberg is a non-profit, community-led effort that provides Git hosting and other services for free and open source projects. We believe that a non-profit organization is a much better home for our project than a multi-billion-dollar multinational corporation based in the US.

Our plan is to move all our repositories from GitHub to codeberg.org.

Flash - Master of the Universe

Tue, 04 Feb 2025 00:00:00 +0000

The 28C256 EEPROM, which holds the BIOS, has been our go-to choice since the early breadboard days. Before that, we relied on EPROMs, which required UV erasure before every upgrade—a time-consuming and inconvenient process. Switching to an EEPROM significantly improved our workflow, reducing turnaround time.

However, the 28C256 has a couple of drawbacks:

It cannot be written in-circuit since it requires a 12V programming voltage, which the Steckschwein does not provide.
It is slow, with an access time of 150ns, forcing us to introduce wait states to slow down the CPU when accessing the BIOS.

Because of these limitations, using ROM routines isn’t ideal from a performance standpoint. As a result, the BIOS’s sole function is to load the steckOS bootloader from an SD card into RAM and start it.

Brainfck

Tue, 08 Oct 2024 00:00:00 +0000

After introducing BASIC and Forth as interpreted languages on the Steckschwein, it’s time to add another unique and productive language—Brainf*ck.

For those unfamiliar, Brainf*ck (or Brainf**k) is an “esoteric” programming language created in 1993 by Urban Müller, the founder of Aminet. You can read more about it on Wikipedia.

A compact Brainfck interpreter can be found here, originally developed for the Apple ][. This version served as the foundation for the Steckschwein adaptation. The Apple ][ ROM calls were replaced with custom code, and the interpreter loop was optimized using 65C02-specific instructions, making it smaller and faster. Although performance gains in Brainf*ck aren’t critical, the improvements are noteworthy.

VCFe 23.0 - It's been great - as always

Mon, 09 Sep 2024 00:00:00 +0000

We are reflecting on a very special VCFe, as it marked the 10th (or 10 1/2th) birthday of the Steckschwein.

Reconnecting with old friends, making new friends, and celebrating and eating our 12 cycle muffin NOPslide together were all incredibly enjoyable experiences.

Additionally, Marko allowed an exciting sneak peek into his nearly complete Pacman implementation, the first ever on a 6502 that closely replicates the behavior of the original Namco Pacman Arcade.

VCFe 23.0 - The wait is finally over

Mon, 02 Sep 2024 00:00:00 +0000

The 23th annual European Vintage Computer Festival will take place on 7./8. September 2024!

The special focus of this year’s VCFe is _50 years of 8080 and 6800 with a lot of exhibitions and talks around those CPUs.

Also, the Steckschwein will celebrate it’s 10 year anniversary (more like 10 1/2 now) with you!

We will be showing all Steckschwein incarnations from its humble and nameless beginnings on a breadboard to the current 512k SBC version! Also, we will host a talk about the most important milestones and challenges in the last 10 years, and of course we’d like to celebrate!

Generating QR Codes

Wed, 24 Apr 2024 00:00:00 +0000

In order to generate our own QR codes natively on the Steckschwein, we drew a lot of inspiration from this article https://8bitworkshop.com/docs/posts/2022/8bit-qr-code.html

It even points to an adapted version of the qrtiny library, that has been made to compile with cc65, including a demo for the Apple ][, using cc65’s own Tiny Graphics Interface (TGI). Which is very nice, because all the hard work has already been done.

We have not implemented TGI (yet?), but we do have our rudimentary BGI (Borland Graphics Interface), which is similar. So all that’s left to do is porting the code to BGI, which has proved to be fairly trivial:

VCFe 23.0 - UPDATE

Thu, 18 Apr 2024 00:00:00 +0000

Update

VCFe 23.0 has been postponed until September 7th due to issues with the building.

Save the date! The 23th annual European Vintage Computer Festival will take place on 7./8. September 2024 !

And of course there can be no VCFe without Steckschwein. This time is special, as we first presented the humble beginnings of our (then nameless) favourite homebrew computer at VCF 15.0 in 2014. So this year not only marks the 10th anniversary of the Steckschwein, but also the 10th anniversary of the VCFe being “home” of the Steckschwein.

Sorting Demo

Wed, 17 Apr 2024 00:00:00 +0000

To share my fascination for the numerous sorting algorithm videos on youtube, I took some sorting algorithm examples in C from https://www.geeksforgeeks.org/sorting and visualized them using our BGI compatible C graphics library (more about that later).

The algorithms shown are:

Bubble Sort
Cocktail shaker Sort
Gnome Sort
Insertion Sort
Comb Sort
Heap Sort
Shell Sort
Selection Sort
Quick Sort
Merge Sort
Radix Sort

The code examples from https://www.geeksforgeeks.org/sorting are only slightly adapted and could be compiled with cc65 almost instantly. The trick was only to find the places in the code where the interesting search array accesses happen.

Niklaus Wirth 15.2.1934 – 1.1.2024

Thu, 04 Jan 2024 00:00:00 +0000

Niklaus Wirth has died on 1.1.2024 at the age of 89. Known to most as the creator of the programming language Pascal, Wirth was also primary designer of the programming languages Euler, PL360, ALGOL W, Modula, Modula-2 and Oberon, heavily influencing coming languages and the paradigm of object oriented programming, and programming methodology altogether. Furthermore, he led the team designing the Lilith workstation, a graphical workstation with a bitmapped graphical display, heavily influenced by the Xerox Alto.

10 Years

Tue, 26 Dec 2023 00:00:00 +0000

In order to fill the void in the days between Christmas and New Year’s Eve 2013, we began experimenting with a 65C02 on a breadboard. This little experiment would later evolve into an actually working 8bit computer. 10 years and some significant amount of focus creep later we had build this cool little 8bit machine with the specifications found here.

The amount of new stuff to learn to design a new computer out of “old” or “retro” components was massive. We went about it as rather electronics noobs who only had basic knowledge about anything. We did not have a lot of experience with circuit board design. We did some assembly coding on the C64, but nothing as big and complex as a FAT32 filesystem, let alone some sort of an operating system, albeit a rudimentary one.

Saving ASCII sources in EhBasic

Sun, 10 Dec 2023 00:00:00 +0000

Our FAT32 driver now supports byte-wise writing of a file. Reason enough to continue reworking the file handling of our EhBasic port that we started here to finally having the SAVE command write ASCII source files.

The basic idea is to open a file, redirect the EhBasic output vector to our new kernel call “krn_write_byte”, then trigger the LIST command internally. The listing being output by LIST will then be written to the opened file instead the screen. Finally, once LIST is done writing, close the file and return.

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

Wed, 26 Oct 2022 00:00:00 +0000

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.

Loading ASCII sources in EhBasic

Thu, 23 Sep 2021 00:00:00 +0000

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.