STECCY emuliert einen ZX-Spectrum 48K auf einem STM32F407VET-Black-Board, welches für ca. 10 Euro bei eBay oder Aliexpress erstanden werden kann. Außerdem ist STECCY auch unter QT übersetzbar, so dass STECCY auch unter Windows und Linux genutzt werden kann.
STECCY bildet als Emulator nicht nur den Befehlssatz einer Z80-CPU ab, sondern auch Teile der ZX-Spectrum-Hardware. Das 256x192 große Spectrum-Display wird dabei auf einem TFT-Display mit einer Vergrößerung von 2:1 dargestellt - also mit einer Auflösung von 512x384 Bildpunkten.
Das Laden und Speichern von Programmen geschieht über eine SD-Karte, welche FAT32-formatiert ist. Hier werden die Cassettenrecorder-Routinen im virtuellen ROM umgebogen auf eigens erstellte Lade- und Speicher-Routinen für SD-Karten. STECCY unterstützt dafür TAP-, TZX- und Snapshot-Dateien. Mittels Snapshots kann jederzeit der aktuelle Zustand des emulierten ZX-Spectrums eingefroren und abgespeichert werden. Dadurch ist es dann zum Beispiel möglich, am nächsten Tag ein Spiel genau zu dem Zeitpunkt weiterzuspielen, wie es als Snapshot gespeichert wurde.
Es wird der ZX-Spectrum 48K emuliert. Der virtuelle Spectrum hat also ein ROM mit einer Größe von 16KB und RAM mit einer Größe von 48KB. Dabei wird der Inhalt des Original-Sinclair-ROMs verwendet. Dieses wurde schon vor langer Zeit (1999) von Amstrad, dem derzeitigen Rechteinhaber, als frei verfügbar und weiter verteilbar erklärt.
Nichtsdestotrotz können aber auch alternative ROMs wie zum Beispiel das "GOSH WONDERFUL ZX Spectrum ROM" verwendet werden - ladbar analog zum Original-Sinclair-Rom über die SD-Karte.
Z80-Emulator
Es werden nicht nur die dokumentierten, sondern auch alle undokumentierten Befehle einer Z80-CPU nachgebildet. Dieses ist insbesondere bei Spielen wichtig, da manche ZX-Spectrum-Spiele undokumentierte Instruktionen verwenden.
Über http://clrhome.org/table/ findet man sämtliche möglichen Z80-Instruktionen. Die dokumentierten sind grau hinterlegt, die undokumentierten haben einen roten Hintergrund. Diesen bilden den weitaus größeren Teil des Z80-Instruction-Sets.
Hardware-Emulator
Folgende ZX-Spectrum-Hardware wird durch STECCY nachgebildet:
Z80 durch timinggenaue Emulation einer 3,5MHz getakteten Z80-CPU
ULA-Chip für Display und Interrupts
Spectrum-Tastatur durch PS/2-Tastatur
Cassettenrecorder durch SD-Karte
Spectrum-ROM durch Datei auf SD-Karte
Spectrum-Screen auf 7" TFT-Display mit SSD1963-Controller
Display
Als Display wird ein 7-Zoll-TFT-Display mit 800x480 Pixeln und SSD1963-Controller verwendet. Dabei wird der Spectrum-Screen von der ursprünglichen Auflösung von 256 x 192 Pixeln auf 512 x 384 Pixel aufgebohrt.
Features
Die Features von STECCY kann man mit folgenden Punkten zusammenfassen:
Emulation sämtlicher Z80-Instruktionen - auch der undokumentierten.
Das Timing gleicht dem einer Z80-CPU bei 3,5MHz
Vergrößerte Anzeige des ZX-Spectrum-Displays inkl. "Border" auf TFT mit 800x480 Pixeln
Verschiedene ZX-Spectrum-ROMs möglich
Laden und Speichern von TAPE-Daten über SD-Karte
Simulation der Spectrum-Tastatur durch eine PS/2-Computer-Tastatur
Simulation diverser Joysticks über Tastatur-Nummernblock
Spiele
Viele der ZX-Spectrum Spiele sind mittlerweile Public-Domain. Informationen über Copyrights findet man hier: https://www.worldofspectrum.org/permits/. Im Zweifel gilt: Ist man Eigentümer des Original-Spiels in Form der Compact-Cassette, ist man auf der sicheren Seite.
Überhaupt ist https://www.worldofspectrum.org/ diejenige Anlaufstelle, um sich allgemein über den ZX-Spectrum zu informieren oder auch Programme/Spiele herunterzuladen. Über das Archiv https://www.worldofspectrum.org/archive.html kann auf Text-Adventures, Utilities und über 10.000 Spiele für den ZX-Spectrum zugegriffen werden. Auf Urheber-Rechte sollte unbedingt geachtet werden!
Weitere geplante Features
Unterstützung einer USB-Tastatur (bereits im Test)
Unterstützung der Original-ZX-Spectrum Matrix-Tastatur (8x5)
Ausgabe von Ton über einen externen Lautsprecher
Alles weitere findet man im Artikel STECCY. Dieser wird in den nächsten Tagen weiter ausgebaut.
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]
Coole Sache, Respekt. Ich fühle mich in meine Jugend zurückversetzt. Mit
einer Radiergummitastatur mit sechsfacher Tastenbelegung wäre das ganze
jetzt auch noch gefühlsecht :-)
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.
Wahnsinn. Das will ich mir auch bauen.
Kann man dann auch in BASIC und Maschinensprache programmieren?
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?
Joe.
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.
Ja, wenn's geht, wäre das eine elegante Umschiffung des
Beschaffungsproblems. Der 8255 hat einen Parallel-Bus mit drei
8-Bit-Ein-/Ausgängen. Ginge das, drei oder vier 8-Bit-Ports; und I2C und
SPI transparent nach draußen anschliessbar zu machen? Ich habe jetzt
noch nicht den detaillierten Überblick über die Hardware; aber so etwas
wäre eine feine Sache.
Analoge Ein- und Ausgänge sind dann vielleicht auch denkbar? Beruflich
bin ich Hardware-Entwickler, da könnte ich mich einbringen.
Joe
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.
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.
Bei zwei 8-Bit-Ports, wäre eine Erweiterung denkbar mit z. B. einem
acht-aus-drei Dekoder, 74HCT138 oder so. Braucht drei Bits.
Wenn man 16 Leitungen für I/O nehmen könnte?
0 - |
1 ----74HCT138 ===> 8 Bits nach draußen für Ausgänge, SPI/SS,
CS-Leitungen
2 - |
3 - I2C/SDA
4 - I2C/SCL
5 - SPI/MOSI
6 - SPI/MISO
7 - SPI/SCLK
0 - I/O, geht auch als gelatchter Daten-/Adressbus, für Transistoren
oder Relais.
1 - "
2 - "
3 - "
4 - "
5 - "
6 - "
7 - "
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.
Wenn man die I/O-Leitungen nach außen auf 16 begrenzt, und mit I2C
anschließt, käme ich auf so eine Konfiguration:
Als ganz klassisches I2C-System, mit gesteckten ICs im DIP-Gehäuse
(falls mal etwas kaputt geht):
2x PCF8574 oder 1x PCF8575, 16-Bit-I/O Expander mit Interrupt (3.
Input-Leitung evtl. notwendig)
1x PCF8591, der Klassiker für analog in/out; 4x analog in, 1x analog
out.
So wär's eine runde Sache für Leute wie mich, die auch mal eine
Elektronik anschließen wollen. Ein toller, kleiner Steuerungscomputer.
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.
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.
Frank M. schrieb:> Mit dem zusätzlichen ESP8266 könnte der STM32 über WLAN geflasht werden,> wenn Updates verfügbar sind.
Wenn man sich furchtbar langweilt :-) könnte man das Interface
Spectranet und TNFS kompatibel machen.
https://www.bytedelight.com/?page_id=3515 Damit könnte der Emulator
direkt Games aus dem Internet laden.
Frank M. schrieb:> STECCY emuliert einen ZX-Spectrum 48K auf einem STM32F407VET-Black-Board
Gratulation!
Das sieht ja nach einem wirklich sehr hübschen Bastelprojekt aus - und
es erinnert mich an früher. Ich hatte so Mitte der 80er Jahre einen
ZX-Spectrum 48K in diskreter Logik aufgebaut. Ging gut, sämtliche Spiele
taten wie sie sollen.
Aber das ist nun schon rund 35 Jahre her - und wenn man mal bedenkt, was
heutzutage angesagt ist, dann merkt man mal deutlich, was es seitdem für
eine gewaltige technische Entwicklung gegeben hat. Libre Office versus
TLW (TheLastWord) oder so.
Für mich erstaunlich ist, daß es offenbar eine Menge ZX-Fans gibt, die
selbst teure Teile wie z.B. Leergehäuse für viel Geld (rund 100 Euro!)
kaufen, so daß es dafür einen Markt gibt.
W.S.
Michael Gugelhupf schrieb:> Wenn man sich furchtbar langweilt
Ich schätze, daß man mit jeder Art Erweiterung, die nicht schon damals
vorgesehen war, ungeahnte Komplikationen hervorruft. Dann laufen
plötzlich irgendwelche Apps/Spiele nicht mehr. Schon damals hatten die
Softwarehersteller alle möglichen Tricks benutzt, um das Disassemblieren
und Kopieren zu erschweren. Eigene Kassettenroutinen, undokumentierte
Maschinenbefehle, Stackpointer auf passende Stelle im ROM und vieles
Andere.
Da nun anstelle der Kassette anderweitige Speicher oder anstelle der
Tastenmatrix eine andere Tastatur benutzen zu wollen, macht
Schwierigkeiten und Inkompatibilitäten. Das sollte man berücksichtigen,
wenn man sowas tun will. Sonst hat man zwar eine nette Peripherie, aber
keine dazu passende Software.
W.S.
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/
Super Teil. Erstaunlich, was man so alles machen kann.
Wenn das OS vom C64 frei wäre... Aber auch da sind erste Anzeichen für
eine Neuauflage in Sicht...
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ß!
Gibt es eigentlich bei dem Display noch mehr Optionen?
Ich würde da gern was mit anderen AV Eingängen einsetzen - z.B. um auch
einen C64 dran zu hängen.
Grüße,
Egberto
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 ;-)
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.
Klar, ist alles total sinnlos. Aber natuerlich schon auch sehr cool!
> Für mich erstaunlich ist, daß es offenbar eine Menge ZX-Fans gibt, die> selbst teure Teile wie z.B. Leergehäuse für viel Geld (rund 100 Euro!)> kaufen, so daß es dafür einen Markt gibt.
Vor allem wenn man bedenkt das ich damals wenn ich mich richtig erinnere
399DM fuer eine richtige Tastatur ausgegeben habe in der man die Platine
des ZX einbauen konnte. Da wuerde ich heute kein Geld mehr ausgeben um
wieder Gummifeeling zu haben. :-)
BTW: Es ist garnicht so lange her das ich das externe 5 1/4Zoll
Diskettenlaufwerk fuer den ZX Spectrum weggeworfen habe. Hat damals
1000DM gekostet! Bevor die Fans jetzt Schnappatmung bekommen, das war
sowieso kacke weil das eine eigene Firmware hatte die sich in die oben
16k anstatt des Rams eingeblendet hat. Damit lief dann viele Software
nicht mehr weil man im Prinzip einen 32k Spektrum hatte.
Olaf
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ß!
Wenn ich das richtig verstehe, ist diese I2C-Schnittstelle universell
einsetzbar, für 7-Bit-addressierbare ICs.
Dann wäre der PCF8591P (4-Kanal-A/D, 1-Kanal-D/A-Wandler) und eine RTC,
z. B. auch kein Problem?
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)
Es soll die teuren Meßtechnik-Erweiterungen für die Taschenrechner von
Casio und TI ersetzen, im Schulunterricht.
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...
>und direkt mal bestellt. Zum Testen ist das wohl ganz nett, aber 5" oder>7" gefallen mir von der Größe her besser.
Mir sind die 3.2 Zoll mittlerweile auch zu klein.
7 Zoll ist tatsächlich eine angenehme Größe, aber so viele Kabel zu
ziehen finde ich immer etwas nervig. Ich tendiere mittlerweile zum
bequemen und mit etwas Glück findet man oft geeignetere Teile.
Übrigens:
Vor kurzem gab's auf Hackaday mal einen Beitrag von Bitluni zum ESP32:
https://hackaday.com/2020/02/24/bitluni-brings-all-the-esp-32-multimedia-hacks-to-supercon/
Der hat in seiner Library VGA-Treiber in allen erdenklichen Richtungen
breit getreten:
https://github.com/bitluni/ESP32Lib
Nein, ich glaube, das I2C ist so wie es jetzt schon ist, voll
einsatzfähig. Man kann eine Adresse auf den Bus schreiben, und eine
Antwort lesen. Das ist schon fein so. Die 8 Bit muss man dann natürlich
selbst in seiner Software interpretieren. Also keine Extra-Befehlsworte
für spezielle, am I2C-Bus hängende ICs. Einfach nur einen universellen
I2C-Bus. Der Nutzer muss dann natürlich selber schauen, dass es keine
Kollisionen bei den Adressen gibt.
Der PCF8591 (A/D, D/A-Wandler) hat z. B. diese Adressen: 0x90 bis 0x9E.
Aber anstatt jetzt jeden einzelnen I2C-Chip speziell zu berücksichtigen,
würde ich eine universelle Lösung vorschlagen. Also quasi einen
transparent schreib- und lesbaren I2C-Bus.
So kaum ist eine Woche vergangen schon habe ich dieses
Projekt entdeckt ;-)
Ich staune welche Arbeit man in so ein Spiele-Projekt steckt.
Dazu meinen vollen Respekt. Ich würde es nicht tun ....
Aber:
- Projekt in Embitz (ich liebe es) geschrieben
- sauberer Aufbau in Gliederung, Modularisierung
- sehr saubere Sourcen
- SPL verwendet
Alles in allem, sehr klasse gemacht!
Da möge sich so mancher Einsteiger der mit Mühe sein erstes
CubeMX-Projekt auf die Beine stellt, ein Vorbild nehmen.
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.
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.
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.
> Gummitastatur und auch einen ZX Spectrum 128k mit 3-Kanal Soundchip und> eben 128k RAM (Bankswitching lässt grüssen ;-) ).
Wie bist du eigentlich darauf gekommen? Ich hatte den Eindruck das es
bei uns nur Spektrum mit 16k und 48k gab und dann erfolgte praktisch bei
jedem nahtlos der Uebergang auf Atari ST, Amiga oder vielleicht schon
PC. Die anderen Spektri gab es doch IMHO nur in England oder?
Olaf
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.
> 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 ;-)
Ich kenne noch die verschaerfte Version: Nach vielen Stunden Hexlisting
eingeben schaltet Mutti ihren Staubsauger ein und Sir Clive hat wohl
niemals ueber Surge und Burst nachgedacht. :-D
Olaf
Frank M. schrieb:> 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 ;-)
(ich steige mal auf das bisschen Off-Topic ein ...)
Da hatten es die Apple User schon etwas komfortabler, die
Audio-Kasetten-Zeit konnte man da schon hinter sich lassen,
Spiele gabe es auf Diskette (5.25 Zoll) und so langsam waren
Disk-Laufwerke leistbar, auch weil damals schon in Fernost
jede Menge Billig-Kopien erhältlich waren. Und zum "Sichern"
von Spielen gab es zum einen kopiergeschützte Disketten
und auf der anderen Seite Kopierschutz-Kopierprogramme und
die sogenannte Wildcard mit der man komplette Speicherabzüge
von geschützten Spielen machen konnte.
Ja auf der Basis könnte man sich mit wenig(er) Mühe einen
netten Apple II(e) Emulator schreiben.
Aber nein, ich werde es mir trotz aller Schönheit dieser
Kreation nicht antun, so verlockend es für einen Apple User
auch sein mag.
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.
> 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.
Die kleinen Speccis hatten 16k. Wenn du den erweitert hast dann hatte
der praktisch automatisch 80k weil man nur 4164 kaufen konnte, waehrend
die originalen 48k da 4132H oder 4132L drin hatten. Ich konnte also auch
bei meinem die oberen 32k umschalten. Allerdings war das weitestgehend
nutzlos weil das ja von niemanden unterstuetzt wurde. Ausserdem wisst
ihr doch hoffentlich alle noch wie lange das gedauert hat bis man 48k
von der Kassette in den Speicher geladen hat. :)
Wofuer wurde denn der Speicher beim originalen 128er genutzt? Spiele?
Olaf
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...
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ß :-)
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.
Frank M. schrieb:> Hier werkelt ein STM32F103, dem> der USB-spezifische interne Pullup fehlt.
Eigentlich sollte man nicht "fehlen" dazu sagen. Natürlich kann man
einen fest nach Vcc gehenden 1k5 vorsehen (extern oder intern), aber das
ist manchmal unerwünscht, damit man ggf. vor dem Enumerieren noch andere
Sachen im µC erledigen kann. Dazu haben ältere Chips extra Pinfunktionen
aus dem USB-Core heraus (low-aktiv! braucht also noch nen Transistor) -
aber das belegt dann ja ein Portpin und sowas ist gerade bei kleineren
Gehäusen nicht gern gesehen. Da ist es allemal am besten, keinen
eingebauten 1k5 im Chip zu haben, so daß der Schaltungsentwickler es
sich aussuchen kann, ob er einen geschalteten 1k5 oder einen fest an Vcc
haben will.
W.S.
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. Gäbe es alternative
Anschlussmöglichkeiten für Bildschirme über gängige Anschlüsse(AV, VGA,
DVI, irgendwas)? 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), aber das Original hing ja auch am
TV...
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.
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!
Frank M. schrieb:> Ich habe jedenfalls keine Lust, mehrere Minuten zu warten,
nanana, bei manchen Spielen war das Intro der netteste Teil des ganzen
Spiels gewesen.
Aber der entscheidende Punkt ist: wer hat noch einen geeigneten
Kassettenrecorder und die Kassetten dafür?
W.S.
sehr geil!
ich hab erst kürzlich überlegt wo ich n alten Fernseher herbekomme um zu
gucken ob's mein ZX noch tut.
(ist glaub ich aber n 81.. hab den dummerweise in ne Cherry Tastade
gequetscht weil mir der Folienblödsinn auf die Testikel schlug
seinerzeit
mit der ganzen Abtipperage aus den Büchern damals)
Das ist doch mal was für alte Herren die nen faulen Sonntag mit
Zeitreisen verbringen möchten..
Dankeschön :D
'sid
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.
Ich denke, HDMI wäre ziemlich übertrieben. Es ist zwar aktuell der
gängigste Anschluss, aber die Hardware-Voraussetzungen dafür sind doch
relativ heftig und werden von dem, was ein Spectrum darstellen konnte,
nie und nimmer benötigt. Ich sehe die Stärke von Steccy gerade darin,
daß man ein kleines, günstiges Board einsetzen kann. Das macht die
Einstiegshürde niedrig. Teurere Lösungen wie Retropie (primär zum zocken
gedacht) oder nachgebaute Spectrum-Hardware (Harlequin, Omni, Nuvo,
Pentagon)gibts reichlich. Alle haben ihre Vor- und Nachteile und alle
gehen durchaus ins Geld (z.B. Harlequin-Bausatz ca.90€, Nachbau-Gehäuse
komplett ca.80€, SD-Interface ca.40€). Genau deshalb sehe ich das
Display, was der teuerste Teil am Steccy ist, kritisch und würde mir da
eine Alternative wünschen.
Unterstützung der Original-Tastatur wäre nett, ist aber für mich nicht
zwingend nötig. Notfalls wird eine billige USB-Tastatur beklebt.
Kassetten und Recorder hätte ich eh nicht mehr. Ich sehe da den
deutlichen Fortschritt durch die SD-Karten-Speicherung. Ob man
vielleicht für die Puristen einen "klassischen" Lademodus implementieren
könnte, der mit mehr oder weniger Originalgeschwindigkeit das Tape-image
von der SD-Karte läd, damit man trotzdem in den Genuss spezieller
Ladebildschirme kommen könnte? Mir persönlich wäre das eher egal.
sid schrieb:> Das ist doch mal was für alte Herren die nen faulen Sonntag mit> Zeitreisen verbringen möchten..>> Dankeschön :D
Dein Steccy ist ein wares "Leuchtturmprojekt" in dem Meer von
Belangloses, das sich hier mitlerweile ausbreitet.
Dickes Dankeschön für dieses tolle Projekt und die Qualität deiner
Arbeit!
Völker/Bastelvolk, hört die Signale und lernt zu siegen/den Kampf gegen
Mittelmass!
Nobs schrieb:> Genau deshalb sehe ich das> Display, was der teuerste Teil am Steccy ist, kritisch und würde mir da> eine Alternative wünschen.
Tja, das ist heutzutage ein kaum lösbares Problem. Für den Spectrum mit
seinen 256×192 Pixeln würde ein 320x240 TFT ja völlig ausreichen - aber
wo kriegt man das in ausreichender Größe und wenig Geld? Ich hatte
sowas vor etwa 20 Jahren in meinen Geräten verbaut, aber der Zug ist
weg, heutzutage sind die Auflösungen weitaus größer - und damit steigt
der Aufwand.
Ich hab hier noch ein paar Boards mit LPC17nochwas, LPC4088 und so
herumfliegen, alle mit eingebautem TFT-Controller, ausreichend SDRAM und
für TFT 800x480 geeignet. Solche TFT's gab's vor Jahren beim Chinesen
für etwa 18..23€.
Das Steccy-Projekt ist aber nicht so organisiert, daß man mal eben die
Plattform von STM32 nach LPC und den Screen vom originalen Display nach
direktem TTL-RGB565 wechseln könnte, was ja völlig ausreichen würde.
Hab deshalb auch noch keinen diesbezüglichen Versuch gemacht.
W.S.
W.S. schrieb:> Hab deshalb auch noch keinen diesbezüglichen Versuch gemacht.
Das wird hier auch kaum jemanden interessieren. Ein LPC4088 kostet netto
schon mehr als das das komplette Board (incl. Versand) das Frank
verwendet. Die LPC sind den Chinesen scheinbar komplett unbekannt. Bis
auf ein paar Boards von Waveshare, aber die sind preislich für die
Meisten auch uninteressant.
Ein 320 x 240 TFT nochmal einen 10er dazu und das Ganze wird ein
kompakter ZX-Gameboy. Das hat Frank ja auch schon bestellt, und die SW
Anpassung hält sich sehr in Grenzen.
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.
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.
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. Nur mit dem seitlichen Menu wird es dann vermutlich eng
mit 320 Pixeln Breite.
Wo zieht man sich eigentlich ROMs für den ZX, ohne sich gleich einen
Virus einzufangen oder dass die manipuliert sind ? Das scheint mir ein
riesen Problem bei den Retro-ROMs anderer Systeme zu sein
(südamerikanische Server ?).
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
case0x32:// archive info
2
{
3
if(!tzx_read_block_32(tape_load_fp))
4
{
5
fclose(tape_load_fp);
6
tape_load_fp=nullptr;
7
return0;
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
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 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 ;-)
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
Hi,
ich wünsche mir noch einen schön aufgeräumten Z80 Maschinen Monitor mit
Asm/Disasm, peek/poke Memory, Registeranzeige, single Step/Run to/...
Es gab/ich hatte für den ZX auch einen sehr Guten.
Jetzt geht das natürlich viel besser mit der Emulator-Engine und ohne
Speicherbelegung im Z80 Addressraum.
Das wäre mein Traum ... :-)
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.
Prima, daß Steccy jetzt auch mit dem kleinen, günstigen Display und der
Tastaturmatrix läuft. Ein kleines, handliches System zu einem
attraktiven Preis. Was will man mehr? Sehr gute Arbeit!
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.
Frank M. schrieb:> Keine Ahnung, ob das schnell genug ist.
Nein ist es natürlich nicht .... Spässle g'macht.
So ein kleines serielles verträgt soweit ich mich erinnere nur
10MHz Clock, da kommt man nicht weit ...
Arduinoquäler schrieb:> So ein kleines serielles verträgt soweit ich mich erinnere nur> 10MHz Clock, da kommt man nicht weit ...
WIMRE braucht man ca. 150 ms um einen 320x240-Screen im SPI-Mode zu
beschreiben. Das verträgt sich hier nicht mit den Anforderungen.
> So ein kleines serielles verträgt soweit ich mich erinnere nur> 10MHz Clock, da kommt man nicht weit ...
Das ist offiziell laut Datenblatt. Es gibt aber Leute die betreiben die
Teile auch mit 40Mhz CLock und es funktioniert. Wenn man nur Teile
beschreibt die sich aendern, ich mache das derzeit mit lvgl, koennte es
gerade so klappen.
if (Used_Display == MODUS_ili9341)
{
//40Mhz ist deutlich mehr als das Datenblatt erlaubt,
//aber Internet sagt das ist okay und es klappt auch
uartInit.baudrate = 40000000;
uartInit.clockMode = usartClockMode0;
}
Aber natuerlich, schoen ist anders....
Olaf
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ß!
Kleine Off-Topic-Bemerkung:
Die Tatsache dass Frank Embitz für sein Projekt nutzt bestätigt
mich in meiner (sowieso unumstösslichen) Meinung dass Embitz eine
richtig geile schnelle Entwicklungsumgebung ist.
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.
Hi!
Dieses Projekt ist ja mit Abstand die interessanteste ZX Spectrum
Emulation die ich bis jetzt gesehen habe!
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?
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".
Kurz Schluss schrieb:> Es gab (...denke es war 2015) ein Projekt Namens "recreated ZX> Spectrum"
Ach herrje - grad mal nachgeschaut bei ebay: rund 170€ nur für eine
gebrauchte Tastatur im ZX-Spectrum-Format.
Nee, das ist viel zu teuer und auch unangemessen. Immerhin soll Frank's
Steccy ja auf so einem 10€ Evalboard laufen, was ohne Steccy bloß in der
Schublade sedimentiert.
Da grämt es unsereinen bereits, für so ein 7" Display mit dem SSD1963
noch einmal rund 35€ oder mehr ausgeben zu sollen, wo in der Bastelkiste
bereits mehrere LPC4088 mit 8 MB RAM, SD-Karte, sonstiger Peripherie und
7" Display herumliegen. An dieser Stelle hätte ich mir eine bessere
Portierbarkeit von Steccy gewünscht, aber genau das Thema hatten wir
schon mal.
Ähnliches gilt für die originalen Tastatur-Gummimatten für rund 17€,
Tastatur-Leiterfolien für weitere 15..9€ und Tastatur-Abdeckung für
nochmal 20€.
Nein, all das ist viel zu teuer für den Spaß hier. Wenn also überhaupt,
dann eben Eigenbau oder bleibenlassen.
W.S.
So, damit mal eine Alternative zu den teuren Displays hereinkommt.
Gelegentlich sieht man ja passable TFT für 12..20€, dazu dann diese LP
und fertig ist die Laube.
Die LP im Anhang ist für diverse TFT-Module. Es sind 3 verschiedene
Folienstecker vorgesehen: LB080WV3, LB070WV1 und ein generisches für
AT070TN92, bei dem man jedoch die Analogspannungen separat zuführen
müßte.
Wer das nicht so gebrauchen kann, muß eben die LP bearbeiten. Ansonsten
sind die Dateien für JLCPCB dabei.
W.S.
Kurz Schluss schrieb:> Wäre eigentlich mit dem Board nicht auch eine VGA Ausgabe möglich so wie> hier?
Was meinst du? Die von dir gezeigte Schaltung sieht mir eher nach einem
SH Prozessor aus, dafür gab's mal ne Windows-CE Version - falls mich das
nicht täuscht.
Ansonsten ist die von mir gepostete LP eigentlich für Controller
gedacht, die selbst keinen Framebuffer auf die Beine stellen können.
Also geht das Ganze dann über einen 8 Bit Port. Geht ja so, allerdings
ist mir ein direkt erreichbarer Framebuffer durchaus lieber.
Die Chips von Solomon sind für kleinere µC aber auch nicht so dolle:
zwar relativ billig, aber eben nur Grafikausgabe. Da ist ein 8 Bitter
schon recht schnell an der Grenze, wenn er z.B. Text ausgeben will.
Wenn ich mir zum TFT den µC aussuchen kann, dann nehme ich weitaus
lieber einen, der einen TFT-Peripheriecore bereits intus hat und der
extern ein SDRAM verträgt. Seit einiger Zeit mein Liebling ist da der
LPC4088, aber es gibt mittlerweile auch andere Typen, sogar welche von
ST - da hab ich ein paar Eval-Muster aus der ersten Charge noch in der
Schublade, aber die haben am EBI noch ne Macke, hab sie also noch nie
benutzt.
Naja und für einfachere CPU's wäre aus meiner Sicht der RA8875 weitaus
besser geeignet. Der kann sowohl grafisch als auch Textmode. Ist bloß
etwas teuer. Allerdings ist sowas für Steccy wiederum überdimensioniert.
W.S.
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"?
Endlich habe ich meine Teile auch beisammen. War leider ein ziemliches
Abenteuer. Ich wollte das direkt steckbare ILI-Display, allerdings von
e-bay, da ich dort schon einen Kunden-Account habe. Leider habe ich nach
langer Lieferzeit nicht "exakt" das passende Display bekommen, ein paar
Pins sind vertauscht. Also doch Kabelverhau...
Tastatur-Matrix hatte ich schon mal für einen ZX-81 gebaut. Da muß nur
eine neue, laminierte Folie mit Spectrum-Tastenlayout drüber.
Ich komme immerhin bis zur Copyright-Meldung des Spectrum. Hatte jetzt
aber einen ziemlichen Kampf mit der .ini Datei. Aus irgend einem Grund
wollte die in kompletter Form nicht funktionieren und hat einen
schwarzen Bildschirm erzeugt. Stand jetzt ist einzig und alleine die
Zeile zur Drehung des Bildschirms vorhanden und nur so geht es auch bei
mir.
Tastatur will aber noch nicht und der Menü-Knopf reagiert auch nicht.
Jetzt muß ich wohl mal die PS/2-Variante versuchen.
Gibt es eigentlich was Neues bezüglich Beeper-Tonausgabe?
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.
Hier der Text-Inhalt der funktionierenden ini.Datei:
ORIENTATION=1
Und hier die, die nicht funktioniert (Ich habe dabei verschiedene
Einstellungen durchprobiert):
# PATH: Default is current directory (only QT)
PATH=c:\steccy
# ROM: Default is 48.rom
ROM=48u.rom
# Autostart: Default is yes
AUTOSTART=yes
# Autoload: Default is none
AUTOLOAD=no
# Orientation: Default is 0 (only STM32)
ORIENTATION=1
# RGB Order: Default is 0 (only STM32)
RGB=0
Für die PS/2-Variante muß ich erst mal nach einer passenden Buchse
kramen. Das wird heute nichts mehr.
So, PS/2 hab ich getestet und funktioniert einwandfrei. Buchse hatte ich
keine, habe kurzerhand die Kabel in den Stecker gestopft. Pullups hatte
ich vergessen, geht aber auch ohne. Ist nur furchtbar umständlich, einen
Spectrum mit einer normalen Tastatur bedienen zu wollen.
Das legt den Verdacht nahe, daß ich entweder mit der Matrix auf den
falschen Pins bin oder ein anderes Problem vorliegt. Derzeit habe ich
PC0-PC7 und PE0-PE4 angeschlossen. PC0 zu PE5 soll ja das Menü aufrufen,
aber auch das klappt leider nicht.
Ich habe auch mal ein Bild von meinem Display angehängt. Das ist leider
nicht 100% Pin-Kompatibel. Muß mal schauen, wie ich das am Ende lösen
kann. Zur Not muß ein Pin ausgelötet werden.
Wie gesagt, ich hatte die Matrix-Tastatur ursprünglich für einen
ZX81-Nachbau gebaut. Da fehlt jetzt nur noch eine neue, laminierte
Karte, dann wird eine Spectrum-Tastatur draus.
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
Danke für die Aktualisierung. Leider kann ich keinen Erfolg vermelden.
Egal wie ich KEYBOARD=ZX in der .ini auch schreibe (groß, klein,
Leerzeichen), die Tastatur wird nicht erkannt.
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.
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.
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.
@UKW:
Deine Antworten und Verbesserungen kommen schneller, als mir der
Alltags-Streß Zeit zum Testen läßt. Dein "Kundenservice" ist
ausgezeichnet! Vielen Dank dafür!
Nur der Vollständigkeit halber:
Ja, ich habe Windows-Notepad verwendet. Das hatte ich als mögliche
Fehlerquelle in Betracht gezogen, konnte es aber auf die Schnelle nicht
mit etwas anderem gegenchecken. Drum hatte ich es erwähnt. Aber daran
lag es ja in dem Falle nicht.
Den "Kabel-Test" (Pins überbrücken um Tastendruck der Matrix zu
simulieren) hatte ich zumindest mit dem Menü-Knopf probiert und da ging
nichts. Das war für mich das Indiz, daß meine Matrix vermutlich nicht
fehlerhaft ist. Zudem hatte ich die Matrix seinerzeit Zeile für Zeile
und Taste für Taste mit LEDs durchgeprüft.
Solange ich diese beiden Zeilen
KEYBOARD=ZX
KEYBOARD=PS2
in der .ini hatte, ging bei mir die PS2-Tastatureingabe durchgängig.
Eine Blockierung der PS2-Eingabe durch diesen Eintrag in der .ini konnte
ich nicht reproduzieren.
Da du ja alles schon selber herausgefunden hast, muß ich wohl nur noch
die neue Hex-Datei einsetzen. Ich berichte, sobald ich das erledigt
habe.
@Kurz Schluss:
Da ich ja mit der Beschaffung des Displays Probleme hatte, bin ich auch
über den von dir angesprochenen Beitrag gestolpert. Ich habe aber leider
keine Infos eingeholt, obwohl die Option sehr interessant klang.
Meine 3,2" sind schon recht klein. Da ich aber einen "mobilen" Steccy
bauen möchte, war mir das letztlich lieber als die teuren 5" und 7"
Displays. Das heißt aber nicht, daß ich bei einer größeren, günstigen
Alternative nicht doch schwach werden würde.
Nobs schrieb:> Da du ja alles schon selber herausgefunden hast, muß ich wohl nur noch> die neue Hex-Datei einsetzen.
Ich hoffe es. Leider kann ich es nicht selbst testen, da ich keine
Tastatur-Matrix habe. Ich werde mir wohl langfristig noch eine bauen,
obwohl ich mit der PS/2-Tastatur ganz gut zurechtkomme.
> Meine 3,2" sind schon recht klein. Da ich aber einen "mobilen" Steccy> bauen möchte, war mir das letztlich lieber als die teuren 5" und 7"> Displays. Das heißt aber nicht, daß ich bei einer größeren, günstigen> Alternative nicht doch schwach werden würde.
Das direkt aufsteckbare ILI-Display ist mit 12 EUR schon ganz nett. Aber
so ein 7"-Display finde ich schon besser.
P.S.
ICh habe nun hier eine Test-Version mit Speaker am laufen. Jetzt piepen
die Spiele fröhlich vor sich hin - genauso wie beim Original. Kommt dann
im nächsten Release.
Version 1.4.4 ist nun verfügbar. Jetzt kann STECCY auch die
Tonausgabe.
An PC13 des STM32 kann ein aktiver Lautsprecher oder ein kleiner
Audio-Verstärker angeschlossen werden. Aktive PC-Lautsprecher
funktionieren zum Beispiel sofort.
Möchte man etwas kleineres in ein STECCY-Gehäuse integrieren, bietet
sich ein kleines LM386 Verstärker-Modul, welches für ca. 3 EUR
erhältlich ist, an. Hier kann dann auch ein Mini-Lautsprecher
angeschlossen werden, z.B. findet man welche mit 0,25W und 27mm
Durchmesser wie Sand am Meer. Auf weitere Einfachst-Vorschläge bin ich
gespannt :-)
Bestens! Tonausgabe wird gleich als nächstes aufgebaut.
Die Matrix-Tastatur funktioniert dank deiner Updates jetzt perfekt. Die
Mikrotaster prellen überhaupt nicht, die Bedienung ist wirklich super
und dank passender Tastaturfolie man muß die Kommandos nicht mehr blind
raushauen.
Mein nächster Job nach dem Sound-Modul wird sein, den Kabelverhau
langsam zu reduzieren und dann mal in Richtung eines praktischen,
handlichen Gehäuses zu gehen.
So, Ton funktioniert auch. Derzeit ist noch eine kleine Aktiv-Box
angehängt. Da wird aber noch etwas kleineres gebastelt.
Ich hätte jetzt noch eine Frage zum Steccy-Menü bzw. zur Menü-Navigation
per ZX-Tastatur:
Ich kann zwar das Menü mit dem Menü-Knopf aufrufen und die Optionen des
obersten Menüpunkts (Joystick-Typ Auswahl) mit Druck auf die Tasten
Enter oder Space vorwärts oder rückwärts durchschalten. Ich erreiche
aber mit keiner anderen Taste einen anderen Menüpunkt und auch
wiederholtes Drücken des Menüknopfs hat keinen Effekt. Ich komme auch
nicht mehr aus dem Menü raus.
Was genau mache ich da falsch?
Muß ich zusätzlich zum Menü-Knopf noch mehr Tasten aus der
"Sonderfunktions-Reihe" anschließen?
Hi,
Sorry, Ich hatte leider in der letzten Monaten keine Zeit, um an dem
Projekt weiter zu arbeiten und bin in der Integration eines Touchpanels
hängen geblieben. Dafür hatte ich auch die Sondertastenreihe wieder
abgebaut - ich kann also dein Problem mit der ZXTastatur momentan nicht
nachstellen.
Aber, laut Code und auch laut Erinnerung sind die Pfeiltasten (Hoch,
Runter) für die Navigation in dem Menu zuständig.
BG, Tom
Das klappt bei mir leider nicht. Hab es grade nochmal versucht. Während
die Pfeiltasten im Basic zum Verschieben des Cursors normal
funktionieren, geht im Steccy-Menü leider gar nichts. Auch Beenden mit
BREAK klappt nicht. Das einzige, was funktioniert, ist ein Durchschalten
der Joystick-Optionen, also des obersten Menü-Eintrags mit ENTER und
SPACE. Dabei schaltet eine Taste die Optionen in die eine Richtung durch
und die andere in die entgegengesetzte Richtung.
Ich hatte dann noch den Verdacht, daß es nicht funtionieren könnte, weil
ich in der .ini immer noch PS2 und ZX-Tastatur aktiviert hatte. Aber
auch wenn ich die PS2-Tastatur-Option rausnehme, macht das keinen
Unterschied.
Könnte mir mal bitte einer beschreiben, wie die Prozesskette für die
vollständige Inbetriebnahme aussieht. Ich habe hier BlackBoard STM32F4XX
auf dem Tisch liegen sowie ein zugehöriges Display 3.2 Zoll Display
ILI9341. Selbstverständlich habe ich mir den Forumsartikel „STECCY“
genau durchgelesen, denke ihn auch verstanden zu haben. Doch wie bekomme
ich z.B. die Steccy-ili9341.hex auf das BlackBoard?
Vielen Dank für die Hilfe!
aktuellen STM32CubeProgrammer installieren (unter Windows das Setup als
Administrator ausführen!).
Dann einen Jumper zwischen BT0 und 3V3 stecken und USB anschliessen. Das
Board sollte als 'STM32 Bootloader erscheinen. Hexfilex auswählen,
Download drücken, Jumper raus und neustarten.
habe es auch mal mit dem ILI9341 Display probiert, es bootet aber die
Schrift ist spiegelverkehrt. Dann habe ich das 48u.rom auf die SD Karte
gepackt und eine steccy.ini dazu:
1
ROM=48u.rom
2
AUTOLOAD=yes
3
AUTOLOAD=jswilly.tzx
4
ORIENTATION=1
es erscheint aber immer nur der weisse Bildschirm mit der '1982
Sinclair' Meldung. Die ini wird gelesen, die Schrift ist jetzt richtig
und durch das u ROM (das PA2=TxD und PA3=RxD sind dürfte auch in die
Doku rein) erscheint eine Meldung in PuTTY:
1
Welcome to STECCY
2
SD card mounted, retry count = 0
aber es gibt kein Echo und keine Reaktion auf Eingaben. Eine Tastatur
habe ich noch nicht dran, kann es sein das der Emulator dann hängt?
Johannes S. schrieb:> aktuellen STM32CubeProgrammer installieren...
Danke! hat funktioniert.
Nun habe ich jedoch das gleiche Verhalten, welches du auch beschrieben
hast. Mit dem 48.ROM ist die Schrift spiegelverkehrt und mit dem 48u.ROM
bootet er mit korrekter Darstellung, nimmt jedoch keine Eingaben über
die Konsole an.
habe jetzt eine USB Tastatur angeschlossen (R21 ausgelötet) und mit Tab
wird das Menu angezeigt. Nach dem Load einer TAP/TZX Datei passiert nix,
muss dann noch was gedrückt werden? Ein List Befehl zeigt ein leeres
Programm, Run ebenso nur '0 OK'.
Sind die Dateinamen case sensitive? Die SDC habe ich vorher mit dem
SDFormatter formattiert.
Edit:
habe es in der Anleitung gefunden, nach dem Load muss noch LOAD ""
eingegeben werden.
Joe G. schrieb:> Doch wie bekomme ich z.B. die Steccy-ili9341.hex auf das BlackBoard?
Wie oben beschrieben über den UART-Bootloader oder über die
ISP-Schnittstelle mit einem ST-Link-V2 bzw. Clone für ein paar EUR beim
freundlichen Chinesen.
Johannes S. schrieb:> habe es auch mal mit dem ILI9341 Display probiert, es bootet aber die> Schrift ist spiegelverkehrt.
Dann muss entsprechend der Wert von ORIENTATION in STECCY.INI
eingestellt werden, siehe unten.
Johannes S. schrieb:> Meldung in PuTTY:Welcome to STECCY> SD card mounted, retry count = 0>> aber es gibt kein Echo und keine Reaktion auf Eingaben.
An der seriellen Konsole kann man nichts eingeben, sie dient nur
Debugging-Zwecken (Ausgaben). Vielleicht baue ich da später noch ein
Kommando-Interface ein, mal sehen.
Joe G. schrieb:> Mit dem 48.ROM ist die Schrift spiegelverkehrt und mit dem 48u.ROM> bootet er mit korrekter Darstellung
Das liegt aber nicht an dem ROM. Das ROM ist unabhängig von der
Orientierung. Das 48.ROM ist das Original-Spectrum-ROM, das 48U.ROM ist
das GOSH-Wondferful ROM, wo man die BASIC-Token komplett eintippen muss
statt nur eine Taste in der Sinclair-typischen Eingabe dafür zu
verwenden.
Zurück zur Orientierung:
Wie eben geschrieben: ORIENTATION=1 sollte der richtige Wert für ein
ILI-Display sein.
Im Artikel ist auch beschrieben, wie man den richtigen Wert für
ORIENTATION herausfindet. Man stellt zunächst ORIENTATION=0 ein und
drückt dann nach dem Boot solange die F1-Taste auf der angeschlossenen
PS2- oder USB-Tastatur, bis die Orientierung richtig ist. Die Anzahl der
Tastendrücke von F1 entspricht dann dem Wert für ORIENTATION in
STECCY.INI.
Zitat aus dem Artikel:
Mit der F1-Taste kann man im Betrieb zwischen 4 Orientierungen wählen:
1
0 Flip None (Standard)
2
1 Flip Vertical
3
2 Flip Horizontal
4
3 Flip Vertical + Horizontal
Man kann in der INI-Datei "steccy.ini" die Orientierung speichern. Dazu
zählt man nach dem Start, wie oft man die F1-Taste drücken musste, um
das Bild richtig herum zu sehen.
Diesen Wert trägt man in der INI-Datei als
ORIENTATION=0 # oder 1, 2, 3
ein.
Johannes S. schrieb:> Nach dem Load einer TAP/TZX Datei passiert nix, muss dann noch was> gedrückt werden?
Der Load einer TAP-/TZX-Datei entspricht dem Einlegen der Cassette in
den Cassettenrecorder.
Anschließend gibt man im Spectrum LOAD "" ein. Dann wird das Programm
von der virtuellen Cassette geladen. Wie die Eingabe dazu geht, ist im
Artikel beschrieben.
> Sind die Dateinamen case sensitive?
Diese sollten im 8.3-Format auf der SD abgelegt werden, also max. 8
Zeichen vor dem Punkt und 3 Zeichen nach dem Punkt, z.B. MANIC.TZX. Es
ist egal, ob man das auf dem PC als "manic.tzx" oder als "MANIC.TZX"
speichert, es erscheint immer als "MANIC.TZX".
> habe es in der Anleitung gefunden, nach dem Load muss noch LOAD ""> eingegeben werden.
Prima :-)
Hi,
...habe heute mein ILI9341 bekommen - leider stimmt weder die
Steckerbelegung noch die Anzahl der Pins! :-(
Zudem hat es keine Buchsen- sondern auch eine Steckerleiste! :-(
Kann mir vielleicht jemand eine (günstige) Bezugsquelle für ein 3,2"
oder 5" Display nennen welches sich aufstecken lässt (Äbay od. Ämazon)
oder mir helfen die entsprechenden Signale zuzuorden?
DANKE!!!
Kurz Schluss schrieb:> Kann mir vielleicht jemand eine (günstige) Bezugsquelle für ein 3,2"> oder 5" Display nennen welches sich aufstecken lässt (Äbay od. Ämazon)> oder mir helfen die entsprechenden Signale zuzuorden?
Es ist darauf zu achten, dass in der Artikelbeschreibung auch "für
STM32F407 entwicklung bord" (Übersetzungsfehler "bord" statt board" mit
übernommen) steht.
Unter STECCY: Display habe ich 5 Bezugsquellen angegeben - allerdings
ist das Aliexpress. Auf den Fotos sieht man auch immer eine Buchse statt
Stecker.
Ich habe zuhause noch eins liegen, welches ich gern abgeben kann.
Hallo Frank,
das wäre ja phantastisch wenn Du da eines über hättest!!! Ich habe so
das Gefühl das diese ILI's mittlerweile rarer werden - die Auswahl von
welchen mit herausgeführtem Parallelport sieht man nur noch relativ
selten - mit Buchse hab' ich leider gar keine in der Bucht gefunden...
Wie kann ich Dich kontaktieren?
Derweil schon mal herzlichen Dank für Deine Bemühungen!!!
Kurz Schluss schrieb:> hast Du mir evtl. schon was geschrieben? - hab' noch nichts erhalten...
Tut mir leid, war länger unterwegs. Habe Dir gerade geschrieben.
Hallo Frank,
ich habe das Projekt gerade entdeckt. Ich möchte nach ca. 30 Jahren
Abstinenz mich wieder etwas mit dem ZX Spectrum beschäftigen, baue
gerade einen Harlequin auf.
Mein großes Kompliment und Danke für das Teilen dieses Projekts!
Ich habe mal spontan das SMT32 Board und (erstmal) das kleine Display
bei Ali bestellt.
Könnte mir vorstellen später eine Platine zu machen für STM32 Board und
großes Display um den Verkabelungsaufwand in Grenzen zu halten.. Habe
einige Cortex-M (STM32, LPC, TI) und PCB Layout Erfahrung.
Arduinoquäler schrieb:> Zur Not halt so:>> Beitrag "Re: STM32F407 Black und Arduino"
Hi!
Danke für den Link! ...trotzdem würde ich mir den Fädelverhau gerne
ersparen...
Frank M. schrieb:> Tut mir leid, war länger unterwegs. Habe Dir gerade geschrieben.
Hi Frank,
hast Du meine Mail bekommen die ich Dir geantwortet hab'?
Viele Grüße
Ich melde mich noch mal bezüglich meines Matrix-Tastaturproblems. Habe
jetzt notgedrungen nochmal die PS2-Lösung angeschlossen, um überhaupt
weiter basteln zu können. Dort funktioniert die Tastaturabfrage so, wie
es beschrieben ist und auch das Steccy-Menü läßt sich problemlos
bedienen.
Bei der Matrix habe ich den Fehler jedoch noch immer nicht gefunden. Ich
komme zwar ins Steccy-Menü, aber es reagiert nicht auf die Pfeiltasten
der Matrix. Habe die Tasten mit und ohne Shift und mit Symbol Shift und
beiden Shifts versucht (sowie alle anderen Tasten der Matrix), aber ich
konnte keine Reaktion feststellen. Da im Basic alles (inklusive der
Pfeiltasten meiner Matrix) so funktioniert, wie es soll, nehme ich an,
daß da noch ein Programmfehler drin sein könnte.
Meine nächsten Jobs sind ein kleiner Audio-Verstärker mit
Mini-Lautsprecher statt der Aktivbox und der Wechsel vom inzwischen
katastrophalen Dupont-Buchsen-Jumper-Kabelverhau auf modifizierte
Pfostenbuchsen. Irgendwann soll das ganze ja mal in ein portables
Gehäuse passen...
Nobs schrieb:> Bei der Matrix habe ich den Fehler jedoch noch immer nicht gefunden. Ich> komme zwar ins Steccy-Menü, aber es reagiert nicht auf die Pfeiltasten> der Matrix.
Ich habe mir jetzt bei eBay einen defekten Spectrum für wenig Geld
geschossen und werde diese Tastatur an STECCY anschließen und dann den
Code für die Tastatur-Matrix neu schreiben - stammt ja nicht von mir.
Ich melde mich dann wieder, wenn's läuft.
Danke, das wäre super. Mit dem Rest bin ich einen Schritt weiter
gekommen (schnell geknipstes Bild ist grauenhaft, ich weiß...). Das
Gehäuse ist aus MDF. Die Tastaturfolie ist immer noch vom ZX81, die vom
Spectrum ist ausgedruckt aber immer noch nicht laminiert. Ton
funktioniert jetzt, allerdings nicht mit dem LM386. Der mochte zumindest
mit den Referenz-Beschaltungen aus dem Datenblatt das Signal des Steccy
nicht so wirklich. Aber das ließ sich mit zwei Transistoren statt dessen
zufriedenstellend lösen.
Bei der Verkabelung hab ich noch einige Baustellen. Speziell bei der
Stromversorgung bin ich noch beim Sinclair-System (Stecker ziehen). Aber
immerhin das Display sitzt jetzt bündig. Ich habe nur die Unterteile von
Pfostensteckern auf die Platine gesteckt und die Kabel an die
Schneidkontakte direkt angelötet. Mehr Platz war leider nicht.
Für den Rest warte ich mal wieder auf Teile. Der Menüknopf muß noch
dran, ein Drehknopf fürs Poti fehlt noch, ich wollte mir noch einen 9er
Sub-D für Gamepads nachrüsten und wenn das alles fertig ist, muß ich mal
testen, wie lang das Ding mit der 4000mAh Powerbank unter der Tastatur
läuft.
Nobs schrieb:> schnell geknipstes Bild
Naja, da hast du ja über die Feiertage eifrig gebastelt - und das sogar
mit Holz und dergleichen. Sieht man hier im Forum ja recht selten.
Was mich bei all dem immens stört, ist daß das Ganze auf recht winzige
Displays hinausläuft, oder sehr schnell recht teuer wird, weil Frank nur
Displays mit dem Solomon vorgesehen hat. TFT mit schlichtem
TTL-Interface wären deutlich billiger.
Aber ich hätte da noch nen Tip: als Gehäusematerial einfach ABS nehmen.
Kann man auch leicht zusägen und mit Aceton kleben. Da muß man nicht mit
so vielen Schrauben arbeiten.
W.S.
Neue Version 1.4.5 ist online.
Änderungen:
- ZX-Matrix-Tastatur-Routinen komplett überarbeitet
- Modularisierung und Aufteilung von z80.c in Emulator und I/O-Module
Damit funktioniert die originale ZX-Tastatur nun auch im Menü-Modus.
Nobs schrieb:> Ton funktioniert jetzt, allerdings nicht mit dem LM386. Der mochte> zumindest mit den Referenz-Beschaltungen aus dem Datenblatt das Signal> des Steccy nicht so wirklich. Aber das ließ sich mit zwei Transistoren> statt dessen zufriedenstellend lösen.
Hast Du da mal ein Schaltbild dazu, welches ich im Artikel zur Verfügung
stellen kann? Du kannst - wenn Du willst - das auch direkt selbst in den
STECCY-Artikel einbauen.
Zu der ZX-Matrix-Tastatur: Wie ich oben schrieb, habe ich mir bei eBay
für wenig Geld einen defekten Spectrum geschossen. Dann habe ich die
Innereien rausgeworfen, die gebrochenen Folientastatur-Anschlüsse durch
Kürzen mit der Schere "repariert" und dann an den STM32 angeschlossen.
Dabei stellte ich fest, dass die Implementierung der
Tastatur-Scan-Routine von Tom den Fehler hatte, dass im Basic andere
Tasten ausgelesen wurden als in manchen Spielen. Es lag an einem
fehlendem Delay - es wurde sonst immer der Scan-Code von der
Tastatur-Zeile zurückgegeben, die vorher aktiv war.
Auch weil das STECCY-Menü sich nicht über die ZX-Tastatur bedienen ließ,
habe ich kurzerhand die Matrix-Routinen neu geschrieben.
Fazit: Jetzt funktioniert alles. Allerdings wirst Du die Tastatur-Zeilen
nochmal neu anschließen müssen - die waren nämlich durch Toms Fehler
alle um eins verrutscht.
Siehe dazu auch: STECCY: ZX-Tastatur
W.S. schrieb:> Aber ich hätte da noch nen Tip: als Gehäusematerial einfach ABS nehmen.> Kann man auch leicht zusägen und mit Aceton kleben. Da muß man nicht mit> so vielen Schrauben arbeiten.
In meinem Gehäuse sind bis jetzt nur die Schrauben, welche die
Elektronik-Komponenten befestigen, verbaut. Der Rest ist mit Holzleim
verleimt. Nur die Platte auf der Rückseite wird vier Schrauben bekommen,
damit man sie bei Bedarf öffnen kann. Das ist Stand jetzt leider nötig,
wenn man Dateien auf die SD-Karte kopieren möchte. Vielleicht kann ich
später mal den Slot nach draußen verlegen oder eine kleinere Klappe
hinten einbauen. Der Grund für MDF und Holz war einfach, daß ich das
hier liegen hatte. Kunststoff war schon auch eine Überlegung, hätte ich
aber bestellen müssen.
Frank M. schrieb:> Hast Du da mal ein Schaltbild dazu, welches ich im Artikel zur Verfügung> stellen kann?
Habe ich Stand jetzt nicht, kann ich aber auftreiben.
Frank M. schrieb:> Wie ich oben schrieb, habe ich mir bei eBay> für wenig Geld einen defekten Spectrum geschossen. Dann habe ich die> Innereien rausgeworfen, die gebrochenen Folientastatur-Anschlüsse durch> Kürzen mit der Schere "repariert" und dann an den STM32 angeschlossen.
Erstaunlich, denn immer wenn ich nach Spectrums gesucht habe, sind sogar
defekte Computer für unheimlich viel Geld über den Tisch gewandert.
50-100€ für einen defekten Spectrum, der ohne Kassettenrecorder und
passenden TV ja herzlich wenig bringt, waren mir immer zu viel. Hast du
vor, die defekten "Innereien" zu reparieren oder weiter zu verkaufen?
Frank M. schrieb:> Fazit: Jetzt funktioniert alles. Allerdings wirst Du die Tastatur-Zeilen> nochmal neu anschließen müssen
Prima, ich mache bei nächster Gelegenheit ein Update und schließe die
Tastatur neu an. Leider hab ich die "Dupont"-Phase schon hinter mir,
kann also nicht mehr einfach umstecken. Trotzdem bin ich froh, daß das
Update jetzt kommt. Denn noch ist nicht alles fertig und der "Deckel"
ist noch nicht drauf.
Meine letzten Fortschritte waren die Fertigstellung der
Stromversorgungs-Verkabelung. Der Steccy ist jetzt über den Drehschalter
des Lautstärkepotis einschaltbar (noch zwei Details, die das Original
nicht hatte: Einen Schalter und einen Lautstärkeregler :))und hat eine
Hohlbuchse außen am Gehäuse bekommen, um die Powerbank zu laden. Der
Menü-Knopf ist inzwischen auch eingebaut.
Nobs schrieb:> 50-100€ für einen defekten Spectrum, der ohne Kassettenrecorder und> passenden TV ja herzlich wenig bringt, waren mir immer zu viel.
Es waren 32 EUR + Versand. Netzteil war auch noch dabei. Das fand ich
okay.
> Hast du> vor, die defekten "Innereien" zu reparieren oder weiter zu verkaufen?
Nach dem Screenshot des Verkäufers zu urteilen, auf dem einige schwarze
Klötzchen nach dem Booten zu sehen sind, sind die unteren 16KB des RAMs
defekt. Sonst sieht er eigentlich ganz gut aus.
Das waren die häufigsten Defekte beim ZX-Spectrum: Tastaturfolienbruch
und defektes 16KB RAM. Da nützt es beim ZX-48K auch nichts, dass für die
"obere Hälfte" tatsächlich 64KB RAM aufgesteckt ist, von denen nur eine
Hälfte genutzt wird. Es fehlt schlichtweg die Dekodiereinheit dafür, die
andere Hälfte auch zu nutzen. Vermutlich würde das wegen der ULA sowieso
nicht funktionieren, weil diese die Oberhoheit auf das Screen-RAM in den
unteren 16BK hat.
Vermutlich reicht der Tausch der 8 x 16Kbit RAMs, um ihn wieder zum
Laufen zu bringen. Diese sind aber nicht gesteckt, müssen also
ausgelötet werden. Ersatz gibts heute noch zu kaufen. Ich tue mir das
nicht mehr an, das habe ich seit den 80ern schon hinter mir.
Wenn Du willst, kannst Du die ZX-Spectrum-Platine plus Netzteil haben.
Ich wollte nur eine funktionsfähige Tastatur. ;-)
P.S.
Ich bin gerade dabei, in das Spectrum-Gehäuse ein STM32-Bluepill
reinzubauen, welches die Tastatur-Matrix dekodiert und das ganze als
PS/2-Signal zur Verfügung stellt. So kann ich die Spectrum-Tastatur vom
Display, hinter welchem das STM32407-BackBoard werkelt, über ein
PS/2-Kabel absetzen.
Hab grade die neue Version geflasht. Funktioniert bestens. Lustigerweise
war gar keine Neuverkabelung nötig. Es hat alles auf Anhieb
funktioniert.
Der Schaltplan des Verstärkers ist auch angehängt. R9 und R10 sind in
Wirklichkeit ein Poti mit 5k.
Frank M. schrieb:> Wenn Du willst, kannst Du die ZX-Spectrum-Platine plus Netzteil haben.> Ich wollte nur eine funktionsfähige Tastatur. ;-)
Na klar würde ich die nehmen! Das wäre sicher interessant zum weiter
basteln. Ich selber kann dir keine PN schicken, aber ich kenne jemanden
mit Account, der sich bei dir melden wird.
Nochmals vielen Dank für das super interessante Projekt. Jetzt warte ich
gespannt auf den Steccy 128k ;) .
Der User "Kaktusbombe" hat sich inzwischen per PN wegen der Platine und
dem Netzteil bei dir gemeldet. Das ist derjenige mit dem Account, an den
ich mich gewandt habe. Er hat mir auch die .hex-Dateien geflasht und
jede Menge Unterstützung bei diversen Problemchen geliefert. Auch die
Verstärker-Schaltung ist von ihm.
Ich habe jetzt mal noch ein Bild des chaotischen "Innenlebens"
angehängt, sowie eines der fast fertigen Vorderseite. Jetzt muß ich nur
noch die Spectrum-Tastaturfolie und das Logo endlich laminieren, dann
bin ich fertig.
Dabei verschwinden dann auch die beiden häßlichen, weißen Streifen ober-
und unterhalb der Tastatur.
K. B. schrieb:> Verstärker-Schaltung ist von ihm.
... nicht sehr clever!
Da fehlen zwei Dioden zwischen den Basisanschlüssen, damit die
BE-Threshold Spannung kompensiert wird und es weniger Verzerrung gibt.
kannAllesBesser! schrieb:> ... nicht sehr clever!> Da fehlen zwei Dioden zwischen den Basisanschlüssen, damit die> BE-Threshold Spannung kompensiert wird und es weniger Verzerrung gibt.
Bild bitte.
Frank M. schrieb:> Bild bitte.
Wozu?
Das weiß man doch!
Q2 und Q3 haben bekanntlich jeweils eine BE-Flußspannung so im Bereich
von etwa 0.5V und die Verstärkerschaltung hat keine Gegenkopplung, wie
man sieht.
Also gibt es immer eine Lücke, wo beide Transistoren nicht leitend sind.
Und um diese Lücke zu verringern, fügt man zwischen R6 und R7 irgend
etwas ein, das diese Lücke verringert. Zum Bepiel besagte zwei Dioden in
Flußrichtung. Man muß bloß aufpassen, daß deren Gesamtflußspannung nicht
größer ist als die der zwei Transistoren, sonst geht der
Ruhestromverbrauch in die Höhe.
Eigentlich sollte all dieses zum Grundwissen eines jeden Elektronikers
gehören.
W.S.
W.S. schrieb:> Wozu?
Weil ich das Bild dann in den Artikel stellen möchte.
> Das weiß man doch!
Was hat das damit zu tun, dass ich ein Schaltbild in den Artikel stellen
möchte, wie ich hier
Beitrag "Re: STECCY - ZX-Spectrum-Emulator mit STM32"
bereits schrieb?
> Eigentlich sollte all dieses zum Grundwissen eines jeden Elektronikers gehören.
Soll ich einfach in den Artikel schreiben, dass das sowieso jeder weiß
und sich jeder selbst ein Schaltbild im Kopf pinseln soll? Den Artikel
lesen nicht nur Elektroniker!
Ja, ich kenne Deine Antwort schon: "Mals doch selber!". Nö, ich habe
hier in dieses Projekt schon die meiste Zeit reingesteckt, da kann auch
mal ein Leser hier etwas beisteuern, und zwar auch mal ein Schaltbild
und nicht nur eine neunmalkluge Antwort.
Frank M. schrieb:> Weil ich das Bild dann in den Artikel stellen möchte.
Und das soll ich aus deiner höchst umfänglichen Bemerkung "Bild bitte"
entnehmen?
Aber ich bin ja nicht so....
W.S.
W.S. schrieb:> Aber ich bin ja nicht so....
Super, vielen Dank! Welche Dioden würdest Du hier empfehlen?
Ich habe hier https://www.elektronik-kompendium.de/sites/slt/0205141.htm
eine etwas andere Variante gefunden, siehe Bild.
Was ist der Vorteil der beiden Dioden oberhalb des Signals (Deine
Variante) gegenüber der symmetrischen Anordnung der Dioden hier im Bild
- abgesehen von der Kapzität und dem Drehpoti am Eingang?
Da der Steccy sowieso nur High- und Low-Pegel (also 3,3 V und 0 V) an
dem Pin anbietet, war mir das Risiko auf Verzerrungen im Übergang
relativ egal. Eine von Bachs klassischen Overtüren wird man mit den
Bordmitteln des Spectrums sowieso kaum hinbekommen. Insofern war das als
reine Impedanzwandlung für Rechecksignale gedacht.
Außerdem war das Verhalten genau im Sinne des Erfinders: Der oben
gezeigte Steccy-Aufbau wird durch einen Schalterkontakt am
Lautstärkepoti ein- und ausgeschaltet. Und so ist der Ton bei minimaler
Potieinstellung immernoch komplett aus und braucht auch keinen Strom.
Frank M. schrieb:> Was ist der Vorteil der beiden Dioden oberhalb des Signals
Daß ich das ohne Neuzeichnen der Schaltung dort per mspaint
hineinzeichnen konnte.
Obendrein könnte man eine BAR43S nehmen, spart ein Bauteil und die
Flußspannung ist auch nicht zu groß - das kommt auf den Querstrom an.
Die 330mV im Datenblatt sind übrigens gelogen, die Diode hat schon bei
1..2 mA mehr als 450 mV.
W.S.
Bitte um Hilfe bei der Steccy Inbetriebnahme.
Ich versuche Steccy nachzubauen,
doch das Display bleibt dunkel. Es ist nichts zu sehen auf dem Display,
und auch keine Hintergrundbeleuchtung. 5V an pin 35 liegen an.
Ich habe die letzte Software Version geflasht. (version_1_4_5)
Auf der CF-Karte habe ich nur die Datei 48.rom kopiert. (Karte mit FAT32
schnellformatiert)
Nach dem Reset kann ich mit scope an der CF-Karte Signalle messen.
Auch an dem Display Pins sehe ich Digitale Signale nach dem Reset, (die
erst mal vernünftig aussehen. Pegeln,Flanken)
Das display habe ich wie in der Tabelle „Anschluss TFT“ im steccy
Artikel angeschlossen.
Mit Ohm Meter habe ich jede Leitung kontrolliert. (Gemessen von pcb
Display zu PCB STM32 board)
Das display hat einen pin LED_A - Pin 37. Muss dieser Pin irgendwo
angeschlossen?
Wird die Display Hintergrundbeleuchtung vom STM32 eingeschaltet ?
Oder sollte die Hintergrundbeleuchtung schon nach dem anlegen der 5V an
sein?
Sollte das Display auch was ohne CF-Karte anzeigen?
Danke im Voraus
Gruß,
Jan
Jan schrieb:> Das display hat einen pin LED_A - Pin 37. Muss dieser Pin irgendwo> angeschlossen?> Wird die Display Hintergrundbeleuchtung vom STM32 eingeschaltet ?> Oder sollte die Hintergrundbeleuchtung schon nach dem anlegen der 5V an> sein?
LED_A ist für die Hintergrundbeleuchtung, muss also angeschlossen
werden.