Apple II Emulation

[drohne235]

das was du mit dem in den Hive umziehen meinst, überlege ich mir auch schon seit gerauer zeit mit dem Apple ii, allerdings, würde ich vermuten das ein Propeller ausreichen würde. 1-3 cogs für den interpreter, 1-2 cogs für die grafik, je nachdem welcher grafik modus benötigt wird. für lowres reicht einer. die restlichen cogs für die steckkarten.

Also eine gute Emulation für den Apple II könnte mir gefallen - hab gerade über die Feiertage das Buch iWoz verschlungen! Kennst du dich mit dem Gerät aus? Wahrscheinlich würde auch ein Prop reichen, aber mit dem Hive haben wir doch eine gute Plattform um solche Sachen komfortabel und mit der nötigen Ellenbogenfreiheit zu realisieren. Hättest du Lust gemeinsam so etwas zu programmieren?

Diverse CPU-Emulationen gibt es ja schon:

http://forums.parallax.com/showthread.p ... mocog+6502

Darunter auch ein Ansatz für den 6502:

http://forums.parallax.com/showthread.p ... post846492

Hab jetzt noch nicht geschaut wie weit die Emulation ist, aber man könnte es ja als Ausgangsbasis verwenden. Zum Schaltplan, ROM's und Software muss ich erstmal schauen. Ich glaube ich habe noch eine Emulation für den PC, muss ich mir gleich mal anschauen.

[quix]

Für die Apple II-Rechner gibt es sehr viel Informationen im Netz. Ich sende Dir mal eine Mail mit zwei Büchern zu: The Red Book und The Blue Book. Beides Referenzwerke zum Apple II.

[Nadji]

Ja mit dem Apple ][ kenne ich mich sehr gut aus, ok , hab wohl ein paar Sachen nicht mehr so direkt im Kopf, aber das ist schnell wieder erlesen.
Ich kannte dort jede Leitung auswendig. Ich glaub ich war der einzigste der einen mit 256kB hatte, davon 192kB onboard. Waren einige Sachen dran verändert

Der Grundaufbau ist einfach.
$0000 .. $BFFF Ram, hier gibt es keine Besonderheiten, das Videoram liegt hier.
$C000 .. $CFFF I/O bereich der ist etwas komplizierter aufgebaut, aber geradlinig. (Memorymapping usw)
$D000 .. $FFFF ROM bzw später languagecard (Sprich RAM)

für den ersten Schritt würden 4KB Ram $0xxx und 4KB ROM $Fxxx reichen. So wurden die erste auch ausgeliefert. (Ok er hatte 8kB ROM, aber in den letzten 4kB ist der wichtige Monitor (assembler/disassembler) drin, würde also für die ersten Versuche ausreichen. dann bleiben 16k Ram, zum entwickeln, alles was übrigbleibt kann nachher zum ram dazu oder in 8kb ROM das Integerbasic.
Bis zu dem Punkt kann auf jeden Fall alles im Propeller laufen.
An der Stelle kann man dann überlegen ob man externen RAM dazunehmen will.

1 COG wäre wohl für die einfache Grafik Text, lowres, mixmode ausreichend. evt kann er auch noch die highres grafik.
Später wäre ne 80Zeichenkarte, sinnvoll, die man dann virtuell in den virtuellen Slot steckt.

[drohne235]

Ich kannte dort jede Leitung auswendig.

Klingt verdammt gut.

Das RAM-Mapping könnte vielleicht in die CPU-Emulation integriert werden. Wenn man das parametrisierbar macht, kann man am Anfang klein anfangen und mit Spin debuggen, was die Sache sehr vereinfachen würde. Man hat ja für die Emulation den VGA und für die Debuggertools die Hostschnittstelle parallel in einem Terminalfenster auf am PC.

Wie groß ist der Videospeicher? Wieviel RAM bräuchte man um die interessantesten Programme zum laufen zu bekommen?

Wenn der Videospeicher mit im Hauptspeicher liegt, müsste eine COG diesen Bereich permanent zu Bellatrix spiegeln, so wie Uwe das auch mit seinem Tiny macht. Gleichzeitig muss diese Cog den Tastencode von Bella abholen. Wie wird im Apple II die Tastatur abgefragt? War das nicht eine Matrixtastatur? Hab grad einen Schaltplan geholt, finde aber die Tastaturansteuerung nicht. Wenn es eine Matrixtastatur ist, könnte die Cog oder der Code in Bellatrix das gleich passend umsetzen.

[Nadji]

Die erste stufe würde ich sehen wenn, der Monitor läuft und man die Grafik modes durchschalten könnte. 4KRam+4kRom evt etwas weniger
der nächste wäre dann integer basic zum laufen zu bringen +4k rom, damit und mit der lowresgrafik könnte man das klassische Breakout spielen. das war der auslieferzustand der ersten apple. Damit gingen die ersten Spiele.
der nächste schritt wäre das dos zum laufen zu bekommen, sprich booten von diskette, ab da brauch man dann mehr speicher. für spätere Spiele brauch man dann schon 48k ram.
Fürs FPbasic brauch man 12k rom $e000-$ffff.

Die Tastatur wird an $c000 abgefragt, wenn msb gesetzt liegt ein zeichen an. ansprechen von $c010 setzt das msb zurück. Also ganz easy.
im $c030 bereich z.b. liegt der speaker, dann ist da noch a/d wandler für die paddels, casseten i/o

Grafik hat er 4 seiten,
$0400-07ff, text,lowres page 1 ;$0800-0bff text low res page 2
$2000-$3fff hi Res 1, $4000-$5fff Hi res 2
die grafik ist nen bissel bunt sortiert, also die zeilensortierung, sollte aber kein problem sein.

[drohne235]

Knifflig ist die Sache mit dem Speicher im Hive, da der eRAM völlig verschieden vom hRAM angesteuert wird. Der Propellerchip hat halt von Hause aus kein Speicherinterface, auf welches dann mit den gleichen Maschinencodebefehlen zugegriffen wird wie auf den hRAM. Der eRAM hängt an den IO-Ports von Regnatix und wird auch über IO-Befehle angesteuert. Der hRAM wird über rd*/wr*-Maschinencodebefehle angesprochen. Letztlich bedeutet das: Wenn die Emulation später auch auf den eRAM zugreifen soll, muss das möglichst schon zu Anfang vorgesehen werden.

Ich denke, wenn die CPU nur auf den hRAM zugreifen bräuchte, würde man das alles in einer COG realisieren können. Wenn man den eRAM einbezieht, ist es vielleicht sinnvoll, die Adressierung und das Mapping von Anfang an komplett mit einer zweiten COG zu realisieren, nennen wir sie mal mCOG. Im Prinzip kann man dann gleich den Code komplett in den eRAM verlegen, müsste man mal schauen. Durch die Verwendung vom hRAM wird es zwar langsamer, aber durch die Nebenläufigkeit reicht die Geschwindigkeit vielleicht dennoch für die Emulation eines 1 MHz 6502 aus, denn während der Verarbeitung des Befehlscodes kann die zweite COG schon den nächsten Code einlesen.

Die Verwendung einer getrennten mCOG für den Speicherzugriff hätte auch einen anderen Vorteil: Unter Verwendung einer Adresstabelle könnte diese COG entscheiden, was wirklich beim Zugriff auf bestimmte Speicherbereiche passiert. Findet zum Beispiel der Zugriff auf den Videoram statt, kann der Wert nicht aus dem eRAM, sondern direkt von Bellatrix aus dem real verwendeten Videoram geholt werden. Das ist mit Sicherheit schneller, als später bei der Hires-Grafik ständig den 8KB-Speicherblock zwischen Regnatix und Bella zu übertragen.

Ich hab aber noch keinen Plan wie die beiden COG's zusammenspielen. Die mCOG zum Beispiel benötigt dann auch einen rudimentären Befehlsdekoder, damit alle Befehle welche den Programmcounter beeinflussen (BRK, JMP, JSR, RTS, RTI) gleich direkt in dieser COG ausgeführt werden. Der Befehl- und Registersatz ist ja glücklicherweise sehr übersichtlich.

Im übrigen ähnelt diese Struktur dem realen 6502: Im Wikipedia steht, dass der 6502 der erste Mikroprozessor mit einer rudimentären zweistufigen Pipeline war. Während also der Befehl abgearbeitet wurde, holte die "Speichereinheit" im Chip schon den nächsten Wert aus dem RAM.

[Nadji]

Sorry, da ich im Moment nicht so zum Antworten komme, aber bei mir war gerade Weihnachten . Meine Atmegaplatinen sind angekommen, die natürlich erst mal stark nach Aufmerksamkeit gerufen haben. ( da scheint nen magnet dran zu sein,m die zeuehen mich immer an )dann sind nen Tag später auch noch die Radiomodule gekommen, da weis man gar nicht wo man zuerst anfangen soll.

$0000 - $07ff sollte auf jeden fall konstant im hRAM bleiben, auslagern wäre unsinning. Hier liegen unter anderem die wichtige zeropage $ 00xx und der Stack $01xx.

Die Frage ist wie wie cogs zusammenspielen, und hier muß dann die schnittstelle sauber definiert werden, das da keine zeitvertluste entsehen. Um da was zu sagen müßte ich mich mit dem assembler und dem timing auseinandersetzen, hab dazu aber im moment keine zeit.
Der assembler vom 6502 ist schon echt einfach, ich hab schon mal für den einen Interpreter geschrieben, da stellte sich dann schon an ein paar Befehlen einige Ungereimtheiten heraus, die Recherche wie der Befehl sich genau verhielt hat länger gedauert, das der restliche Interpreter. Wenn das Konzept steht ist es fast nur Fleißarbeit.
Die Frage ist dann auch wie weit später die Emulation gehen soll. ob z.b. DOS bootbar sein soll. aber dafür muß dann das mit eRAM stehen.

[drohne235]

Meine Atmegaplatinen sind angekommen

Er hat Jehova gesagt!

Was meinst du: Muss die Emulation Taktgenau sein? (Weil das ist dann ziemlich aufwändig.) Am einfachsten ist es natürlich alllein im hRAM. Wenn man mit den 32 KB hinkommen würde wäre das toll. Zumindest wäre es wahrscheinlich schon hilfreich, wenn man den RAM in Bellatrix als Videoram direkt mitnutzen könnte.

[Nadji]

Er hat Jehova gesagt!

ööhm , ich hab nichts gehört, war wohl der Strum. *pfeiiif*

Taktgenauigkeit muß für das meiste glaube ich nicht sein.
Wenn man basic macht ist schneller besser als warten, bei den basic spielen könnte man notfalls das timing anpassen.
kritisch könnte es beim ton werden der dann anders klingt.
ich hatte das seinerzeit so gelöst, eine schnelle variante und eine taktgenaue die dann viel wartezyklen hatte, es waren nur 1-2 befehle die dann zu langsam liefen, weil die extrem lange zum emulieren brauchten. Ich hatte da allerdings auch kein Platzproblem.
Ich fände es schon cool, wenn man es hinbekommen würde, wenn die kleine Version in nur einem Propeller passen würde. für die große Verison werden wir, wegen speichemangel schon mehr brauchen. Bei der Entwicklung sollte man natürlich gleich beachten das die erweiterungen eram mit vorzusehen sind.

[drohne235]

In einem Chip wäre ein guter Anfang. Wenn wir alle Speicheroperationen in eine Unterroutine ausfaktorisieren, kann man später diese Routine einfacher auf eRAM umstellen. Mit dem eRAM war auch nur so eine Idee, ich kenne mich mit dem Apple II ja nicht aus und habe keine Übersicht, wie viel sinnvolle Software mit wenig Speicher nutzbar ist.

Wie werden eigentlich die Grafikmodis umgeschaltet? Da muss doch sicher auch in der Hardware etwas passieren? Wenn es da ein Modusregister gibt, muss ja unsere Grafik-COG, welche die Videodaten zu Bella sendet, darauf reagieren.