HIVE-Project

Jo, den Rainer hat richtig die Programmierwut gepackt...

Hmm .. kann man die Variable "heap" nicht einfach deklarieren, ohne eine definierte Länge von 32kB ?

Sollte gehen, muss man nur umsortieren, damit die Heap-Variable als letzte deklariert wird. Jetzt ist aber noch das Problem, wie man in diesen Heap den entsprechenden Testcode/Code für das Logo bekommt. Man könnte natürlich aus dem EEProm nachladen, bräuchte dafür aber SPI-Routinen im Loader die das machen und man müsste die Daten vorher in das BIN-Image "reinlinken".

Also geil wäre so ein Analysator schon muß ich sagen.

drohne235 hat geschrieben:Jo, den Rainer hat richtig die Programmierwut gepackt...

Ich habe IMMER Programmierwut
Leider überholen meine Ideen oftmals meine Programmierfähigkeiten. Ich bräuchte z.B. DJ als meinen Sklaven .. ich sag' ihm was ich haben will .. und er machts in 10 Minuten *hehe*
Beim Hive (und ähnlichen Projekten) macht Programmieren ganz einfach für mich wieder Sinn. Nichts, was ich auf dem PC programmieren könnte, hat nicht irgendjemand schon um Welten besser gemacht als ich es je könnte ... also was solls dann ?

Leider beschränkt sich meine Zeit zum Programmieren teilweise auf wenige Stunden in der Woche ... wir führen gerade SAP ein bei uns in der Firma, was mich nahezu täglich in die Nähe eines Nervenzusammenbruchs bringt. Wenn ich dann zu Hause bin muß ich oft Dokumentieren, Schnittstellenbeschreibungen ausarbeiten, usw.
Macht nicht wirklich Spaß.
Naja .. Schluß mit jammern .. arbeiten muß schließlich jeder. Donnerstag/Freitag habe ich mal frei .. und spätestens nach dem langen WE ist Regime soweit fertig

drohne235 hat geschrieben: Sollte gehen, muss man nur umsortieren, damit die Heap-Variable als letzte deklariert wird. Jetzt ist aber noch das Problem, wie man in diesen Heap den entsprechenden Testcode/Code für das Logo bekommt. Man könnte natürlich aus dem EEProm nachladen, bräuchte dafür aber SPI-Routinen im Loader die das machen und man müsste die Daten vorher in das BIN-Image "reinlinken".

Also geil wäre so ein Analysator schon muß ich sagen.

Hmm .. muß ich direkt mal probieren. Die Idee (wahrscheinlich vollkommen bescheuert):
- "heap" als RES definieren
- Den Code, den ich beim Start laufen lassen will im Proptool kompilieren und das Ergebnis im Loadercode direkt in "heap" packen (also das Kompilat direkt in den Loadercode rein und den dann kompilieren) und dann starten .. sozusagen das gleiche wie das auch beim nachladen von Code passiert. Könnte mit der "file"-Direktive in der DATA Sektion funktionieren.

Also sozusagen "heap" statt mit 32000 Nullen eben gleich mit laufähigen Code bestücken.

[EDIT]
Irgendwie so: Die Binary mit "file" in den Space während dem kompilieren reinladen, evtl noch mit Nullen auf 32 k auffüllen damit "heap" die richtige Größe hat ... damit wäre es eigentlich GENAU das gleiche wie das nachladen über SD. Oder man nimmt statt "binary" vll. "eeprom", das man auf die richtige Länge mit einem Hexeditor beschneidet .. sind ja eh nur Nullen am Ende.
[/EDIT]

Gruß.
Rainer

Irgendwie so: Die Binary mit "file" in den Space während dem kompilieren reinladen

Die Idee kam mir auch sofort als ich deine Beschreibung oben gelesen hab. Quasi zweimal geschachtelt compilieren.

Aber noch eine andere Idee: Wenn der Busanalysator praktisch ist und man ihn vielleicht auch oft im "Alltag" braucht, warum packen wir ihn nicht einfach mit in den Texttreiber und schalten per Funktionsaufruf die Anzeige in den entsprechenden Modus? Man könnte das Ganze sogar soweit bringen, dass man unter dem Analysebereich noch einen normalen scrollbaren Textbereich hat, wie ich das in meinem Schachprogramm mache. Der Platz sollte eigentlich dafür reichen. Man könnte dann mit einer Tastenkombination den Modus zum Beispiel in Regime umschalten und im oberen Bereich hat man einen Busanalysator, wärend im unteren Logbereich Regime ganz normal weiter läuft. So bräuchte man überhaupt nicht am Loader basteln (der Splashscreen ist ja nochmal ein anderes Thema) und hätte diese geile Funktionalität in fast allen textbasierten Programmen potentiell verfügbar.

Nun, meine Idee war, da ich oftmals das Problem habe, daß ich beim Verändern von Programmen einfach nur einen schwarzen Bildschirm habe, weil irgendwas nicht so geklappt hat wie ich das wollte. Dann stehs't erstmal da und weißt nicht was los ist.
So weiß ich, daß Bel noch tut (da der Screen da ist) und kann unter Umständen mit der Diagnose sehen was los ist.
Zumindestens sehe ich aber ob der nachgeladene Bildschirmtreiber spinnt (Startbild weg), oder ob mein Hauptprogramm spackt (Treiber wird nicht übergeben).
Außerdem tut sich kurz nach dem einschalten des Hive schon was, was auch einen psychologischen Effekt hat

Das Scope kann man natürlich durchaus auch in die Grafiktreiber integrieren .. Dein Schachprogramm-Sequel zeigt wie es gehen kann.
Das Ding ist auch ziemlich cool ... gibt einen fast/slow Modus, ist ein Speicher-Analyzer, kann getriggert werden (startet wenn man will nach High/Low von einem bestimmten Pin), überwacht alle 31 PIN's, usw.
Nur die Grafik-Auflösung und andere Kleinigkeiten müsste man noch anpassen. Ich habe es soweit angepasst, das ich es direkt in Bel flashen kann.
Bin nur nicht wirklich sicher ob die Auflösung reicht ... fast = 6,66 MHz und slow = 4,4 MHz. Auf den VGA-Pins sehe ich aber die Pegel .. 0b ich da alles immer "erwische" weiß ich allerdings nicht. Wenn man aber nicht alle 31 Pins überwacht (was eh Blödsinn ist im Hive), dann kann man wohl noch schneller werden.

Ich habe die Sourcen mal angehängt falls jemand rumprobieren will. VGA und Keyboard sind an den Hive von mir angepasst worden, der Rest ist Original Parallax.
Einfach mit F10 nach Bellatrix flashen und den Anweisungen folgen. Ich habe auch noch eine Testversion mit kontinuierlicher Echtzeitanzeige, die aber ziemlich flimmert .. war mir aber damals nicht wichtig genug da weiterzumachen.


Gruß.
Rainer

Frisch aus dem amerikanischen Forum: Seriously improved 8x8 NTSC text driver (early WIP release, if you've test time, please do)

Link: http://forums.parallax.com/forums/defau ... 5&m=385414

Ich hab den Testcode noch nicht getestet - keine Ahnung ob das ein vernünftiges Bild auf einem TV gibt, aber prinzipiell ist das interessant.

Es geht weiter...

Das Tutorial "Build your OS" kam gerade zur rechten Zeit.
Beim studieren der Quelltexte fiel es mir wie Schuppen aus den Haaren.

Da Rainer gerade am BIOS schraubt, macht es für mich momentan keinen Sinn, das auch zu tun. Daher habe ich mich der Bildansteuerung angenommen. Es ist immer noch oberstes Ziel, eine Geräteunabhängige Ansteuerung zu implementieren.
Daher sehe ich eine Zwischenschicht zwischen BIOS bzw. Applikation und Low-Level-Treiber vor, die den Zugriff auf die einzelnen Bildschirme (VGA, TV, LCD...) vereinheitlicht.

Das ganze lässt sich dann als gerätespezifischer Treiber in das BIOS einbinden, ohne dass Änderungen am BIOS selbst erforderlich werden, wenn man das Ausgabegerät ändert.

Um zu sehen, ob dies prinzipiell funktioniert, habe ich mal einen Prototypen gebaut (Datei screen-vga-treiber.spin).
Er basiert auf den Quellen aus dem Tutorial, wobei ich die Print-Befehle sowie Cursorsteuerung aus den Demo-Sourcen in den Treiber ausgelagert habe. Die Applikation (z.B. Matrix-Bildschirmschoner) wird entsprechend viel übersichtlicher.

Die Cursorsteuerung habe ich etwas gepatcht, so dass die Koordinaten beim Setzen und Abfragen des Cursors übereinstimmen, jeweils beginnend bei Null.

Neu ist, dass vor dem Setzen des Cursors das darunter liegende Zeichen gespeichert wird. Beim Bewegen oder Ausschalten des Cursors wird es wieder hergestellt, so dass kein Bildinhalt zerstört wird.
Der Cursor in der ursprünglichen Version hinterließ jeweils nur Leerzeichen.

Zur Demonstration ist das Matrix-Programm in einer angepassten Version enthalten sowie ein Programm, mit dem man auf den Bildschirm schreiben kann und das die Cursorposition anzeigt. Bei letzterem funtionieren die Cursortasten sowie Home, End, PgUp und PgDown.

Beiliegen die aktuellen Sourcen sowie die Programme
b-matrix.bin und
b-type.bin
Letztere lassen sich mit "bload b-matrix.bin" oder "bload b-type.bin" direkt von SD starten.

Viel Spaß beim Testen,

oooooog

Ich hab es mir zwar jetzt mangels Zeit noch nicht angeschaut, aber an sich klingt das nach hübschen Experimenten!

Ich schreibe momentan am zweiten Teil des Tutorials - dem Regnatix-Code. Dort wird ausführlich der Bus und die Kommunikation zwischen den Propellern besprochen und nachdem die ersten Zeichen von Regnatix über den Bus sausen und auf dem VGA erscheinen, wird auch nochmal intensiver an dem Code von Bellatrix gebastelt, denn was noch fehlt ist ja die ganze Busmechanik und der Funktionsinterpreter. Was ich damit sagen möchte: Es geht auch in Richtung Bellatrix noch weiter im nächsten Teil.