Memory on Steckschwein

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.

V9958 YJK (YUV) mode

Wed, 20 Mar 2024 00:00:00 +0000

Some time ago we introduced a tiny tool called ppmview.prg in our collection of tools and progs for our Steckschwein. The ppmview.prg, as the name already tells, is able to load an image in ppm (Portable BitMap) format with a maximum size of 256x212px and displays it on the screen.

The first version of ppmview was released in 2018 and since then we just use the SCREEN 8 (MSX) also known as graphic mode 7 (RGB).
Mode 7 is a bitmap mode where we have 256 colors available and each pixel requires 1 Byte for their color information. The 1 Byte color information must be stored in VRAM encoded as GRB 3:3:2 (green, red, blue), which means 3 Bit green, 3 Bit red and 2 Bit blue.
On the other side we have the PPM color information - which is 24Bit RGB - so we have to adapt or map the 24Bit to our 8 Bit GRB color value in some way.
It becomes apparent that this comes with a price, namely the loss of color information. Especially the blue part of the pixel is just 2 Bit, hence we have 4 levels of blue per pixel available only. The following screenshot from our Emulator shows the loss of color information.

SBC - troubleshooting

Mon, 15 May 2023 00:00:00 +0000

Our debugging journey at VCFe began right at powering up the board the first time, when something got real hot real fast. Fair enough, and easy to spot. There was a mixup of VCC and GND at U29, a 74HCT244. Embarassing, but not that critical, as U29 is only used to connect the joystick ports to Port A of the VIA. We can live without them for now.
The mixup likely happened when I transferred the IO-board schematics from KiCad 6 to 7 while updating the symbols from the current library, which happened to be different than the old ones. I had to mirror the new symbols to fit the schematic. This meant that GND is at the top now, and VCC at the bottom. Which I happened to overlook. While routing, I was briefly wondering why U29’s bypass capacitor was at the opposite corner compared to all the other 74HCTnnn chips. I maybe should have become suspicious at that point.

It's alive - sort of

Tue, 09 May 2023 00:00:00 +0000

Our plan for VCF2 22.0 was to assemble the first Steckschwein SBC right at our booth as some kind of show-cooking event. That only half worked, as this quickly turned into show-debugging instead of show-cooking. It was only just right before the end of VCFe 22.0, just before we had to pack everything up, we managed to get the SBC to talk to us via serial:

New boards are here!

Thu, 27 Apr 2023 00:00:00 +0000

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/

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.

It's a Long Way to the Memory Top

Tue, 28 Jun 2022 00:00:00 +0000

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.

512k Ought to Be Enough for Anybody

Fri, 27 May 2022 00:00:00 +0000

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.

V9958+OPL2-Boards are there

Sat, 15 Dec 2018 00:00:00 +0000

The newly made boards made their way from China to Munich. Starting now, the multi board version of the Steckschwein is made up of 3 Boards: CPU/Memory, IO/UART and V9958-OPL2.

V9958 - Es ist vollbracht

Sat, 17 Mar 2018 00:00:00 +0000

Da ist sie nun, die neuen Videoplatine. Nach einigen Umwegen hat der Packen Boards uns erreicht (die erste Lieferung ist versehentlich in Spanien gelandet, während wir die Platinen des spanischen Bastlers erhalten haben. Inzwischen hat jeder Ersatz erhalten).

Wir haben ja bekanntlich unsere Vorgehensweise geändert, indem wir schneller Platinen anfertigen lassen. Aber zu unserer großen Freude funktionierte die erste Platine nach Bestückung auf Anhieb. Selbstverständlich haben sich aber auch ein paar Patzer eingeschlichen.

Logikanalyse II [UPDATE]

Thu, 04 May 2017 00:00:00 +0000

Inzwischen sind die 74F00 eingetroffen und der 74HCT00 durch einen ebensolchen ersetzt. Das Oszilloskopbild sieht gleich deutlich besser aus:

gelb: /WE, blau: A9

Der Schreibvorgang wird also jetzt zumindest abgeschlossen, bevor sich die Adresse auf dem Adressbus ändert. Das ist schonmal viel sauberer.

Nur leider hat es das Problem nicht gelöst, das Steckschwein läuft mit den “richtigen” RAMs immer noch instabil, was sich insbesondere bei BASIC-Programmen bemerkbar macht:

Logikanalyse

Mon, 01 May 2017 00:00:00 +0000

Auf dem VCFe 18.0 gab es Dank Nick Müller die Möglichkeit, das Steckschwein mal mit einem Logic Analyzer “für große Jungs” zu untersuchen. Unsere USB-Logic-Analyzer sind zwar für vieles gut, aber um komplett Adress- und Datenbus sowie einschlägiger Steuerleitungen abzuhorchen, fehlen einfach Kanäle, und selbst dann wären sie nicht schnell genug.

Das Steckschwein am Logic Analyzer. im Hintergrund Nicks Finger.

Die Gelegenheit, ein solches Höllengerät (genauer: ein HP 1652B) und mit Nick auch noch jemanden greifbar zu haben, der selbiges beherrscht, gibt uns die Chance, ein merkwürdiges Problem zu untersuchen, welches schon länger Rätsel aufgibt: Die aktuell verwendeten Hyundai-SRAMs sind mit einer Zugriffszeit von 100ns eigentlich viel zu langsam für 8MHz, zumal der 6502 ja nur die 2. Takthälfte für Buszugriffe nutzt. Diese ist nur 62,5ns lang. Von dieser Zeit geht ausserdem noch die Durchlaufzeit der Adressdekodierung und weiterer Glue-Logik ab. Eigens angeschaffte neue SRAMs von Alliance Memory mit 55ns Zugriffszeit sollten also ganz knapp schnell genug sein. Trotzdem treten mit diesen immer wieder merkwürdig zufällige Abstürze auf, die 100ns-Chips laufen dagegen problemlos.

ROM an, ROM aus

Sun, 26 Oct 2014 00:00:00 +0000

Nachdem wir also mit dem Adressdecoder durchaus zufrieden sind, müssen wir uns noch einen Weg überlegen, die /ROMOFF-Leitung per Software steuerbar zu machen. Wenn es schon beim BIOS-Update Test äußerst nützlich ist einfach nur eine Brücke umzustecken und damit das ROM zu deaktivieren, wie praktisch muss es erst sein, dies einfach durch Beschreiben einer Speicherstelle zu tun.

Was wir also brauchen, ist ein IO-Pin, der die /ROMOFF-Leitung steuert. Zusätzlich muss dieser Pin beim Einschalten des Systems einen definierten Zustand haben, damit sichergestellt ist, daß zu diesem Zeitpunkt das ROM eingeblendet ist. Passende Pins finden wir an der VIA und am UART. Die Portpins der VIA beispielsweise sind initial als Eingänge geschaltet und per internem Pullup high. Auch die OUT1 und OUT2-Pins des UART sind initial high. Gegen den UART-Ansatz spricht, dass sich diese Pins nur über ein Write-Only-Register setzen lassen und es keine Möglichkeit gibt, den Zustand dieser Pins über irgendein UART-Register abzufragen.

Dekoder, die Dritte

Thu, 23 Oct 2014 00:00:00 +0000

Bekanntlich dekodiert unser GAL die oberen 8bit des Adressbus, um den Bereich $8000-$ffff unter RAM, IO-Bereich und ROM einzuteilen. Die unteren 32k werden am Decoder vorbei direkt von der Adressleitung A15 selektiert. Das Memory-Mapping, das sich daraus ergibt, ist - zur Wiederholung - wie folgt:

Bereich	Was
$0000 - $7fff	RAM
$8000 - $cfff	RAM
$d000 - $dfff	IO-Bereich
$e000 - $ffff	ROM

Die letzte Änderung am Decoder war, das ROM bei Bedarf ausblendbar zu machen. Dieser Mechanismus hat sich beim Test von BIOS-Updates als pures Gold erwiesen, da man ums neu Brennen des EEPROM herumkommt. Das spart Zeit und schont Material.

Noch schlauerer Decoder

Tue, 01 Jul 2014 00:00:00 +0000

Wir sind jetzt also fast in der Lage, das RAM unter dem ROM zu nutzen. Hineinschreiben geht, lesen noch nicht. Da ist das ROM noch im Weg. Wir müssen also einen Weg finden, die GAL-Logik von außen zu beeinflussen. Unser GAL hat noch genügend Eingänge, sodass wir einen Pin zum ROM-Ein-/Ausschalter machen wollen. Lesezugriffe nach $e000-$ffff sollen also nur noch dann im ROM landen, wenn es “eingeschaltet” ist. Sonst wollen wir ins RAM. Die wiederum erweiterte Logik im GAL sieht jetzt so aus:

Schlauer(er) Decoder

Tue, 01 Jul 2014 00:00:00 +0000

Im Rahmen unserer Reihe “Kleine Verbesserungen an der Architektur” ist heute der Adressdekoder dran. Dieser entscheidet bekanntlich anhand der am Adressbus anliegenden Adresse (oder genauergesagt deren höheren 8bit), welcher Baustein an der entsprechenden Adresse eingeblendet werden soll. Durch den Umstand, dass die oberen 8k dem ROM gehören, lassen sich die darunterliegenden 8k RAM nicht ohne weiteres nutzen. Die für die Selektierung des ROMs und der oberen 32k RAM sehen folgendermaßen aus:

... kein Spaß - Murphy schlägt zu

Mon, 31 Mar 2014 00:00:00 +0000

Neben all den ermutigenden Experimenten gibt es natürlich auch immer mal wieder Rückschläge. Mittlerweile haben wir schon ein durchaus komplexes Gebilde auf dem Steckbrett, welches ja per se nicht die ideale Plattform ist, um so etwas zu bauen.

So wie aktuell gerade mein “Steckschwein” ein sehr merkwürdiges Verhalten an den Tag legt, ohne dass an der Schaltung etwas geändert worden wäre (Marko ist Zeuge).

Vorab nochmal der Ablauf unserer Upload-Routine, mit der wir das Steckschwein via RS232 mit Code befüttern:

Das Design wird erweitert

Sun, 16 Mar 2014 00:00:00 +0000

Sinn der Sache ist ja nicht, etwas 1:1 nachzubauen, sondern ein möglichst eigenes Design. Nachdem wir mit Chris’ Design - bzw. dessen, was wir davon übernommen haben (Adressdekodierung, ACIA, VIA) - genug herumgespielt hatten, galt es, “unser” Ding draus zu machen. Der erste Schritt war ein Sprung ins kalte Wasser in die uns bislang noch unbekannte Welt der Programmierbaren Logik. Dazu haben wir zunächst die Adressdekodierung bestehend aus 74ls138/74ls154 sowie etwas glue Logic in VHDL implementiert und auf ein GAL22V10D gebrannt. Somit haben wir 3 TTL-ICs durch einen GAL ersetzt und wieder Platz auf dem Steckbrett geschaffen. Und das Beste: Änderungen an der Dekodierungslogik laufen ab sofort minimalinvasiv.

TMS9929 - Wir wollen was sehen...

Sun, 02 Mar 2014 00:00:00 +0000

… und zwar auf einem Bildschirm! Aber wie stellt man sowas an?! Nun, wir schauen uns um, was Ende der 70-er bzw. Anfang der 80-er Jahre Stand der Technik war und was sich mit überschaubarem Aufwand an eine 6502 CPU “anschließen” lässt. Die Auswahl ist leider überschaubar, denn es sollte irgendwas in DIP maximal noch SDIP sein und dazu noch irgendwie lieferbar - “new old stock”.

Wir fanden die TMS9918/28/29-Serie und einige Nachfolger wie den TMS9938/58. Für’s erste sollte es ein TMS9929 sein, weil der tatächlich noch zu beschaffen ist und dazu auch noch im DIP-Gehäuse daherkommt. Der -29 ist für den europäischen Markt gebaut worden, um diese an PAL-Fernsehgeräte anschließen zu können. Hier eine kleiner Auszug der technischen Fähigkeiten, die im Jahre 1980 wahrscheinlich gigantisch wirkten.