Hallo,

Mega-Hz hat uns doch seine ausdekodierte PIA gezeigt, in seinem Rechner belegt die PIA nur noch die $D300-$D303. Die bisherigen Schattenadressen bis $D3FF sind also frei für neue Erweiterungen. In meinem Beispiel eine weitere PIA auf $D304-$D307.

Wie wäre es denn, wenn man eine Ramdisk entwirft, die zwar mit Bankswitching nach bewährtem Muster funktioniert, aber als Steuerung nicht PORTB $D301 sondern freie Bytes auf einer 2. PIA nutzt. In meiner Vision ist dies eine SRAM Erweiterung und Batteriegepuffert. Rein technisch wohl kein grösseres Problem als andere Erweiterungen auch.

Ich weiss jetzt leider nicht genau, wie ein DOS die Ramdisk nutzt.
Ist es möglich, die Ramdiskverwaltung zB von SpartaDOS, BeweDOS oder MyDOS umzuschreiben, das sie statt auf $D301 auf (zB.) $D304 zugreift? Jetzt könnte der Ramdisktreiber alle 8 Bits von $D304 nutzen, um problemlos jede Menge Bänke zu schalten. Richtig grosse RamDisks die nur über PortB geschaltet werden haben ja so ihre Kompatibilitätsprobleme. Mit der Nutzung eines freien Bytes wären die allesamt passé...

Ultimativ wäre es, wenn man sowohl ein herkömmliche Ramdisk (weiters XE-RD genannt) als auch eine über $D304 gesteurte XE Ramdisk (weiters Super-RD genannt) im gleichen Rechner haben könnte.

Dann hätte der User eine gepatchte Sparta-(Bewe-/ My-)-DOS Installation in der Super-RD, mit der er arbeiten, seine Files organisieren usw. kann. Wird aus der Super-RD ein programm geladen, das eine Ramdisk nutzt, wird es die XE-RD ansprechen und die Daten in der Super-RD nicht verändern!

Man könnte also zB Numen sehr flott aus der Super-RD laden, es nutzt für sich die XE-RD und nach der Demo macht man einen Kaltstart um in Sekundenschnelle aus der Super-RD zu booten.

Da die Super-RD per Batterie gepuffert ist, kann man jederzeit von der hohen Geschwindigkeit des Ramdisk-Prinzips profitieren.

Mit den 8 Bits in $D304 könnte man mit Bankswitching nach XE-Manier 4096kB kontrollieren, oder? Liesse sich auch ein RD-Treiber schreiben, der 2 Bytes zum Bankswitching nutzt? Dann wären einige MByte grosse RDs denkbar.

Was meint ihr, ist das machbar?

Gruss,
Stefan

Hi,

Beetle hat geschrieben:Ich weiss jetzt leider nicht genau, wie ein DOS die Ramdisk nutzt.

Das ist von Dos zu Dos unterschiedlich. Atari-DOS 2.5 hat einen nachladbaren Treiber. MyDOS hat die Verwaltung eingebaut, da der Quellcode verfügbar ist, kann man dieses DOS ändern. Sparta und Bewe-Dos haben nachladbare Treiber.

Generell kan man bei fast allen DOS Systemen den CIO Vektor "umbiegen" und alle Zugriffe auf die Super-Ramdisk vor dem DOS abgreifen.

Beetle hat geschrieben:Ist es möglich, die Ramdiskverwaltung zB von SpartaDOS, BeweDOS oder MyDOS umzuschreiben, das sie statt auf $D301 auf (zB.) $D304 zugreift? Jetzt könnte der Ramdisktreiber alle 8 Bits von $D304 nutzen, um problemlos jede Menge Bänke zu schalten. Richtig grosse RamDisks die nur über PortB geschaltet werden haben ja so ihre Kompatibilitätsprobleme. Mit der Nutzung eines freien Bytes wären die allesamt passé...

Softwaretechnisch kein grossen Problem. Man muss nur 1-2 K freien Speicher finden.

Beetle hat geschrieben:Ultimativ wäre es, wenn man sowohl ein herkömmliche Ramdisk (weiters XE-RD genannt) als auch eine über $D304 gesteurte XE Ramdisk (weiters Super-RD genannt) im gleichen Rechner haben könnte.

Dann hätte der User eine gepatchte Sparta-(Bewe-/ My-)-DOS Installation in der Super-RD, mit der er arbeiten, seine Files organisieren usw. kann. Wird aus der Super-RD ein programm geladen, das eine Ramdisk nutzt, wird es die XE-RD ansprechen und die Daten in der Super-RD nicht verändern!

Das alles sollte möglich sein.

Beetle hat geschrieben:Man könnte also zB Numen sehr flott aus der Super-RD laden, es nutzt für sich die XE-RD und nach der Demo macht man einen Kaltstart um in Sekundenschnelle aus der Super-RD zu booten.

Das wird schwierig. Die Superramdisk wird über ein DOS oder einen nachgeladenen Treiber angesprochen. Wenn ein Kaltstart ausgelöst wird, dann sind die Treiber weg. Um von einer RamDisk "booten" zu können, muss das OS angepasst werden (QMEG-OS kann das).

Beetle hat geschrieben:Da die Super-RD per Batterie gepuffert ist, kann man jederzeit von der hohen Geschwindigkeit des Ramdisk-Prinzips profitieren.

Mit den 8 Bits in $D304 könnte man mit Bankswitching nach XE-Manier 4096kB kontrollieren, oder? Liesse sich auch ein RD-Treiber schreiben, der 2 Bytes zum Bankswitching nutzt?

Was meint ihr, ist das machbar?

Es lassen sich softwaretechnisch beliebig viele Bytes zum Bankswitching benutzen. Der Algorithmus wird nur ein wenig aufwendiger, der Datenstrukturen grösser, aber nur ein bisschen. 16 MB Ramdisk sollten kein grosses Problem sein.

Ciao

Carsten

Hallo Beetle

Wie Du vielleicht schon gesehen hast, benutzt meine RAMdisk 6 Bits der Adresse $D301. Falls es mir gelingt, die Timing Fehler (liegt warscheinlich an der Sch**ß CPU) raus zu kriegen, hatte ich geplannt, auch mal etwas mehr ein zu bauen als "nur" 1MB. Es gab ja mal 30 Pin SIMMs mit 4MB oder sogar 16MB. Als extra Adresse wollte ich auch eine der Schattenadressen benutzen, die um ein vierfaches oberhalb von $D301 liegen. Also entweder $D305, oder $D309, usw.

Jetzt rechne ich mal kurz:
6 Bits macht 1 MB
7 Bits macht 2 MB
8 Bits macht 4 MB
9 Bits macht 8 MB
10 Bits macht 16 MB
11 Bits macht 32 MB
12 Bits macht 64 MB
13 Bits macht 128 MB
14 bits macht 256 MB

14 Bits würde heissen, man benutzt 6 Bits der Adresse $D301 und 8 Bits der zweiten Adresse. Wenn man aber keine 256 MB braucht, könnte man sich auswählen welche Bits man benutzen will. Ich würde als erstes die Bits 2 und 3 benutzen und als letztes die Bits 4 und 5. Dies, damit Software die das zweite PIA port am ersten PIA nicht über $D301 ansprechen, sondern über eine der Schattenadressen, immer noch auf ein Teil der RAMdisk zugreift, nur nicht da, wo der Programmierer sich das gedacht hatte.

Jetzt gibt es aber ein kleines Problem. Da bei den XL-Erweiterungen die RAMchips meistens ersätzt sind statt wie beim XE extra eingebaut (eine erweiterte XL hat meistens 256kB wo eine erweiterte XE meistens 64+256=320kB hat) braucht ein DOS eine Tabelle mit allen Werte die in $D301 gültig sind, statt einen Wert der alle benutzten Bits darstellt. Bei einer 1MB erweiterung braucht man also 64 Byte (für jede Bank eins) statt nur einem Byte (zB 11110011 für eine Erweiterung die Bits 0, 1, 2, 3, 6 und 7 benutzt). Wenn man aber eine neue Adresse benutzen will, könnte man natürlich nur für diese Adresse das eine Byte benutzen.

Da im Moment unsere DOSse nur 16MB verwalten können, würde man eine größere Erweiterung natürlich Softwaremäßig in kleinere RAMdisks zerlegen.

Tschüß

Mathy

Hallo an alle,

Batterie Puffer geht nür gut mit S-Ram.
Sonnst muss auch den Refresh aktiv gehalten werden und dies ist nicht einfach.
Um den Ram-Bank zu steuern reicht auch ein einfaches TTL-Ic, ein Latch sehr gut aus. (74LS273 oder 74LS373)
Wenn man auch noch eine extra Decodierung macht, kann der Ram-Disk als PBI-Gerät ausgefüht werden.
Damit sind dann Samtliche Treiber zu laden.

Auch im Freezer ist noch etwas vorgesehen. Hier kann ein 512K-S-Ram montiert werden.
Und mit ein wenig extra kann diese auch eine Batterie bekommen.

mfg.
Guus

Schon mal Danke für die informativen Antworten. Es freut mich, das meine Vision einer sehr grossen SRAM-Disk theoretisch verwirklicht werden kann.

Wenn man das Bankswitching auf 2 Bytes verteilen kann, wäre es natürlich sinnvoll, nur eine physikalische Ramdisk im Rechner zu haben. Dem DOS gibt man die Steuerbits für den Bereich oberhalb von 320k und dann können andere Programme sich mit der XE-Ramdisk austoben.

Wenn man mit dem QMEG von der RD booten kann, ist das doch ok.
Vielleicht kann man sein QMEG so patchen das es standardmässig von der RD bootet.

Das wäre echt cool.

Gruss,
Stefan

Hallo Stefan

Beetle hat geschrieben:Vielleicht kann man sein QMEG so patchen das es standardmässig von der RD bootet.

Wenn der Dietrich es so macht, das man über einen Jumper (der sich ja jeder durch einen Schalter ersätzen kann) festlegen kann, ob man von der RAMdisk oder was anderes booten will, braucht man kein gepatched-es QMEG.

Und wenn man daraus ein PBI-Gerät macht, funktioniert das sogar mit jedem OS. Die BlackBox klinkt sich ja auch automatisch ein, sodaß von der Festplatte gebootet wird.

Tschüß

Mathy

anstatt einer 2. PIA kann man auch ein einfache 8Bit Latch wie z.B.
74373 o.Ä. benutzen, welches die reingeschriebene Bank "behält" und
an seinen Ausgängen zur Verfügung stellt, mehr braucht man nicht.
Ne (seltene) PIA braucht man dafür nicht zu verschwenden!

By the way: An die 128KByte und 512KByte SRAMs komme ich sehr günstig ran, müsste man mal sehen, wieviel Platz 32 512K RAMs
auf ner 2seitigen Platine wegnehmen!

Gruß,
Wolfram.

Mathy hat geschrieben:Da im Moment unsere DOSse nur 16MB verwalten können, würde man eine größere Erweiterung natürlich Softwaremäßig in kleinere RAMdisks zerlegen.

Diese Beschränkung sehe ich nur bei DOS mit eingebauter Ramdisk Verwaltung. Bei DOS mit ladbaren Treibern, oder bei der Benutzung eines CIO-Filter-Treibers (der alle Zugriffe auf D8: vor dem DOS abfängt) sollten beliebig grosse Ramdisks möglich sein.

Bei einer Ramdisk wird ja kein SIO mit der Beschränkung auf 2 Byte Sektor Adressen benutzt, eine Ramdisk simuliert ja nur ein Dateisystem.

Einziges Problem wird die Grösse des Treibers sein, denn der muss neben dem DOS noch irgendwo in den "normalen" Speicher. Und dort ist bei denmeisten Spielen und Anwendungen nur sehr wenig Platz.

Ciao

Carsten

dann müsste der ramdisktreiber so angepasst werden, daß er nachguckt, ob in der super-rd seine tabelle schon liegt und diese verwenden! Wenn sie noch nicht dort liegt, muss er sie erst da reinkopieren, in eine feste Bank z.B.

Gruß,
Wolfram.

cas hat geschrieben:Einziges Problem wird die Grösse des Treibers sein, denn der muss neben dem DOS noch irgendwo in den "normalen" Speicher.

jetzt muss ich auch mal kurz dazwischenquatschen:

Könnte das DOS nicht einen Teil der RAM-Disk nutzen, um dorthin einige Funktionen auszulagern? Die Funktionen würden dann einfach nachgeladen, wenn sie gebraucht werden.
Das als Lösungsansatz für Speicherprobleme ...

Könnte das DOS nicht einen Teil der RAM-Disk nutzen, um dorthin einige Funktionen auszulagern? Die Funktionen würden dann einfach nachgeladen, wenn sie gebraucht werden.
Das als Lösungsansatz für Speicherprobleme ...

Yep, dat isses!"

Macht z.B. SpartaDOS X seit fast 20 Jahren. Ein bisschen BankSwitching für das DOS braucht's dazu.

BTW: Wozu sollen große und sehr große Speichererweiterungen gut sein? Plant jemand eine echte Softwarenutzung oder geht es hier nur um die technische Machbarkeit?

Als RAMDisk reicht dass locker aus, was es schon gibt. Und ein 16MB-ATR über SIO2PC oder eine 16MB große Partition auf einer HD am MSC-IDE-Hostadapter reichen locker...

Aber hat denn jemals jemand eine nützliche Software oder ein pfiffiges Spiel dafür geschrieben?

Wozu das gut sein soll? Tempo!

Weil ich dann mein 16MB Arbeitsimage in die Super RD laden kann. Alle Programme die ich oft brauche, passen dann in den Speicher des Rechners. Und wenn die RD batteriegepuffert ist, und keine Demo und kein Spiel mir die Ramdisk abschiesst, kann ich nach der Demo/ dem Spiel auch gleich wieder aus der RD booten.

Wenn das richtig zuverlässig funktioniert, mache ich nur gelegentlich ein Backup auf meiner 1001 oder über SIO2PC auf dem Rechner, arbeite aber hauptsächlich aus der RD.

Das wäre für mich Anwendung genug. BossX zB. würde auch davon profitieren. Es wäre quasi "Instant on" oder "Standby-fähig"

Gruss,
Beetle

GoodByteXL hat geschrieben:

Könnte das DOS nicht einen Teil der RAM-Disk nutzen, um dorthin einige Funktionen auszulagern? Die Funktionen würden dann einfach nachgeladen, wenn sie gebraucht werden.
Das als Lösungsansatz für Speicherprobleme ...

Yep, dat isses!"

Macht z.B. SpartaDOS X seit fast 20 Jahren. Ein bisschen BankSwitching für das DOS braucht's dazu.

Bei SpartaDOS X wird Bankswitching im ROM gemacht. Die Gefahr beim Treibern im Ram liegt darin, das RAM überschrieben werden kann und dabei Daten verlorengehen. Was fehlt ist ein Speichermanagement Interface an das sich RAMDisk und Programme mir Zugriff auf den Erweiterungsspeicher halten. Teile der Logik in den Erweiterungsspeicher auszulagern bringt für einen Ramdisk Treiber nicht wirklich etwas, denn dann bin ich ja schon im Erweiterungsspeicher. Es geht ja um die Grösse des Treibers um den Erweiterungsspeicher erstmalig ansprechen zu können.

Ein Idealer Treiber wäre 256-512 Byte gross, alles darüber kann schon Probleme machen. Man kann sicher einen Treiber machen (Stub-Treiber), der eine bestimmt Bank einblendet und dort einen erweiterten Treiber aufruft. Das problem ist das dieser erweiterte Treiber ja auch Bankswitching machen muss, sich also beim switchen der Bank selber wieder ausblendet. Also müsste der erweiterte Treiber in jeder Bank gespeichert sein, eine unnötige Speicherverschwendung.

Sparta DOS X macht es warscheinlich wie ACTION! und die anderen OSS Module, das eine Bank immer fest ist (die mit der Bankswitching logik) und eine andere immer Umgeschaltet wird. Beim PORTB Ram-Bank Switchen haben wir aber nur einen Speicherbereich, der immer komplett geswitch wird ($4000-$7FFF).

Ramdisktreiber in der Ramdisk ist nicht wirklich die Lösung.


Eine OS-Erweiterung a-la SpartaDOS X wäre schön (4 K des OS sind immer fest, andere 4 K können geswitched werden). Das ganze dann als Flash, so das das OS vom Atari umprogrammiert werden kann. Dann könnte man im OS auch Ramdisktreiber ablegen, Booten von der Ramdisk einbauen, und auch Treiber für MyIDE und USB per Treiber in das OS einbauen.

Ciao

Carsten

Es wäre aber kein Problem, noch ein sagen wir mal 32K SRAM nur für das Bankswitching mit draufzubringen, welches ausschliesslich nur für die Tabellen der verschiedenen DOSse ist!

Wie wäre denn die Platine am Besten?
4x 8 RAM-Chips oder 2x 16 RAMs (lang und schmal)?

gruß,
Wolfram

Hallo zusammen!

So ganz gehe ich mit dem Tempoargument nicht mit - wahrscheinlich weil ich schon ewig mit ROMDisk bzw. Festplatte bzw. Slave-PC arbeite.

Never change a running system ...

Wenn ich das alles nicht haette, ok ...

Allerdings sollte mal eine Begrifflichkeit klar sein:

Eine RAMDisk ist keine Speichererweiterung !!!

RAMDisk ist die Softwarenutzung einer Speichererweiterung. Das wurde hier ein wenig vermanscht ...

SpartaDOS X macht Bank Switching in der Cartridge, klar. Aber es nutzt ausserdem zusaetzlich 16KB der Speichererweiterung zum auslagern fuer DOS-Routinen, Ruecksprungadressen etc.

Und beides zusammen nutzen ist doch sehr clever, da man so die Klippen des XL/XE-Rechners in Sachen Bank Switching (Port B) und limitierter Resourcen (Cartridge) gut umschiffen kann.

Das duerfte doch gerade fuer Dinge wie Boss X interessant sein. Gab es uebrigens auch schon einmal und hiess Diamond OS. Nutzte die gleiche Technik wie SpartaDOS X oder andere Super Cartridges von OSS.

Und das ganze mit gepuffertem SRAM duerfte keine grosse Sache sein, da Guus das schon einmal gemacht hat in einer speziellen Freezer-Version.

Ein Ansatz in diese Richtung kann viele Probleme loesen, nur eines nicht:

technisch machbare Gimmicks auszuprobieren

Moin Walter,

nicht verwechseln, diese SuperRD soll NICHT als Speichererweiterung sondern mehr als RAMDISK benutzt werden!
Neben einer "richtigen" Speichererweiterung die kompatibel mit D301 usw. ist! Wenn jemand Demos oder Programme zur Nutzung
der SuperRD entwickelt, wäre es aber trotzdem machbar.
Hauptziel jedoch ist es, eine Ramfloppy zu haben.

Gruß,
Wolfram.

cas hat geschrieben:Ramdisktreiber in der Ramdisk ist nicht wirklich die Lösung.

Was, wenn der Treiber (oder andere Routinen) außerhalb des Dateisystems der RAM-Disk liegen würde, ich meine irgendwo, wo er mit einer simpleren Routine eingelesen werden kann?

atarixle hat geschrieben:

cas hat geschrieben:Ramdisktreiber in der Ramdisk ist nicht wirklich die Lösung.

Was, wenn der Treiber (oder andere Routinen) außerhalb des Dateisystems der RAM-Disk liegen würde, ich meine irgendwo, wo er mit einer simpleren Routine eingelesen werden kann?

So kompliziert, das der Treiber als Datei im Dateisystem liegt, habe ich je garnicht gedacht. Der komplizierte Teil des Treibers ist die Bankswitching Logik, die muss einfach in den normalen 64 KB (- geswitche Bank) liegen, sonst funktioniert es nicht. Und dieser Teil sollte unter 512 Byte gross sein. Die Dateisystemlogik kann z. B. ohne Probleme im erweiterten Speicher liegen.

Es kann ja auch vorkommen das der Treiber von einem Programm angesprochen wird, welches im Bereich $4000-$7FFF liegt, ider der Dateibuffer des Programms in diesem Bereich liegt, dann muss man die Daten zwangsweise über einen Buffer im "normalen" RAM kopieren. Und dieser Speicher ist knapp, da Programme wie Turbo-Basic oder Sparta-DOS schon jedes freie Speicherplätzchen nutzen.

Ich sage nicht, es ist unmöglich!
Es ist nur schwierig!

Ich überlege schon seit 2 Jahren wie ich Forth beibringe eine Speichererweiterung tranzparent zu nutzen, so das der Programmierer im Forth direkt 320 KB (oder 128 KB) als Programm und Datenspeicher zur Verfügung hat, ohne sich über Bankswitching gedanken machen zu müssen. Ich habe bisher noch keine ideale Lösung gefunden, u. a. da immer der Effekt auftreten kann, das Programmcode und bearbeitet Daten in zwei verschiedenen Bänken liegen können und dann pro Speicherzugriff 2 Bankumschaltungen notwendig wären. Der Apple II hat es ein wenig einfacher gelöst, dort kann man die Bänke getrennt für Lese und Schreibzugriffe umschalten. D.h. der Programm kann weiterhin von $4000-$7FFF ausgeführt werden, aber Daten in eine Bank in $4000-$7FFF schreiben.

Ciao

Carsten

Hallo Carsten

cas hat geschrieben:D.h. der Programm kann weiterhin von $4000-$7FFF ausgeführt werden, aber Daten in eine Bank in $4000-$7FFF schreiben.

Aber nur wenn "schreiben" und "lesen" nicht im gleichen RAMbaustein stattfinden, oder?

Wenn man sowieso eine externe Erweiterung macht, kann man ja den getrennten Zugriff (also für lesen und schreiben) einbauen. Fragt sich nur, ob der Atari sowas unterstützt.

Tschüß

Mathy

...der 65816 unterstützt das! --->Apple ...