atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Fr 05.04.2019, 13:27:00
-
Grafikkarte (Nova) und Atari Falcon ...
Bei einer installierten 16MB Ramkarte werden im Combel hardkodiert 14MB vom TOS genutzt sagte mir @czietz mal. Wäre es nicht möglich das TOS 4 so zu patchen das anstatt 14MB nur 10MB nutzbar sind. Die Grafikkarte belegt durch den Grafikkartentreiber den Bereich von 10MB bis 14MB. Darauf wird ja dann im Grunde doppelt geschrieben einmal in den Grafikkartenspeicher und zum zweiten in den Rechner Ram vom Bereich von 10MB bis 14MB. Also das Betriebssystem darf dann keinen Zugriff mehr auf den Bereich von 10MB bis 14MB haben ...
Wie macht das denn z.B. die Rhothron VME Bus Erweiterung für den Atari Falcon. Der VME Bus sollte doch auch bei 10MB starten?
-
Interesantes Thema. Es lassen sich ja einige Dinge mit der im 68030 enthaltenen MMU anstellen (hab ich mal gehört) . Aber ob es ausreicht ein entrsprechendes Programm in den Autoordner zu packen oder ob der Falcon sich da wegen der sich überschneidenden Speicherbereiche schon vorher weg gebombt, da bin ich überfragt. Denn dann müsste doch das TOS gepatcht werden. Wenn du bloß so gut Assembler könntest wie du löten kannst, dann wäre das auch schon erledigt. ;D
-
Wiederholtes fragen ändert leider nichts der Antwort: Das ist ein Hardwarethema und kann nicht einfach in TOS weggepatcht werden. (Nein, die MMU hilft da ebenfalls rein gar nichts.)
https://forum.atari-home.de/index.php/topic,14594.msg233145.html#msg233145
-
Wenn der Rechner bzw. das Betriebssystem bombt kann man das doch abfangen oder nicht?
-
Das hat mit Deiner ursprünglichen Frage aber nichts zu tun.
-
Es geht ja darum von den 14MB 4MB wegzunehmen/frei zu machen.
-
Irgendwie habe ich das Gefühl mich ständig zu wiederholen: Das ist ein Hardwarethema und kann nicht einfach in TOS weggepatcht werden.
Selbst wenn Du TOS 4 MB RAM wegnähmst (was selbstverständlich trivial wäre), hilft das nichts. Wenn der NOVA-Treiber auf die Grafikkarte zugreifen will, antwortet gleichzeitig auch das RAM. Das kannst Du nicht durch Software/Patches verhindern, weil die Adressdekodierung nicht in Software sondern im COMBEL gemacht wird.
-
Das TOS ließe sich schon dazu bringen, den Speicherausbau oberhalb 10 MB zu ignorieren (das obere Ende des ST-RAMS steht in der Systemvariable _memtop, was darüber liegt, wird von TOS nicht angefaßt.
Bloß ist das nur die eine (einfachere) Hälfte der Miete.
Du kannst nicht einfach auf zwei Speicher gleichzeitig schreiben und erwarten, dass das einfach so funktioniert. Selbst wenn die Bustreiber in der Lage wären, beide Speicher gleichzeitig zu "versorgen" (was ich bewzeifle), würden auch beide ein DTACK schicken. Und das garantiert nicht zum exakt selben (richtigen) Zeitpunkt.
Das kann nicht gut gehen.
Interesantes Thema. Es lassen sich ja einige Dinge mit der im 68030 enthaltenen MMU anstellen (hab ich mal gehört)
Die 68030-MMU kann eine ganze Menge. Aber Wunder wirken kann sie nicht.
-
Ich traue mich ja kaum hier mitzulesen ... ;-)
Also bestünde doch eventuell Hoffnung !?!
-
Ich traue mich ja kaum hier mitzulesen ... ;-)
Also bestünde doch eventuell Hoffnung !?!
Mir dünkt, Du hast nicht zuende gelesen?
-
DTACK wird durch die Hardware ausgelöst? Und das kann ein Programm nicht verhindern, oder?
-
mfro hat -- nur etwas ausführlicher und eloquenter -- das gleiche geschrieben wie ich: Das ist ein Hardwarethema und kann nicht einfach in TOS weggepatcht werden.
-
Die 4MB der Grafikkarte liegen doch auf dem Bereich zwischen 10MB und 14MB. Ist doch gemappt, oder?
Kann das nicht völlig egal sein was da in den Speicher geschrieben und gelesen wird, wenn das Betriebssystem dafür gesperrt ist?
-
Wie würde das in Hardware aussehen?
Ist es der Combel der das /DTACK erzeugt abhängig von der Adresse und den vergangenen Zyklen?
Wenn dem so ist, könnte man dann das Signal unterbrechen und mittels eines Adressdecoder im Bereich oberhalb 10MB verhindern? Dann bliebe aber noch das Problem das erst zu aktivieren wenn das 14MB Modul bereits erkannt ist, richtig?
-
Trotzdem würde man in zwei Speicher an der selben physischen Adresse schreiben. Das ginge zwar gut, solange ein DTACK unterbunden wird. Aber was ist, wenn der Grafiktreiber Status-Register oder so aus der Grafikkarte auslesen müsste? Dann würde gleichzeitig das RAM mit garantiert anderem Inhalt antworten.
Man könnte höchstens über eine Art Bankswitching nachdenken. Das würde aber umfangreiche Änderungen an der Platine erfordern, man müsste die Adressleitungen zwischen CPU und Combel auftrennen und da entsprechende Logik verbauen und irgend einen Weg finden, wie man die Bank schnell umschalten kann. Programme die dann auf der RAM Karte in Bankswitch-Bereich liegen, können dann etweder garkeine Grafik ausgeben, oder nur quälend langsam.
Das einfachste wird wohl sein, zu versuchen, sich noch eine ct60e zu sichern, wenn nochmal welche aufgelegt werden, und drauf hoffen, dass es nochmal SuperVidels gibt. Ist halt nicht wirklich billig.... Oder darauf hoffen, dass es mal eine Vampire für den Falcon gibt, an der für den A1200 wird ja schon gearbeitet - die A1200 Trapdoor-Schnittstelle dürfte technisch recht nah am Falcon-Erweiterungsbus sein.
-
Wenn man das mit 8MB machen würde könnte man an der ST-RAM Karte die 24te Adressleitung trennen. Dann müsste evtl. das Falcon-TOS noch angepasst werden, falls es sich nicht selbst über den Speichertest darauf einstellen kann. Der Zugriff über der 8MB Grenze wäre dann nicht auf zwei Speicherbereiche gleichzeitig und könnte sich auf den Grafikadapter konzentrieren.. Der Aufwand sollte dann von der Hardwareseite erheblich geringer sein, oder? Ich hoffe jemand versteht wie ich es meine. ;D
-
Das geht ja schon lange so ähnlich mit der Magnum Falcon (8MB gedrosselt auf 6) und einer 4MB ST-RAM Karte. Macht nur keinen Spaß, weil der Speicher da immer noch knapp und arg fragmentiert ist.
Wenn man dann mehr haben will, landet man ganz schnell bei Erweiterungen wie CT2, CT63 und ähnlichen Konzepten.
MfG
Ektus.
-
Das geht ja schon lange so ähnlich mit der Magnum Falcon (8MB gedrosselt auf 6) und einer 4MB ST-RAM Karte. Macht nur keinen Spaß, weil der Speicher da immer noch knapp und arg fragmentiert ist.
@Ektus, und es ist einfacher eine Leitung auf zu trennen als eine Platine neu aufzulegen. So lange kein MiNT benötigt wird, mit mehreren Anwendungen im RAM ist das gar nicht so schlecht. Neu Speicherkarten für den Falcon könnten auch gleich einen passenden Jumper auf 8MB mitbringen. :D Und Geneva z.B. läuft auch mit wenig Speicher auf einen ST noch.
-
Einfach eine Adressleitung auftrennen, ich weiß nicht, ob das bei DRAM geht, ob das reicht, um es still zu legen. Und es stellt sich die Frage, wie TOS auf 8 MB RAM reagiert, statt erwartete 1, 2, 4 oder 14 MB.
-
Einfach eine Adressleitung auftrennen, ich weiß nicht, ob das bei DRAM geht, ob das reicht, um es still zu legen.
A24 zu den Chips kann ja auf einen definierten Pegel gelegt werden. A24 vom Board wird ja dann an der Grafikkarte anliegen...
Und es stellt sich die Frage, wie TOS auf 8 MB RAM reagiert, statt erwartete 1, 2, 4 oder 14 MB.
der Rest stand schon oben in #15 wegen des TOS.
-
Eine PAK mit Fastram für den Falcon wäre was. Dann könnte man bei 4MB ST Ram bleiben.
Mit A24 meint ihr doch A23, oder? Der Falcon ist ein 16bit Rechner. Die Adressen die zum Speicher gehen liegen innerhalb vom Combel, da kommt man nicht ran.
Die Idee von Idek klingt doch gut ...
-
Mit A24 meint ihr doch A23, oder?
Ja.
-
Die Adressen die zum Speicher gehen liegen innerhalb vom Combel, da kommt man nicht ran.
Kannst du das näher erläutern?
-
Schaue dir mal die Magnum Schaltpläne an ...
Mit Adressen die zum Speicher gehen meine ich wie beim ST die MAD0 bis MAD9 für 4MB oder eben plus MAD10 dann bis 16MB im Falcon. Das liegt beim ST in der MMU und beim Falcon im Combel. Im Magnum Schaltplan sind das die 74F157 Gatter ...
-
Frank, wenn ich auf der 14MB Speichererweiterung des Falcon a23 trenne, also nur 8MB physikalisch adressieren kann, dann ist doch keine Überschneidung des Speichers mehr vorhanden. Ich verstehe nicht was die Innereien des Combel damit zu tun haben.
-
Da sind RAS, CAS, WE, D0-D15 sowie MAD0-MAD10
Wo ist da A23, A23 ist nur am Combel zur Generierung von MAD0-MAD10
-
Frank, wenn ich auf der 14MB Speichererweiterung des Falcon a23 trenne, also nur 8MB physikalisch adressieren kann, dann ist doch keine Überschneidung des Speichers mehr vorhanden. Ich verstehe nicht was die Innereien des Combel damit zu tun haben.
Guck Dir den Schaltplan einer Speichererweiterung an: es gibt dort gar keine Leitung A23! Der COMBEL dekodiert die Adressen bereits aus, in Zeilen- und Spaltenadressen. Du kannst auf der Speichererweiterung keine Leitungen trennen, um den COMBEL dazu zu bringen, nur 8 MB zu adressieren.
PS: Frank war schneller...
-
Was ist denn mit der Idee von Idek das DTACK abzufangen?
-
Ich denke, man müsste stattdessen den kompletten Buszugriff abfangen, d.h. /AS zwischen CPU und COMBEL unterbrechen und nur durchlassen, wenn Adressen zwischen 0 - 10 MB auf dem Bus liegen. Eine konkrete Schaltungsidee habe ich aber nicht, zumal ich mangels Falcon-Erfahrung nicht einschätzen kann, welche Nebenwirkungen auftreten.
Zudem denke ich, dass die wenigsten Falcon-Besitzer bei ihren kostbaren Rechnern Leiterbahnen auf dem Mainboard durchtrennen wollen.
-
Jetzt hab ich es verstanden... danke @Lukas Frank u. @czietz für eure Geduld.
-
XAS geht an zwei der fünf Bussteuer GALs und zwar an U63 und U68 aber weiss jetzt nicht wo das ausser an die CPU sonst doch hingeht. Am Combel einen Pin hochlegen und da einen Fädeldraht anlöten ist nicht ohne. Eine Leiterbahn auf der Platine kappen ist schon besser und Gangbarer.
Und ob der Aufwand dann lohnt ist die Frage. Ein 32bit 030 auf dem Erweiterungsbus mit Fastram wäre besser. Mit CT60 und Co läuft der Novaadapter trotz 4MB ST Ram nicht, mit Afterburner 040 schon.
-
Ein 32bit 030 auf dem Erweiterungsbus mit Fastram wäre besser.
Gab es ja, Mighty Sonic 32 (http://wiki.newtosworld.de/index.php?title=Mighty_Sonic_32). Betonung auf der Vergangenheitsform, leider. Ich fand das eine ziemlich gute Karte, bei einem Freund lief die prima. Sehr kompatibel mit alter Software, da „nur“ 68030, aber doch fix mit moderner, dank echtem 32-Bit-Fast-RAM.
-
Ohne 68080 macht keine Spaß mehr. :D
-
Mich interessiert das auch nur akademisch. Meine Falcons stehen normalerweise zwar eher ungenutzt im Schrank rum, aber riskieren würde ich die "Wertanalage" dann doch nicht. >:D