Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Z8 (U883 u.ä.) als Softcore » Themenansicht

Autor

Thread - Seiten: -1-

000
21.01.2024, 14:03 Uhr
jute-tom

Nachdem ich mit einem Tang Nano 9k etwas rumgespielt habe, versuche ich Verilog zu lernen.

Seit ein paar Wochen versuche ich, einen Z8-Prozessor als Softcore nachzubauen. Wen es interessiert: https://github.com/tmssngr/fpga/tree/main/cpu4

Wer kennt sich mit FPGA-Programmierung aus und könnte (später) Tipps geben, wie etwas hardware-sparender umgesetzt werden kann?

Wer kennt sich mit technichen Details zu den Z8-Prozessoren aus, die über das was in Kieser/Bankel steht, hinausgeht? Es wäre bspw. hilfreich zu wissen, wie genau die Zyklenangaben der Befehle zu verstehen sind. Bei vielen 2-Byte-Befehlen steht 6+5 Zyklen. Heißt das, dass mit den 6 Zyklen diese gemeint sind, um die 2-Bytes zu laden? Die 5 restlichen Zyklen laufen dann ab, wenn der nächste Befehl schon geholt wird?
Wie sieht es dann beim Kommando DA (decimal adjust, 40 und 41) aus, der mit 8+5 Zyklen angeben ist. Wenn je 3 Zyklen zum Laden der 2 Bytes erforderlich sind, was ist dann während der 2 zusätzlichen Zyklen am Bus los?
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
21.01.2024, 16:04 Uhr
volkerp
Default Group and Edit

https://hackaday.com/2014/03/01/design-your-own-processor-with-verilog/

Vielleicht wirst du hier fündig?
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
21.01.2024, 18:09 Uhr
jute-tom

Das kenn ich schon, ist aber unpassend. Es ist relativ einfach, eine eigene ISA (Instruction Set Architecure) zu entwickeln. Beim Nachbau eines bestehenden Prozessors ist man da halt an die Instruktionen gebunden, die der Prozessor umsetzen soll.

Einen Z8-Nachfolger habe ich unter https://github.com/fabiopjve/VHDL/tree/master/FPz8 gefunden, allerdings in VHDL, nicht Verilog. Einen Z80 kann man hier finden: https://github.com/Time0o/z80-verilog
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
21.01.2024, 23:03 Uhr
Bert

Bei Verilog bin ich raus, das kann ich nur mit Mühe lesen.
VHDL dagegen ist nach Englisch meine zweite Fremdsprache...

Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
27.01.2024, 12:49 Uhr
jute-tom

Hurra! Das erste Mini-Programm (Lauflicht an Port 2) läuft auf dem Soft-Z8.

Anfangs hatte ich nur mit YoSYS gearbeitet und getestet. Leider konnte ich damit allerdings nicht bauen - an die genaue Fehlermeldung erinnere ich mich nicht mehr. Dann hab ich die (kostenfreie) GoWin-IDE genommen und diese hat bessere Fehlermeldungen geliefert, sodass ich die Warnungen beheben konnte.

Das Projekt ist jetzt unter https://github.com/tmssngr/z8verilog zu finden.
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
08.02.2024, 21:57 Uhr
jute-tom

Hat jemand eine Idee, ob Jump/Call/Ret-Befehle z.B. auch deshalb viele Zyklen brauchen, weil sie die Pipeline leeren müssen, also evtl bereits geladene weitere Bytes nicht verwenden können?
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
08.02.2024, 22:39 Uhr
Bert

Das wäre gut vorstellbar. Wobei es ja eigentlich nur bei bedingten Verzweigungen ungewiss ist, wohin die Reise geht.

Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
09.02.2024, 14:35 Uhr
jute-tom

Das exakte Umsetzen der Taktzyklen scheint fast aufwändiger zu sein als die Umsetzung aller Kommandos (bereits erledigt).

Vor allem bleibt mir weiterhin unklar, wie die Zyklen genau zu zählen sind. Beispiel:
Ein "nop" ist mit 6 "Ausführungszyklen" und 0 Pipelinezyklen angegeben. Er braucht also 3 Zyklen, um 3 Byte zu lesen, für 1-Byte-Befehle liest er offenbar sinnloserweise auch das Folgebyte, ergibt die erwähnten 6 Zyklen.

Ein "add r, r" ist mit 6 "Ausführungszyklen" und 5 Pipelinezyklen angegeben. Sind da die 2*6 Zyklen zum Lesen der 2 Byte gemeint, während die 5 Pipelinezyklen das Kommando dann abarbeiten? Angenommen, nach "add r,r" folgt "adc r,r" würden nacheinander erfolgen, dann würde er
- 3 Zyklen zum Lesen des ersten Bytes von "add r,r"
- 3 Zyklen zum Lesen des zweiten Bytes von "add r,r"
- 3 Zyklen zum Lesen des ersten Bytes von "adc r,r"; nebenbei startet er mit der Abarbeitung von "add r,r"
- 3 Zyklen zum Lesen des zweiten Bytes von "adc r,r"; nebenbei wurde "add r, r" bereits ausgeführt und das Ergebnis im entsprechend Register gespeichert
- während er das erste Byte des Folgebefehls liest, beginnt er mit der Abarbeitung von "adc r, r"
Das klingt also plausibel.

Ein "incw R" ist dagegen mit 10 "Ausführungszyklen" und 5 Pipelinezyklen angegeben. Hier wird es schon tricky (Annahme, ein "ld r, #IM" folgt). Hier meine Interpretation/Idee:
- das Kommando braucht 15 Zyklen, wovon 2*3 auf das Lesen der beiden Bytes entfallen:
- 3 Zyklen zum Lesen des ersten Bytes von "incw R"
- 3 Zyklen zum Lesen des zweiten Bytes von "incw R"
- er startet mit der Abarbeitung des Befehls
- nach 10 Zyklen, also 10-3-3=4 Abarbeitszyklen, beginnt er mit dem Lesen des ersten Bytes von dem Folgebefehl "ld r, #IM"
Sehe ich das richtig?
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
09.02.2024, 14:52 Uhr
jute-tom

Gehe ich also recht in der Annahme, dass bswp. das "incw R"-Kommando also nicht mit dem Lesen der nächsten Bytes bereits unmittelbar nach dem Lesen seiner eigenen beiden Bytes beginnt, sondern erst "rechtzeitig" bevor es mit seiner Abarbeitung fertig ist?
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
09.02.2024, 18:49 Uhr
Bert

Ich hab mal zwei Bilder aus dem EMR-Buch (Borman/Rentsch) hier eingestellt.
Die kennst Du vermutlich schon.

M.E. kann das Pipelining nur funktionieren, wenn die Ergebnisse einer Operation nicht auf den externen Bus geschrieben werden sondern in den internen Registern landen.

Im zweiten Bild gibt ja plötzlich noch einen M3-Zyklus, den es im ersten Bild nicht gibt.

Im um001604-0108 von Zilog findet sich der folgende Satz:

Zitat:

For those instructions that require execution time
longer than that of the overlapped fetch, or reference program or data memory as part of
their execution, the pipe must be flushed.

Dort ist auch zu sehen, das Pipelining nur bei 1-Byte-Befehlen genutzt wird.
Bei 2-Byte-Befehlen wird in M1 und M2 gelesen und bei 3-Byte-Befehlen in M1, M2 und M3.

NOP dient u.a. zum Leeren der Pipeline und wird vor STOP bzw. HALT benötigt.

Vermutlich wirst Du bei solchen Fragen in englischsprachigen Foren eher eine brauchbare Antwort erhalten (Usenet? eevblog?).

Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
17.02.2024, 17:21 Uhr
jute-tom

Die Simulation scheint schon ganz halbwegs zu funktionieren:

Leider bekomme ich noch nichts auf dem Display zu sehen.
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
17.02.2024, 18:27 Uhr
jute-tom

Ich bin ein Trottel - in der Gowin-IDE wurde eine andere ROM-Datei herangezogen als bei der Simulation. Jetzt sehe ich etwas:

Ist noch nicht perfekt, aber ein riesiger Fortschritt!
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
18.02.2024, 10:04 Uhr
Bert

Das sieht doch schon recht brauchbar aus

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
18.02.2024, 10:43 Uhr
ralle

Sogar mit den gleichen Fehler wie beim Original.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
18.02.2024, 12:03 Uhr
jute-tom

So, die gröbsten, optischen Fehler sind beseitigt:

Und das ist der 15 EUR-FPGA, auf dem das Ganze läuft:

Jetzt bleibt noch, eine Tastatur anzuschließen...
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
18.02.2024, 12:07 Uhr
HeikoS

Hallo Thomas,

eine tolle Arbeit - Glückwunsch ! Der Tiny lebt ! Habe Dir einen Stern im Repo gespendet. :-)

Viele Grüße,
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
18.02.2024, 12:10 Uhr
jute-tom

BTW, das Videosignal wird aus nur 2 Widerständen gemischt, wie in Antwort 014 in https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=21691 beschrieben.

Danke, mein erster Stern!

Laut Gowin-IDE sind nur 46% der FPGA-Ressourcen benutzt. Da würde also noch mehr gehen.
--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 18.02.2024 um 12:14 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
18.02.2024, 12:17 Uhr
HeikoS

Alles was funktioniert ist gut ! Ob nun altbewährte Lösungen, die zigmal erfolgreich nachgebaut wurden oder auch mal neue Ideen. Wichtig ist der Spaß am Hobby !

Viele Grüße,
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
06.04.2024, 10:50 Uhr
jute-tom

Es ging die letzten Tage etwas weiter. Nun kann ich mit 6 Widerständen (als Spannungsteiler, vielleicht würden mit internen Pullups auch nur 4 reichen) auch noch den 2k-Ju+Te mit einer älteren PS/2-Tastatur bedienen.

--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 06.04.2024 um 10:50 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

019
09.04.2024, 07:48 Uhr
jute-tom

Rückschlag: um mehr als 4k RAM zu addressieren, muss man offenbar Kopfstände machen, damit der PSRAM zur Mitarbeit überredet werden kann.
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

020
09.04.2024, 09:37 Uhr
HeikoS

Du bekommst das hin ! ... "Ein Fehlschlag ist keine Option." (... aus Apollo 13)

;-)

Grüße,
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

021
14.04.2024, 13:30 Uhr
jute-tom

Danke für die Motivation, es hat geholfen:
- PSRAM will ich vermeiden, da irgendwie mit DRAM umgesetzt (ich will keinen RAM-Inhalt nach einem Reset verlieren; ich bräuchte fremde IP)
- ich arbeite nun mit 2k-großen RAM/ROM-Blöcken
- RAM ist auf 8k gewachsen
- das Geflacker am unteren Bildrand ist komplett verschwunden (hab eine Leitung aus dem Prozessor rausgezogen, die zwischen Start einer ISR bis zum iret aktiv ist und nur dann das Laden des Pixel-Shift-Registers erlaubt)
- es läuft nun das 4k-System "EMR-ES 1988"
- die PS/2-Tastatursteuerung wurde für "normales" Shift/Ctrl/Alt-Handling geändert
- Ctrl+Alt+Del löst hardwaremäßig ein Reset aus
- es werden 52% der Ressourcen des FPGA benutzt, u.a. 12 von 26 BSRAM-Blöcke (3 für ROM, 4 für RAM, 1 für Register, Rest nimmt sich aus irgend einem Grund der Prozessor)
--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 14.04.2024 um 13:34 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

022
14.04.2024, 17:45 Uhr
HeikoS

... das Raumschiff ist auf dem Weg ! Super.

Das Geflacker am unteren Bildrand wird unter "Insidern" wohl Bart genannt :-))) ... da gibt es eine Lösung auch am Original - die "Bart-Ab-Schaltung" ... mit Software-Patch. Hatte ich mal für einen User aus dem Forum zusammengestellt:

-------

Zum Ju-Te 4K gibt es tatsächlich eine Anleitung, wie man den „Bart“ abschneiden kann. Da war ein Basic-Programm abgedruckt, welches die Bildschirm-Routine patcht und 2 Dioden und ein Widerstand sind nötig. Den Patch habe ich gleich in den ROM gebrannt. Dann geht das so:

Hardware-Änderung:
• EMR Pin 14 -> Pin 6 D130 auftrennen
• Diode von EMR Pin 14 -> Pin 6 D130 (Kathode an EMR)
• Diode von EMR Pin 10 -> Pin 6 D130 (Kathode an EMR)
• Widerstand 22K von Pin 6 D130 nach +5V

4K EPROM/EEPROM:
• 02EF = A0 (alt 80)
• 0335 = 5F (alt 7F)

8K EPROM/EEPROM:
• 0AEF = A0 (alt 80)
• 0B35 = 5F (alt 7F)

Grüße,
Heiko

Dieser Beitrag wurde am 14.04.2024 um 17:47 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

023
14.04.2024, 20:28 Uhr
jute-tom

Ich wollte keine Port-3-Pins dafür verbraten oder die Software anpassen müssen.

Jetzt würde ich gern mal das ES2.3 ausprobieren wollen. Wo bisher (bei den 64x64 Pixel Darstellungen)

nop
pop 80

für 1 darzustellendes Byte benutzt wurden (6 cycles + 10 cycles = 16 cycles = 4us), werden beim ES2.3 ja nur

pop 80

genutzt, sodass nur 10 cycles (2,5us) für das Rausschieben von 8 Bit zur Verfügung stehen. Hat jemand noch den Schaltplan für die Hardwareänderung?
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

024
15.04.2024, 07:10 Uhr
Bert

Einen Schaltplan habe ich nicht, hier sind die nötigen Hardwareumbau aufgeführt:
https://hc-ddr.hucki.net/wiki/lib/exe/fetch.php/tiny/es_2_3.pdf

Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

025
15.04.2024, 21:19 Uhr
jute-tom

Danke. Ich denke, der 2,5-Teiler sollte so aussehen in Verilog:

reg[4:0] counter = 5'b10101;

always @(posedge clk) begin
counter <= { counter[3:0], counter[4] };
end

assign shiftClk = counter[4];

Richtig?
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

026
15.04.2024, 22:29 Uhr
Bert

Das sieht mit etwas zu einfach aus. Hast Du mal simuliert?
Ansonsten hier, Punkt 5.2:
https://www.mikrocontroller.net/attachment/177198/Clock_Dividers_Made_Easy.pdf

Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

027
16.04.2024, 13:01 Uhr
volkerp
Default Group and Edit

Zitat:

HeikoS schrieb
Zum Ju-Te 4K gibt es tatsächlich eine Anleitung, wie man den „Bart“ abschneiden kann.

In JU+TE 7/1989, Seiten 550-553 hat Harun Scheutzow die Hardware vorgestellt (die beiden Dioden bzw. 1 AND-Gatter)
In JU+TE 11/1989, Seiten 871-873 gab es dann das Basic-Programm dazu

(jutecomp2.pdf + jutecomp3.pdf zum Nachlesen)
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

028
16.04.2024, 13:05 Uhr
HeikoS

Genau, und ich habe den Patch, den das Basic-Programm gemacht hat, einfach fest in den EPROM gebrannt. Das könnte sich wohl mit einer "Erika" Schreibmaschine am JuTe in die Quere kommen, aber die habe ich ja nicht ...

Grüße,
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

029
19.04.2024, 18:44 Uhr
OE4DEA

Zitat:

jute-tom schrieb
Danke für die Motivation, es hat geholfen:
- PSRAM will ich vermeiden, da irgendwie mit DRAM umgesetzt (ich will keinen RAM-Inhalt nach einem Reset verlieren; ich bräuchte fremde IP)
- ich arbeite nun mit 2k-großen RAM/ROM-Blöcken
- RAM ist auf 8k gewachsen
- das Geflacker am unteren Bildrand ist komplett verschwunden (hab eine Leitung aus dem Prozessor rausgezogen, die zwischen Start einer ISR bis zum iret aktiv ist und nur dann das Laden des Pixel-Shift-Registers erlaubt)
- es läuft nun das 4k-System "EMR-ES 1988"
- die PS/2-Tastatursteuerung wurde für "normales" Shift/Ctrl/Alt-Handling geändert
- Ctrl+Alt+Del löst hardwaremäßig ein Reset aus
- es werden 52% der Ressourcen des FPGA benutzt, u.a. 12 von 26 BSRAM-Blöcke (3 für ROM, 4 für RAM, 1 für Register, Rest nimmt sich aus irgend einem Grund der Prozessor)

Wow - ich bin begeistert!
Ich hatte 2018 den JU+TE Computer inkl. der Streifenkorrektur aufgebaut.
Bei der Eingabe der Basic-Routine ist der JU+TE Computer aber immer hängen geblieben.
Mit der nun erfolgten Modifikation am EPROM sind die Streifen weg.

http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=15909&highlight=JU+TE

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

030
19.04.2024, 22:13 Uhr
HeikoS

Zitat:

OE4DEA schrieb
Wow - ich bin begeistert!
Ich hatte 2018 den JU+TE Computer inkl. der Streifenkorrektur aufgebaut.
Bei der Eingabe der Basic-Routine ist der JU+TE Computer aber immer hängen geblieben.
Mit der nun erfolgten Modifikation am EPROM sind die Streifen weg.

http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=15909&highlight=JU+TE

Das freut mich sehr ! Deine Version des TINY hatte ich noch gar nicht gesehen – eine sehr schöne Arbeit.

Das Prinzip ist ja simpel. Es wird zusätzlich der Port 35 in der ISR gesteuert, um zu verhindern, dass das Schieberegister in den Bildrändern (mit Müll) geladen werden kann. Aber dazu wird die ISR in den RAM umgeladen und der Interrupt-Vektor umgebogen. Bei mir hat das Basic-Programm sofort funktioniert. Das kann aber schon mal schiefgehen. Ist aber viel Aufwand, nur um 2 Bytes für die Portansteuerung zu ändern.

Meine erster JuTe ist auf Basis der Leiterplatten von "stone" (Jona) entstanden. Erstaunlich, wie viele Nachbauten es inzwischen davon gibt. Schönes Projekt !

Viele Grüße,
Heiko

Dieser Beitrag wurde am 19.04.2024 um 22:18 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

031
20.04.2024, 08:36 Uhr
jute-tom

Zitat:

jute-tom schrieb
- das Geflacker am unteren Bildrand ist komplett verschwunden (hab eine Leitung aus dem Prozessor rausgezogen, die zwischen Start einer ISR bis zum iret aktiv ist und nur dann das Laden des Pixel-Shift-Registers erlaubt)

Habe festgestellt, dass dieser zusätzliche Ausgang der CPU auch den deutlichen Vorteil hat, in der Simulation leichter die ISR zu erkennen.
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

032
20.04.2024, 17:03 Uhr
jute-tom

Ich kann wieder etwas Fortschritt vermelden:
- hab Videosignalerzeugung (VBS) mit Hardware gespielt; mal ein Rechteck auf den Monitor zu bringen, war relativ leicht
- dann habe ich etwas RAM zur Videohardware hinzugefügt und konnte Zeichen ausgeben (komplett losgelöst vom bisherigen Z8)
- dann habe ich das Videomodul und das ES2.3 zusammengebracht; das funktioniert selbst mit den üblichen 4MHz CPU-Takt prima (48us waren "Platz" in der Bildzeile, die 16 Zeichen nehmen bei 4Mhz also 32us ein; vertikal wird jede Zeile verdoppelt, also 256 Zeilen bei ca. 270 verfügbaren)
- das sieht nun so aus; horizonal und vertikal könnte man das Bild einfach verschieben
- das Bild bleibt nun bestehen, auch wenn der Interrupt abgedreht wird - aktuell läuft das System noch mit dem sauberen Originalsystem, vertrödelt also viel Zeit mit dem Videosignal

--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

033
20.04.2024, 17:30 Uhr
Bert

Ja, mit FPGA kann man viele Dinge relativ schnell realisieren und ausprobieren, wo man früher viele Chips, viel Grips und viel Lötzinn benötigte.

Bei der Z1013-Portierung für das MiST-System habe ich auch das Bild auf VGA hochgerechnet:
https://github.com/boert/Z1013-mist

Per Overlay werden Status-Informationen und wahlweise das Menü und/oder eine Onlnehilfe angezeigt.

Viele Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

034
20.04.2024, 17:36 Uhr
jute-tom

Ja, VGA wäre so vermutlich auch ohne viel Aufwand möglich. Ich bräuchte wohl hauptsächlich eine zweiten PLL für den VGA-Takt, eine getrennte Ausgabe der SYNC-Impulse und natürlich andere Anschlüsse.

Faszinierend fand ich, dass das Videomodul nur knapp über 70 LUT brauchte, also bei den >4000 des Rests eine sehr geringe Zahl.
--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 20.04.2024 um 17:37 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

035
20.04.2024, 18:02 Uhr
Bert

Ich weiß nicht, was auf Deinem System an Taktquellen zur Verfügung steht.
Ich würde den Takt für den Tiny dann aus dem Pixeltakt herleiten. Für's runterteilen braucht man ja keine PLL:
http://tinyvga.com/vga-timing

Grüße,
Bert

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

036
02.05.2024, 08:41 Uhr
jute-tom

So, das 6k-System läuft nun auch.

--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

037
02.05.2024, 11:25 Uhr
HeikoS

Das ist ja cool !!! Super. Jetzt noch Farbe !

Ich suche noch jemanden, der auf auf dem Raspi Pico einen "JuTe 6K -> VGA Konverter" programmieren könnte. Es gibt da ja ein Projekt für den Sinclair QL

https://github.com/holmatic/video_if_ql_vga

und hier im Forum das Projekt "VGA-Adapter für A7100".

Grüße,
Heiko

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

038
02.05.2024, 12:40 Uhr
HeikoS

Oder tatsächlich auch als FPGA.

https://www.kilgus.net/ql/ql-vga-v1/manual/

Würde es viel Arbeit machen, die RGB-Signale einzufangen und dann so auszugeben, wie Du es ja bereits implementiert hast ?

Grüße,
Heiko

Dieser Beitrag wurde am 02.05.2024 um 12:57 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

039
02.05.2024, 18:42 Uhr
jute-tom

Farbe gibt der kleine FPGA vom BSRAM nicht her. Er hat, wenn ich es richtig verstehe, 26x2k Blöcke SRAM (und ein paar MBit PSRAM, der aber echt schiach zum Ansprechen ist). Für den Prozessor nimmt er sich schon 5 Blöcke, wovon ich einen durch die Register erklären kann. Für den ROM noch 4, für die 8kB RAM noch 4, für den Bildschirm noch mal 4, bleiben gerade mal 9 übrig. Ich bräuchte allerdings noch 12 weitere.

Auch zickt die chinesische Software nun langsam rum, stürzt u.U. reproduzierbar ab oder wirft unerklärbare Fehlermeldungen (z.B. "ERROR (IF0008) : The number(32768) of LUT4 used to infer "mem0" exceeds the resource limit(8640) of current device(GW1NR-LV9QN88PC6/I5)"). Yosys ist noch nicht nutzbar, weil die rPLL noch nicht in den offiziellen Releases funktioniert.

Weitere Ziele sind:
- VGA oder DVI (an HDMI-Anschluss)
- serielle Schnittstelle zum PC statt Kassetteninterface
--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 02.05.2024 um 18:45 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

040
02.05.2024, 18:47 Uhr
jute-tom

Interessant finde ich, dass
- das ES2.3 den Bildschirm vertikal besser ausnutzt (die 128 Pixel werden gedoppelt, also 256) als das ES4.0 (192 Pixel)
- ich mich zusammenreißen muss, langsam zu tippen, weil er sonst Tastendrücke verschluckt.
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

041
04.05.2024, 20:14 Uhr
jute-tom

Ich versuche gerade, die SIO zu implementieren. Gemäß den Tests sollte sie zwar funktionieren, aber irgendwie bekomme ich nichts zum PC übertragen. Ich wollte dabei die Save-Routine des 2k-Tiny nutzen. Wenn ich den Code ab 0A38 richtig verstehe, dann wird da einfach versucht, mit 600 Baud (PRE0=0x21, T0=0x0D) mittels Polling so lange Bytes zu schreiben, bis ein 0x00-Byte geschrieben wurde. Am PC nutze ich 8Bit, No parity, 1 Stoppbit, aber es kommt entweder nichts oder nur Müll an.

Ist meine Idee, die Save-Funktion und P37 direkt zu nutzen, so falsch?
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

042
05.05.2024, 09:15 Uhr
Bert

Ich nehme mal an, das Du den Magnetbandanschluss [1] nicht mit 'emuliert' hast, oder?
Die Magnetbandschaltung würde das Ausgabesignal noch mit ca. 4,8 kHz von P3.6 modulieren.

Wie sieht denn die Empfangshardware am PC aus? Kommt die mit den 5V-TTL-Pegeln des Tiny2k klar?
Sind die Massen miteinander verbunden?

Viele Grüße,
Bert

[1] https://github.com/boert/JU-TE-Computer/blob/main/Erweiterungen/Schaltplan__Magnetbandanschluss.pdf

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

043
05.05.2024, 15:00 Uhr
jute-tom

Nein, die Modulation habe ich nicht umgesetzt, nur den Output des Rx/Tx.

Der Lade- oder Sendecode beim 2k-Tiny schickt immer erst ein 0xFF-Byte raus. Das kam am PC unerwarteterweise immer als 0xE0 an. Ich habe nun die Vermutung, dass der im Tang Nano 9k verbaute USB-Serial-Chip keine 600-Baud verträgt. Die 600 Baud sind ja mit PRE0=8 und T0=13 realisiert. 9600 Baud gehen sich schon mal nicht aus, denn das wäre 16x schneller. PRE0=1 und T0=6 (oder 7) liefert zwar das initiale 0xFF am PC, aber der Rest ist verwurstet.
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

044
05.05.2024, 15:11 Uhr
jute-tom

Hurra! Mit 4800Baud (PRE0=1, T0=13) funktioniert es.
--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 05.05.2024 um 15:12 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

045
19.05.2024, 16:45 Uhr
jute-tom

Ich konnte nun auch den Bildschirm entstören - der Video-RAM kann als Dual-Port-RAM konfiguriert werden (die Videoseite liest, der Prozessor liest/schreibt unabhängig davon).

Die letzten Tage habe ich nun versucht, die Ausgabe über HDMI (besser: als DVI über HDMI-Anschluss) zu erreichen. Das funktioniert soweit - nun kann ich sogar mit meinem 8k-Video-RAM Farbe sehen, z.B. grün-schwarz oder orange-schwarz

.

Aber dafür funktioniert der PS/2-Anschluss nicht mehr. So etwas Ähnliches hatte ich auch bisher schon erlebt, nur nicht so extrem - damals verschluckte sich der Tastaturdecoder nur manchmal. Jetzt (vermute ich) so sehr, dass gar kein Zeichen mehr erkannt wird.

Eine Frage an die FPGA-Experten: kann es sein, dass bestimmte Baugruppen mit hoher Frequenz andere so sehr stören, dass externe Signale nicht mehr korrekt erkannt werden? Ich habe den PS/2-Port recht rustikal einfach mit einem Spannungteiler hingefrickelt, da ich keine Level-Shifter hier habe.

--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 19.05.2024 um 16:46 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

046
19.05.2024, 19:45 Uhr
jute-tom

Ah, wie immer war es ein user error. Jetzt funktioniert es mit DVI/HDMI (störungsfrei) bei 640x480 Pixel/60Hz:

--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 19.05.2024 um 19:46 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

047
19.05.2024, 21:54 Uhr
HeikoS

Das sieht doch gut aus ! Sehr interessant, dass die Störungen auch auftraten. Aber wenn Du zwei Prozessoren nachgebildet hast und diese 100% so arbeiten wie im Original, dann hast Du alles richtig gemacht ;-)

Dann müsste ja meine kleine Schaltung

https://github.com/haykonus/JU-TE-6K-Video-HW-Patch/blob/main/Bilder/Schaltplan.png

auch funktionieren ... ? Aber kann man den Takt auch im FPGA "strecken" ?

Viele Grüße, Heiko

Dieser Beitrag wurde am 19.05.2024 um 22:27 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

048
19.05.2024, 22:36 Uhr
jute-tom

Ich habe keine 2 Prozessoren nachgebaut. Das hätte der kleine FPGA nicht hergegeben und wäre Overkill gewesen. Die Logik zum Auslesen eines Video-RAMs in der richtigen Reihenfolge ist ja ziemlich einfach. Im Ju+Te-ES 4.0 hat man nur einen zweiten Prozessor genommen, weil es einfacher aufzubauen war (im Sinne von weniger Chips). Es wäre aber auch möglich gewesen, mit mehr "kleinen" Chips es ohne zweiten Prozessor hinzubekommen.

Dass die Störungen auch beim Auslesen mit Hilfe von "kleinen Chips" (oder meiner ersten, initialen Implementierung im FPGA) auftritt, liegt in der Natur der Sache. Der Videospeicher muss zu einer bestimmten Zeit ausgelesen werden. Wenn, wie bei verwendeten RAM üblich, diese nur von genau einer Adresse gelesen/geschrieben werden können, bekommt der Video-Ausleser halt die Prozessordaten, wenn dieser genau dann zugreift, wenn der Videospeicher ausgelesen wird. Der Block-SRAM im FPGA kann aber auch von "2 Seiten" gelesen werden (oder von 1 gelesen und der anderen beschrieben). Somit kann der Prozessor brav schreiben oder lesen, und der Video-Zugriff kann gleichzeitig von einer anderen Adresse ungestört lesen.

So kann jetzt auch mit deutlich höherer Frequenz (z.B. 25,2MHz für 640x480 Pixel/60Hz) störungsfrei gelesen werden.

Ja, man könnte auch so eine Taktverzögerung im FPGA nachbauen. Aber eleganter ist es natürlich mit dem beidseitig lesbaren Block-SRAM.
--
Viele Grüße,
Thomas

Dieser Beitrag wurde am 19.05.2024 um 22:40 Uhr von jute-tom editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

049
19.05.2024, 22:48 Uhr
HeikoS

Danke für die Erklärung. Du hast die Video-Steuerung quasi "diskret" aufgebaut. Dein Projekt hat ja auch nicht zum Ziel, die Original-Hardware zu 100% im FPGA abzubilden.

Dual-Port-RAM ist da natürlich eleganter, auch wegen der Möglichkeit mit VGA-Timing auszulesen.

Grüße und schönen Feiertag morgen !
Heiko

Dieser Beitrag wurde am 19.05.2024 um 22:48 Uhr von HeikoS editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

050
20.05.2024, 09:13 Uhr
jute-tom

Noch ein Argument sprach gegen den 2. Prozessor: mein Softcore hätte dann das langsame Timing unterstützen müssen. Dazu ist aber fast gar keine Dokumentation zu finden und hätte auch das Testen komplizierter gemacht. Mein Softcore kann also nur das normale "schnelle" Timing.
--
Viele Grüße,
Thomas

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]