Hallo zusammen,

nach erfolgreichen Abschluss der 512k SRam Erweiterung hätte ich da noch eine Idee auf eine 2MB Erweiterung.
Diesmal arbeite ich mit einem Trick - sobald PB4 aktiv geschaltet wird erfolgt kein Zugriff mehr auf die PIA. Damit kann ich mir die Latches sparen

Parallel zur Pia wird ein weiterer Baustein gesetzt der die ganze Logik beinhaltet. Die Erweiterung ist Rambo kompatibel und könnte auch über einen Akku oder eine Batterie gepuffert werden.

Besteht Interesse an der Erweiterung? (Bei unserem Admin weiß ich es schon, er hatte leuchtende Augen bei meinem Vorschlag)

Viele Grüße,
Bernd

Hallo Bernd

Wieso nicht PB4 OR PB5?

Tschüß

Mathy

Hallo Bernd,

Das interessiert mich natürlich was Du da wieder bastelst.
Was bedeutet denn "Kombo kompatibel" ?

Gruß,
Steffen

Hallo zusammen,

noch ein kleiner Nachtrag. Die Idee mit dem parallelen Latch hat mir Guus auf der letzten JHV vorgeschlagen.
Leider brauche ich immer etwas länger es zu verarbeiten.

PacMan hat geschrieben:Hallo Bernd,

Das interessiert mich natürlich was Du da wieder bastelst.
Was bedeutet denn "Kombo kompatibel" ?

Gruß,
Steffen

Hallo Steffen,

es sollte Rambo heißen, war ein Tippfehler von mir. Ich habe noch nicht mit der Erweiterung angefangen.

Mathy hat geschrieben:Hallo Bernd

Wieso nicht PB4 OR PB5?

Tschüß

Mathy

Hallo Mathy,
NOT PB5! Beide Versionen Compy und Rambo würde den Bauteileaufwand erheblich in die Höhe treiben.
Kleine Rechnung: PB0 bis PB3 und PB5 bis PB7 ergibt 2 hoch 7 = 128 Seiten a 16k = 2048k = 2Mbyte.
Wenn PB5 dazukommt habe ich nur 1Mbyte.
Warum keine 4-8-16Mb? Es wird von keinem Programm unterstützt. Zudem müsste ein weiteres Register dazukommen. Der Aufwand ist mir zu groß.
Gibt es überhaupt ein Programm was 2MB unterstützt?

Viele Grüße,
Bernd

Hallo Bernd

Bernd hat geschrieben:Gibt es überhaupt ein Programm was 2MB unterstützt?

Ich kenne nur XRAM. Wenn ich mich nicht irre, testet es bis 4MB. Würde mich aber wundern, wenn man dann nicht eine bestimmte Adresse und ein oder zwei bestimmte Bit benutzen muß.

Das Problem mit >1MB ist ja das es ohne Hardware keine Software gibt und ohne Software keine Hardware.

Tschüß

Mathy

Hallo Bernd

Was ist eigentlich an Guus seine Idee anders als wie ich es gemacht habe?

Tschüß

Mathy (der Mal wieder neugierig ist)

@Bernd:

hardwaremäßig und auch Gal-technisch gesehen ist es ja schon ne feine Sache!
Habe ja auch bei dem *** Projekt 32x512KB vorgesehen, allerdings nicht als Speichererweiterung.

Aber mal im Ernst, WER braucht WOFÜR soviel Speicher der von sogut wie nix unterstützt Selbst die 512K Erweiterung ist doch schon mehr als genug, oder? Gibt es Programme, die die vollen 512K ausnutzen? (Ausser für Samples...)

Wünsche Dir trotzdem viel Erfolg damit, falls Du es wirklich realisieren möchtest!

Gruß,
Wolfram.

Ich hab da ne Idee, wie man ohne große Probleme zu einer richtig großen ZWEITEN Ramdisk kommen könnte:

1.Ramdisk Standart (256K,512K $D301 Benutzung)
2.Ramdisk 16MB mit Benutzung einer völlig neuen Adresse !
(Ja, es gibt einige, die nicht benutzt sind und quasi frei sind!
nicht D1XX,D6XX,D7XX oder wo sonst noch irgendeine Hardware-Erweiterung sich hinsetzt!)

Diese 2. riesen Ramdisk könnte dann z.b. für Soundsampling o.Ä. genutzt werden, Programme, Module oder sonst was dort ablegen.

Was man auch noch recht einfach realisieren könnte:
Auf die normale 512K SRAM Ramdisk einfach 1 oder mehr Rams
obendrauf und per Umschalter dann auf RD1,2... umschaltbar machen!

Schreibt mal Eure Meinung dazu!
Gibt es überhaupt Leute, die mehr als 512K gebrauchen könnten?

Gruß,
Wolfram.

Hallo Wolfram

Ich würde eine Adresse nehmen in $D3xx.
Was man auch damit machen könnte, ist in die eine 'ne Videodatei und in die Andere die Sounddatei. So könnte man sich 'nen Film ansehen von der RAMdisk, statt zB von der MyIDE Festplatte wie der Sijmen das macht.

Tschüß

Mathy (der sich seine eigene Erweiterung demnächst vielleicht noch mal anschauen sollte. BASIC, OSRAM, Selftest, Missile Command (nur XEGS), separater ANTIC und CPU zugriff, 1MB und dazu kämme dann noch SRAM statt DRAM und noch mehr RAM)

Ich würde mal etwas provokant sagen, daß außer in ein paar wenigen Spezialfällen niemand eine 2MB oder 16MB Ramdisk braucht. Interessant ist so eine grosse Ramdisk wohl nur für Leute die zB ein BBS am Atari betreiben und die häufig benötigten Files dort ablegen (schnellerer Zugriff).

Ende der 80er habe ich einen 8Bit Soundsampler für den Atari gebaut, bei 40kHz Samplerate war die 1MB Erweiterung dann auch sehr hilfreich.

Aber mehr Speicher? Irgendwie muss man die Daten ja auch da rein bekommen bzw sichern.

Videos von der Ramdisk? Nicht wirklich sinnvoll: Per SIO2PC schafft man im Highspeed Modus ca. 5kB pro Sekunde. 16MB würden also knapp eine Stunde dauern. Klar, mit einem schnellen Harddisk Interface würd's kürzer dauern, aber dann ist es auch sinnvoller die Videos direkt von der Platte oder CF-Karte zu streamen. Die MyIDE Videos belegen pro Minute etwa 3.5MB, auf eine 16MB Ramdisk passen also nichtmal 5 Minuten Video.

Ich sehe aber durchaus Möglichkeiten für verbesserte Speichererweiterungen am Atari (vor einiger Zeit hatte ich mit dem Carsten darüber gesprochen und eigentlich wollte ich schon längst mal was in der Richtung bauen - im Moment habe ich keine Zeit, aber vielleicht geht sich was für den HW Wettbewerb 2008 aus).

Das Problem bei so ziemlich allen bisherigen Ramdisks ist, daß sie nur sehr schwierig als Erweiterungsspeicher für Programme verwendet werden können. Das Bankswitching ist einfach zu simpel und man ist dauernd damit beschäftigt $D301 mit neuen Werten zu laden. Der separate Antic Zugriff ist zwar eine nette Idee, aber auch wieder kaum sinnvoll zu verwenden (deshalb gibt's ja auch kaum Programme die das unterstützen).

Beim Apple II haben sie einen ganz anderen Ansatz für die 128k Speichererweiterung verfolgt (danke an Carsten für den Tip): Die zweiten 64k liegen parallel zum Hauptspeicher und man kann für Lese und Schreibzugriffe getrennt festlegen ob der normale Speicher oder der erweiterte Speicher verwendet werden soll. Damit kann man wirklich einfach zwischen den Speicherbänken hin-und-her kopieren. Man muss natürlich aufpassen, daß beim Umschalten des Lesezugriffs der Stack etc. noch passt, sonst kracht's (aber das betrifft uns hier erstmal nicht).

Ich habe mir dann mal folgendes ausgedacht (eine Kombination beider Konzepte): Vom Atari übernehme ich die Idee mit der RAM-Bank in einem abgegrenztem Speicherbereich (zB $4000-$7FFF) aber statt einem Bankselect Register nehmen wir 3 Stück. Eines legt fest, woher die CPU die Daten liest, eines wohin die CPU ihre Daten schreibt und das dritte ist für den ANTIC Zugriff. Jedes Bankselect Register besteht aus einem Steuerbit (wie PB4) das den Zugriff auf den erweiterten Speicher an/abstellt und einem Adressteil (der Banknummer). Evtl. könnte es praktischer sein, die 3 Steuerbits von den Adressbits zu trennen und gemeinsam in einem 4. Register zusammenzufassen, da bin ich mir noch nicht ganz sicher.

Was könnte man damit nun anfangen und wieso ist das praktischer? Nehmen wir mal folgendes Beispiel:

Die meisten Spiele haben eine mehr oder weniger große Menge an Daten aus denen sie das gerade angezeigte Bild berechnen. Bei aufwändigeren Sachen verwendet man Doublebuffering, also das nächste Bild wird in einem 2. Bildspeicher aufgebaut, wenn es fertig ist schaltet man den ANTIC auf den 2. Screen um (dadurch flackert nichts). Ich selber habe auch schon Triple-Buffering verwendet um den Frame-Durchsatz zu erhöhen.

Legt man den ANTIC Bildschirmspeicher im internen Atari RAM ab, verliert man schnell 8-24k, die man ansonsten besser für die Programmroutinen verwendet (beim Freezer ist der ROM-Code in 3 Bänke aufgeteilt, das ist schon recht mühsam und man muss immer aufpassen in welche Bank man nun reinspringt, es ist wirklich viel einfacher wenn der gesamte Programmcode jederzeit ohne Bankswitching zur Verfügung steht).

Mit getrennten Bank-Registern kann man nun aber folgendes machen: Der ANTIC bekommt ein paar eigene Bänke, die Daten kommen in die anderen Bänke. zB ANTIC Bank 0,1 Daten 2-15. Zeigt der ANTIC Bank 0 an, setze ich die Schreib-Bank auf 1 (ich will das nächste Bild berechnen) und die Lese-Bank auf eine der Daten-Bänke (zB 3). Somit kann man wirklich schnell Daten von einer Bank in die andere kopieren (LDA $4000 STA $4000 kopiert von 3 nach 1) ohne andauernd das Bankselect Register neu setzen zu müssen.

Mir ist klar, das ist ein ganz neues Konzept am Atari und dafür muss auch erst mal Software geschrieben werden. Technisch ist so eine Erweiterung relativ einfach und günstig zu realisieren (ein CPLD, ein SRAM und etwas "Gemüse" dazu) und vielleicht schaffen wir damit die Basis für zukünftige, aufwändigere Programme.

Gebt' mal Bescheid, was ihr dazu denkt.

so long,

Hias

Jau,
stimmt - mehr als 1MB RAM ist derzeit absolut nicht sinnvoll. An Programmen gibt es dafür gerade mal ein paar Demos:

- 1 MB Raytracing demo von Solocoder of Ace (erhältlich u.a. in der ABBUC-PD-Bib.; läuft jedoch nur auf K.Peters Megaram 3); Umfang ca. 8 disketten, Ladezeit ca. 17 Minuten; animationszeit: unbekannt (vermutlich deutlich unter 17 Minuten)

- 1MB Brull-Soundsample-Demo (oder so ähnlich), natürlich aus Polen, gab es mal auf atari-area zum Download; da ich nicht über 1Mb (sondern nur 512k bw. 576k) verfüge, erhalte ich gleich zu beginn die Meldung "requires min. 1024 kbytes" und das war es auch schon. Schätze dass auch hier die Ladezeit deutlich über der playing time liegt...

- und vermutlich noch weitere Demos...

Das gleiche gilt für die MyIDE-Videos. Direkt von der Festplatte sind die Dinger ja noch schön anzusehen, aber der versuch sie in die RD zu laden und dann von da aus zu gucken ist mühsam. Man muss stundenlang warten bis das Video eingeladen ist, um dann ein paar minuten Animation zu sehen. Das will sich wohl keiner wirklich antun, obwohl man natürlich bei einigen Retro-Events damit ganz gut angeben könnte (man könnte ja die Daten bereits vorher zuhause in die batterie-gepufferte RD laden und auf dem Event nur die Animation zeigen)...

Für Spiele sind derzeit schon 128k voll ausreichend, wer unbedingt alle aktuellen Demos anschauen möchte, der braucht eigentlich auch nicht mehr als 320k RAM (wobei 512k ganz gut sind, damit man sowohl über CS/Megaram als auch über Newell/Rambo/Toms standard verfügt; bei der 512k Erweiterung von mega-hz ist das ja der Fall). natürlich kann man auch bei 320k bleiben und sich einen schalter einbauen um zwischen den beiden standards umzuschalten - ich fand das aber auf dauer nervig und hatte lieber gleich 512k (bzw. 576k) in meinem Atari.

eigentlich ist es ja auch nicht so wichig, wieviel RAM man hat, sondern dass es viele Programme gibt, die das nutzen. und jenseits der 512k gibt es für den atari *derzeit* nunmal kaum Programme. und ich bezweifle doch ein wenig, dass sich daran in zukunft viel ändern wird, denn zum einen ist da die schon angesprochene sehr lange ladezeit, zum anderen wird man (zumindest als User eines realen Ataris nebst Floppy) wieder mal zum Diskjockey...

Aber vielleicht könnte der ABBUC ja einmal sowas wie einen Standard schaffen, man spendiert einfach allen 400 members eine bestimmte hardware und zack, schon könnte jeder darauf zugreifen. nur leider wäre so ziemlich jede hardware zu teuer, um sie allen abbuc-members als jahresgabe zu schenken, sprich es würde das abbuc-guthaben auf einen schlag sehr drastisch reduzieren... und dann gäbe es sicher böse reaktionen von members, die (aus welchen gründen auch immer) die HW gar nicht haben wollten und ziemlich sauer über die verprassung der eigenen gelder wären... (stichwort: 400 members, 400 versch. meinungen)... -Andreas Koch.

Gute idee mit den CPLD.
Aber wenn schon neue Sachen gemacht werden, dann auch noch mehr Modi.
1) Mittels ein Register auch "compatibel Modus" (Wie 130XE +)
2) Banking vom OS-Bereich.
3) Banking im Bereich $0100-$7FFF.
4) Banking im Bereich $0-$BFFF
Bei 3 und 4 die Wahl ob Zero-Page auch im Bank ist.
Für Bank erkennung, einblenden von Bankregister auf bestimmter Ort.
Z.B. $7FFF oder $BFFF ist Banknummer.
Überlege beim OS-Banking auch ein "Sperr-Bereich"
Es bleibt dann ein Teil immer am gleichen "Ort"

BR/
Guus

Hallo Guus!

guus hat geschrieben:1) Mittels ein Register auch "compatibel Modus" (Wie 130XE +)
2) Banking vom OS-Bereich.
3) Banking im Bereich $0100-$7FFF.
4) Banking im Bereich $0-$BFFF

Bei den ersten beiden Punkten bin ich mir noch nicht ganz sicher, an die letzten beiden Sachen hab' ich auch schon gedacht.

Den "XE Kompatibilitäts Modus" könnte man zB als Default setzen, den "erweiterten Modus" dann extra aktivieren. Stellt sich die Frage ob man gleichzeitig den XE-Modus unterstützen will und (zB auch bei einer vorhandenen XE Erweiterung) welche dann Priorität haben soll (zB wenn beide RAM bei $4000 einblenden wollen).

Banking im OS Bereich ist etwas tricksig. Bei $D000 ist ja das 2k Loch durch die Custom-Chips und am Ende des 8k Blocks $E000-$FFFF liegen die wichtigen Interrupt-Vektoren. $C000-$CFFF alleine ist auch etwas zu klein. Aber vielleicht geht ja folgendes:

Wir machen die Basisadresse einfach per Software konfigurierbar. zB $0000, $4000, $8000, $C000. Und das getrennt für Read, Write und Antic. Dann blenden wir zB die Bank mit dem Bildschirmspeicher bei $C000-$FFFF ein während die CPU dort auf das interne RAM zugreift. Zeichensätze etc. können dann auch gleich dort rein. Wenn das OS-ROM eingeblendet ist, greift der ANTIC auch dort zu und bei $D000 ist einfach ein 2k Loch für die Custom Chips (so wie jetzt im XL/XE, das RAM dort kann einfach nicht angesprochen werden).

Bei 3 und 4 die Wahl ob Zero-Page auch im Bank ist.

Hmmm. Wenn, dann sollten wir den ganzen Bereich $0000-$03FF ausnehmen. Stack, Interrupt-Vektoren etc. sind ja auch noch wichtig. Das "Loch" ist natürlich wieder etwas störend. Darüber sollten wir noch mal ein wenig nachdenken.

Für Bank erkennung, einblenden von Bankregister auf bestimmter Ort.

Anders als beim Freezer möchte ich dieses Mal "richtige" Register machen die man dann auch wieder auslesen kann (und zB einfach ein "INC READBANK" ermöglichen).

BTW: Wir können auch überlegen, ob wir grössere oder kleinere Bänke haben wollen (obwohl ich persönlich 16k einen recht guten Kompromiss finde).

Überlege beim OS-Banking auch ein "Sperr-Bereich"
Es bleibt dann ein Teil immer am gleichen "Ort"

Meinst Du damit jetzt Banking für's OS ROM oder für das erweiterte Ram unter dem OS ROM?

OS ROM Banking würde ich vorerst mal weglassen, das sehe ich hier recht unabhängig von der RAM-Erweiterung. Evtl. können wir später mal drüber nachdenken, ob man das (zB mit einem Flash) mit auf die Platine nimmt.

so long,

Hias

- 1MB Brull-Soundsample-Demo (oder so ähnlich), natürlich aus Polen, gab es mal auf atari-area zum Download; da ich nicht über 1Mb (sondern nur 512k bw. 576k) verfüge, erhalte ich gleich zu beginn die Meldung "requires min. 1024 kbytes" und das war es auch schon. Schätze dass auch hier die Ladezeit deutlich über der playing time liegt...

Hier: http://atari.fandal.cz/download.php?files_id=2519 , heisst "Brullwurfel"

WOU,

ist schon Klasse was mit einer Anfrage doch so alles zusammen kommt. Was für Ideen - weiter so.

Mein Wuschtraum:
Eine komplett neu entworfene kleine Platine mit mehr Speicher, allen Original Atari Chips, Stereo Pokey, Aki zum Anschluss einer PC Tastatur, S-Video Ausgang, SIO2XXX - wenn schon dann alles, usw......
Das alles in einem Traum von Gehäuse - siehe Skizzen von Atari auf der Webseite von Atarimuseum.

Viele Grüße,
Bernd

Hallo,

Mit den Banknummer meine ich dies:
Es ist ein CPLD der den ganzen MMU-funktion übernimmt.
Irgendwo im I/O bereich ist ein Latch der die Banknummer generiert.
Aber ein Lese/Schreibe zugriff auf die letzte Addresse (Oder erste) vom Bank, gibt immer den Inhalt dieses Latches. So kann mann immer einfach die Banknummer checken.
Ja, dies geht auch am "Latchaddresse". Sehe es wie die "Schattenregister" So kann eine "Sprungtabelle" vielleicht einfacher werden.

Beim Blockieren eine Addresse kann dies im Ram hinten den OS sein, aber auch im extra Ram.
Wenn da ein Teil beim Lese Zugriff immer gleich bleibt, kann diesen Teil benützt werden für Teile der Software die "immer da sind"
Ist dann quasi wie DLI brauchbar. Und ein "Schreibzugriff" lässt dann alles da.

Hoffentlich macht dies irgendwie Sinn....

mfg.
Guus

Hallo Guus!

guus hat geschrieben:Aber ein Lese/Schreibe zugriff auf die letzte Addresse (Oder erste) vom Bank, gibt immer den Inhalt dieses Latches. So kann mann immer einfach die Banknummer checken.
Ja, dies geht auch am "Latchaddresse". Sehe es wie die "Schattenregister" So kann eine "Sprungtabelle" vielleicht einfacher werden.

Das finde ich nicht so praktisch. Ein Byte des RAMs ist dann immer verschwendet, mit einer Info, die man auch woanders herbekommt (nämlich aus dem Bank-Register).

Beim Blockieren eine Addresse kann dies im Ram hinten den OS sein, aber auch im extra Ram.
Wenn da ein Teil beim Lese Zugriff immer gleich bleibt, kann diesen Teil benützt werden für Teile der Software die "immer da sind"
Ist dann quasi wie DLI brauchbar. Und ein "Schreibzugriff" lässt dann alles da.

Ich hoffe, ich verstehe das gerade richtig. Meinst Du damit sowas ähnliches wie die OSS bzw XEGS Bankswitching Module?

Das würde dann zB bei einem erweiterten Bankswitching OS ROM durchaus Sinn machen (zB $E000-$FFFF fix, $C000-$CFFF umschaltbar), da ja einiges an Code/Daten permanent da sein muss und sich das OS nicht einfach irgendwelche RAM-Adressen nehmen darf.

Für die RAM-Erweiterung bringt das glaube ich nicht so viel. Das Programm kann ja einfach die Sachen, die immer da sein müssen, ins normale Atari RAM legen (Programmcode, Display-Daten etc).

Anstatt einer fixen Bank wäre es dann wahrscheinlich sinnvoller, 2 getrennt schaltbare Bänke zu machen (zB 2 mal 8k statt 1 mal 16k). Aber ich denke, das führt dann schon wieder etwas zu weit.

so long,

Hias

Hallo Hias,

Ja, wenn man es so seht, die Daten sind ja im Register.

Das OSS-verfahren ist praktisch.
Aber warum nicht das gebiet grösser machen?
Die "Lücke" für I/O ist nicht so schön.
Aber man könnte auch ein OS anpassen und das I/O gebiet verschieben.

Ein CPLD kann natürlich auch geändert werden.
Es sollte so flexibel wie möglich gemacht werden.
Und weil relativ viel drin geht, warum nicht auch ein "Configurations-Register" ?
Start in "Compatibel-Modus" und dann per Anwendungszweck wählen wass die Configuration wird.

BR/ Guus

Hallo Hias und Guus,

bitte macht die Speichererweiterung über einen MODE-Befehl auch RAMBO und COMPY komaptibel.
Damit deckt man zugleich alles an Progammen ab die extendet Memory nutzen.
Wenn eine Modulemulation mit eingebaut werden sollte habe ich da einige Ideen - XEGs abschaltbar, MegaCart, AtariMax.

Viele Grüße,
Bernd