HIVE-Project

Was haltet ihr eigentlch vom Gameduino, den man ja nun auch per Prop und PASM steuern kann?

http://forums.parallax.com/showthread.p ... =gameduino
http://excamera.com/sphinx/gameduino/

Ich finde die Sache ja effektiv ziemlich toll, bin aber doch gespalten. Die Programmierung von Tiles basierter Retrografik ist durch den FPGA-Chip (bzw. das Board) sehr einfach und quasi in Silizium ausgelagert. Sound sehe ich beim Prop und im speziellen im Hive nicht als Nadelöhr an, da sind genug Ressourcen da.

Aber nun zur dunklen Seite der ganzen Geschichte! Nehmen wir mal an, es gäbe eine Gameduino-Erweiterungskarte für den Hive. Was wüde das bedeuten? Ich sehe das so:

1. Es geht nicht ohne SMD.
2. Im Hive sehe ich die Verwendung eines FPGA ein wenig als einen Stilbruch an, denn das Schöne am Hive ist in meinen Auge: alle Funktionen werden im wesentlichen durch drei gleichartige Chips per Software realisiert. Der bei dem Gameduino enthaltene FPGA bricht mit dieser Tugend.

Natürlich sind die Ergebnisse verlockend, aber wenn man letztlich den Verlockungen folgt landet man jenseits von allem was Propeller und Hive ist. Da stellt sich mir immer die Frage: Bekommt man das mit Bellatrix nicht auch in Software hin?

Hallo!
Ich hatte heute mal etwas Zeit den Gameduino bzw. das Shield im Netz zu begutachten. In der Tat ein verlockendes Gerät. Etwas ähnliches ist schon mal für ATmegas als VGA-Ausgabe entwickelt worden aber nicht in dieser Güte.

Was bedeutet das aber aus meiner Sicht für den Propeller im allgemeinen bzw. den Hive im speziellen.
Für einen ATmega basiertes Microcontrollerboard (z.B. Arduino) ist das natürlich ein Meilenstein, da diese nie die Möglichkeit wie der Propeller hatten, direkt vom Prozessor an einen VGA-Monitor eine Ausgabe zu verwirklichen.

Für ein Board mit einem einzelnen Propeller ohne zusätzlichem RAM könnte es natürlich auch eine interessante Erweiterung darstellen wenn der Propeller schon mit anderen Tätigkeiten ausgelastet ist. Wenn ich die Möglichkeiten mal mit dem GBP vergleiche ist beim GBP diese "VGA"-Erweiterung der Prozessor im LCD-Display und der zusätzliche Speicher im SPI-RAM und -Flash. Die Ansteuerung erfolgt beim Gameduino und beim GBP über SPI. Interessant für den GBP könnten die Softwarelösungen in PASM für den Gameduino-Shield sein. Nicht in 1:1 Übernahme aber als Inspiration für die eigene Programmierung.

Was wäre aber die Auswirkung für den Hive? Benötigt der Hive so eine VGA-Ausgabe ?
Ich kann das mit Bestimmtheit nicht sagen. Ich denke aber, Bellatrix schaft die VGA-Ausgabe in Gameduino-Güte nur in einer konzertierten Aktion mit Regnatix und dem RAM und wahrscheinlich konsequenter Assemblerprogrammierung.

Was mich aber an dem Gameduino-Shield ein wenig stört, ist die Tatsache, daß eine Auflösung 800x600 mit 72Hz verwirklicht wurde. Ein alter CRT-Monitor kann damit vielleicht noch umgehen aber so mancher TFT-Monitor, so wie meiner, kann das vielleicht nicht. Hier ist oft nur 60Hz und 75Hz verfügbar......

Gruß
TuxFan

Wenn ich http://liudr.wordpress.com/2011/02/04/arduino-memory/ richtig verstehe steckt das Programm eines AVRs immer im Flash-Speicher.

Muß man da nicht bei jedem Wechsel des Spieles (ich denke jetzt mal an Arduino-Uno plus Gameduino) um die Integrität des prozessoreigenen Flash-Speichers zittern? Irgendwann ist auch der mal ausgelutscht...

Eignet sich soeine Plattform überhaupt um wechselbare Spiele laufen zu lassen oder einen Rechner wie einen C64 nachzubauen? Oder wäre dann das Spiel eher 'n wechselbares "ROM-Modul" in dem sich dann doch heimlich ein ganzer Atmega versteckt damit das Spiel nicht dauernd umgeflasht werden muß?

Mir ist da schon lieber daß das Speichermedium von dem gestartet wird beim Propeller ein externes ist und das Programm zum Ausführungszeitpunkt im RAM liegt...

...oder ist das doch viel unkritischer als ich denke und ich höre lediglich die Flöhe reihern?

Moin moin!

yeti hat geschrieben:Wenn ich http://liudr.wordpress.com/2011/02/04/arduino-memory/ richtig verstehe steckt das Programm eines AVRs immer im Flash-Speicher.....

So ist es. Die Werte von Variablen landen soweit ich das verstehe im RAM.

yeti hat geschrieben:Muß man da nicht bei jedem Wechsel des Spieles (ich denke jetzt mal an Arduino-Uno plus Gameduino) um die Integrität des prozessoreigenen Flash-Speichers zittern? Irgendwann ist auch der mal ausgelutscht.....

Z.B. die ATmega-Reihe 48PA, 88PA, 168PA und 328P werden mit 10000 Schreib/Lösch-Zyklen angegeben. Reine Flashspeicher werden z.Zt. mit 100000 Zyklen angegeben.

yeti hat geschrieben:....Eignet sich soeine Plattform überhaupt um wechselbare Spiele laufen zu lassen oder einen Rechner wie einen C64 nachzubauen? Oder wäre dann das Spiel eher 'n wechselbares "ROM-Modul" in dem sich dann doch heimlich ein ganzer Atmega versteckt damit das Spiel nicht dauernd umgeflasht werden muß?.....

Bei 10000 Zyklen denke ich, daß ein ROM-Modul (d.h. eingebauter ATmega) die günstigere Alternative ist. Die Preise für einen ATmega328 sind ja nicht im astronomischen Bereich zu finden. Wenn man die einfach in ein kleines Plastikkärtchen in Größe einer SD-Karte einbaut die Konsole enthält dann die ganze Peripherie.
Den Nachbau eines C64 sehe ich da eher nicht. Es gibt da zwar einen Ansatz eines Basic-Computers im Microcontroller-Netz aber wenn man in Richtung Klein- und Kleinstcomputer im Sinn ZX81, C64 etc. geht, ist meines Erachtens der Propeller der geeignetere Chip, allein durch seinen inneren Aufbau (CPU's, RAM, Peripherie). Die ATmegas sind meiner Meinung nach eher für statische (statisch im Sinne weniger Programmwechsel) Aufgaben geeignet.

yeti hat geschrieben:Mir ist da schon lieber daß das Speichermedium von dem gestartet wird beim Propeller ein externes ist und das Programm zum Ausführungszeitpunkt im RAM liegt...

Wenn man den Propeller als Kleinstcomputer benutzt, sehe ich das auch so. Wenn man dagegen einen universellen Chip sucht der einmal programmiert seine Aufgabe erledigt ist es eigentlich egal ob das Programm in externem oder internem Speicher gelagert ist.

Gruß
TuxFan

TuxFan hat geschrieben:Moin moin!

yeti hat geschrieben:Wenn ich http://liudr.wordpress.com/2011/02/04/arduino-memory/ richtig verstehe steckt das Programm eines AVRs immer im Flash-Speicher.....

So ist es. Die Werte von Variablen landen soweit ich das verstehe im RAM.

Der Atmel kann Programme nur im Flashrom ausführen (Harvard). Daten können im Flashrom eeprom, sram oder den register stehen. (oder auch extern eeprom, ram , sdcard, usw)
wenn aber ein Interpreter darauf läuft, z.b. von 6502, kann das 6502 programm auch überall da stehen wo Daten stehen können.

Nadji hat geschrieben:Der Atmel kann Programme nur im Flashrom ausführen (Harvard). Daten können im Flashrom eeprom, sram oder den register stehen. (oder auch extern eeprom, ram , sdcard, usw)
wenn aber ein Interpreter darauf läuft, z.b. von 6502, kann das 6502 programm auch überall da stehen wo Daten stehen können.

Das mit dem Interpreter ist schon klar... da hab ich ja insbesondere ein Auge auf AVR CP/M geworfen, warte aber noch ab ob/wann dies von 8080- auf Z80-"Interpreter" umgestellt wird.

Ich komme aus der Ecke SC/MP, Z80, 6502, 68000 und bin halt mit CPUs aufgewachsen die nicht nach n-maligem reprogrammieren verschlissen sind.

Der Gedanke daß ein verschleißender Speicher in der CPU bzw im Microcontroller steckt ist für mich irgendwie arg gewöhnungsbedürftig, auch wenn es das "damals" in Form von EPROM oder sogar nur einmal "schießbarem" PROM auch bei einigen 8xxx-Chips gab...

Im Falle von fertig entwickelten Applikationen die dann dank Flash, EEPROM und RAM im Microcontroller im Extremfall sogar nur den Microcontroller selbst in der Schaltung benötigen ohne weiteres Brimborium drumherum (wie z.B. in USB-PCB-Business-Card) ist das schon von Vorteil, seh' ich ja ein... ich werd' mich schon noch dran gewöhnen...

yeti hat geschrieben: Das mit dem Interpreter ist schon klar... da hab ich ja insbesondere ein Auge auf AVR CP/M geworfen, warte aber noch ab ob/wann dies von 8080- auf Z80-"Interpreter" umgestellt wird.

hm, ich war immer froh wenn ich mit dem CP/M nichts machen mußte, und werde mir soetwas bestimmt nicht nachbauen. das einzigste was für mich in frage käme wäre nen Apple][, und dafür halte ich den Propelle eientlich besser geeignet als nen Atmel, die haben einfach zu wenige internen Speicher, sind eben für was anderes ausgelegt.

Ich komme aus der Ecke SC/MP, Z80, 6502, 68000 und bin halt mit CPUs aufgewachsen die nicht nach n-maligem reprogrammieren verschlissen sind.

Ich kann deinen Gedanken nachvollziehen, es bereitet mir auch jedesmal unbehagen wenn ich ihn neu flashen muß. Auch wenn man sich ausrechnen kann, wenn er 10000 Flashen verträgt, wäre er bei 27 mal pro tag erst nach einem Jahr verschliessen, .. und kosten tun die ja nicht wirklich viel. Habe mir z.b. gerade ATmega8A nen 10erpack für 10 Euro bestellt. auch andere sind mit 2-3 Euro zu haben, ich glaub es gibt keinen der mehr als 10 Euro kostet.
.. anz schlimm finde ich es bei eingen uC die bei jedem Breakpoint setzten oder löschen, neu flashen. Da sind dann 10000 doch mal schnell erreicht.

Der Gedanke daß ein verschleißender Speicher in der CPU bzw im Microcontroller steckt ist für mich irgendwie arg gewöhnungsbedürftig, auch wenn es das "damals" in Form von EPROM oder sogar nur einmal "schießbarem" PROM auch bei einigen 8xxx-Chips gab...

Wirklich zurück sehen ich mich nicht an die Eprom zeit, es hat schon recht lange gedauert, löschen neu brennen, da war immer einiges an zeit weg, länger gehalten haben die auch nicht, und billiger wie heute die ganze cpu sind sie auch nicht.
aber zu der zeit ist einem eingebläut worden, vorsichtig mit den Resourcen umzugehen, und das ist das was man heute noch empfindet. Den uC auf dme entwicklungboard muß man eben gleich abschreiben, und sie freuen wie lange er dann doch hält.

Im Falle von fertig entwickelten Applikationen die dann dank Flash, EEPROM und RAM im Microcontroller im Extremfall sogar nur den Microcontroller selbst in der Schaltung benötigen ohne weiteres Brimborium drumherum

Das ist der Vorteil, die Dinger kosten ja fast nix, man kann sie zuhause liegen haben, brennt sie, schliest spannung an, und sie machen was man will. statt 2 TTLs zu nehmen, um nen Würfel zu baun, schliest man einfach die Leuchtdioden an nen tiny an, Programm rein und es läuft. morgen ändert man das Programm und man hat nen Lauflicht oder ne Temperaturanzeige, oder was immer man gerade braucht. Statt ne Schaltung aus 3 Transistoren, lieber nen Attiny, ... ist weniger lötarbeit, ... tja die Zeiten haben sich gewandelt.

Moin moin!

Wenn ich das richtig verstanden habe basiert z.B. AX81 auf einer Z80-Emulation. Wenn man dann noch den ATmega1284 mit 128kB Flash und 16kB Ram benutzt und es irgendwie schafft den Z80-Emulationskern aus der ZX81-Emulation zu isolieren hätte man ein Einchip Z80 System. Gegebenenfalls mit Tastatur und TV-/VGA-Ausgabe. Hier wäre noch Softwareentwicklung/Modification angesagt.
Der AVR-CP/M-Ansatz auf ATmega88 Basis benötigt für die CP/M-Emulation auf 8080-Basis den/die externen DRam-Baustein/e und das SD-Laufwerk. Dazu kommt entweder Terminal oder Zusätzliche Hardware wie MicroVGA. Die CP/M-Emulations-Software ist bereits fertig. Da wäre nur einmal flashen angesagt.
Die CP/M bzw. MP/M Gegenstücke auf Propellerbasis sind z.B. Ramblade und Triblade von Clusoe mit fertiger Software bzw. Hardware und Dracblade von Dr.Acula. Alle drei mit externem SRAM. Basis Z80-Emulation.
Meiner Meinung nach gibt es in beiden Lagern geeignete anwendungsfertige Entwicklungen. Was beiden Lagern zu Eigen ist, ist der geringe Stromverbrauch zu einem originären Z80-System, bei dem man neben der CPU noch so einiges an weiteren IC's (VGA-, Tastatur-, Seriell-, Parallel-Schnitstelle sowie Bustreiber, Adressdecoder etc...auch wenn es in 74HCT*** ist.) betreiben muß. Dazu gehört dann noch ein dickes mehrere Ampere starkes Netzteil , heute natürlich ein Schaltnetzteil. Wenn man das dann mit dem Ramblade von Clusoe oder dem 2IC mächtigen AVR-CP/M vergleicht...........

Den einzigen Vorteil den ich persönlich in der Z80-Schaltung sehe liegt in der Offenheit der Hardware, bei der man jedes einzelne Signal mit Oszi oder Logicanalyser verfolgen kann (z.B. wie NDR-Klein-Computer).


Gruß
TuxFan

Hallo,

hatt schonmal jemand propiert den Quellcode (Assembler) vom z.B. ZX81 in Assembler für den Propeller zu portieren?

Ein Programm zum umsetzen von Z80 Assemblercode in Propeller Assemblercode könnte ich schreiben ich bräuchte nur die äqivalente schreibweise.

Währe dann in QT unter Linux lauffähig.

das thema passt nicht mehr direkt zum propeller µC... sollten wir das thema nicht besser aufteilen...?

---

ich verfolge das ax81 - zx81 auf einem atmel µC - schon eine weile, kann aber aus mangel an zeit/ geld usw, nicht mit machen... gibt es einen guten X81 emulator auf dem prop...?