Forum: Projekte & Code STECCY - ZX-Spectrum-Emulator mit STM32

coooolst

Sorry, ich hatte im Artikel versehentlich eine Source-Version von STECCY 
bereitgestellt, die zuviele Source-Dateien beinhaltete, die nicht zum 
eigentlichen Projekt gehören, sondern lediglich zum Test gedacht waren.

Daher habe ich die Zip-Datei für den STM32-Source nochmals aktualisiert.

Download ist jetzt: STECCY: Download

Wer den Source bereits heruntergeladen hat, möge ihn durch obige Version 
ersetzen. Danke!

[Mod: Link aktualisiert]

Markus schrieb:
> Ein Bild der Hardware-Version wäre nicht schlecht.

Bilder von der Hardware liefere bis zum Wochenende nach. Im Moment 
hängen Display und PS/2-Tastatur noch über Dupont-Kabel am STM32-Board. 
Das ist ein ziemlicher Kabelverhau. Deshalb plane ich da noch eine 
Adapterplatine, damit man Board und Display einfach zusammenstecken 
kann.

Vancouver schrieb:
> Mit einer Radiergummitastatur mit sechsfacher Tastenbelegung wäre das
> ganze jetzt auch noch gefühlsecht :-)

Solche ZX-Spectrum-Leergehäuse inkl. Radiergummi-Tastatur werden für 
Retro-Fans immer noch hergestellt. Bei eBay gibts die zu kaufen - in 
allen möglichen Farben, z.B. hier: 
https://www.ebay.de/itm/ZX-Spectrum-16K-48K-Repro-Case-Set-Blue-Repro-Gehause-Blau/113936308104

Die Tastaturmatten kann man dort auch ohne Gehäuse erwerben.
Faceplate: 
https://www.ebay.de/itm/Oberseite-Faceplate-schwarz-aus-Metall-fur-Sinclair-ZX-Spectrum-16-48k-Tastatur/382421410026
Gummimatte: 
https://www.ebay.de/itm/Gummimatte-Tastatur-grau-fur-Sinclair-ZX-Spectrum-16k-48k-Retro-Neu/193263854632

Einfach dort mal nach "ZX-Spectrum Leergehäuse" oder "ZX-Spectrum 
Tastatur"  suchen.

Mich juckts auch schon in den Fingern, so ein Ding zu bestellen, um dann 
das STM32-Board ins Gehäuse stopfen. Bleibt noch das Display, was 
irgendwie außen angebracht werden muss. Dann hat man einen 
ZX-Spectrum-Laptop ;-)

Die Unterstützung der ZX-Spectrum-Tastatur ist auf jeden Fall geplant, 
kommt also. Pins dafür sind auf dem STM32F407 BlackBoard genügend 
vorhanden.

Der müde Joe schrieb:
> Kann man dann auch in BASIC und Maschinensprache programmieren?

Ja, das funktioniert. Siehe auch Anhang, ich gerade mal in der 
QT-Version ein kleines Basic-Programm eingegeben und dann gestartet.

Maschinencode geht natürlich auch, sonst würden die ganzen Spiele ja 
nicht funktionieren.

> Gibt es Möglichkeit, Hardware anzuschließen? Und evtl. über IN/OUT- oder
> PEEK-POKE-Befehle z. B. den 8255 oder Relais, LEDs anzuschließen?

Das ist eine interessante Anregung. Ich könnte natürlich den Datenbus 
plus /RD und /WR transparent auf ein paar STM32-Pins legen und dazu noch 
ein paar /CS-Pins für bestimmte Adressen simulieren. Dann wären sonst 
noch nötige Adressdecoder für bestimmte Adressen einfach in Software 
gegossen.

Dann könnte man eine 8255-Pio in einer CMOS-Version sogar direkt 
anschließen. Ansonsten bräuchte man einen Pegelwandler. Der Anschluss 
einer Z80-PIO wäre schwieriger, da diese noch den /M1-Zyklus braucht. 
Den emuliere ich momentan nicht, da er sonst nicht notwendig ist.

Ich habe zuhause sogar noch ein paar 8255 rumfliegen, könnte das also 
mal austesten...

Allerdings könnte ich auch den 8255 ebenso emulieren, dann könnten Deine 
LEDs oder Relais (über einen Transistor) direkt an den STM32 ;-)

Ich glaube, das letztere halte ich für sinnvoller, oder? Spart auf jeden 
Fall alte Hardware, die nicht mehr ganz so einfach zu beschaffen ist.

Der müde Joe schrieb:
> Ginge das, drei oder vier 8-Bit-Ports;

Wird knapp. Eine ganze Menge an Pins (ca. 20) gehen drauf für den 
Parallel-Anschluss des Displays (FSMC). Dann sind noch einige Pins 
belegt für Board-interne Komponenten wie FLASH, LEDs, Taster. Okay, das 
Flash brauchen wir nicht, aber zumindest vom CS-Pin sollte man die 
Finger lassen ;-)

Okay, die beiden Board-LEDs könnte man sogar noch nutzen über 
OUT-Befehle des Spectrums auf einer festen Adresse. Das habe ich mal 
direkt auf die TODO-Liste gesetzt ;-)

Es bleiben - über den Daumen gepeilt - ca. 37 Pins übrig zur freien 
Verfügung.

Dafür sind schon verplant:

 - 1 Pin für Speaker
 - 8 + 5 = 13 Pins für eine Original-Spectrum-Tastatur-Matte
 - 2 Pins für UART, ansprechbar über speziellen Spectrum-Stream
 - 5 Pins für Anschluss eines ESP8266 für OTA-Flash

Mit dem zusätzlichen ESP8266 könnte der STM32 über WLAN geflasht werden, 
wenn Updates verfügbar sind. Ich habe dies schon erfolgreich für das 
Projekt "WordClock mit WS2812" implemtentiert. Ist ungeheuer praktisch. 
Außerdem könnte der ESP8266 einen Telnet-Port aufmachen, so dass ein 
USART des STM32 direkt transparent über TELNET läuft.

Bleiben 16 Pins übrig. Davon könnte man 8 Pins als Inputs festlegen und 
8 Pins als Output. Reicht Dir das? Oder warum möchtest Du soviel 
I/O-Ports?

Man könnte natürlich die externe Spectrum-Tastatur und den ESP8266 
optional machen. Wenn man diese nicht braucht, gewinnt man nochmal 
mindestens 16 Pins, also zwei 8-Bit-Ports dazu.

> und I2C und SPI transparent nach draußen anschliessbar zu machen?

Ja, das wäre möglich, über Spectrum Streams oder IN/OUT, muss ich mal 
drüber nachdenken, was hier sinnvoller ist. Da jetzt die Pins etwas 
knapp werden, würde ich dann bei Verwendung (und nur dann!) I2C und SPI 
in die zur Verfügung stehenden 8-Bit-Ports mappen, so dass dann bei 
gleichzeitiger Verwendung der 8-Bit-Ports ein paar Bits nicht mehr zur 
Verfügung stehen würden, da dann von SPI und I2C belegt.

Aber bevor wir hier immer weiter spekulieren, sollte man sich die Frage 
stellen: Was braucht man wirklich? Und wozu?

> Analoge Ein- und Ausgänge sind dann vielleicht auch denkbar?

:-))) Theoretisch: Ja. Aber braucht man das? ;-)

> Beruflich bin ich Hardware-Entwickler, da könnte ich mich einbringen.

Das klingt schon mal gut. Man könnte natürlich durch Port-Extender 
weitere Pins aus dem Hut zaubern. Da kannst Du ja mal einen Vorschlag 
machen.

Der müde Joe schrieb:
> Wenn I2C transparent nach draußen verfügbar sind, braucht man dann nicht
> so viele Port-Pins, ja. Port-Expander, A/D-, D/A-Wandler etc. etc. gibt
> es ja alles schon für I2C.

Dann lass es uns mit I2C machen. So bleiben noch jede Menge weiterer 
STM32-Pins für andere Sachen übrig. Da kommen bestimmt noch ein paar 
Ideen :-)

Der müde Joe schrieb:
> 2x PCF8574 oder 1x PCF8575, 16-Bit-I/O Expander mit Interrupt (3.
> Input-Leitung evtl. notwendig)

Klingt gut. Ich präferiere für bis zu 2 x PCF8574, dann ist man 
flexibler. Eventuell will jemand nur einen 8-Bit-Port - falls überhaupt.

> 1x PCF8591, der Klassiker für analog in/out; 4x analog in, 1x analog
> out.

Okay.

> So wär's eine runde Sache für Leute wie mich, die auch mal eine
> Elektronik anschließen wollen. Ein toller, kleiner Steuerungscomputer.

... und altmodischer Steuerungscomputer ;-)

Aber egal, Retro macht Spaß.

> Es gibt auch Keyscan-ICs, für 70 Tasten oder 104 Tasten, etc. Laufen
> auch mit I2C. Damit könnte man die Spectrum-Tastatur an den STM32
> anschließen.

Könnte man, möchte ich aber nicht. Ich möchte die Keyscan-Routine 
komplett dem emulierten Z80 überlassen. Manche ZX-Spiele gehen nicht 
über die ROM-Keyboard-Scan-Routine, sondern haben eigene. Um hier ein 
1:1-Verhalten gegenüber dem Original zu erzeugen, würde ich die 
notwendigen 13 Leitungen direkt auf die Tastatur-Matrix legen und die 
IN-/OUT-Befehle entsprechend auch emulieren. Dann läuft das auch sauber 
- egal, wie die Tastatur von den Spielen ausgelesen wird.

Der müde Joe schrieb:
> Ich könnte eine Platine designen, für so eine ZX-Spectrum-Tastatur, das
> wäre eine feine Sache! Ich habe diese Tastaturen auch schon gesehen,
> auch einen passenden Gehäusedeckel. Muss ich noch mal schauen, ob es
> dann auch den passenden Gehäuseboden dafür gibt.

Ein paar eBay-Links für Komplett-Gehäuse, Tastaturen und Faceplates habe 
ich oben schon gepostet. Da kommen dann zwei Flachbandkabel (5 + 8) 
raus, die an die entsprechenden STM32-Pins geführt werden müssen. Also 
wie beim Original.

W.S. schrieb:
> Gratulation!

Danke.

egberto schrieb:
> Egal - Haupsache "Horace goes skiing" läuft - "No money, no ski"!

Gerade getestet, läuft :-)

Vielleicht stößt es ja auf Interesse. Ich hatte mich damals an der 
Kampagne [1] beteiligt und in dieser Woche kam nach einer spannenden 
Wartezeit von 2 Jahren die Lieferung. Nun soll es eine weitere Auflage 
geben.

[1] https://www.specnext.com/

Hier ein paar Bilder von der STECCY-Hardware.
Sorry für die Spiegelungen, hinter mir war ein Fenster...

Ich habe für die STM32-Version ein paar Eweiterungen eingebaut:

Unterstütz7ung der Board-LEDs:

Die BlackBoard-LEDs am STM32 können mit Z80-OUT-Befehlen (sowohl in 
BASIC als auch in Assembler) angesprochen werden.

UART für ZX-Spectrum:

Der STM32-UART kann nun mit den ZX-Spectrum Basic-Befehlen "PRINT #4" 
bzw. "INPUT #4" für serielle Aus- und Eingabe verwendet werden.

Beispiele für beide Features gibt es im Artikel, siehe 
STECCY: STM32-Hardware-Erweiterungen

Im Download-Bereich liegt daher eine Version 1.1.

Viel Spaß!

Die QT-Version von STECCY liegt nun auch vor, siehe STECCY: Download.

Damit kann man STECCY auch direkt unter Windows oder Linux ausprobieren.

Die Windows-Version ist getestet, die Linux-Version nicht, da ich nur 
Zugriff auf Linux-Server ohne GUI habe.

Viel Spaß!

egberto schrieb:
> Gibt es eigentlich bei dem Display noch mehr Optionen?

Es gibt wohl Möglichkeiten, mit dem STM32 ein VGA-Signal zu erzeugen, 
zum Beispiel:

  https://www.artekit.eu/vga-output-using-a-36-pin-stm32/
oder
  https://github.com/abelykh0/VGA-demo-on-bluepill

Jedoch habe ich da keine großen Ambitionen, so etwas anzupassen. Ich 
nehme auch an, dass hier so viel CPU-Zeit verbraten wird, dass zuwenig 
Zeit für die Spectrum Emulation bleibt.

Aber wenn Du möchtest, kannst Du Dich mal dranmachen ;-)

Welche Stromaufnahme hat das ganze Werk? Wäre ein Akkubetrieb denkbar?

Thomas G. schrieb:
> Welche Stromaufnahme hat das ganze Werk? Wäre ein Akkubetrieb
> denkbar?

Keine Ahnung, müsste ich mal durchmessen. Am meisten frisst die 
Hintergrundbeleuchtung des Displays. Diese ist aber per PWM dimmbar. Im 
Moment nutze ich das aber nicht.

Im Datenblatt, welches ich im Eckstein-Shop gefunden habe, soll die 
Hintergrundbeleuchtung maximal 200mA benötigen. Der SSD1963-Controller 
wird aber auch noch was verbraten. Ich schätze mal, dass insgesamt schon 
zusammen mit dem STM32 500mA oder mehr zusammenkommen. Ein Akku würde da 
wohl nicht so lange halten.

Schade eigentlich, ich hätte sonst eine Art "Laptopgehäuse" 
vorgeschlagen.

Thomas G. schrieb:
> Schade eigentlich, ich hätte sonst eine Art "Laptopgehäuse"
> vorgeschlagen.

Wenn Du da eine USB-Powerbank reinsteckst, sollte das für ein paar 
Stunden reichen.

Um welchen Faktor ist die Emulation denn schneller als das Original wenn 
diese nicht ausgebremst wird?

Wenn man mal bedenkt, dass der ZX auch Grafikspielchen konnte mit einem 
3,5MHz Z80, dann bin ich guter Hoffnung, dass auch mit dem 4MHz MIPS TTL 
sowas mal gehen wird später.
Der Z80 ist ja Multicycle mit min 3 Zyklen, aber jeder Zyklus kann dann 
nochmal mehrere "echte" Takte brauchen.
Das ist schon echt eine interessante Architektur, aber eben vor meiner 
Zeit.

Der müde Joe schrieb:
> 2x PCF8574

Die I2C-Portexpander PCF8574 und PCF8574A werden nun von STECCY 
unterstützt. Man kann von den beiden Modellen jeweils bis zu 8 Module 
anschließen, also insgesamt bis zu 16. Ich denke, das reicht ;-)

Getestet habe ich das mit dem Modul im Bild. Diese kann man einfach 
durch Aneinanderstecken kaskadieren. Man muss lediglich darauf achten, 
dass die Adress-Jumper A2,A1,A0 verschieden gesteckt sind.

Im Artikel steht daher nun die Version 1.2 bereit. Wie man die PCF8574 
über STECCY unter BASIC oder Assembler ansteuern kann, ist im Kapitel 
STECCY: PCF8574 Port-Expander beschrieben.

Viel Spaß!

Der müde Joe schrieb:
> Wenn ich das richtig verstehe, ist diese I2C-Schnittstelle
> universell einsetzbar, für 7-Bit-addressierbare ICs.

Ja.

> Dann wäre der PCF8591P (4-Kanal-A/D, 1-Kanal-D/A-Wandler) und eine RTC,
> z. B.  auch kein Problem?

Da sehe ich erstmal kein Problem. Ich muss mir nur für jedes I2C-Device 
neue ZX-Spectrum-Ports ausdenken.

> Im Ganzen möchte ich nämlich diese Chips anschließen:
>
> PCF8574 (GPIO-Erwweiterung)
> PCF8591 (A/D- und D/A-Wandler)
> LM75 (Temperatursensor)
> PCF8563 (RTC)

Klingt gut, ich studiere in den nächsten Tagen mal die Datenblätter...

> Es soll die teuren Meßtechnik-Erweiterungen für die Taschenrechner von
> Casio und TI ersetzen, im Schulunterricht.

Ah, Schulunterricht! Jetzt macht das Ganze auch für mich Sinn. ;-)

Markus schrieb:
> Wäre ein Display, bei dem man sich das Verkabeln spart nicht sinnvoller:

Klingt gut, ist wahrscheinlich auch ein SSD1963 Display und damit auch 
kompatibel. Ist aber auch kleiner, aus dem AliExpress-Link lese ich da 
mickrige 3,2 Zoll raus.

Tatsächlich funktioniert der AliExpress-Link gar nicht mehr.

Hast Du da einen alternativen Link?

Zum Verkabeln:

Ich bin zur Zeit dabei, eine Adapterplatine zu entwerfen, so dass man

entweder
  BlackBoard und Display Rücken an Rücken stecken
oder
  mit einem 1:1 Flachbandkabel verbinden
kann.

Dann beschränkt sich das Verkabeln aufs Aufstecken.

Markus schrieb:
> Wäre ein Display, bei dem man sich das Verkabeln spart nicht sinnvoller:

Habs gefunden:

https://de.aliexpress.com/item/32991977705.html

und direkt mal bestellt. Zum Testen ist das wohl ganz nett, aber 5" oder 
7" gefallen mir von der Größe her besser.

EDIT:
Da ist ein ILI9341 Controller drauf und kein SSD1963. Damit sind dann 
noch Software-Anpassungen nötig...

Der müde Joe schrieb:
> Nein, ich glaube, das I2C ist so wie es jetzt schon ist, voll
> einsatzfähig.

Nicht ganz, die möglichen I2C-Adressen sind für den PCF8574 (ab 0x20) 
bzw. PCF8574A (ab 0x38) momentan hart codiert, siehe Tabelle im Artikel.

> Man kann eine Adresse auf den Bus schreiben, und eine
> Antwort lesen.

Die Adresse, die Du im ZX-BASIC angibst, ist der ZX-Spectrum-Port. Der 
wird momentan nach einem bestimmten Schema auf I2C-Adressen gemappt, 
aber momentan nur für I2C-Adressen von PCF8574 und PCF8574A.

Aber Du bringst mich auf eine Idee. Der Spectrum-I/O-Port ist 16-Bit 
breit. Für STM32-IO habe ich die Low-Port-Adresse 0x7F reserviert. Ich 
könnte für die 7-Bit-I2C-Adresse einfach das obere Byte 1:1 nehmen. Dann 
ist es wirklich egal, was da für ein I2C-Device dranhängt.

Also: Z80-Port xx7F = I2C-Device mit 7-Bit-I2C-Adresse xx.

Damit wäre ein PCF8574 mit Basis-Adresse 0x20 ansprechbar über den 
Z80-Port 207F, ein PCF8574A mit Basis-Adress 0x38 über den Z80-Port 
387F, ein LM75 mit Basisadresse 0x48 über den Z80-Port 487F.

Ich werde das so anpassen. Das ist wesentlich flexibler.

STM Apprentice schrieb:
> Alles in allem, sehr klasse gemacht!

Danke!

Mw E. schrieb:
> Um welchen Faktor ist die Emulation denn schneller als das Original wenn
> diese nicht ausgebremst wird?

Ich habe gerade mal ein paar Tests gemacht, indem ich eine Turbo-Taste 
eingebaut habe, welche die Bremse löst. Es ist ungefähr Faktor 2 bis 3, 
je nachdem, was gerade so läuft.

Danke fürs nachsehen.
Ist immer interessant zu wissen wieviel Power so eine Emulation braucht.

Super Sache, finde ich GRATULATION :-)

Ich persönlich hatte in den 80er Jahren einen ZX Spectrum+, also keine 
Gummitastatur und auch einen ZX Spectrum 128k mit 3-Kanal Soundchip und 
eben 128k RAM (Bankswitching lässt grüssen ;-) ).
Ist denn eine Erweiterung auf 128k angedacht, weil die Spiele machten 
mit dieser Sounduntermalung echt Spass.
Zu DDR-Zeiten hatte ich auch eine Floppyerweiterung laufen, war mit 
irgendeinem WD Chip.

Hallo Frank.

Ich habe mit einem ODROID-XU4 und QT5 Vers.5.9.5 das Programm erstellt.

Drei Änderungen musste ich machen.
TRUE und FALSE in Kleinschrift ändern, also false und true.

Hier wurde strnicmp in strncmp geändert.

*----------------------------------------------------------------------- 
-------------------------------------------------
 * z80_set_fname_load () - set filename for LOAD Tape
 *----------------------------------------------------------------------- 
-------------------------------------------------
 */
void
z80_set_fname_load (const char * fname)
{
    if (strlen (fname) > 4)
    {
        z80_close_fname_load ();

        if (! strncmp (fname + strlen (fname) - 4, ".tap", 4))
        {
            tape_load_format = TAPE_FORMAT_TAP;
            strncpy (fname_load_buf, fname, 255);
            fname_load_valid = 1;
        }
        else if (! strncmp (fname + strlen (fname) - 4, ".tzx", 4))
        {
            tape_load_format = TAPE_FORMAT_TZX;
            strncpy (fname_load_buf, fname, 255);
            fname_load_valid = 1;
        }
        else if (! strncmp (fname + strlen (fname) - 4, ".z80", 4))
        {
            tape_load_format = TAPE_FORMAT_Z80;
            strncpy (fname_load_buf, fname, 255);
            fname_load_snapshot_valid = 1;
        }
    }
}

Habe noch kein Programm getestet.

Super.

Gruß
Kurt

Kurt P. schrieb:

> Ich habe mit einem ODROID-XU4 und QT5 Vers.5.9.5 das Programm erstellt.

Prima!

> Drei Änderungen musste ich machen.
> TRUE und FALSE in Kleinschrift ändern, also false und true.

Interessant, dass da QT unter Windows und QT unter Linux tatsächlich 
verschieden sind.

Ich benutze TRUE und FALSE in Großbuchstaben ganz bewusst, wo C zum 
Tragen kommt, da das z80.cpp unter QT und das z80.c für den STM32 
identisch sind. Hier übersetzt einmal ein C- und einmal ein C++-Compiler 
den identischen Source. Das QT unter Windows kannte aber bereits TRUE 
und FALSE, deshalb hatte ich für QT eine extra Definition unterlassen, 
wie ich sie für die STM32-Variante eingebaut hatte. Das lief auch glatt.

> Hier wurde strnicmp in strncmp geändert.

strnicmp() ist die Groß-/Kleinbuchstaben-invariante Schwester von 
strncmp(), denn ich will sowohl ".tap"- als auch ".TAP"-Dateien 
erkennen.

Aus alter Gewohnheit hatte ich strnicmp() für die Windows-Version von QT 
gewählt, weil viele C-Compiler unter Windows für lange Zeit die korrekt 
lautende POSIX-Lösung strncasecmp() überhaupt nicht kannten. Jetzt habe 
ich das aber nochmals für QT unter Windows getestet: Hier klappt das mit 
dem strncasecmp() auch.

Lange Rede, kurzer Sinn... Die saubere Lösung ist:

Nimm bitte wieder die Original-Version von z80.cpp. Du findest fast ganz 
oben unter den include-Anweisungen folgende 3 Zeilen:

1

#define strnicmp            strncasecmp

2

#define TRUE                1

3

#define FALSE               0

Die Zeile

1

#define strnicmp            strncasecmp

löschst Du.

Die beiden Zeilen

1

#define TRUE                1

2

#define FALSE               0

verschiebst Du unter das #endif, welches ein paar Zeilen tiefer folgt. 
Dann gilt es nicht nur für die STM32-Variante, sondern für alle.

Anschließend ersetzt Du die drei verbliebenen Vorkommen von strnicmp 
durch strncasecmp.

Dann sollte sich das z80.cpp wieder übersetzen lassen und dem Programm 
ist es dann auch wieder egal, ob die Dateien mit den Extensions ".tap", 
".tzx", ".z80" in Groß- oder Kleinbuchstaben auf der Platte liegen.

> Habe noch kein Programm getestet.

Meldet sich denn schon das Sinclair-ROM mit seiner typischen 
Copyright-Meldung von 1992?

Ich bin gespannt auf Deine Rückmeldung.

Jürgen M. schrieb:
> Ich persönlich hatte in den 80er Jahren einen ZX Spectrum+, also keine
> Gummitastatur und auch einen ZX Spectrum 128k mit 3-Kanal Soundchip und
> eben 128k RAM (Bankswitching lässt grüssen ;-) ).

Wow. Ich hatte von 1982-1986 nur den Spectrum 48K, wo ich nächtelang 
HEX-Listings aus ZX-Spectrum-Zeitschriften abgetippt habe, um wieder 
irgendein Spiel auszuprobieren, was sich dann nach vielen Stunden 
mühseliger Tipperei und anschließender Fehlersuche doch einfach als 
Schrott erwiesen hat. Ich glaube, das kennt wohl jeder Spectrum-User von 
damals ;-)

Dann folgte ein Atari Mega ST 4 mit 20MB-Festplatte...

Der ZX-Plus bzw. 128k sind natürlich schon komfortabler als ein 48K. 
Aber ich hatte da niemals ein Bedürfnis, auf einen ZX+ oder gar 128K zu 
wechseln. In der Uni, wo ich damals war, machten sich die Atari ST 
breit. Und die waren zu damaliger Zeit einfach klasse.

> Ist denn eine Erweiterung auf 128k angedacht, weil die Spiele machten
> mit dieser Sounduntermalung echt Spass.

Das hängt wohl davon ab, wieviele Leute sich dafür interessieren. Ich 
selber kenne die 128k-spezifischen Spiele gar nicht. Müsste ich mir mal 
anschauen.

> Zu DDR-Zeiten hatte ich auch eine Floppyerweiterung laufen, war mit
> irgendeinem WD Chip.

Die einzige Erweiterung, die ich hatte, war eine selbstgeätzte Platine 
zum Einstecken in den ZX-Slot hinten. Auf der Platine waren ein Taster, 
der an NMI hing, ein EPROM und ein wenig 74er Steuerlogik, welches das 
zusätzliche EPROM in den Adressbereich des Original-ROMs einblendete und 
letzteres deaktivierte.

In dem EPROM steckte nämlich eine kleine selbstgeschriebene NMI-Routine, 
welche bei Betätigen des Tasters die CPU-Register in die letzte - also 
192te - Bildschirmzeile ganz unten rechts kopierte und anschließend den 
kompletten RAM-Bereich auf den Cassetterecorder überspielte.

So konnte ich dann, wenn ich ein Spiel unterbrechen wollte, einfach den 
NMI-Taster drücken, den Spielstand abspeichern und am nächsten Tag das 
Spiel durch Laden von Cassette dort weiterspielen, wo ich es 
unterbrochen hatte. Lediglich ein paar Pixel ganz unten rechts waren 
kaputt. Aber das machte nichts, meistens haben die Spiele das dann 
selber nach ein paar Sekunden wieder "repariert".

Das geht mit STECCY natürlich auch: Da heißt der Button "Snapshot". Er 
kommt ganz ohne NMI aus und zerstört auch keine Pixel in der letzten 
Bildschirmzeile ;-)

P.S.
Warum die letzte Bildschirmzeile? Das war die sicherste Methode, 
möglichst non-invasiv Zusatzinformationen im RAM abzulegen. Schon das 
Sichern aller CPU-Register (inkl. Shadow-Register) auf dem oft klein 
bemessenen Stack konnte unter verschiedensten Bedingungen im Spiel zu 
Fehlern (Stackoverflow) führen.

Naja, der Spectrum+ war auch nur ein 48k mit mechanischer Tastatur 
(Folientastatur). Den 128k habe ich teilweise defekt (hatte irgendeinen 
kapazitiven Fehler mit der Tastatur) bekommen, wobei wir hier in der DDR 
auch für den normalen 48k Speichererweiterungskarten gebaut haben, wo 
glaub 16k RAM-Blöcke, wie beim echten 128k, geswitched wurden.
Leider habe ich den 128k bei meinem letzten Umzug irgendwo verkramt und 
muss den mal suchen.
Also ich würde mich auf jeden Fall sowohl für die Speichererweiterung, 
als auch den AY-Soundchip interessieren, der Sound war echt um Längen 
geiler anzuhören, als das 1-Bit-Gequäke.
Ich hänge mal n paar Schematics vom 128k dran, falls interessiert.

Hallo Frank,

ja funktioniert.
Danke für die Info.

Gruß
Kurt

Olaf schrieb:
> Wofuer wurde denn der Speicher beim originalen 128er genutzt? Spiele?

Na klar, so wie zu PC-Zeiten auch, nur hier halt mit Dateien, Grafik, 
Grafik, Grafik ^^.

Hi Kurt,

Kurt P. schrieb:
> ja funktioniert.

Danke für die Rückmeldung und den Screenshot. Mir ist aufgefallen, dass 
in der Linux-Version die Button-Texte rechts nicht ganz reinpassen. Da 
müsste man wohl die Buttons etwas vergrößern...

Hier gibt es ein Projekt das mit einer Blue-Pill arbeitet:
https://github.com/sdima1357/specci48/

https://youtu.be/n4u6VNxCTdA

Karsten M. schrieb:
> Hier gibt es ein Projekt das mit einer Blue-Pill arbeitet:
> https://github.com/sdima1357/specci48/

Das Projekt ist wohl noch im "proof of concept" Modus, wie der Autor 
selber schreibt.

Frank M. schrieb:
> Karsten M. schrieb:
>> Hier gibt es ein Projekt das mit einer Blue-Pill arbeitet:
>> https://github.com/sdima1357/specci48/
>
> Das Projekt ist wohl noch im "proof of concept" Modus, wie der Autor
> selber schreibt.

Keine Frage das Dein Projekt wesentlich ausgereifter ist.
Danke das Du dieses hier mit uns teilst!

Wenn man allerdings nur ein bisschen Spaß haben möchte, sind die 
Investitionskosten für das "proof of concept" jedoch deutlich geringer.
Es ist ja nicht jeder ein ausgewachsener "Retro-Fan". ;-)

Mich würde hier eher ein Apple ][ in dieser Form eher reizen. :-)
Diese Variante gibt es ebenfalls:
https://www.applefritter.com/content/stm32-arm-cortex-m4-apple-1-replica
Leider ein Apple 1

Das sieht schon besser aus:
https://hackaday.com/2017/02/21/a-full-speed-portable-apple-e/
https://hackaday.io/project/19925-aiie-an-embedded-apple-e-emulator

Die Version 1.3.0 ist online. Neben einigen kosmetischen Änderungen gibt 
es auch eine Neuerung:

- Unterstützung von USB-Tastaturen

Man kann also nun zwischen PS/2- und USB-Tastatur wählen oder sogar 
beide anschließen, um sie gleichzeitig zu verwenden. Das kann bei 
Multiplayer-Spielen ganz sinnvoll sein, wenn man sich nicht um die 
Tastatur streiten will ;-)

Nachzulesen im Artikel: STECCY: USB-Tastatur

Der STM32-Quellcode steckt nun im SVN von mikrocontroller.net, siehe 
dazu auch: STECCY: Download

P.S.
Der Einbau von USB als HID-HOST hat mich das ganze Wochenende zur 
Verzweiflung gebracht: Es lief einfach nicht: die Tastatur wurde nicht 
erkannt. Erst heute nacht kam ich auf die zündende Idee: Der am 
USB-DP-Pin hängende 1,5K-Pullup auf dem BlackBoard ist zwar im Betrieb 
als USB-Device ganz sinnvoll, im Betrieb als HID-Host aber 
kontraproduktiv. Eine Tastatur oder Maus hat nämlich auch einen Pullup. 
Zusammen liegt dann der tatsächliche Widerstandswert außerhalb der 
Spezifikation.

Da hilft dann nur Auslöten des externen Pullups R21, siehe Anhang. Das 
ist auch nicht schlimm, da er bei der STM32F4XX-Familie überhaupt nicht 
notwendig ist - weder als USB-Device noch als USB-Host. Bei einem 
ST32F103 sieht das wieder ganz anders aus.

Viel Spaß :-)

Warum auch immer der Pullup da ÜBERHAUPT wohnt.
Die STM32F4 haben ja einen Internen.

Mw E. schrieb:
> Warum auch immer der Pullup da ÜBERHAUPT wohnt.
> Die STM32F4 haben ja einen Internen.

Eben, nämlich speziell für USB, nicht nur den relativ hohen GPIO-Pullup. 
Ich nehme mal an, dies ist ein Angstwiderstand. Man wollte wohl nicht 
den Fehler wie bei den BluePills machen. Hier werkelt ein STM32F103, dem 
der USB-spezifische interne Pullup fehlt.

Nobs schrieb:
> Tolles Projekt! Was ich bisher lese und sehe gefällt mir sehr gut.
> Die gelante Unterstützung für die Original-Tastatur finde ich klasse,
> denn an den Spectrum-Emulatoren für PC nervt das veränderte
> Tastaturlayout einer modernen Tastatur doch gewaltig.

Ich habe bei STECCY möglichst versucht, auch alle anderen auf der 
Tastatur verfügbaren Tasten auf ZX-Spectrum-Tasten zu mappen, z.B. 
funktionieren auch die auf der PC-Tastatur befindlichen Tasten wie

           , ; . : - _ # ' + *

ganz transparent (die hochgestellten mit der rechtenShifttaste), so dass 
ich hier oft sogar eine Verbesserung sehe. Die Unterschiede fallen hier 
jedenfalls nicht so stark ins Gewicht.

> Gäbe es
> alternative Anschlussmöglichkeiten für Bildschirme über gängige
> Anschlüsse(AV, VGA, DVI, irgendwas)?

Die Frage wurde hier schon einmal gestellt. Allerdings geht für so etwas 
eine ganze Menge CPU-Power drauf. Mittlerweile habe ich STECCY aber so 
weit optimiert, dass im Turbo-Modus der Geschwindigkeitsfaktor gegenüber 
dem Original auf einen Wert von satten 5 gewachsen ist. Da ist also für 
so etwas wie VGA mittlerweile mehr Luft nach oben. Mal sehen, wann ich 
das anpacke.

> Die kleinen Displays sind zwar nett
> und würden in einem geeigneten Gehäuse einen schönen, portablen Spectrum
> ergeben (ähnlich z.B. dem Klon Spectrum Omni HQ 128),

So ein 7" Display hat auch schon eine stattliche Größe ;-)

> aber das Original hing ja auch am TV...

Mal schauen, ausschließen will ich das nicht.

Der User "das rote mopped" hatte einfach einen R2R DAC an die LTDC 
Ausgänge des STM32 gehangen und schon wars VGA.

Nur finde ich den Thread leider grade nicht.

Version 1.3.2 ist online.

Verbesserungen:

- Optimierungen im 50Hz Display-Update
- Optimierungen im USB-Tastatur-Handling

Damit ist STECCY auf dem STM32 im Turbo-Modus nun bis zu 5 mal schneller 
als das Original.

Mw E. schrieb:
> Der User "das rote mopped" hatte einfach einen R2R DAC an die LTDC
> Ausgänge des STM32 gehangen und schon wars VGA.

Das klingt gut! Ich werde da mal recherchieren. Ich muss mir selbst 
erstmal etwas KnowHow über analoge Monitorsignale aneignen. Da fehlt mir 
einfach Wissen.

Ich habe mal ein wenig rumgeschaut wegen VGA über R2R an LTDC 
rumgeschaut und dabei u.a. auch die Homepage von "das rote mopped" 
gefunden.

Wenn ich das richtig sehe, braucht man dafür 2 bis 8 MB - je nach 
Auflösung - an externem SDRAM. Da müsste man wohl auf ein anderes Board 
ausweichen, wie z.B. das STM32F29-Disco oder ähnliches.

Frank M. schrieb:
> Verbesserungen:
>
> -

Original Tape-Interface???

Jop, auch bei gemütlichen 640x480 kommt man auf 900kbyte bei RGB888.
Auch RGB565 kommt auf 600k.
Mit Doublebuffering sind das dann eben ein 2MB RAM IC.

Aber wieviel Farben kann der ZX eigentlich?
Die Bilder im Eingangspost sehen nach 256 Farben aus.
Dann empfielt sich der Farbtabellenmodus des LTDC für 150k RAM Verbrauch 
für 1 Bild, das passt dann schon in interne SRAM.
Wobei jetz die 407er alle nur 192kb haben, wird auch eng ;)

Einen µC mit HDMI findet man jetz aber nich so oft.
Da brauchts dann was dickeres wie ATSAM5 oder imx6.
Ist dann aber eeeetwas overkill für ein kleines Heimprojekt eines ZX 
Emulators.

Es gibt auch externe Konverter ICs, aber die sind jetzt auch nix zur 
Heimanwendung.

Mw E. schrieb:
> Aber wieviel Farben kann der ZX eigentlich?
> Die Bilder im Eingangspost sehen nach 256 Farben aus.

Irrtum. Der ZX kann nur 8 Farben (einschließlich Schwarz und Weiß) in 
zwei Helligkeitsstufen.

Route_66 H. schrieb:
> Irrtum. Der ZX kann nur 8 Farben (einschließlich Schwarz und Weiß) in
> zwei Helligkeitsstufen

So ist es. Dabei kann jede 8x8 Zelle nur jeweils eine Vorder- und 
Hintergrundfarbe haben - und optional noch blinken. So kommt der 
ZX-Spectrum bei einer Auflösung von 256 x 192 mit 6144 Bytes als 
Screen-RAM aus. Bit gesetzt: Schriftfarbe, Bit nicht gesetzt: 
Hintergrundfarbe.

Von den 8x8 Zellen gibt es dann 768 Stück, macht 768 zusätzliche Bytes. 
In jedem dieser Attribut Bytes sind belegt:

3 Bits für Vordergrundfarbe
3 Bits für Hintergrundfarbe
1 Bit für Hell (Bold)
1 Bit für Blinkend (Flash)

Die 6144 Bytes für die Pixeldaten sind leider auch nicht linear 
angeordnet. Zunächst kommen die Pixel für die nullte Reihe, dann für die 
8te, dann 16te, dann 24te usw bis 56te. Dann geht es weiter mit Reihe 
1,9,17,25...57. Dann 2,10,18,26...58. Das wiederholt sich dann bis zur 
63ten Zeile.

Das obige entspricht dann einem Drittel des Screens. Auf gleiche Weise 
folgt dann das zweite und das dritte Drittel. Beim Spectrum hat der 
ULA-Chip die Aufgabe gehabt, aus dem obigen RAM von 6144 + 768 Bytes das 
TV-Signal zu zaubern. Dabei hat er den Z80 bei konkurrierenden Zugriffen 
einfach ausgebremst.

Dieses macht in der QT-Fassung ein zweiter Task übrigens genauso, um an 
die Pixeldaten zu kommen und diese auf den PC-Monitor zu pinseln.. Er 
lässt dann den Z80-Emulator-Task einfach warten.

Route_66 H. schrieb:
> Original Tape-Interface???

Kannst Du gern einbauen ;-)

Ich habe jedenfalls keine Lust, mehrere Minuten zu warten, bis ein Spiel 
geladen ist. STECCY liest und speichert die TAP- und TZX-Dateien in 
einem Sekundenbruchteil.

Frank M. schrieb:
> STECCY liest und speichert die TAP- und TZX-Dateien in
> einem Sekundenbruchteil.

Dazu müssen sie erst mal vom Band eingelesen und als TAP oder TZX 
abgespeichert werden!

Route_66 H. schrieb:
> Dazu müssen sie erst mal vom Band eingelesen und als TAP oder TZX
> abgespeichert werden!

Solltest Du tatsächlich noch alte Cassetten haben, die Du nicht im Netz 
als TZX- bzw. TAP-Dateien findest: Es gibt PC-Programme, die das direkt 
vom Cassettenrecorder einlesen und konvertieren können.

Johannes S. schrieb:
> Ich möchte ja kein Spielverderber sein, aber mit dem RetroPie
> gibts da viel mehr:
> https://retropie.org.uk/

Es hat ja auch niemand behauptet, dass unter Linux nichts besseres gäbe. 
Der ZX-Emulator Fuse ist da wohl unübertroffen.

Hier ist das Thema jedoch ZX-Emulator auf einem STM32. Da läuft RetroPie 
nun mal nicht drauf ;-)

Der müde Joe schrieb:
> Hmmm... HDMI fände ich nützlicher. Jeder Fernseher hat HDMI, aber
> ich habe seit Jahren keinen VGA mehr gesehen.

HDMI ist eine ganz andere Hausnummer. Da kannst Du auch einen PI mit 
Fuse als Emulator nehmen.

Klar, ich könnte STECCY auch auf den PI portieren. Aber das halte ich 
für Verschwendung. STECCY läuft ja jetzt schon unter QT und damit auf so 
ziemlich jedem Linux mit einer GUI.

Höchstens unter dem Gesichtpunkt der Anwendung von I2C wäre das noch 
interessant- um zum Beispiel eine ZX-Tastatur anzuschließen.

Johannes S. schrieb:
> Das hat Frank ja auch schon bestellt, und die SW Anpassung hält sich
> sehr in Grenzen.

Dieses Dislay habe ich bestellt:

https://de.aliexpress.com/item/32991977705.html

Kostet unter 12 EUR. Sobald es da ist, passe ich die SW an das Teil an.

Vorteil:

- Es kann direkt auf das STM32F407VET6-Board gesteckt werden.
- Ein Adapterkabel oder eine Adapterplatine ist nicht notwendig.
- Unschlagbar billig.

Nachteil:

- Es hat halt nur 3,2 Zoll.

Man kann halt nicht alles haben. Billig und Groß gleichzeitig geht halt 
nicht. Kompromiss wäre noch das 5-Zoll-Display mit SSD1963 für knapp 30 
EUR für diejenigen, denen die 40 EUR für die 7-Zoll-Ausführung zu viel 
sind.

Johannes S. schrieb:
> genau dieses TFT habe ich auch

Ah, jetzt wissen wir genau, welches du meist ;)

Hallo schrieb:
> Wo zieht man sich eigentlich ROMs für den ZX,

Aus einem der originalen ZX oder Nachbauten in meinem Keller...

Hallo schrieb:
> Wo zieht man sich eigentlich ROMs für den ZX,

Aus einem der originalen ZX oder Nachbauten in meinem Keller...

Du kannst auch das Assemblerlisting aus dem Buch "Das ZX-Spectrum ROM" 
abtippen oder als PDF im Internet finden.

https://skoolkid.github.io/rom/

Johannes S. schrieb:
> genau dieses TFT habe ich auch. Das hat noch einen Touchscreen mit
> XPT2046 der per SPI angeschlossen ist, das könnte mit vorhandener
> Belegung kolidieren.

Ich habe darauf geachtet, keine der Pins, die auf dem TFT-Stecker 
liegen, zu verwenden. Mein 7" Display hat nämlich auch Touch - auch wenn 
ich es derzeit nicht verwende.

> In der Software ist der Init anders, zum Pixel setzen wird auch ein 'set
> address window' command gesendet und dann die Pixel auf der data Adresse
> rausgefeuert.

Danke für die Tipps.

> Nur mit dem seitlichen Menu wird es dann vermutlich eng
> mit 320 Pixeln Breite.

Das Menü kann ich auch über den Spectrum-Screen einblenden. Es ist 
derzeit nur deswegen rechts, weil der Platz einfach da ist.

Johannes S. schrieb:
> und es ist leider sehr blickwinkelabghängig.

Das spricht dann auch eher für die 7" Variante. Hier ist der Blickwinkel 
angenehm groß.

> Das 7zöllige hat mich aber
> auch neugierig gemacht, habe es für 30€ (+Versand) hier (letzte Woche
> geliefert, bestellt 22.02.) bekommen:
> https://de.aliexpress.com/item/32541422103.html

Na also, geht doch :-)

Beachte bitte: auf der Rückseite muss noch eine Drahtbrücke für die 
Hintergrundbeleuchtung gesetzt werden, um diese zu aktivieren. Ist aber 
beschriftet und nicht zu übersehen.

Hallo schrieb:
> Wo zieht man sich eigentlich ROMs für den ZX, ohne sich gleich einen
> Virus einzufangen oder dass die manipuliert sind ?

Eine Quelle wird im Artikel genannt. Du kannst aber auch mehrere 
Varianten aus diversen Quellen ziehen und dann binär vergleichen.

Hallo Frank M.,

Wie sieht es aus, wenn man Erweiterungen für dein tolles Projekt hat?
Ich habe die Tastaturmatrix ran gestrickt und TZX ein bißchen erweitert 
(Archive-Block). Nichts umwerfendes, aber vielleicht für manche 
interessant.
Kann man einen branch anlegen?

BG, Tom

Hi Thomas,

Thomas H. schrieb:

> Wie sieht es aus, wenn man Erweiterungen für dein tolles Projekt hat?
> Ich habe die Tastaturmatrix ran gestrickt und TZX ein bißchen erweitert
> (Archive-Block). Nichts umwerfendes, aber vielleicht für manche
> interessant.

Das hört sich super an! Das heisst, es läuft bei Dir? Welches Display 
nutzt Du da? Das sieht mir eher nach dem 5"-Display aus, oder?

Ich sehe da zwei Möglichkeiten: Entweder Du schickst mir Deine 
Änderungen - vorzugsweise als diff - oder ich gebe Dir 
Schreibberechtigung aufs SVN und Du checkst Deine Änderungen direkt ein. 
Letzteres ist wohl dann sinnvoller, wenn Du auch zukünftig daran 
mitarbeiten möchtest. Sag einfach mal, was Du für sinnvoller hältst.

> Kann man einen branch anlegen?

Ein extra Branch ist nicht unbedingt notwendig, es arbeiten ja nicht 
Dutzende von Leuten daran. ;-)

Gruß,

Frank

Hallo Frank,

Ich würde vorschlagen, ich schicke dir meine Änderungen erstmal als 
diff, dann kannst du dir meine Änderungen ansehen und entscheiden.
Es gibt zxkeyboard/zxkeyboard.* wo die eigentliche Abfrage ist (ich 
benutze PA0-PA7 + PC0-PC5). Damit sind 8 zusätzliche Tasten möglich (ich 
benutze aber aktuell nur eine um in den Menue-Modus zu gelangen).
Im z80 Modus ist es einfach, da der Specci-code die Abfrage gesteuert. 
Im Menuemodus muss ich das selbst machen und dem ps2-adapter 
unterschieben.
Funktioniert, aber füllt sich manchmal etwas hakelig an. Da kann man am 
Timing noch schrauben.
Bei tape.c ist nur die Behandlung des 0x32 Blockes dazugekommen, da bei 
www.worldofspectrum.org (und anderen Archivseiten?) dieser vorkommt.

Das ist ein 7" Display 
(https://de.aliexpress.com/item/32845300432.html?spm=a2g0s.9042311.0.0.39d04c4dP7BLm9).

Ich weiß nicht wieviel Zeit ich haben werden, aber gelegentlich werde 
ich schon weiter daran basteln :)  z.B Touchscreen-support fürs Menue, 
Vorschaubilder bei TZX und TAP files.

BG, Tom

Hi Tom,

Thomas H. schrieb:

> Ich würde vorschlagen, ich schicke dir meine Änderungen erstmal als
> diff, dann kannst du dir meine Änderungen ansehen und entscheiden.

Ich habe den Source gerade mal überflogen, wirklich gut gemacht und 
gefällt mir sehr gut. Auch der Coding-Style fügt sich perfekt ein, auch 
wenn ich eher auf unterschiedliche Groß-/Kleinschreibung von Dateien und 
Variablennamen verzichte. Von daher werde ich da Details noch nach 
Kleinbuchstaben konvertieren, um das Ganze noch einheitlicher zu 
gestalten - wenn es Dich nicht stört.

> Es
> gibt zxkeyboard/zxkeyboard.* wo die eigentliche Abfrage ist (ich benutze
> PA0-PA7 + PC0-PC5).

Ich hatte für die Tastaturmatrix eigentlich PC0-PC7 für die Reihen und 
PE0-PE4 für die Spalten vorgesehen. PAx wollte ich mir nämlich wegen des 
UARTs auf PA2/PA3 (der übrigens jetzt schon für Logging und INPUT#4 und 
PRINT#4 genutzt wird!) und wegen der Board-LEDs PA6/PA7 freihalten.

Spricht etwas dagegen, stattdessen PC0-PC7 und PE0-PE4 dafür zu nutzen? 
Wenn Du damit kein Problem hast, würde ich das so anpassen.

> Damit sind 8 zusätzliche Tasten möglich (ich benutze
> aber aktuell nur eine um in den Menue-Modus zu gelangen).

Achso, deshalb hast Du sechs Spalten und nicht nur fünf. Gute Idee!
Klar, das kann man auch um PE5 erweitern.

> Im z80 Modus ist es einfach, da der Specci-code die Abfrage gesteuert.

Jepp.

> Im Menuemodus muss ich das selbst machen und dem ps2-adapter
> unterschieben.

Ja, genauso habe ich es auch für USB gemacht. Da schiebe ich es ebenso 
dem PS2-Treiber unter. Das spart redundanten Code.

> Funktioniert, aber füllt sich manchmal etwas hakelig an. Da kann man am
> Timing noch schrauben.

Ist das nur im Menü-Modus hakelig? Vielleicht liegt es auch daran, dass 
die aktuelle SW bereits PA2, PA3, PA6, PA7 bereits verwendet?

Okay, wenn es nur das Timing ist, bekommt man das sicher noch 
glattgebügelt.

> Bei tape.c ist nur die Behandlung des 0x32 Blockes dazugekommen, da bei
> www.worldofspectrum.org (und anderen Archivseiten?) dieser vorkommt.

Ist mir bisher nicht aufgefallen. Aber ich habe auch noch icht alle 
Spiele dort durchprobiert ;-)

Baue ich gern ein.

> Das ist ein 7" Display
> 
(https://de.aliexpress.com/item/32845300432.html?spm=a2g0s.9042311.0.0.39d04c4dP7BLm9).

Ahja, das ist identisch mit meinem. Der Preis ist mit unter 31 EUR auch 
sehr attraktiv.

> Ich weiß nicht wieviel Zeit ich haben werden, aber gelegentlich werde
> ich schon weiter daran basteln :)  z.B Touchscreen-support fürs Menue,
> Vorschaubilder bei TZX und TAP files.

Das hört sich gut an. Erstmal vielen Dank! Wenn Du Dich da noch weiter 
reinhängen willst, kann ich Dir gern Schreibzugriff aufs SVN geben, kein 
Problem!

Hi Tom,

ich habe da noch ein paar Fragen zu Deinem Code:

Vermutlich kann die nicht verwendete Funktion _emulate_ps2key() (mit 
führendem Unterstrich) weg, oder? Scheint eine Testfunktion zu sein.

Es spricht doch nichts dagegen, das ZX-Keyboard gleichzeitig mit den 
anderen Keyboards zu erlauben?

Wenn ja, würde ich die Zeile

1

        if (settings.keyboard == KEYBOARD_ZX)

zu

1

        if (settings.keyboard & KEYBOARD_ZX)

ändern.

Zu den Tape-Routinen:

Deine fprintf()-Calls habe ich nach debug_printf() geändert. Außerdem 
habe ich in der Funktion tzx_read_block_32() doch den Return-Code auf 1 
im Erfolgsfall geändert, damit man Fehler und Erfolg unterscheiden kann.

Stattdessen habe ich den Aufruf geändert:

1

                    case 0x32:                                                      // archive info

2

                    {

3

                        if (! tzx_read_block_32 (tape_load_fp))

4

                        {

5

                            fclose (tape_load_fp);

6

                            tape_load_fp = nullptr;

7

                            return 0;

8

                        }

9

10

                        rtc = 0;                                                    // force continuing of tape read

11

                        break;

12

                    }

Vielleicht kannst Du mir eine TZX-Datei nennen, womit ich das testen 
kann. Du hattest da auf dem Foto ein schickes Spiel ;-)

Hi Frank,

- Pass den Code so an, wie du es für richtig hältst. Ich ziehe mir dann 
die angepasste Version runter und arbeite damit weiter.
- Die Keyboardports habe ich so gelegt, dass alles möglichst 
nebeneinander auf einer Steckerreihe liegt (sorry, an die UART habe ich 
nicht gedacht ;))
Mir fehlte da auch eine Liste der verwendeten, bzw. für Erweiterungen 
reservierten Ports.
Die LEDs auf der Rückseite hatte ich schon bemerkt, da sie aber bei mir 
nicht zu sehen sind war es mir egal.
Aber OK - Deine Zuordnung ist eigentlich besser, ich kann die paar 
Leitungen auch umlöten.

- Ja, _emulate_ps2key() war eine alte/missglückte Version. Kann raus.
-

1

 if (settings.keyboard & KEYBOARD_ZX)

 ist besser.
- klar:

1

 debug_printf

   Wie wärs, wenn man die Felder unter einem Menüpunkt "Archive-Info" 
oder ähnlich anzeigen kann? (OK, Plan für später ;) )
- Das ist Tujad 
(https://www.worldofspectrum.org/infoseekid.cgi?id=0005448)

Der Schreibzugang wäre schon nett, aber ich würde trotzdem einen eigenen 
Branch aufmachen, damit du immer entscheiden kannst, was in den Master 
reinkommt - ist ja schließlich dein Projekt. Und wir können auch relativ 
unabhängig basteln.

Beste Grüße, Tom

Hi Tom,

Thomas H. schrieb:

> - Pass den Code so an, wie du es für richtig hältst. Ich ziehe mir dann
> die angepasste Version runter und arbeite damit weiter.

Okay, ich lade nachher mal die aktuelle Version hoch. Die ist aber stark 
experimentell, weil ich schon mal mit dem ILI9143-Display angefangen 
habe, obwohl es noch nicht bei mir angekommen ist. Kann also sein, dass 
da noch die eine oder andere Macke drin ist.

Die ILI9341-Variante ist auch noch nicht fertig, ich habe erst heute 
nachmittag aus diversen Beiträgen herausgelesen, dass die Punkte 
hintereinander ohne neue Positionierung nur in Portrait-Orientierung 
geschrieben werden können. Das heisst, ich muss da noch die Logik 
ändern, um die Pixel untereinander und nicht nebeneinander 
rauszuschieben, damit ich auch gleich die 90°-Drehung zum 
Landscape-Modus erschlage. Es gibt zwar ein Ansteuer-Bit im ILI9341, um 
das Bild vom Controller zu drehen, jedoch bleibt die Schreibrichtung 
gleich. Und das passt nicht zum Landscape-Modus. Wenn ich es richtig 
verstanden habe, bleiben bei der Controller-Drehung dann nur noch 
240x240 übrig, ist also unbrauchbar.

> - Die Keyboardports habe ich so gelegt, dass alles möglichst
> nebeneinander auf einer Steckerreihe liegt (sorry, an die UART habe ich
> nicht gedacht ;))
> Mir fehlte da auch eine Liste der verwendeten, bzw. für Erweiterungen
> reservierten Ports.

Die Liste gibt es, schau mal in der main.c in den Header. Da hatte ich 
sogar schon die vorgesehenen Keyboard-Rows und -Columns eingetragen ;-)

> Die LEDs auf der Rückseite hatte ich schon bemerkt, da sie aber bei mir
> nicht zu sehen sind war es mir egal. Aber OK - Deine Zuordnung ist
> eigentlich besser, ich kann die paar Leitungen auch umlöten.

Prima, dann baue ich gleich noch die Ports um und lade das dann hoch. 
Sehr gut gefällt mir auch die Lösung mit den OpenDrain-Ausgängen, um die 
beim Original-Spectrum verwendeten Dioden zu sparen :)

> - Ja, _emulate_ps2key() war eine alte/missglückte Version. Kann raus.

Alles klar, ist raus.

> - klar:  debug_printf   Wie wärs, wenn man die Felder unter einem
> Menüpunkt "Archive-Info" oder ähnlich anzeigen kann? (OK, Plan für
> später ;) )

Ja, später :)

> - Das ist Tujad
> (https://www.worldofspectrum.org/infoseekid.cgi?id=0005448)

Danke, werde ich bei nächster Gelegenheit mal ausprobieren.

> Der Schreibzugang wäre schon nett, aber ich würde trotzdem einen eigenen
> Branch aufmachen, damit du immer entscheiden kannst, was in den Master
> reinkommt - ist ja schließlich dein Projekt. Und wir können auch relativ
> unabhängig basteln.

Okay, ich richte Dir den Schreibzugriff ein und melde mich bei Dir per 
Mail.

Dank und Gruß,

Frank

Der Source-Code mit der Version 1.3.3 ist nun im SVN.

Neu:

- Unterstützung ZX-Keyboard-Matrix
- Erweiterung Tape-Routinen um Archiv-Block
- Diverse Änderungen/Optimierungen

Dank nochmal an Tom.

Ich werde die Änderungen gleich im Artikel dokumentieren. Eine neue 
HEX-Datei stelle ich aber erst später bereit, da die Version noch 
experimentell und zum Teil ungetestet ist.

Achja: Für diejenigen, die STECCY selbst kompilieren möchten und nicht 
EmBitz verwenden, dies noch zur Info:

Es muss zum Übersetzen die Compiler-Option -DSSD1963 hinzugefügt werden, 
damit der Source für Displays mit SSD1963 übersetzt wird. Alternative 
wäre die Option -DILI9341. Dies wird jedoch erst in einer späteren 
Version korrekt funktionieren.

Im EmBitz sind nun 4 Target-Varianten konfiguriert:

   ILI9341-Debug
   ILI9341-Release
   SSD1963-Debug
   SSD1963-Release

Hier sollte SSD1963-Release ausgewählt werden.

Hi Frank,

Ich habe die letzten Tage mehr an der Mechanik (Gehäuse) als an der SW 
gebastelt und musste dafür auch die Displayverdrahtung neu machen.
Ich glaube in der letzten Version ist ein Bug beim Display-update. Ich 
dachte zuerst es liegt an meiner Löterei, aber mit der (alten) Revision 
geht es.
Ist aber auch nicht 100% ausgeschlossen, daß ich etwas lokal falsch 
gemergt habe.
Ich habe gesehen, du arbeitest auch an einem Zoom fürs Display. Wäre 1/2 
auch möglich (für Vorschau von Snapshots)?

Beste Grüße, Tom

Hi Tom,

Thomas H. schrieb:
> Ich glaube in der letzten Version ist ein Bug beim Display-update.

Ja, kann gut sein, dass ich da einen Fehler eingebaut habe. Wie gesagt, 
ich habe versucht, den ILI9341-Treiber zu integegrieren. Es kann 
durchaus sein, dass ich dadurch im gemeinsamen Code von update_display() 
etwas kaputtgemacht habe. Ich selbst konnte es noch nicht am lebenden 
Objekt testen. Schaue ich mir aber noh heute (Sonntag) an.

> Ich habe gesehen, du arbeitest auch an einem Zoom fürs Display. Wäre 1/2
> auch möglich (für Vorschau von Snapshots)?

ZOOM ist momentan eine Konstante. Diese habe ich lediglich für den 
gemeinsamen Code in update_display genutzt, um beide Displays ILI9341 
(320x240) und SSD1963 (800x480) über ein- und denselben Code zu 
versorgen.

Im ersten Fall sind es nämlich ZOOM=1 und im zweiten ZOOM=2 - über 
defines. Aber die Vorschaubilder sind wirklich eine interessante Idee!

Gruß,

Frank

Vielleicht ersetzt Du erstmals die Funktion update_display  durch die 
alte. Ich komme wohl erst heute Abend dazu.

Hallo Frank,

Klar, kein Problem - lass dir Zeit. Ich habe eine lauffähige Version bei 
der ich die Touch-Funktion einbauen kann. Außerdem ist das Wetter ein 
bißchen zu schön zum Basteln ;).

Schönen Sonntag!
Tom

Hi Frank,

Nur mal ein Update, ich bin noch da und arbeite am Touchscreen. Die 
Kalibrierung haut noch nicht hin :(.
BG, Tom

Hi Tom,

Thomas H. schrieb:

> Nur mal ein Update, ich bin noch da und arbeite am Touchscreen. Die
> Kalibrierung haut noch nicht hin :(.

Ich hatte mich da auch schon mal vor ein paar Monaten dran versucht 
(nicht STECCY, aber dieses Display) und hatte jede Menge Probleme mit 
nicht-reproduzierbaren gemessenen Koordinaten.

Dann hatte ich das Thema erstmal wieder zur Seite gelegt. Du siehst 
also: Mit diesem Problem bist Du nicht allein ;-)

Falls jemand noch ein 5,7" Display braucht (240x320) ich hätte gegen 
aufgerundedes Porto 4 Stück abzugeben. Kurze Nachricht per PN genügt.

Version 1.3.4 ist online

Einziger Punkt:

- Bug in ZX-Spectrum-Display-Anzeige beseitigt.

Damit ist sowohl der Source wieder funktional als auch die im Artikel 
STECCY zum Download angebotene HEX-Datei zur Version 1.3.4.

Somit kann nun jeder auch eine originale oder nachgebaute 
ZX-Spectrum-Tastatur-Matrix am STM32 verwenden.

P.S.
Mein bestelltes ILI9341-Display ist heute angekommen. Zur Erinnerung: 
Das ist das Display, welches man direkt auf das STM32F407VET-Blackboard 
aufstecken kann. Allerdings ist es mit 3,2" um einiges kleiner als das 
unterstützte 7"-Display mit SSD1963-Controller.

Ich mache mich im nächsten Schritt nun an die Portierung auf das 
ILI9341.

STECCY läuft nun auch mit dem ILI9341-Display.

Einfach aufs BlackBoard stecken und loslegen :-)

Auf dem Bild sieht man den Protoyp mit PS/2-Adapter und ST-Link-Clone.

Die Sources/Hex-Files mache ich heute abend fertig.

Die Version 1.4.0 ist eingecheckt. Diese unterstützt nun auch die 
aufsteckbaren ILI9341-Displays mit 3,2" Größe.

Neu:

- Source mit ILI9341-Unterstützung
- Separate HEX-Datei Steccy-ili9341.hex für ILI-Variante

Auf dem ILI9341-Display wird das STECCY-Menü wegen der geringeren 
Auflösung erst bei Drücken der TAB-Taste in den ZX-Spectrum-Screen 
eingeblendet, siehe Bild.

Ich werde heute noch den Artikel in den Beschreibungen zum Display 
aktualisieren.

P.S.
Das Display bekommt man über 
https://de.aliexpress.com/item/32991977705.html für knapp 11 EUR

DasTutWeh schrieb:
> ich wünsche mir noch einen schön aufgeräumten Z80 Maschinen Monitor mit
> Asm/Disasm, peek/poke Memory, Registeranzeige, single Step/Run to/...

In STECCY ist sogar bereits ein Disassembler eingebaut. Im Debug-Mode 
kann er jede Z80-Instruktion, die er gerade ausführt, auf stdout 
ausgeben. Das ist aber natürlich kein echter Z80-Monitor. Ich benutzte 
den Disassembler nur zum eigenen Debuggen des Emulators.

Wenn ich mal viel Lust und Zeit habe, kann ich das gern mal anpacken. 
Sieht aber im Moment nicht danach aus ;-)

P.S.
Die PDFs stellen u.U. Urheberrechtsverletzungen dar. Deshalb musste ich 
die löschen. Diverse ROM-Disassembly-Listings sind öffentlich im Netz 
erhältlich und auch allgemein bekannt.

Mittlerweile läuft STECCY auch auf einer Linux-Console über den 
Linux-Framebuffer.

Für diejenigen, die gerne STECCY über einen Monitor statt TFT-Display 
laufen lassen möchten, könnte das interessant werden. Ein Raspberry Pi 
im Console-Mode reicht dafür aus.

Im Moment laufen noch diverse Tests in einer VMWare. Danach gehts auf 
einen RasPi. Der Screen sieht exakt wie auf dem 7-Zoll-TFT für den STM32 
aus, siehe Anhang.

Arduinoquäler schrieb:
> Ich möchte noch ein serielles TFT anschliessen ;-)
>
> CS, SCLK, SDATA, C/D

Keine Ahnung, ob das schnell genug ist. Immerhin wird das Display 50 mal 
pro Sekunde aktualisiert. Wobei aber durch die Optimierung im Programm 
über ein Shadow-Ram nur die geänderten Bereiche neu beschrieben werden 
müssen.

Die Displays mit SPI gibt es nicht ohne Grund nur für die kleineren 
Auflösungen. Über 3,2" ist nach meiner Kenntnis dann auch Schluss. Da 
kann man auch das ILI-Display nehmen. Immerhin kann das direkt 
aufgesteckt werden, macht also noch weniger Verdrahtungsaufwand als ein 
SPI-Display.

Die Linux-Version von STECCY ist nun eingecheckt. Damit kann man STECCY 
auch im Framebuffer eines Raspberry PI laufen lassen.

Die Anleitung zur Installation findet man unter 
STECCY: STECCY unter Linux.

Im Anhang ein Screenshot - mit 24" Monitor am RaspPI.

Viel Spaß!

STECCY läuft nun auch auf dem Linux-Desktop und muß daher nicht mehr 
notwendigerweise in einer Linux-Console gestartet werden.

Im Anhang ist die X11-Version 'xsteccy' auf dem Desktop eines 
Raspberry-PI zu sehen.

Die Installations-Anleitung im Artikel habe ich unter 
STECCY: STECCY unter Linux entsprechend angepasst, die aktuelle 
Software-Version ist unter STECCY: Download verfügbar.

Viel Spaß!

STECCY hat nun auch ein Desktop-Icon bekommen. Damit lässt sich STECCY 
auf dem RaspBerry-PI nun direkt vom Desktop per Klick aufs Icon oder 
über das Start-Menü ausführen.

Installations-Anleitung ist angepasst. :-)

EDIT:
Das Icon ist natürlich oben und unten transparent, das wird hier 
offenbar nicht richtig angezeigt.

Kurz Schluss schrieb:
> Dieses Projekt ist ja mit Abstand die interessanteste ZX Spectrum
> Emulation die ich bis jetzt gesehen habe!

Danke :-)

> So richtig toll wäre es wenn ich daran meine "recreated ZX Spectrum"
> Tastatur anschließen könnte - hat das schon mal jemand probiert, bzw.
> implementiert?

Wenn Du die ZX-Tastatur-Matrix meinst: Ja, das hat Thomas H. eingebaut, 
siehe auch Beitrag "Re: STECCY - ZX-Spectrum-Emulator mit STM32"

Seine Erweiterung habe ich übernommen, ist also in der STECCY-SW 
enthalten. Im Artikel STECCY wird das im Kapitel STECCY: Tastatur 
auch beschrieben, blättere von dort bis zur Überschrift "ZX-Tastatur".

W.S. schrieb:
> So, damit mal eine Alternative zu den teuren Displays hereinkommt.

Die oben vorgestellten Displays sind nur so "teuer", weil sie eben groß 
sind.

Erhältlich sind:

7": ab 31 EUR
5": ab 25 EUR
3,2": ab 11 EUR, aufsteckbar, 
Beitrag "Re: STECCY - ZX-Spectrum-Emulator mit STM32"

Was spart man mit Deiner "Alternative"?

Nobs schrieb:
> Ich komme immerhin bis zur Copyright-Meldung des Spectrum.

Gut.

> Tastatur will aber noch nicht und der Menü-Knopf reagiert auch nicht.

Zeige doch mal Deine ini-Datei. Auch die Variante, die bei Dir den 
schwarzen Bildschirm erzeugte.

> Jetzt muß ich wohl mal die PS/2-Variante versuchen.

Auf jeden Fall eine gute Idee.

> Gibt es eigentlich was Neues bezüglich Beeper-Tonausgabe?

Noch nicht, ist aber noch auf meiner TODO-Liste.

Nobs schrieb:
> Derzeit habe ich PC0-PC7 und PE0-PE4 angeschlossen.

Das ist korrekt.

Damit die Keyboard-Matrix auch ausgelesen wird, muss in der ini-Datei

1

KEYBOARD=ZX

eingetragen werden. Wenn Du folgendes einträgst

1

KEYBOARD=PS2

2

KEYBOARD=ZX

sollten beide Tastaturen gleichzeitig funktionieren.

Sorry, offenbar habe ich im Artikel vergessen, die Zeile KEYBOARD=xxx in 
der Ini-Datei zu dokumentieren. Hole ich nach.

Frank M. schrieb:
> Sorry, offenbar habe ich im Artikel vergessen, die Zeile KEYBOARD=xxx in
> der Ini-Datei zu dokumentieren. Hole ich nach.

Gerade nachgeholt, siehe STECCY: INI-Datei

Nobs schrieb:
> Egal wie ich KEYBOARD=ZX in der .ini auch schreibe (groß,
> klein, Leerzeichen), die Tastatur wird nicht erkannt.

STECCY ignoriert in der ini-Datei Groß-/Kleinschreibung, von daher ist 
es egal. Trotzdem empfehle ich, es genau so einzutragen:

KEYBOARD=ZX

Leerzeichen sind nicht erlaubt! Auch nicht vor dem Schlüsselwort, hier 
"KEYBOARD".

> Kann es sein, daß der Text-Editor vom Windows, den ich zum Erstellen der
> .ini verwende, das Problem verursacht? Denn wie gesagt, die ausführliche
> .ini hat nicht funktioniert, nur der Einzeiler geht.

Ja, das wundert mich auch, dass die Standard-Datei bei Dir nicht 
funktioniert. Die sollte auf jeden Fall gehen. Was hast Du zum 
Editierien genutzt? Den Windows-Notepad? Eigentlich akzeptiert STECCY 
sowohl Windows- als auch Unix-/Linux-Format (CRLF vs. LF). Ich werde das 
aber nochmal prüfen.

> Die Tastatur-Matrix hatte ich seinerzeit ausgiebig getestet, die sollte
> funktionieren. Und da auch der Menü-Aufruf, den ich per Kabelstück
> auszulösen versuche, nicht funktioniert, würde ich eigentlich darauf
> tippen, daß die Pins aus irgend einem Grund noch nicht abgefragt werden.

Du kannst auch mal testweise mit einem Kabel eine Verbindung zwischen 
irgendeinem PCx (0-7) und PEx (0-4) herstellen. Dann sollte eigentlich 
die entsprechende Taste ausgelöst werden.

Noch eines könntest Du testen. Trage bitte mal in der STECCY.INI 
folgende zwei Zeilen ein:

KEYBOARD=ZX
KEYBOARD=PS2

Ich habe gestern abend nämlich nochmal in den Source geschaut. 
Eigentlich sollten dann beide Tastaturen aktiv sein. Wie ich aber nun 
gesehen habe, sorgt die ZX-Tastatur automatisch dafür, dass die 
PS/2-Tastatur nicht mehr abgefragt wird. Das ist eigentlich ein 
Programmfehler, kann hier aber nützlich sein.

Frage: Funktioniert mit obigen 2 Zeilen die PS/2-Tastatur noch?

Ich habe den ZX-Keyboard Bug gefunden, es war ein dummer Tippfehler.

Statt

1

#ifdef STM324XX

in z80.c muss es natürlich heißen:

1

#ifdef STM32F4XX

Die HEX-Dateien habe ich aktualisiert, ebenso die Änderungen im Source 
eingecheckt.

Damit sollte die ZX-Tastatur nun auch funktionieren.

Ich werde die ZX-Tastatur-Routine noch einmal überarbeiten, da nach Toms 
Aussage diese im STECCY-Menü noch etwas "hakelig" ist.