Klingt gut, nur bitte aufpassen wegen Urheberrechtsverletzung.... mich nervt die Sanduhr auch
EmuTOS fehlt aber noch jede Menge mehr zum original Atari TOS. Zum Beispiel läuft eine VME Bus Grafikkarte nicht beim Mega STE mit EmuTOS ...
Das TOS spiegelt den Grafikkartenspeicher im ST Ram und das funktioniert nicht. Da ist viel zu viel Ram frei und die Bildschirmausgabe zerstört...
Egal ob NVDI Matgaph oder ET4000 oder der Nova Treiber, die Spiegeln alle den Grafikkartenspeicher noch mal im ST Ram...Das mag sein, funktioniert aber nur in mono. In den Farbmodi geht's nicht (inkompatibler Plane-Aufbau).
@czietz ... habe mich mal eingeschrieben. Wie genau schreibe ich denn etwas ?
Egal ob NVDI Matgaph oder ET4000 oder der Nova Treiber, die Spiegeln alle den Grafikkartenspeicher noch mal im ST Ram.Das betrifft aber nur den TT und das ist jenseits der ersten 4 MB, wahrscheinlich sogar jenseits der ersten 10 MB, also irgendwo da wo auch "Altram" liegt, im Profibuch steht die Adresse drin. Beim Mega-STE wird im ST-RAM die gleiche Adresse verwendet, wie beim TT gespiegelt.
Egal ob NVDI Matgaph oder ET4000 oder der Nova Treiber, die Spiegeln alle den Grafikkartenspeicher noch mal im ST Ram.
Mit einer 1MB Grafikkarte habe ich bei einem 4MB Rechner so 2,7MB frei ohne andere Sachen im Auto Ordner.
Ohne alles bleibt beim Mega STE mit 4MB unter ST-Hoch 3,74MB an freien Speicher.
Mit Nova Treiber bei 1024x768 /256 Farben bleiben 2,96MB an freien Speicher.
Mit Nova Treiber bei 1024x768 /2 Farben bleiben 3,31MB an freien Speicher.
Mit Nova Treiber bei 640x480 /16 Farben bleiben 3,48MB an freien Speicher.
Ob das jetzt im ST Ram gespiegelt wie ich schrieb oder Buffer sind soll mir ja egal sein. Dafür habe ich zu wenig Ahnung ...
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.
@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.
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.
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.
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).
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
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).
und inwiefern unterscheidet sich jetzt (abgesehen davon, daß Du - im Gegensatz zu mir - falsch abgeschrieben hast) von dem, was ich geschrieben habe?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.
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.
$PEOO OOOO .. $PEPE FFFF
Ich hatte das nur irgendwo gelesen, und die Adressen stammen aus dem Profibuch. Seitenangabe siehe oben, lies selbst.
...
In den Archiven befinden sich folgende fertige Images:
emutos-aranym
emutos (Firebee)
etos512k
etos256de
etos192de
...
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.
Versuche nicht, mich hier irgendwie fertig zu machen.
... da ich die Sanduhr von EmuTOS nicht gerade sehr gelungen finde ...
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.
Versuche nicht, mich hier irgendwie fertig zu machen.
Keineswegs.
Ich kann's auch nicht ab, wenn ich mal nicht recht habe 8) .
Aber ich finde, es zeugt von innerer Größe, das bei passender Gelegenheit mal zuzugeben. Würde dir gut anstehen ...
... 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.
So wird das leider (aus - für mich nachvollziehbaren - Copyright-Überlegungen heraus) wahrscheinlich eher nix.
Vielleicht gibt's aber einen Workaround, der es ermöglicht, die Mauszeiger über die EMUICON.RSC nachzuladen.
Ist verständlich, dass man das nicht offiziell einpflegen möchte, wenn es Copyright-Bedenken gibt...
Die Mauszeiger rauszunehmen halte ich nicht für sinnvoll. Man will nicht immer von Platte booten, und man will die Mauszeiger nicht auf jede Diskette kopieren.Die eingebauten sollen ja nicht raus, sondern auf Wunsch "übersteuerbar" sein.
Vielleicht setzt sich einer hin und pixelt eine neue Biene, die aber an das Original erinnert? Oder eine Hummel?Es gibt nichts Gutes, außer man tut es.
Ist verständlich, dass man das nicht offiziell einpflegen möchte, wenn es Copyright-Bedenken gibt. Mich würde mal interessieren, wer die Copyrights auf das Bienchen hält.
Was EmuTOS angeht, habe ich schon das Gefühl, dass die Team-Mitglieder mehr wollen, als "nur" einen simplen TOS-Ersatz für Emulatoren zu schaffen ..... Aber vielleicht haben die Entwickler auch schlicht Spaß am Implementieren der neuen Funktionen :)Das eine geht nicht ohne das andere ;)
Aber bisher unterstützt ja EmuTOS noch nicht mal den TT.
EmuTOS is a single-user single-tasking operating system for 32-bit Atari
computers, clones and emulators. It [...] can also run on some real
hardware, including the Atari ST(e), TT, [...].
This ROM is suitable for the following hardware:
- TT
[...]
Die Mauszeiger rauszunehmen halte ich nicht für sinnvoll. Man will nicht immer von Platte booten, und man will die Mauszeiger nicht auf jede Diskette kopieren.
Vielleicht setzt sich einer hin und pixelt eine neue Biene, die aber an das Original erinnert? Oder eine Hummel?
Ein TT ohne SCSI ist uninteressant, von einem externen Laufwerk booten? Solange EmuTOS die Hardware eines Rechners nicht vollständig funktioniert. ist es darauf wertlos.
... Wenn nicht die gesamte Hardware der Maschine unetrstützt wird, dann unterstütz es diese Maschine nicht...
Wieso? TOS 3.06 unterstützt alle Hardwaredes TT, und TOS 4.04 alle Hardware des Falcon.
... Ein Bootlaufwerk aber lässt sich durch nachträgliche Software nicht einbinden...
Ja, so kann man natürlich ne Diskussion auch abwürgen. Ich will von meiner ohnehin vorhandenen SCSI Platte (73 GB groß, leise und schnell genug) booten. Ist das so schwer zu verstehen?
Wieso? TOS 3.06 unterstützt alle Hardwaredes TT, und TOS 4.04 alle Hardware des Falcon.
Soweit ich mich erinnere gabs bei dem LAN Port auch noch ein rechtliches Problem, denn dieser LAN Port ist hardwareseitig identisch mit Apple Local Talk. Man konnte/wollte die Konkurrenz nicht unnötig aufscheuchen.
Möglich ist auch, dass als die LAN-Hardware im TT, M-STE und Falcon schon fertig war, dass sich zeitglich Ethernet (BNC, RJ45) durchsetzte und das miteinander nicht kompatibel ist und man deswegen für diese Schnittstelle die Prio weg genommen hat - sollen doch andere was damit machen...
... aber die Beschränkung auf max 4 Fenster auf dem Desktop rührt ja auch da her, das ist ja keine technische Beschränkung...
Ja. Soweit ich das weiß, ist das eine Abfrage an einer Stelle im Desktop, da steht die Zahl 4 drin. WinX patcht genau das, wenn man die Beschränkung aufhebt. Und wenn man in TOS 4 Laufwerksfenster auf hat, kann man immer noch zusätzlich bis zu 6 ACC Fenster aufmachen, Control, XControl, Kubis, Paula, ... die machen ja allesamt richtige Fenster auf, macht dann schon insgesamt 10 Fenster ohne zu patchen.
RS422 Softwareunterstützung? Nope. Nullkommanull.
In Cubase gibt es einen Treiber für diese Schittstelle. Man kann dann z.B. einige MIDI-Interfaces
Ich habe gerade festgestellt, daß Android anscheinend auch ein 4-Fenster-Problem (http://smartundzart.de/was-bedeutet-die-meldung-limit-fuer-fenster-erreicht-bei-android-smartphones/) hat. Angst vor Apple? >:D Haben die immer noch das Patent auf das 5. Fenster? ;D
... Stimmt, das war der zweite Grund mir so ein Kabel mal zusammen zu löten, denn mein Yamaha MU90R Racksynthesizer hat neben normalen Midi-Schnittstellen auch so ein Interface und kann darüber 32-Stimmig angesteuert werden.
... Wenn nicht die gesamte Hardware der Maschine unetrstützt wird, dann unterstütz es diese Maschine nicht...
Der MU90R hat RS422.
Nehme ich meinen TT und stecke da das aktuelle EmuTOS rein und meckere dann dass ich damit nicht von SCSI booten kann, sagen mir die EmuTOS Entwickler, das wird nicht unterstützt. Einsatz von EmuTOS nicht sinnvoll.
Wo ist da jetzt der Unterschied? KEINER!
Beim EmuTOS auf dem Amiga ist aber immerhin der Wille da, das zu unterstützen.
Und EmuTOS auf dem Amiga steht ja noch ganz am Anfang, dafür dass nur eine Person an Amiga-Unterstützung arbeitet, ist das schon ziemlich enorm.