HIVE-Project

...z.B.Apple ][ ? Würde sich doch mit der Bellatrix RAM-Erweiterung 'zwingend' anbieten....

Mich würde ja erst mal der Apple I wieder hinterm Ofen vorholen.

Prinzipiell gibt's den Apple 1 ja schon auf 6502+Propeller-Basis. Siehe http://www.brielcomputers.com/wordpress/?cat=17 , sogar mit Qellcode unter 'Downloads'.
Wäre ein nettes Bastelprojekt. Ob das auf dem Hive geht, weiss ich nicht. Man müsste vermutlich die 6502-CPU auf einem zweiten Propeller emulieren.
Auf Arduino ist das möglich, siehe KIM-1 Projekt http://obsolescence.wixsite.com/obsoles ... mary-c1uuh . Hab nur leider keine Zeit dazu...

NJO ich muss dich leider entäuschen auf dem http://www.brielcomputers.com/wordpress/?cat=17 werkelt unten links noch ein 6502 herum.

Eine Assimilation währe kein problem nur allein ....

Um auf die selbe geschwindigkeit wie beim original zu kommen müssten 6COGs zusammenspielen.

1. - Interface COG er arbeitet mit dem externen Ram und bereitet den CODE vor. ( 3 Bytes Pipeline-Architektur RAM, ROM erkennung)
2. - Interface COG er Stellt die Verbindung Hartware von und zum Ram ( Memory Mapped I/O )
3. - 6502 runtime verarbeitet alle Befehle von 00h - 3FH
4. - 6502 runtime verarbeitet alle Befehle von 40h - 7FH
5. - 6502 runtime verarbeitet alle Befehle von 80h - BFH
6. - 6502 runtime verarbeitet alle Befehle von C0h - FFH

Zeropage, Flagregister und Stack befindet sich im Prop.

Das laden kann von RAM, ROM einen SPIN Teil ervolgen

Die Doku vom 6502 habe ich mir angeschaut und die Umsetzung auf Administra währe auf dem HIVE kein Problem.

Da der 6501/6502 keine IO Befehle kennt (ebenso wie der U8810) müssen alle Ein und Ausgaben zum RAM über einen COG gefiltert werden.
Das würde dann der 2.COG übernehmen. Das bedeutet aber zusätzliche Leistungseinbußen.

Immer hin kommt der Proz mit 2 Tackten pro Befehl ziemlich schnell daher.
Das würde Bedeuten das nach ca. 2µS der Befehl abgearbeitet sein muß.
Das sind weniger als ca. 30 PASM Befehle.
Dafür ist das Spin Interface zwischen Administra und Bellatrix zu langsam.

Eventuell kann die Zeropage und der Stack im Administra gehalten werden das würde noch etwas Zeit bei den 2 Taktbefehlen einsparen.


Das größte Problem sehe ich bei der verwendeten PPI 8221 mit ihrer Interuptlogik die müßte in Administra auch ausgewertet werden. Leider fehlen da ein paar freie Leitungen.

PIC18F2550 hat geschrieben:3. - 6502 runtime verarbeitet alle Befehle von 00h - 3FH
4. - 6502 runtime verarbeitet alle Befehle von 40h - 7FH
5. - 6502 runtime verarbeitet alle Befehle von 80h - BFH
6. - 6502 runtime verarbeitet alle Befehle von C0h - FFH

Wenn wir schon bei (engem) Timing sind, wie willst Du die 4 eigentlich synchronisieren? Was spricht gegen eine single-cog Loesung?

Die singel COG währe mir auch lieber aber ich denke bei 256 Befehlsmöglichkeiten währen 512 PASM befehle zu wehnig.
Da mlt die COGs nicht ständig den hram durch ständiges pollen blockieren wird das LED Pin als Status verwendet.
Wenn ein COG den befehl erkennt schalter es die LED ein und die anderen bleiben mit waitpq stehen.
wen der Befehl abgearbeitet ist wird die LED ausgeschaltet und alle COGs scannen ein Longwert ein.

In dem Longwert steht die Adresse , Befehl und ein steuerbyte.

Danke für euer bisheriges Feedback.

@PIC18F2550: du hast recht, die benutzen tatsächlich einen 6502 Prozessor und realisieren wie es aussieht die Pegelanpassung von 5 auf 3,3 V an den Propeller über Widerstände.

Viele Grüße
Norbert

Hi NJO,

es ist bestimmt einfacher einen 6502 über eine Adapterplatiene an den HIVE zu verknoten als die ganze Logik in PASM zu Konvertieren.