Games und Programmierung

[drohne235]

Z-Maschine
http://forums.parallax.com/forums/defau ... 5&m=365829
http://de.wikipedia.org/wiki/Z-machine

Sprite-Editor
http://forums.parallax.com/forums/defau ... 5&m=366629

[petersieg]

In wie weit kann man code für das HYDRA Board auf dem HIVE nutzbar machen?

z.B:
Donkey Kong:
http://forums.parallax.com/forums/defau ... 3&m=193209

Invaders:
http://forums.parallax.com/forums/defau ... 3&m=359868

Rogue:
http://forums.parallax.com/forums/defau ... 3&m=195502

Da ich insbesondere ein Donkey Kong Fan bin würde ich dazu sogar eine Bounty Prämie ausloben.


Peter

[Janaha]

Hm,

wenn wir da zugriff auf den Sourcecode bekommen sollte sich eigentlich alles auch an den Hive anpassen lassen. Die Hydra hat ja 2 Gamepad Ports, die uns noch fehlen. Hier könnte man erstmal auf Tastatur zurück greifen oder halt mal schnell einen Joystick- Adapter bauen. Da wir prinzipiell die 3 fachen Resourcen einer Hydra haben, sollte sich eigentlich jede Hydra anwendung auf den Hive bringen lassen, wenn man den Sourcecode hat um ihn anpassen zu können.

Grüße
Janaha

[petersieg]

Hi. Der Sourcecode ist in den jeweiligen Threads verfügbar..
Ich wäre auch ersteinmal für eine Tastatursteuerung als Ersatz..

Hier noch eine Übersicht aktueller HYDRA Projekte:
http://forums.parallax.com/forums/defau ... 3&m=312639

Code: Alles auswählen

Games and Entertainment:

  3D Monster Maze
  Battlez0wned
  Clickn'Collapser
  Defender
  Donkey Kong
  Frogger
  Grid Runner
  Jetpac
  Kaboom!
  Loadrunner
  Manic Miner
  Maze Mania
  Mercury Mission
  Mythic Flight
  Planetary Defense
  Progue
  Repeat (Simon clone)
  Snake
  Spacewar!
  Spinpong
  Spintris
  Spydriver
  Sudoku
  Unterwelt
  Miscellaneous demos

Sound
  Hydra Dense Music Format (HDMF)
  Hydra Sound System (HSS)

Graphics
  Another High Color TV driver  /  High Color TV driver
  Fantasia
  Full Color driver for Hydra SRAM expansion card
  ZX Spectrum TV driver

Utilities & Applications
  Alternate Firmware for Hydra SRAM expansion card to allow random access to locations >64K
  Atari 2600 emu
  Digital Screen Grab
  Femto BASIC
  Hydra Asset Manager
  Hydra Logo
  SPIN Conditional Compilation Managment (SCCuM)

Und noch einen Texteditor:
http://forums.parallax.com/forums/defau ... 5&m=334122

Peter

[BorgKönig]

Bevor wir mit Games Programmierung anfangen, sollte ersteinmal ein OS stehen. Danach denke ich, sollten wir so vorgehen:

• Dev-Paket entwickeln (Editor, Compiler, Debugger)
• SVN Paket (Wenn möglich, direkter Zugriff vom Hive aus) erschaffen
• Sprite/ Grafikeditoren entwickeln
• Sound- Entwicklerkit erzeugen

Ein Teil der Grundlagen existiert, wenn auch eher "Küchentisch" basiert...

[Janaha]

Hy.

Mein Kumpel und ich sind leider noch nicht ganz mit dem Grundaufbau fertig. Unsere Planung für die Softwareentwicklung sicht etwa so aus, wie Du sie gerad beschrieben hast.

Wir wollen zuerst sehen, das wir das bekannte TRIOS erstmal unseren Ansprüchen entsprechend neu Bauen. Uns schwebt da etwas in der Art wie beim alten AMIGA Betriebssystem vor. Wenn auch ein wenig abgespeckt, um nicht gleich sämtliche Systemresourcen nur mit dem Betriebssystem zu verbrauchen. Auch ein Packet aus Texteditor, Assembler und Compiler wollen wir für dieses System stricken. Hier grübeln wir dezeit noch rum, wie man den Assembler / Compiler so geschickt baut, das er auch klar kommt wenn ein Anwendungsteil mehr als den in einem COG verfügbaren speicher braucht. Hier ist klar, das wir das COG interne RAM so selten wie's nur irgend geht ändern wollen. Wäre blöd, wenn man immer nur eine Subroutine pro COG verwenden kann und der bei jedem CALL aus'm HubRam oder sonstwoher gleich nachladen muss. Auch die Parallelisierung macht uns noch Kopfschmerzen. Im Prinzip müsste unser Assembler auch sowas wie Tasks kennen, damit er den Code optimal auf die COG's verteilen kann. Das ganze braucht dann natürlich auch gleich ne vernünftige Resourcenverwaltung und muss auch gleich noch sowas wie Stacks und Heaps unterstützen.

Das ganze ist noch nicht völlig Durchdesignt und wird sicher einige Zeit brauchen, bis wir es soweit lauffähig haben das es TRIOS ersetzen könnte. Unser Hauptziel dabei ist, das wir spähter die wichtigsten Anwendungen ( Editor, Assembler, Compiler, Linker ) direkt auf dem Hive nutzen können, ohne das wir ständig mit einem PC verbindung halten müssen. Von Spin halten wir dabei erlich gesagt nichts, da es Performant und Resourcenschoned laufen soll. Alles in allen ne Menge Arbeit. Mal schaun wann die beiden Papa's dafür von ihren Kleinen genug Zeit zur Umsetzung bekommen

Grüße
Janaha

[petersieg]

Nun Ja.. Ja. Sicher ein guter Weg.. aber auch ein längerer.. aber bekanntlich ist ja auch der Weg das Ziel

Trotzdem wäre es doch schön, wenn man die HYDRA Projekte mit relativ wenigem Aufwand auf HIVE portieren könnte und würde.. Evtl. beim ersten Port ein Tutorial dazu aufbauen ala 'How to port a HYDRA project to the HIVE platform'..

Ohne das ich mich da wirklich auskenne, sind ja ggf. nur die PIN Assignmens der Hardwareanschlüsse anzupassen und ggf. programmeigene Routinen (VGA, SD Card) auf die im ios vorhandenen um zu bauen..

Im Idealfall hätte man 1 Source der für die unterschiedlichen Plattformen (HYDRA, Demoboard, etc.) übersetzt werden kann..
..und als neue Plattform kommt dann eben HIVE dazu..

Zum einen profitiert man von Softwareentwicklungen im HYDRA Umfeld.. und zum anderem hat man schnell ein paar mehr Applikationen für den HIVE. So wurde es ja schon mit FemtoBasic gemacht..

Peter

[Janaha]

Hm ne so ganz wird das nicht klappen.

Die Hydra hat nur einen Propeller für VGA- Ausgang, Sounderzeugung und Tastatur / Joystick eingänge. Beim Hive liegt der VGA Ausgang und die Tastatur am Bellatrix während die Sounderzeugung am Administra hängt. Und Regnatix währe vorgesehen für die eigentliche Application sozusagen. Hier müsste man den Hydra- Sourceode mindestens so umbauen, das sich Bellatrix und Administra miteinander über den auszugebenden Sound unterhalten können. Dazu würde Bellatrix exklusiven Bus- Zugriff benötigen, welcher aber Designbedingt nur dem Regnatix wirklich zusteht. Also müsste man die Hydra Anwendung eigentlich zwingend auf die 3 Propeller aufteilen, damit sie lauffähig werden. Je nachdem wie der Originalcode aussieht dürfte das mehr oder weniger schwierig werden. Auch das die drei Propeller nicht Synchron laufen, macht das Design nicht wirklich einfacher. Hier könnte man dann nicht einfach die aufgelaufenen Takte zählen sondern muss immer brav das "Acknowlege" - Signal des jeweiligen Empfängers abwarten. Nichts des do trotz sollte die Anpassung der Spiele torzdem möglich sein, ist alles nur eine Frage des Aufwandes den man bereit ist zu Investieren. In manchen Fällen wäre es evtl. sogar schneller, wenn man nur die Idee nimmt und die ganze Anwendung neu schreibt.

Freundliche Grüße
Janaha

[Rainer]

Zu allem was Janaha gesagt hat kommt noch, das die Hydra mit 100 MHz läuft. Was uns Geschwindigkeitstechnisch erst mal noch größere Probleme bringt bei einer 1:1 - Übersetzung des Hydra-Codes auf dem Hive.
Auch wenn ich in der Praxis noch keine Probleme mit ios-Aufrufen hatte, da reichlich schnell, werden wir in Spielen der Kommunikation zwischen den einzelnen Propellern im Hive größere Aufmerksamkeit schenken müssen.
Ich glaube auch das eine komplette Neuprogrammierung wesentlich schneller geht und außerdem den HIVE besser ausnutzt.

Eine größere Softwarebasis am Anfang ist schon eine coole Sache, würde mir aber schon wieder viel an Spaß nehmen (und außerdem vom Programmieren abhalten, wenn ich stundenlang Bomberman spiele).

Was gut portiert werden könnte sind "langsamere" Spiele, wie Schach oder RPG's. Den Schach-Source für Propeller (nicht Hydra) habe ich da wenn jemand portieren will.
Leider hat mein Tag irgendwie immer zu wenig Stunden ... oder ich bin nicht effektiv genug. Das Ergebnis ist aber das gleiche ... tausend Ideen und ich kann nur 10% umsetzen.

Gruß.
Rainer

[Janaha]

Leider hat mein Tag irgendwie immer zu wenig Stunden ... oder ich bin nicht effektiv genug. Das Ergebnis ist aber das gleiche ... tausend Ideen und ich kann nur 10% umsetzen.

Das mit der mangelnden Zeit habe ich auch. Habe zwei kleine Kinder, die immer schon auf Mich warten, wenn ich nach Hause komme. Vor 21:30 Uhr lassen die mich meist nicht wieder gehen. Ideen für den Hive und sein Basisbetriebsystem habe ich genug, nur leider zu wenig Zeit um das alles Umzusetzen. Das einziege das mich im moment am TRIOS stört ist, das es zum großteil in einem Mix aus Spin und Assembler geschrieben ist und noch recht langsam beim nachladen von SD- Card ist. Dieser Mix aus Spin und Assembler macht es mir sehr schwer, mir einen eigenen Assembler/Linker/Compiler zu designen der direkt auf dem Hive laufen soll.

Meine Vision wäre es, das das System spähter sich selbst direkt auf einem Hive übersetzen kann, ohne das man einen PC braucht der diese SPIN- Objekte erst noch zusammen baut. Auch möchte ich es erreichen, das man nicht immer den kompletten Speicher eines Propellers mit einer BIN Datei überschreiben muss, sondern das man auch Funktionsblöcke wie z.B. einen Grafiktreiber einzeln nachladen und starten kann.

Auch eine Art Multitasking könnte ich mir vorstellen. Im Grunde genommen hält uns ja nichts davon ab mehr als eine Anwendung auf dem Regnatix gleichzeitig laufen zu lassen. So lange die Resourcenverwaltung einigermaßen schlau gelöst wird, kann man ja sogar Anwendungen schreiben die z.B. unterschiedliche Grafikmodi brauchen. Man macht dann halt nur eine Unterscheidung, welche Anwendung nun gerade im Vordergunrd läuft und bei der anderen Anwendung werden die Grafikbefehle einfach ohne eine Ausgabe nur mit OK quittiert. Über sowas wie ALT-TAB könnte das Betriebsystem dann leicht die jeweiligen Anwenungen in der Vordergrund holen. Die Anwendung bekommt dann einfach das Event "Alles neu Zeichnen" und schon läßt sich auch das Grafikmodi- Zwitschen hinbekommen. Nicht anders geht DirectX vor, wenn ein Spiel im Vollbildmodus eine andere als die Desktopauflösung haben will. Selbst eine Art Auslagerungsdatei für Anwendungen und Anwendungsdaten die aufgrund von erhötem COG- Bedarf der Vordergrundanwendung ausgelagert werden müssen könnte man sicher mit etwas Aufwand hinbekommen.

Nur muss das natürlich alles erst noch erdacht und umgesetzt werden. Und gerade das würd ich lieber auf dem Hive und in Ruhe machen als mal eben schnell auf meinem PC. Daher möchte ich hier auch nicht versprechen, das das System man eben in einem Monat oder so fertig ist.

Erlich gesagt bin ich ganz froh, das es das TRIOS gibt, da man so schon eine Menge an sachen damit ausprobieren kann. Was ich mir hier zusammenspinne könnte man so sehen, wie damals das GEOS, das das Betriebssystem des C64 mal eben um eine komplette grafische Oberfläche erweitert hat. Und so ähnlich werde ich das mit meinem Kumpel zusammen auch bauen. Solange es irgend geht möchte ich nähmlich jederzeit zwischen meinem System und dem TRIOS hin und her wechseln können.

Grüße
Janaha