Io on Steckschwein

Fixing PS/2 Keyboard handling (Part I)

Sat, 14 Nov 2020 00:00:00 +0000

The way the PS/2 keyboard is handled has always been something we were never quite happy with. The key points being:

The PS/2 controller had no way of signalling that there has been a new keystroke, the buffer had to be polled via SPI.
The PS/2 controller had no way of talking to the keyboard and had to rely for the keyboard to initialize itself properly. Also, typematic rate and delay could not be set, as couldn’t the states of the keyboard LEDs.

Although mid- to long term, we likely might “upgrade” to USB anyway, but not without having done PS/2 right first. So, I will talk about integrating IRQ handling, and in a follow up post Marko will talk about how he got the PS/2 controller talking to the keyboard.

Connecting SNES Controller to the Steckschwein

Wed, 15 Jan 2020 00:00:00 +0000

Recently, Michael Steil published a blog post about connecting NES and SNES Controller to a 6502-based system showing how to use NES and SNES controllers on a C64 without the need for any special hardware, by just connecting them to the C64’s user port.

Why not use his approach and adapt it to the Steckschwein? The Steckschwein has a User Port, too, albeit a very different one as the C64. Basically, the Steckschwein-User-Port consists of the complete Port A of the VIA, plus the /RESET and /IRQ lines. Also of course, VCC and GND.

Weird bug in SD card code

Wed, 16 Oct 2019 00:00:00 +0000

Frank van den Hoef, who is adapting the Steckschwein SPI & FAT32 code for his tiny65 machine made me aware of a classic mistake for a 6502 assembly coder to make. Namely in our sdcard driver, when waiting for the “proper” response from the card (which should have bit 7 cleared). The routine handling this looked like this:

1 sd_cmd_response_wait:
2 	ldy #sd_cmd_response_retries
3 @l:	dey
4 beq sd_block_cmd_timeout ; y already 0? then invalid response or timeout
5 jsr spi_r_byte
6 bit #80	; bit 7 clear
7 bne @l ; no, next byte
8 cmp #$00 ; got cmd response, check if $00 to set z flag accordingly
9 rts
10 sd_block_cmd_timeout:
11 debug "sd_block_cmd_timeout"
12 lda #$1f ; make up error code distinct from possible sd card responses to mark timeout
13 rts

Classic. Obviously, line 6 should read:

NVRAM improvements

Thu, 13 Jun 2019 00:00:00 +0000

As real computer is not a real computer without a real time clock, the Steckschwein is no exception here. As we know, we use the Maxim DS1306 RTC, which is a very common RTC which comes as DIP IC and has an SPI interface. And of course it supports battery backup in various configurations. And this is where things get interesting.

Apart from timekeeping, the DS1306 also has 96 bytes of battery buffered RAM. The ideal place to store system configuration parameters. As of now, the RTC NVRAM contains the name of the file to be read from sdcard at startup, the line parameters for the serial interface (baud rate, data bits, parity, stopbits), and also a version number and a crc7 checksum:

Neue Hardware - die Platinen sind da

Tue, 28 Nov 2017 00:00:00 +0000

Die neuen IO-Platinen mit integriertem UART sind fertig und haben ihren Weg von China nach München gefunden.

Mit dem neuen Layout hat es nicht nur der UART mit aufs IO-Board geschafft, es sind auch etliche kleinere und größere Verbesserungen eingeflossen:

Die Joystickports wurden komplett neu designed. Die Optokoppler sparen wir uns, stattdessen wählen wir über einen VIA Pin verschiedene Treiber an, die den gewünschten Joystickport mit VIA Port A verbindet. Die Ports lassen sich auch per Software komplett abschalten, damit der User-Port frei verfügbar ist. Als Schutz für die VIA werden Serienwiderstände verwendet.
Der SD-Karten-Footprint und der verwendente Slot passen genau zusammen. Das war beim alten Board nicht der Fall. Jetzt sind die Karten- und die Schreibschutzerkennung endlich nutzbar.
Die Datenpins für die PS/2 Schnittstelle am ATmega8 sind gewandert und liegen jetzt an PD6 und 7. Dadurch sind die RX und TX Pins des USART verfügbar geworden und können nun z.B. für das Debugging des Tastaturcontrollers verwendet werden.
Zweckmäßigere Plazierung vom SPI-Anschluss des ATmega8 und des freien SPI Ports am Platinenrand. Updates der Tastaturcontrollerfirmware sind nun kein Krampf mehr.
Der User-Port hat ein besseres Pinout.
Die neue Platine sieht einfach besser aus. Frisch ausgepackte Platine

Fertig bestückte Platine Die nun obsolet gewordenen Platinen.

Mal wieder neue Hardware

Wed, 22 Nov 2017 00:00:00 +0000

Die Zeit ist reif für ein Hardware-Update, und zwar für die IO-Platine 2.0. Vorgesehen war ja schon länger, den UART dort zu integrieren. Ausserdem war das Joystick–Interface noch unausgegoren, sodass auch hier etwas Neues entwickelt wurde.

Zum Schutz der VIA-Pins dienen nun keine Optokoppler, sondern simple Serienwiderstände sollen die Ports zumindest vor dem Fall schützen, dass man doch mal die Datenrichtung der Joystick-Pins auf Ausgang schaltet und dann die VIA grillt indem man den Joystick betätigt. Die Widerstände begrenzen den Strom auf 1mA. Das muss die VIA abkönnen. Zudem war im vorigen Design der Userport nicht wirklich nutzbar, weil immer noch die Joysticks daran hingen. Jetzt ist es so, dass jeder Joystick über Tri State Buffer an VIA Port A verbunden wird, und zwar grundsätzlich wahlweise. Ausserdem besteht die Möglichkeit, die Joyports komplett abzuschalten. Dies wird mit dem OUT1-Pin des UART bewerkstelligt. Somit läßt sich per Software konfigurieren, ob man Userport oder Joystick benutzen möchte.

Mehr Karten (UPDATE)

Fri, 24 Jul 2015 00:00:00 +0000

Unser “Standard”-Massenspeicher SD-Karte funktioniert zwar an und für sehr gut, Sorgenkind war aber immer die Initialisierungs-Routine. Bisher ließen sich damit nur günstige Class4-Karten initialisieren, bei “höherwertigen” Karten schlug die Initialisierung immer fehl, sodass nur etwa 3 von 5 Karten nutzbar waren.

Initialisierungs-Ablauf nach elm-chan.org

Das hat uns schon etwas gewurmt, denn irgendwie hatte dieser Stand ein Geschmäckle von “Funktioniert aus Versehen”. Also mussten wir da nochmal ran. Der Initialisierungs-Flow entspricht im Wesentlichen dem, was auf der bekannten Seite http://elm-chan.org/docs/mmc/mmc_e.html dokumentiert ist. In den letzten Tagen haben wir diesen unter die Lupe genommen, und tatsächlich ist etwas aufgefallen. Vor dem Senden eines Kommandos muss sichergestellt werden, dass die Karte bereit ist. Hierzu sendet man solange $ff an die Karte, bis diese auch $ff zurücksendet. Dann ist die Karte bereit, ein Kommando zu empfangen. In unserer Initialisierungsroutine wurde dies zwischen CMD55 und ACMD41 (näheres bitte dem Link entnehmen) schlichtweg nicht gemacht. Plötzlich lassen sich fast alle vorhandenen Karten initialisieren. Dass dies mit den Class4-Karten trotzdem funktionierte, war also gewissermaßen tatsächlich aus Versehen.

Echte Zeit

Mon, 15 Dec 2014 00:00:00 +0000

Eine batteriegepufferte Echtzeituhr gehört ja heutzutage schon zur Serienausstattung, auch bei Retro-Rechnern. Das Steckschwein soll also auch eine bekommen. Chris Ward’s Design, welches uns zu Anfang als Grundlage gedient hat (mittlerweile ist davon nicht mehr viel übrig geblieben) verwendet eine DS1687, deren Intel-mäßiges Businterface über ein wenig Glue-Logik direkt an den Datenbus des 6502 angelegt ist und damit auch Platz im IO-Bereich benötigt.

Wir wollen das mit dem Steckschwein anders angehen. Unsere Echtzeituhr soll via SPI angebunden werden. Und auch ansonsten sind unsere Anforderungen eher bescheiden: - Einen Interrupt-Pin soll sie haben - Ein paar Bytes batteriegepuffertes RAM wären toll. - DIL-Gehäuse, sonst passts nicht aufs Steckbrett :-)

SPI mit 65c22 VIA

Sun, 13 Jul 2014 00:00:00 +0000

Es gibt verschiedene Ansätze, einem 6502-basierten System SPI beizubiegen. Daryl Rictor hat z.B. einen CPLD-basierten SPI-Controller mit passendem Businterface entwickelt. Meist jedoch wird eine 6522 VIA hergenommen und SPI per Bit Banging implementiert. Auch hier gibt es verschiedenen Ansätze, Andre Fachat hat es mit ein wenig externer Logik sogar geschafft, das Schieberegister der VIA im für SD-Karten nötigen SPI Mode 0 zu betreiben. Normalerweise geht das ja nicht, das das Schieberegister der VIA die Daten nicht vor dem ersten Taktimpuls anlegen kann.

Tore zur Welt

Fri, 11 Jul 2014 00:00:00 +0000

Um dem Ziel eines “richtigen” Computers näher zu kommen, brauchen wir nicht nur einen Videochip, wir brauchen auch Eingabegeräte und Massenspeicher.

Zwar soll unser Rechner so retro sein, dass es ihn damals, zur Hochzeit der 8bit-Heimcomputer, durchaus hätte geben können, realistischerweise wollen wir ihn jedoch mit durchaus modernen Schnittstellen ausstatten. Die 8bit-Rechner aus “unserer Zeit” haben IO-Chips wie den 6526 oder 6522 benutzt, um Tastatur (Matrix), Joysticks und Massenspeicher anzusteuern. Das haben wir auch vor. Nur etwas anders. Wir verwenden eine 65c22 VIA, und machen sie zu einem SPI “Master”. Damit wollen wir einen wesentlichen Teil der Peripherie anbinden.