Propeller-Tiny
U. Nickel hat den TINY 2009 4K komplett in einem Propeller-Chip P8X32 emuliert. Damit wird die Hardware noch einfacher, außerdem gibt es modernen Komfort wie SD-Karten-Speicher (FAT32), VGA-Anschluss, PS/2-Tastatur. Ich bin begeistert!
LP Version von OE4DEA, mein Exemplar. Die Buchsen fürs 5V USB-Netzteil und für die PS/2-Tastatur sind etwas ungewöhnlich, aber mit entsprechenden Kabeln und Adaptern kein Problem. Auf der SD-Karte ist mein angepasstes System TINY4K.SYS drauf, was dann startet. Die Bildschirmfarben gelb auf blau sind im Propeller-Grafiktreiber so eingestellt, der orig. Tiny ist natürlich nur schwarz-weiß.
Downloads
- tiny4k_beta21.zip Version 13.09.2012 2.0Beta (aus HIVE-Forum), Propeller-Quellen, Schaltplan, Doku
- proptyiny_vp.zip modifizierte Version 2024 V.Pohlers inkl. EPROM.bin, Programmen, Src, Dokus
Links
- Thread im HIVE-Forum: http://hive-project.de/board/viewtopic.php?f=24&t=554
- Thread im Robotrontechnik-Forum: http://robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=9022
- Download Version 13.09.2012 http://www.file-upload.net/download-6894494/tiny4k_beta20.zip.html
4k-TINY-Emulator auf Propellerchip (Version V2.0ß)
Kurzbeschreibung
Auf einem Propellerchip wird der TINY in der 4k-Systemversion z.Z. (Arbeitsstand 01.07.2012) möglichst vollständig so emuliert, dass die Ausführung der vorhandenen Software in Form von BASIC und MC-Programmen erfolgen kann, sowie die eingebauten Menus PROG, DATA, BASIC,SAVE,LOAD auch zum Erstellen eigener Programme nutzbar sind. Erreicht wird in etwa die Originalgeschwindigkeit des TINY.
Der TINY-ROM, sowie der interne BASIC-ROM des UB8830 sind geringfügig an die realen Hardwarebedigungen angepasst. Insbesondere die SAVE- und LOAD-Routine wurde verändert, da als Speichermedium hier eine SD-Karte, nicht mehr Tonband benutzt wird.
Beim Laden wird deshalb der Dateiname als Eingabe abgefragt, ebenso die Ladeadresse, die als Standardwert aber aus der Datei als Vorschlag angezeigt wird.
Als zusätzliche Befehle, jedoch ohne Darstellung als Menueintrag sind integriert: D-Directory, X-Delete File, C –Call Hexadresse.
Das “Standard-Rom” wird bei Start des Propeller als Grundsystem automatisch initialisiert, steht also immer zur Verfügung. Wird jedoch auf der SD-Karte eine Datei namens „TINY4K.SYS“ bei Start des Emulators gefunden, so wird diese anstelle des „eingebauten“ ROM-Bereiches geladen.
Es wurden weitere Steuertasten(kombinationen) in den Emulator integriert, die den Bedienkomfort erhöhen:
ALT-GR + F12 | Reboot Propeller |
SHIFT + F12 | Reset TINY, Raminhalt (also ggf geladene Software) bleibt erhalten |
F12 | WAIT, bringt den Z8 in einen Wartezustand, bzw. startet Z8 |
SHIFT + F10 | Aus-/einschalten Interrupsystem |
F10 | Aus-/einschalten IRQ4 des Z8 (im original Bildschirminterrupt) |
Bildschirmausgabe erfolgt über VGA. Bei mir findet ein TFT-Flachbildschirm Verwendung, Analog-Röhren-Monitorausgabe ist ebenfalls mit den mir noch zur Verfügung stehenden Monitoren erfolgreich getestet.
Erweiterung 2024
- Code reassembliert
- Startmenü umgebaut, so dass die neuen Befehle angezeigt werden
- die Basic-Erweiterung 2k auf 1C00h eingebunden
- div. Dokumentationen ergänzt
- div. Programme ergänzt
Besonderheit der Registerverwendung von R0, R1 des Z8 in der Emulation
In der Originalhardware repräsentiert R0 bzw. R1 den Port0/1 des Z8, der im Tiny in der Funktion des Daten-/Adressbusses zur Speicheransteuerung genutzt wird. Bei der Emulation vom ROM bzw. RAM im internen Speicher des Propellers spielen Ein- bzw. Ausgaben über diese Ports bzw. Register keine Rolle. Andererseits kann bei bestehender TINY-Software auch nicht auf diese Register in der originalen Hardware zugegriffen worden sein, eben wegen der o.g. Verwendung der zugehörigen Portleitungen als Busleitungen Damit ergab sich die Möglichkeit sie als Übergaberegister für Kommandos bzw. Daten vom TINY-System an die Propellerumgebung zu nutzen. Davon wird wie folgt Gebrauch gemacht:
R0 | Kommandoregister, beschreiben des Registers mit einem Wert führt zur Ausführung eines, dem Wert zugeordneten Kommandos, Beschreibung der Kommandos s.u. |
R1 | Datenregister, eingeschriebener Wert wird bei Kommandoausführung (ausgelöst durch Beschreiben von R0) als Parameter mit übergeben. Bei bestimmten Kommandos wird in diesem Register ein Rückgabewert geliefert (z.B. Fehlercode bei SD-Card-Routinen). |
Kommandobeschreibungen
$00 | grafischer TINY-Bildschirmspeicher in den Bitmapspeicher bringen, incl. notwendiger Umrechnungen. Keine Parameterübergabe, kein Rückgabewert. Wird nach jeder anderen Kommandoausgabe wieder als Standard gesetzt. |
$10 | SD-Card starten (mounten), kein Parameter, Fehlernummer als Rückgabewert. |
$11 | Datei speichern, kein Parameter, Fehlernummer als Rückgabewert. Dateiname, Start- und Endadresse sind im ehemaligen „Kassetenpufferspeicher“ ($FC00) vorher abzulegen. |
$12 | Datei-Header einlesen in Puffer ab $FC00, kein Parameter, Fehlernummer als Rückgabewert, Einzulesender Dateiname wird in Puffer übergeben, am Ende steht im Puffer der Dateiname, sowie – wenn Datei vorhanden – Start- und Endadresse. |
$13 | Dateiinhalt laden, kein Parameter, Fehlernummer als Rückgabewert. Geladen wird an die im Puffer stehende die Start- und Endadresse |
$14 | Directory laden, kein Parameter, Fehlernummer als Rückgabewert, |
$15 | Datei löschen, kein Parameter, Fehlernummer als Rückgabewert, Gelöscht wird die Datei, deren Name im Puffer steht. |
$1C | Modus der seriellen Schnittstelle einstellen, Modus steht als Parameter in R1. Aufbau des Modusbytes siehe tiny_4k_def.spin |
$1D | Baudrate Faktor 1, Faktor wird als Parameter in R1 übergeben |
$1E | Baudrate Faktor 2, Faktor wird als Parameter in R1 übergeben und Baudrate berechnet nach der Formel: Fakor1 x Faktor2 x 10, Rückgabe $FF in R1 |
$1F | SD-Card stoppen und seriellen Treiber starten mit Modus- und Baudratenübergabe. Fehlernummer SD-Card ist Rückgabewert in R1 |
$24 | Bitmapspeicher beschreiben mit $00, kein Parameter, kein Rückgabewert, |
$25 | Bitmapspeicher beschreiben mit 4-Byte-Muster, kein Rückgabewert, Parameter ist die gerade Registernummer des Z8-Registers, ab dem in 4 aufeinanderfolgenden Registern das Muster gespeichert ist, |
$26 | Bitmapspeicher negiert darstellen, kein Parameter, kein Rückgabewert, |
$27 | Bitmapspeicher auf originale Darstellung schalten, kein Parameter, kein Rückgabewert, |
$28 | Bildschirmblinken 1, kein Parameter, kein Rückgabewert, |
$29 | Bildschirmblinken 2, kein Parameter, kein Rückgabewert, Blinkfarben, Dauer und Anzahl ist in der def-Datei festgelegt, bei Blinkende wird zur aktuellen Farbkombination zurückgekehrt, Blinken erfolgt toggeln zwischen Blinkfarbe und Standardfarbe |
$2C | Standardfarben entspr. Def-Datei setzen, kein Parameter, kein Rückgabewert |
$2D | Hintergrundfarbe übergeben, Parameter ist Farbe, kein Rückgabewert |
$2E | Vordergrundfarbe übergeben, Parameter ist Farbe, kein Rückgabewert |
$2F | Farbkombination setzen, kein Parameter, kein Rückgabewert |
Weitere Kommandos sind im Rahmen des noch zur Verfügung stehenden Speicherplatzes des Prop denkbar und möglich. Die Abfrageroutinen dazu sind zu finden in „calc-z8emu“ (Assembler) bzw. im Hauptobjekt als Spin-Schleife. An diese Stellen wäre dann der entsprechende Programmkode einzubinden.
Besonderheiten der seriellen Schnittstelle gegenüber der Originalhardware
Die SIO im Z8-Original bezieht ihren Takt vom Timer T0 und wird nur dann aktiv, wenn durch entsprechende Programmierung des Registers P3M das Leitungspaar P31/37 als SIO Ein/Ausgang eingestellt wurde. Sie hat praktisch nur einen 1 Byte Lese/Schreibpuffer. Das Schreib-/Lesereister ist Register $F0. Nach erfolgter Ausgabe eines Bytes bzw. Empfang eines Bytes wird erfolgt eine Interruptanmeldung. Es kann ohne bzw. mit (ungerader) Parität mit jeweils gleicher Baudrate für Senden und Empfang gearbeitet werden.
Die Emulation unterscheidet sich in diesen Punkten erheblich. Erstens arbeitet die serielle Ausgabe unabhängig von T0 und damit von der vorherigen Programmierung des Timers.
Für die eigentliche serielle Steuerung wird nämlich ein eigener COG des Propeller verwendet, der also vollkommen asynchron gegenüber der restlichen Emulation Daten senden bzw. empfangen kann und so auch sein eigenes Timing zur Baudratenfestlegung erzeugt.. Die Ablage der Daten erfolgt in einem eigenen Puffer der im COG-Ram lokalisiert ist. Die Puffergröße ist im Rahmen des zur Verfügung stehenden COG-Rams in der def-Datei festlegbar. Ebenso werden dort die Standardbaudrate, sowie der Arbeitsmode festgelegt. Diese Werte können zur Laufzeit des Emulators durch entspredchende Kommandos (s. oben) aber geändert werden. Auf die Paritätserkennung wurde verzichtet, dafür jedoch schon erwähnte Arbeitsmodes integriert. So kann mit bzw. ohne Hardwarehandshake (DTR/CTS) gearbeitet werden und die Polarität der Signale (H/L-Aktiv) eingestellt werden. Als Handshakesignale fungieren P24/P25 des Prop. Es wird stets mit gleicher Baudrate gesendet und empfangen.
Der serielle Eingang bzw. Ausgang ist identisch mit den zur Programmierung des Propeller verwendeten Portleitungen P30,P31.
Unabhängig der Einstellungen in P3M erfolgen immer folgende Abläufe:
Bei Empfang eines Bytes gelangt dieses in den Empfangspuffer des benutzten Cog, und wird, wenn das Z8-Empfangsregister $F0 zuvor bereits gelesen wurde, dorthin weitergereicht. Ein Beschreiben des Registers $F0 führt umgekehrt zur umgehenden Weitergabe an den Sendepuffer des COG.
Wird in P3M SIO-Betrieb vereinbart, so erfolgt zusätzlich zu o.g. Vorgängen entsprechende Anmeldung von Interrupts.
Zusammenfassung der Details der Emulation
- TINY-ROM von 0000h – 27FFh durchgängig
- RAM-Bereich von E000h – FFFFh
- Tastatureingaben von PC-Tastatur werden in „originale“ Tastaturmatrixbelegungen umgesetzt. (z.Z. sind noch nicht alle Tastenbelegungen umgesetzt)
- Soundausgabe/ Timerausgabe über Portpin des Propellerchip (P7)
- Emulation des Port2 des Z8/TINY über P8…P15 des Propeller incl. Handshake
- Original IRQ4-Bildschirmroutine wird nicht benutzt.
- Datenspeichermedium ist SD-Card, Fat-Dateisystem, keine Unterverzeichnisse; 8.3-Dateinamen (Großbuchstaben)
- Serielle Ausgabe, erfolgt über die Portpins, die gleichzeitig zum Programmieren des Propeller benutzt werden. Die Z8-SIO wird dabei nicht emuliert, es wird auf einen separaten Treiber zurückgegriffen, der einen E/A-Puffer besitzt. Standardeinstellungen in der def-Datei.
- Keine Paritätserkennung!
- Interruptsystem ist implementiert, jedoch ohne Prioritätssteuerung (Register IPR).
Die einzelnen Cog’s haben folgende Aufgaben:
Cog 0 : „Startcog“, startet alle anderen Funktions-Cogs, dient dann auch zur Kommunikation(Befehlsaustauch) der Cogs untereinander. Startet bei Bedarf SD-Cog zwecks SD-Routinen
Cog 1 : „VGA-Cog“, Treiber für VGA-Ausgabe, gibt Bitmap-Speicher auf Monitor aus.
Cog 2 : „Berechnung-Cog“, liest emulierten TINY-Bildwiederholspeicher, rechnet ihn nach Bitmap-Darstellung um. Kann auch für weitere Bildschirmorientierte Aktionen (Farben etc.) über spezielle Kommandos benutzt werden
Cog 3 : „Keyb-Cog“, Treiber für PS2-Tastatur und Emulation Tastendruck der TINY-Tastaturmatrix., sowie Steuertastenfunktionen.
Cog 4 : „RS232-Cog“, Treiber für serielle Ausgabe, Zeichenpuffer im Cog-Ram.
Cog 5 : „INT-I/O-Cog“, steuert die Emulation der physischen Ansteuerung der Portpins des Propellers für P2-Emulation, serielle Schnittstelle etc. Interruptsystem
Cog 6 : „Timer-Cog“, emuliert T0 und T1 des Z8
Cog 7 : „Z8-Core-Cog“, emuliert, z.T. unter Verwendung von LMM, d.h. Nutzung des HubRam als Programmspeicher den Z8 und dient der Ansteuerung des virtuellen ROM/RAM-Bereiches des TINY
Cog 8 : „SD-Cog“, wird bei Bedarf gestartet, wenn SD-Card-Kommunikation stattfinden soll.
Der komplette Registersatz des Z8 (00..FFh) liegt ebenso im Hub-Ram des Propellers, wie der emulierte ROM-/RAM-Bereich und die virtuellen Tastaturmatrixzellen.
Dateiformat der SD-Kartenspeicherung
Abspeicherung und Laden von SD-Card erfolgt mittels SAVE/LOAD menugesteuert. Das Dateiformat entspricht dem „*.jtc“ –Formats des PC-Emulators von J. Müller. und besteht aus einem 80h-Byte großen Vorblock, der mit dem Dateinamen beginnt. Hier ist auch momentan der Unterschied zum jtc-Original:
Dort muss der Name stehen, unter dem das Programm gespeichert ist und zwar in der Form 8.3 und in Großbuchstaben. Bei Beachtung dieser Regel ist somit mittels Hexeditor auf dem PC eine jtc-Datei problemlos anpassbar.
Hardwarevoraussetzungen seitens Parallax-Propellerhardware
Es wird nur eine Minimal-Hardware-Umgebung für den Propellerchip benutzt, d.h. ein (selbstgebautes) Parallax-Demoboard. Dies ist ergänzt um einen SD-Cardanschluss zur Datenspeicherung/Laden von Programmen. Benutzt werden dazu die Portpins 0-3.
Anpassung an andere Anschlussbelegungen (Hydra etc.) ist möglich und erfolgt durch ersetzen der entsprechenden Einträge in der Datei „tiny_4k_def.spin“
Installation
Die zip-Datei wird in ein Verzeichnis auf dem PC entpackt, im Ordner SDCard sind einige Beispielprogramme, die auf SD kopiert werden können. Nach Start der Propeller- IDE, ich verwende das Original von Parallax, nicht BST(geht aber genauso), wird die Datei „tiny_4k_beta20.spin“ aufgerufen, gegebenenfalls in „tiny_4k_def.spin“ die für die individuelle Hardwarebasis notwendigen Anpassungen vorgenommen, und dann wie üblich in den EEPROM des Propellersystems geflasht.
Uwe Nickel u.nickel@lycos.com
Hinweise aus dem Hive-Forum
Reboot funktioniert über „Alt-GR und F12“.
Kommt beim Starten Error 16 und wird „ES 1988“ angezeigt, wird die SD-Karte nicht (richtig) gelesen. ES 1988 ist das OS, das sozusagen immer in den virtuellen ROM geladen wird, wenn der Prop startet (im Code mit drinne). Auf des SD-Card sollte eine Dqtei namens TINY4K.SYS sein. Wenn SD funktioniert, wird die als OS geladen und überschreibt das „interne“ ROM. Ist momentan funktionell das gleiche, halt nur Jahreszahl auf 2012 geändert zwecks Unterscheidung.
Habe versucht STEINE.BAS von SD-Karte zu laden. Nach Eingabe des Programmnamens und drücken der Enter-Taste erscheint E000 FBFF unter dem Namen (Ist wohl der belegte Speicherbereich). Der Kursor steht auf E. Wie kann man nun das Programm starten, wenn es denn überhaupt im Speicher steht. Mit Eingabe von + (RUN) Enter passiert nichts außer daß der Kursor auf die nächste Ziffer springt. Was hab ich nicht gesehen?
Deine Vermutung bzgl. der angezeigten Zahlen ist richtig. Es sind die Speicheradressen auf die geladen werden soll.(Anfang und Ende). Der Cursor steht nun auf der Anfangsadress und man könnte jetzt eine andere eingeben, falls man es möchte, was zb bei Auto.bas wenig Sinn machen würde, es ist ein Basic-PGM. Du musst also einfach nur Enter drücken und Laden beginnt. Wenn das Programm geladen ist, drückst du „B“ und kommst ins Basic. „+“ startet, „-“ listet das Programm. Auf der Original-Tastatur des TINY sind diese Tasten gleichzeitig mit den Funktionen belegt. Nach „+“ müsste das Autorennen starten. Mit Umschalt+F12, also Reset des TINY, beendest Du. Die Bewegungstasten beim Spiel sind nicht die Cursortasten auf der PC-Tastatur!! Es ist X und Y für rechts/links.
Bei Maschinenprogrammen, also ich sag ma alles außer *.bas lädst du genauso, tippst dann „C“ (wie Call). Dann blinkt der Cursor rechts unten und du gibst die Startadresse als Hexzahl ein plus Enter und dann macht er los. Auf Volkers Homepage findest Du auch noch viele weitere Programme im jtc-Format. Um sie lauffähig zu machen seitens des Dateiformats geht man folgendermaßen vor:
Eigentlich ist das Format, das ich verwende, identisch mit jtc: 80h -Kopfblock, in dem Name und Adressen abgelegt sind, rest Nullen, und dann die eigentlichen Daten, aber bei *.jtc muss bzw. ist der Dateiname nicht identisch mit dem Namen im Kopfblock. Bei mir muss das momentan noch so sein. Deshalb lädt man die Datei in einen bel. Hexeditor und setzt den „internen“ Namen in der Form 8.3 in Großbuchstaben und speichert da dann unter dem gleichen Namen auch in Groß ab. Dann rauf ne SD und es geht.Beim Abspeichern eines Programmes vom TINY-Emu passiert das automatisch.