Projektidde: GIGATRON im µC

[Joerg W. (joergwolfram)]

Ich hab das jetzt schon mal bei Projekte und Code reingestellt, da das 
wohl zu 100% in ein neues Projekt münden wird.

Konkret geht es um den GIGATRON http://www.gigatron.io bzw. einen 
Clone/Emulator im STM32.

Der GIGATRON ist ein Computer/Spielkonsole mit in TTL aufgebauter CPU 
und jeder Menge cleverer Ideen. Aber kann man das nicht irgendwie 
schrumpfen? Im Offtopic-Bereich hatte ich schon einige Ideen geäußert, 
inzwischen ist es schon konkreter geworden:

Mittlerweile habe ich festgestellt, dass das gigatron ROM im RAM liegen 
muss, um überhaupt konstante Zugriffszeiten zu bekommen. Weil halt auch 
mit abgeschaltetem Cache und Prefetch im gleichen 16-Byte Block liegende 
Daten schneller geladen werden. Außerdem muss man wohl die Branches 
berechnen statt im Emulator zu verzweigen. Und drittens kann der STM32F4 
keinen Code aus dem CCM ausführen, da der nur am D-Bus hängt. Also gibt 
es ein neues Konzept:

- Signalkompatibel zum Original (OK, nur 3,3V)
- Keine weiteren IC's, alles in Software emuliert
- Übertakten auf 200-250MHz (getestet mit einem STM32F405, geht)
- 100% ASM ode, in C halte ich das für nicht realisierbar
- Emulator im Flash, nur Prefetch aktiv
- emuliertes EPROM im RAM, möglichst wenige Patches
- RAM und Berechnungstabellen im CCM

Wenn das emulierte EPROM im RAM liegt, könnte man es auch von extern 
laden und hätte damit eine prima Entwicklungsplattform.


Jörg

[M. K. (sylaina)]

Joerg W. schrieb:
> - 100% ASM ode, in C halte ich das für nicht realisierbar

Müsste aber eigentlich locker gehen. Die heutigen Compiler sind 
eigentlich richtig richtig gut, da kann man kaum noch selbst was raus 
holen bzw. es muss schon sehr sehr speziell sein wenn man besser als der 
Compiler sein will.

Deine Idee finde ich interessant auf der einen Seite, sinnlos auf der 
anderen Seite. Der Witz am Gigatron ist ja eben, dass die CPU gegen 
TTL-Gattern ausgetauscht wurde und du willst jetzt wieder eine CPU 
einsetzen.

Ich werde dein Projekt mal verfolgen, ich finde solche Sachen immer hoch 
spannend. ;)

[Joerg W. (joergwolfram)]

In C wird es schon schwierig, das Timing so hinzubekommen, dass alle 
Befehle gleich lang (160ns) dauern. Bei 225 MHz sind das gerade mal 36 
Takte je Befehl. Selbst in ASM sind die Takte schneller aufgebraucht, 
als dass einem das lieb ist. Und bei 5 Waitstates für den Flash "hängt" 
die Programm-Abarbeitung hin und wieder, wenn der Prefetch nicht 
nachkommt. Dann bewirkt ein einziges eingefügtes NOP, dass die Routine 
gleich zwei Takte mehr benötigt. Um letztendlich einfach einen 
VGA-Monitor anschließen zu können, braucht man exakt 6,25MHz emulierte 
Geschwindigkeit.

Compiler können zwar teilweise sehr gut optimieren, aber gerade bei 
Emulatoren kann man in ASM wesentlich effizientere Programmstrukturen 
realisieren. Das habe ich bei meinem PDP11 Emulator gemerkt, da war dann 
die (Teil-) ASM Variante ungefähr doppelt so schnell wie die Version in 
reinem C. Obwohl auch die schon via gezieltem Inlining und fixer 
Benutzung von Registern geschwindigkeitsmäßig optimiert war. Aber ich 
lasse mich gern eines Besseren belehren, einen Emulator in C gibt es ja 
schon, der müsste halt nur in das Controller-Umfeld integriert und 
optimiert werden.


Natürlich ist das Projekt in einem gewissen Maße sinnlos. Das ist das 
Original aber auch. Aber es zeigt eben auch, was machbar ist. Und das 
ist für mich eigentlich das Interessante daran.

[M. K. (sylaina)]

Joerg W. schrieb:
> Natürlich ist das Projekt in einem gewissen Maße sinnlos. Das ist das
> Original aber auch. Aber es zeigt eben auch, was machbar ist. Und das
> ist für mich eigentlich das Interessante daran.

Ja, ich finde es halt nur deshalb etwas sinnlos bzw. fragwürdig weil ja 
schon das Ursprungsprojekt quasi eine Simulation ist (CPU mittels TTL 
simuliert) und jetzt simulierst du die Simulation. Aber, wie gesagt, es 
ist deswegen nicht weniger spannend ;)

[Als ich aus dem Internet ab (Gast)]

> Ja, ich finde es halt nur deshalb etwas sinnlos bzw. fragwürdig weil ja
> schon das Ursprungsprojekt quasi eine Simulation ist (CPU mittels TTL
> simuliert) und jetzt simulierst du die Simulation. Aber, wie gesagt, es
> ist deswegen nicht weniger spannend ;)

Ich hab auch an einer anderen Implementationsart des Gigatrons ein paar 
Braincycles verbraucht. Jedoch eher an SMD und ACx Logikfamilie zwecks 
Beschleunigung, das geht allerdings Weg von dem Ursprungskontzept.

Der Gigatron ist ja primär ein VGA Signalgenerator, halb in HW, halb in 
SW, der dann sekundär noch etwas Zyklen übrig hat für "simples 
Userland". Selbst die Erschaffer haben bemerkt dass mit dem arg 
reduzierten, nativen RISC ISA und den durch VGA diktieren 
Timingeinschränkungen kaum ein Staat zu machen ist. Folgerichtig haben 
sie als einziges natives Userland Programm ein Emulator ins ROM 
implementiert (I-Speicher der Harward-HW) der eine andere VCPU spielt.
Diese andere VCPU ist dann von-Neumann-isch und ihr kompletter (I- & D-) 
Speicher liegt vollständig im RAM, also D-Speicher der realen RISC HW 
TTL Schaltung (habe bewusst das Kürzel CPU weggelassen, wir sprechen ja 
vom "without CPU" Gigatron :)

Eine andere Umsetzung des Gigatron Konzeptes muss also ebenfalls primär 
VGA Signale generieren, was den Rahmen des Timings diktiert. Dann kann 
sie sekundär bieten was sie will.
Ob "das Extra" nun wie original Gigatron nur in der Bildaustastlücke 
oder aber auch in Zeilen- und Pixelaustastlücken möglich wird, ergibt 
sich aus den Torlaufzeiten der gewählten Logiktechnik.

Habe auch anders weitergemacht: 2 verkoppelte Gigatron, davon nur einer 
der VGA machen muss, der andere steht voll f. Userland zur Verfügung, 
darf auch nativ RISC sein.

Offene Fragen auf meinem Radar: egal wie kurz die Torlaufzeiten f. noch 
handlötbare SMD Logikfamilie ich kaufen kann, bekomme ich auch so 
schnelles RAM & ROM dazu? (PC DRAM möchte ich nicht wirklich...)
Muss der Grundtakt zwingend n*6.25MHz ausfallen?
Wieviel davon soll/darf/muss in HW, wieviel in SW sein damit es noch ein 
Gigatron ist? Oder ist es dann einfach was anderes, vom Gigatron (mehr 
oder weniger) inspiriertes?

Attraktiv wäre auch eine reine VHDL implementation, dann auf ein FPGA. 
Verzichtet dann auch wieder auf den Charme des "löten von TTL Grab", 
halt aber "No CPU" ein.

[Joerg W. (joergwolfram)]

Schnelles SRAM ist kein Problem, die gibt es bis 10ns herunter. Beim 
Flash sieht es schon weniger rosig aus, die aktuellen schnellen Flashes 
laufen meist nur bis 3,3V.

Direkt die vCPU zu simulieren hatte ich mir auch schon gedacht, aber mir 
ging es erst mal darum, ein Gefühl dafür zu bekommen, wie sich taktgenau 
auf einem STM32 programmieren lässt. Und da ist der Gigatron eine 
optimale Herausforderung. Da praktisch alles in Software realisiert ist, 
lässt sich mit dem Board sicherlich noch mehr anstellen...

Und eigentlich soll es ja eine Emulation werden, die sich bis auf die 
geringeren Logikpegel (3,3V) möglichst exakt wie ein echter Gigatron 
verhält.

Leider ist der Thread ins allgemeine µC Forum verschoben worden anstelle 
meinen Tippfehler im Topic zu korrigieren, aber wahrscheinlich ist das 
Gigatron-Forum sowieso der bessere Platz dafür.

Jörg

[Joerg W. (joergwolfram)]

Inzwischen sieht es gar nicht so schlecht aus, auch wenn es teilweise 
eine üble "Popelei" mit dem Trimmen der einzelnen Befehle auf die 
richtige Geschwindigkeit war.

[Joerg W. (joergwolfram)]

Wenn auch etwas später als geplant, gibt es jetzt eine erste öffentliche 
Version vom Projekt:

http://www.jcwolfram.de/projekte/gtmicro_de/main.php

Es werden jetzt 64K RAM unterstützt und es lassen sich verschiedene 
ROM-Images laden.

Jörg