HIVE-Project

Hallo,

Inquisitor, The hat geschrieben:Kannst Du nicht? IIRC - meine U880 Zeit liegt schon 'ne Weile zurueck - ist das nur ein indirekter Sprung. Sprich jmp reg (ohne #). Oder hab ich da was falsch verstanden?

Sprung ist richtig nur die Zieladresse steht in einer Speicherzelle im RAM die durch das Register HL Selectiert und anschließend im PC geladen wird.
Der nähchste Befehl der abgearbeitet wird ist der auf dem der PC zeigt.
Zu vor muß eine Rückkehr Adresse auf dem Stack abgelegt werden.

Das bildet zuammen so eine Art Call (HL).

: Auszug aus dem Z1013 Monitorprogramm

Der Tei den ich meine beginnt ab Adresse 0xF0AC.

Versuch mal den folgenden Code-Schnippsel. Die Sprungtabelle ist im Moment im hub RAM. Wenn Du sie im cog haben willst einfach umsortieren. Derzeit sind drei Unterprogramme verfuegbar. Wenn sie aktiviert werden dann wird A, B oder C im Binaerkode angezeigt (demoboard LED). Die Ruecksprungadresse ist derzeit immer nach dem eigentlichen Unterprogrammaufruf, das Verhalten kann aber geaendert werden. HTH

Code: Alles auswählen

PUB null

  cognew(@entry, @table)

DAT

table           long    "A" << 24 | eins << 9 | eins_ret
                long    "B" << 24 | zwei << 9 | zwei_ret
                long    "C" << 24 | drei << 9 | drei_ret
                long    0
                
DAT             org     0

entry           mov     hl, par                 ' hl == @table

:loop           rdlong  ntry, hl wz
        if_z    jmp     #entry                  ' Ende der Tabelle
                add     hl, #4                  ' naechster Eintrag
                
                mov     temp, ntry              ' |
                shr     temp, #24               ' |
                cmp     temp, #"B" wz           ' |
        if_nz   jmp     #:loop                  ' Vergleich

                movd    jump, ntry              ' Ruecksprungadresse eintragen
                ror     ntry, #9                ' Unterprogrammadresse
jump            jmpret  0-0, ntry               ' call (hl)

zurueck         waitpeq $, #0                   ' Alles erledigt.

        
eins            mov     dira, mask
                mov     outa, #"A"
                rev     outa, #8
eins_ret        ret

zwei            mov     dira, mask
                mov     outa, #"B"
                rev     outa, #8
zwei_ret        ret

drei            mov     dira, mask
                mov     outa, #"C"
                rev     outa, #8
drei_ret        ret

mask            long    $00FF0000

ntry            res     1
temp            res     1
hl              res     1

                fit
                
DAT

Hier mit willkuerlicher Rueckkehradresse. Sorry, alles etwas am eigentlichen Thema vorbei :)

Code: Alles auswählen

                movd    push, ntry              ' Ruecksprungadresse vorbereiten
                ror     ntry, #9                ' Unterprogrammadresse
push            movs    0-0, #zurueck           ' anwenderspecifische Rueckkehradresse
                jmp     ntry                    ' call (hl)

                hubop   $, #%10000_000          ' Zutritt verboten!

zurueck         waitpeq $, #0                   ' Alles erledigt.

Hallo "Inquisitor, The"

ich hoffe das du dich nicht zu tief da hinen gesteigert hast, weil ich mittlerweile mein Konzept etwas geändert habe.

Dabei habe ich mich in Richtung des Vorschlages von drohne235 mit den bin Files genähert.

Jetzt habe ich nur noch das Problem die bin files sollen am ende der vga.spin im DAT bereich stehen.
und bei auswahl der entsprechenden version gestartet werden.

Kann mir jemand erklähren wie das gemacht wird? (bitte in spinn)

EEPROM_1.zip

Dabei habe ich mich in Richtung des Vorschlages von drohne235 mit den bin Files genähert.

Wobei sich der Vorschlag mehr auf den Hive bezogen hat, denn dort könnte eine der drei Dateien ja durch den Loader bei Bedarf von SD-Card geladen und gestartet werden.

Im Prinzip geht es auch im DAT-Bereich, aber das ist nicht wirklich effektiv, da man ja dabei massig RAM verschwendet, wenn alle drei Versionen enthalten sind.

Aber möglich ist das schon: Im Loader für Regnatix (aktuelle TriOS-Version) befindet sich im DAT Bereich das Forth und wird dort gestartet. Aber der RAM dort ist nicht verloren, denn wenn man mit dem Forth Kommando "regime" die Kommandozeile startet, wird das Forth beendet und der Loader (läuft ja ständig in einer getrennten COG) holt von SD-Card die Datei reg.sys, speichert sie im Heap und startet sie dann. Der Heap ist dabei identisch mit dem DAT-Bereich.

Das klingt zwar doppelt gemoppelt, da man ja das Forth auch ganz normal wie Regime einfach von SD-Card starten könnte, aber diese Methode hat den Vorteil, dass das Forth (da es ja im DAT-Bereich schon im EEPROM ist) quasi sofort und ohne Ladezeit beim Einschalten verfügbar ist.

---

Ok, zurück zu deinem Problem: Wenn du bei deinem System aber nicht von SD-Card laden kannst, ist es vielleicht besser, den VGA-Treiber beim Aufruf zu parametrisieren um die Auflösung zu wählen.

Aber im Prinzip hat das auch noch einen anderen Nachteil: Wenn du die Auflösung variabel machst, musst du entweder die Größe des Bildschirmpuffers dynamisch anpassen, oder du verwendest immer die Maximalgröße - was letztlich bei 32 KB hRAM auch wieder verschwenderisch ist. Ich verwende im Normalfall am VGA die fixe Auflösung von 1024x768 im Textmodus, was auf meinen Monitoren ein guter Kompromiss ist. Eine höhere oder geringere Auflösung macht im Textmodus einfach keinen Sinn hab ich so für mich festgestellt.

Moin moin!

drohne235 hat geschrieben:.....Ok, zurück zu deinem Problem: Wenn du bei deinem System aber nicht von SD-Card laden kannst, ist es vielleicht besser, den VGA-Treiber beim Aufruf zu parametrisieren um die Auflösung zu wählen.........

Wäre es in diesem Zusammenhang denkbar die Software aus einem zentralen Flash-Speicher zu laden?

drohne235 hat geschrieben:.....Ich verwende im Normalfall am VGA die fixe Auflösung von 1024x768 im Textmodus, was auf meinen Monitoren ein guter Kompromiss ist. Eine höhere oder geringere Auflösung macht im Textmodus einfach keinen Sinn hab ich so für mich festgestellt.........

Diese Auflösung ist dummerweise bei meinem TFT-Bildschirm (60Hz oder 75Hz) leider nicht möglich. Dieser verträgt die 57Hz des Parallax-Treibers nicht so ganz. Ich bin deshalb auf 800x600 (100 x 50 Zeichen) mit 75Hz beim PropIRC (IRC-Chatprogramm) umgestiegen. Beim MOPs (derzeitiges "Betriebssystem" des MonoProp

) bin ich sogar auf 640 x 480 (80 x 40 Zeichen) mit 75Hz gelandet. Dazu mußte ich aber noch einige Parameter ändern.
Kommt halt auf den jeweiligen Monitor an. CRT's sind da manchmal etwas flexibler als TFT's und meiner ist glaube ich besonders zickig

.
Gruß
TuxFan

Hallo,

die zickigen TFT's sind schon das Problem wass ich damit umgehen will.

Im EEPROM_1 ist sowas wie der Administrator des Systems, er wird komplett vom EEPROM geladen.

Das Speicherproblem ist aufgrund das sich die SD-Carte am Prop 2 befindet nicht so kritisch.

Prop 1: ADMIN
wird komplett aus dem EEPROM geladen
vergleicht Boot.bin mit EEPROM und wenn unterschiedlich Boot.bin --> EEPRON --> Reeboot
- den 1. Monitor in Textmodus (Adminisrtative handlungen)
- die Tastatur für das ganze System (umschaltbar über Windowstaste)
- bei der maus binn ich noch am überlegen (echtzeit)

Prop 2: SD
minni bushandling mit readfunktion von 1.SD-Karte(Boot laufwerk)
den EEPROM zu beschreiben
Programmteile zu laden und zu starten und zu benden
- 2x SD-Karten paralel in 2 COG's
- RTC

Prop 3: VID
den EEPROM zu beschreiben
Programmteile zu laden und zu starten und zu benden
- 2. Monitor text/graphig
- Maus (echtzeit)

Prop 3: AUDIO
den EEPROM zu beschreiben
Programmteile zu laden und zu starten und zu benden
- Audio in/out WAV/MIDI .....

Prop 4: SENS
den EEPROM zu beschreiben
Programmteile zu laden und zu starten und zu benden
- alle möglichen I2C Anwendungen

z.Z sollen Programme (da sie die Hartware über den bus Ansprechen) in frei verfügbare COG's gestartet werden aber ich glaube ich spendierre noch zwei Prop's

Daher ist der Speicherplatz nicht so kritisch anzusehen.

Um mein Proplem mit den Laden von Binary files besser zu verstehen suche ich ein kleines Beispiel zum

.

Moin!

PIC18F2550 hat geschrieben:Hallo,
die zickigen TFT's sind schon das Problem wass ich damit umgehen will.

Um die richtige Frequenz (60Hz bzw. 75Hz) zu treffen, hab ich Werte aus der Tabelle auf dieser Seite verwendet : http://web.mit.edu/6.111/www/s2004/NEWKIT/vga.shtml

Ansonsten viel Erfolg bei deinem Projekt.

Gruß
TuxFan

HIVE-Project

VGA_HiRes_Text.spin

Re: VGA_HiRes_Text.spin

Re: VGA_HiRes_Text.spin

Re: VGA_HiRes_Text.spin

Re: VGA_HiRes_Text.spin

Re: VGA_HiRes_Text.spin

Re: VGA_HiRes_Text.spin

Re: VGA_HiRes_Text.spin

Re: VGA_HiRes_Text.spin