EmuTOS mit "BusyBee"

[mfro]

Auf einem Atari Mega ST4 mit TOS 1.04 und VOFA ET4000 Adapter mit der Nova Treibersoftware ist das Bild gleich ...

gleich wie was?

Unter EmuTOS bleibt fast der gesamte Speicher frei und die Bilddarstellung über die Grafikkarte ist komplett zerstört. Man erkennt kaum den Desktop.

Wenn das schon der Fall ist, bevor das erste Mal ein Menü runtergeklappt oder eine Alert-Box dargestellt wurde, hat es m.E. nichts mit dem "quarter size screen buffer" zu tun.

Wann tritt das Problem genau auf?

[mfro]

@czietz und @mfro ich weiß das ihr beiden mit aktiv Arbeitet am EmuTOS, wie seht ihr das, wäre es theoretisch möglich die Screen Emulation der Nova mit ins EmuTOS mit einzubauen ? So das quasi schon nach dem Einschalten der Willkommensscreen von EmuTOS über die Grafikkarte kommt ? Für TOS gibt es da einen Patch aber hab ihn selbst noch nicht zum laufen gebracht. Leider sind meine Programmierkenntnisse beschränkt.

Klar ginge das. Technisch würde das wahrscheinlich nur am mangelnden Platz in den ROMs klemmen.

Aber:

EmuTOS ist Open Source. Die Nova-Treiber sind es (zumindest meiner Kenntnis nach) nicht.

Den Konflikt könnte man wohl nur durch Neuschreiben (oder eine komplette Offenlegung der Quellen) lösen, also wird das wahrscheinlich eher nicht passieren, denke ich.

[1ST1]

Sicher? Dann würde aber der Bus enorm belastet werden, gerade bei hohen Farbpixelmengen, der müßte ja dauernd >= 500 KB bei n Hz durch den Bus kopieren.

Es geht nicht um den Datenfluss zwischen Mainboard und der Grafikkarte, der gespielegelt (verdoppelt) wird, sondern die VME-Karten sind beim TT an zwei Adressen eingeblendet, die selben Register, die selben RAM-Zellen, nur eben einal an der Originaladresse jenseits von 16 MB, und einmal nach unten gespiegelt, irgendwo zwischen 10 und 12 MB.

[mfro]

Sicher? Dann würde aber der Bus enorm belastet werden, gerade bei hohen Farbpixelmengen, der müßte ja dauernd >= 500 KB bei n Hz durch den Bus kopieren.

Es geht nicht um den Datenfluss zwischen Mainboard und der Grafikkarte, der gespielegelt (verdoppelt) wird, sondern die VME-Karten sind beim TT an zwei Adressen eingeblendet, die selben Register, die selben RAM-Zellen, nur eben einal an der Originaladresse jenseits von 16 MB, und einmal nach unten gespiegelt, irgendwo zwischen 10 und 12 MB.

Erstens hat das nichts mit dem hier beschriebenen Problem zu tun (wie soll das angebliche Spiegeln von VME-Adressraum den Hauptspeicher reduzieren?), zweitens ist es m.E. sowieso ein Gerücht.

Im TT liegt der VME-Adressraum von $FE000000 - $FEFFFFFF (belegt also die 16 MB direkt unterhalb der I/O Adressen). Im Mega STE liegt er bei $A00000 - $DFFFFF (belegt also die 4 MB direkt unterhalb der ROMs).

Allein schon wegen der unterschiedlichen Größe der Adressräume (bedingt durch die Adressknappheit des 68000ers mit seinem 24-Bit Adressbus) macht eine Spiegelung keinen Sinn.

[goetz @ 3rz]

Da dürfte es sich um den von @gh-baden angesprochenen "quarter size screen buffer" handeln. Das ist ein Speicherbereich der AES, wo sie den Bildschirmhintergrund hin retten, wenn Menüs oder Alertboxen angezeigt werden.

Der Puffer ist bei EmuTOS keinesfalls 1/4 des Bildspeichers, aber mindestens 8 kB bzw. mindestens 50 x 10 Zeichen groß (das müssten dieselben Werte wie TOS 1.04 sein).

Hmm. TOS.HYP sagt in http://toshyp.atari.org/de/008002.html#Der%20Quarter-Screen-Buffer (das ist übrigens ziemlich 1:1 aus dem Profibuch kopiert …):

GEM-Version	Methode zum Setzen des QSB	Menge
1.0 und 1.2	statisch	8000 Bytes
1.4	dynamisch	Viertel des Bildspeichers
3.0	dynamisch	Hälfte des Bildspeichers

[…]

Eine gute Formel wäre:
   500 (Zeichen) * Platzbedarf eines Zeichens * Farbebenen

[1ST1]

Im TT liegt der VME-Adressraum von $FE000000 - $FEFFFFFF (belegt also die 16 MB direkt unterhalb der I/O Adressen). Im Mega STE liegt er bei $A00000 - $DFFFFF (belegt also die 4 MB direkt unterhalb der ROMs).

Schau mal ins Profibuch. Seite 1193

Im  TT030  findet sich für Standard-Zugriffe (24 Bit!) der VME-Bus-Adreßraum bei
$PEOO  OOOO  ..  $PEPE FFFF.FürShort-Zugriffeliegtder Adreßbereich bei $FEFF 0000  ..
$FEFF  FFFF.  Im  MEGA  STE  liegt der 24 Bit-Adreßraum bei $  AO  0000 bis  $DE  FFFF.
Short-Zugriffe "landen"  im  MEGA  STE  bei  $DF  OOOO  ..  $DF  FFFF.

Das ist die Hardware-Adressdecodierung. Irgendwo, muss nicht im Profibuch sein, war aber noch zu lesen, dass neben den ST-Shifter-Register im TT-Shifter per PMMU und TOS 3.06 das VME-Fenster auch nach "unten" gespiegelt wird.

[mfro]

Im TT liegt der VME-Adressraum von $FE000000 - $FEFFFFFF (belegt also die 16 MB direkt unterhalb der I/O Adressen). Im Mega STE liegt er bei $A00000 - $DFFFFF (belegt also die 4 MB direkt unterhalb der ROMs).

Schau mal ins Profibuch. Seite 1193

Im  TT030  findet sich für Standard-Zugriffe (24 Bit!) der VME-Bus-Adreßraum bei
$PEOO  OOOO  ..  $PEPE FFFF.FürShort-Zugriffeliegtder Adreßbereich bei $FEFF 0000  ..
$FEFF  FFFF.  Im  MEGA  STE  liegt der 24 Bit-Adreßraum bei $  AO  0000 bis  $DE  FFFF.
Short-Zugriffe "landen"  im  MEGA  STE  bei  $DF  OOOO  ..  $DF  FFFF.

und inwiefern unterscheidet sich jetzt (abgesehen davon, daß Du - im Gegensatz zu mir - falsch abgeschrieben hast) von dem, was ich geschrieben habe?

Das ist die Hardware-Adressdecodierung. Irgendwo, muss nicht im Profibuch sein, war aber noch zu lesen, dass neben den ST-Shifter-Register im TT-Shifter per PMMU und TOS 3.06 das VME-Fenster auch nach "unten" gespiegelt wird.

Dann mußt Du mir jetzt bloß noch erklären, wie Du 16 MB VME-Adressraum im Mega STE unterbringen willst?

[1ST1]

Es wird wohl nur so viel eingeblendet, wie man im Mega STE auch zu sehen bekommt. Mir ist auch keine VME-Karte für den M-STE/TT bekannt, die mehr nutzt. Der 16 MB Adressraum war wohl gedacht, wenn man einen TT mit mehreren Slots ausstattet (wie es Rhotron tat).

Übrigens, das ist kein ABgeschrieben, sondern Copy&Paste aus der PDF, ohne Korrektur.

[Lukas Frank]

Es gibt 1, 2 und 4MB Grafikkarten für den VME Bus ...

[mfro]

Es wird wohl nur so viel eingeblendet, wie man im Mega STE auch zu sehen bekommt. Mir ist auch keine VME-Karte für den M-STE/TT bekannt, die mehr nutzt. Der 16 MB Adressraum war wohl gedacht, wenn man einen TT mit mehreren Slots ausstattet (wie es Rhotron tat).

Übrigens, das ist kein ABgeschrieben, sondern Copy&Paste aus der PDF, ohne Korrektur.

... und was sollen

$PEOO  OOOO  ..  $PEPE FFFF

für Adressen sein? Ist doch Quatsch.

Auch in der Sache muß ich dich enttäuschen: ich habe mir gerade die TT PMMU Tables angeschaut.

Kein Remapping des VME Adressraums.

Aber das ist in deinem TT natürlich gaaanz anders. Meine Empfehlung: schreib' lieber über Sachen, von denen Du was verstehst.

[1ST1]

Ich hatte das nur irgendwo gelesen, und die Adressen stammen aus dem Profibuch. Seitenangabe siehe oben, lies selbst.

[mfro]

Ich hatte das nur irgendwo gelesen, und die Adressen stammen aus dem Profibuch. Seitenangabe siehe oben, lies selbst.

In *meinem* Profibuch steht das, was ich oben geschrieben habe. Mir scheint, dein OCR hat versagt.

[mfro]

...
In den Archiven befinden sich folgende fertige Images:
emutos-aranym
emutos (Firebee)
etos512k
etos256de
etos192de
...

Um wieder zum eigentlichen Thema zurückzukommen, ein kleiner Tip: EmuTOS bringt einen eigenen Lader mit, mit dem man auch auf "echter Hardware" testen kann, ohne daß man gleich ROMS brennen muß.

Das make Target "prg" erzeugt ein emutos.prg, das man bequem direkt als RAM-TOS starten kann. Wenn Du das noch dazulegst, kann's jeder ganz einfach ausprobieren.

[1ST1]

Ich hatte das nur irgendwo gelesen, und die Adressen stammen aus dem Profibuch. Seitenangabe siehe oben, lies selbst.

In *meinem* Profibuch steht das, was ich oben geschrieben habe. Mir scheint, dein OCR hat versagt.

Du kennst die Webseite, wo man die PDF frei herunterladen kann? Darin habe ich mit der Maus die Textpassage markiert, STRG+C und mit STRG+V wieder hier rein. Keine Modifikation, nichts. Versuche nicht, mich hier irgendwie fertig zu machen.

[tuxie]

Lieber @1ST1 das hex System geht nur bis F und nicht bis P und nein auch im Profibuch steht F. Daher hat die OCR Software die den Text dahinter gelegt hat scheisse gebaut. Da ich dir ein gewisses IT wissen zu schreibe und ich mir auch sicher bin das du das hast. Wirst auch du wissen das hex nur bis F geht. Hier ist definitiv ein Fehler bei der OCR Erkennung entstanden.

[mfro]

Versuche nicht, mich hier irgendwie fertig zu machen.

Keineswegs.

Ich kann's auch nicht ab, wenn ich mal nicht recht habe  .

Aber ich finde, es zeugt von innerer Größe, das bei passender Gelegenheit mal zuzugeben. Würde dir gut anstehen ...

[mfro]

... da ich die Sanduhr von EmuTOS nicht gerade sehr gelungen finde ...

Ich habe deine Änderung gerade beim EmuTOS-Team eingekippt. Mal sehen, was die Herren daraus machen.

[Grendell]

Um wieder zum eigentlichen Thema zurückzukommen, ein kleiner Tip: EmuTOS bringt einen eigenen Lader mit, mit dem man auch auf "echter Hardware" testen kann, ohne daß man gleich ROMS brennen muß.

Das make Target "prg" erzeugt ein emutos.prg, das man bequem direkt als RAM-TOS starten kann. Wenn Du das noch dazulegst, kann's jeder ganz einfach ausprobieren.

Das ist ne gute Idee, ich werde das heute abend mal dazu packen.

[1ST1]

Versuche nicht, mich hier irgendwie fertig zu machen.

Keineswegs.

Ich kann's auch nicht ab, wenn ich mal nicht recht habe  .

Aber ich finde, es zeugt von innerer Größe, das bei passender Gelegenheit mal zuzugeben. Würde dir gut anstehen ...

Ich habe nur Copy & Paste gemacht, ohne es zu korrigieren. Man sieht ja auch, dass das was da aus der Zwischenablage kommt, auch Probleme mit den Wortabständen hat. Das war mir schlicht zu viel um das alles zu korrigieren. Ich traue euch durchaus so viel Intellekt zu, das alles selbst festzustellen.

[1ST1]

Das mit dem Committen der Busy-Bee finde ich sehr gut. Damit kommt EmuTOS wieder ein Stück näher an das Original heran. Und jetzt noch eine andere Frage: neulich wurde von irgendjemand hier bei EmuTOS ja auch die Desktop Icons geändert, bzw. dass diese nachgeladen werden. Wurde das auch an die Hauptentwickler weiter gegeben? (Kann sein dass das schon geschrieben wurde, ich erinnere mich aber nicht mehr und finde gerade den Thread nicht)