Das Biest ist viel zu groß. Ich sollte vielleicht ergänzen, dass ich ganz persönlich ja den Fokus auf Aufstellungen lege, die ich mit meinen Rechnern mache. Da müssen die Erweiterungen dann schon klein sein. Für zu Hause habe ich das Problem nicht, weil ich da ja eine gute Rechner/Monitor-Kombination habe. Aber ich habe eben mehr als nur einen oder zwei Rechner.

cas hat geschrieben:

GoodByteXL hat geschrieben:...

Sehr viel besser als Kabel , aber bitte nicht über die lahme SIO . Der A8 kann mehr ...

Wenn es darum geht ein SIO Kabel über Bluetooth zu ersetzen, dann sollte es schon auch das SIO Protokoll sein.

Klar, nur sollte man dabei auch einmal den Blick auf die anderen Möglichkeiten der A8-Hardware werfen. Gerade bei schnellen, kabellosen Verbindungen bietet sich der Parallelbus aufgrund seines hohen Datendurchsatzes an.

cas hat geschrieben:Ich bin ein grosser Fan des SIO Protokolls, weil die Programmierschnittstelle ein sehr schöner Standard ist. Für PBI gibt es keinen Standard, der mit vielen DOS-Versionen und ohne extra Treiber funktioniert.

Das Problem hier ist doch nicht der fehlende Standard. Der Parallelbus ist im OS des A8 verankert, ordentlich dokumentiert und braucht nur vom Programmierer genutzt zu werden. Das zeigen u.a. die vielen Cartridge-Lösungen.

Nur weil die ATARI DOS und viele ihrer Derivate Teile der eigenen Hardware schlicht ignorieren, muss man dem nicht unbedingt folgen. MyDOS und BeweDOS zeigen, dass es möglich ist, mal abgesehen von den seit 1983 existierenden professionellen Lösungen in dem Bereich. In BeweDOS ist der Parallelbus trotz des sehr niedrigen LowMem voll implementiert - ein Paradebeispiel, finde ich.

cas hat geschrieben:Z.B. Ethernet-Netzwerk (TCP/IP) würde ich am SIO Bus sehen, dann gibt es die Chance das es auch wirklich benutzt wird, und nicht nur eine schöne Technologie-Demo ist.

Da gibt es seit geraumer Zeit einige Projekte, die aber offenbar nicht das bieten, was man sich erhofft hatte.

cas hat geschrieben:Mehr als SIO Geschwindigkeit braucht man nur bei Festplatten, aber nicht beim Netzwerk.

Na, das ist doch schon seit den 1980er Jahren anders bewiesen. Bob Puff hatte damals nicht nur Diskettenlaufwerke über den Parallelbus angeschlossen, sondern auch den Multiplexer entwickelt. Diese schnelle Netzwerklösung per Cartridge-Connector, also Parallelbus, zeigte schon vor 25 Jahren, was am A8 geht.

Auf der JHV 2010 hatte Erhard in einer aufwändigen Demonstration die Möglichkeiten des Multiplexer-Netzwerks und dessen Leistungsfähigkeit gezeigt. Leider hatten viele Bit Byter überhaupt nicht realisiert, was da geht, da Gaming im Vordergrund stand. Damals haben viele Besucher der JHV es verpasst, mal über den Tellerrand der SIO hinauszuschauen.


Für Gamer dürften Netzwerkspiele mit hohem Datendurchsatz per Parallelbus eigentlich wesentlich interessanter sein, als die per SIO-Netzwerk existierenden. Man müsste sich nur einmal trauen. Das einzige Manko wäre m.E. der fehlende Ladeton .

Und hier kommt die BT-Verbindung wieder ins Spiel. Ich finde es toll, dass Entwicklung in der Richtung kabellose Verbindung stattfindet. Und würde man statt direkt in die SIO 'reinzuspringen A8-systemkonform über die CIO einsteigen und die Verbindung per Parallelbus anbinden, wären Netzwerkballerspiele etc. in einer ganz anderen Qualität machbar. Mal abgesehen von weiteren, mehr anwenderorientierten Entwicklungsmöglichkeiten.

cas hat geschrieben:ATR Images direkt aus dem Internet-Booten per TCP/IP, das wäre schön.

Ja, oder per BT vom Smartphone .

Und die Branche hat nicht zugehört
PATA -> SATA
LPT -> USB

Montezuma hat geschrieben:Und die Branche hat nicht zugehört
PATA -> SATA
LPT -> USB

Ja, nee, is' klar ...
Die schnellste Übertragung am A8 läuft nun mal leider über den Parallelbus. Modernere Schnittstellen hat er nicht, also ist der Kommentar letztlich sinnfrei.

Fakten: SIO mit getunter Hard- und Software bei Pokey Divisor 0 leistet max. ca. 11 KB/s, ansonsten 1,2 KB/s. Parallelbus ohne Hardwaretuning bis zu 10 Mal so schnell, je nach Auslegung des Geräts. Diese Fakten kann man nun Mal nicht leugnen, aber natürlich stumpf ignorieren. Schade, dass viele so denken. Deswegen gibt es in 30 Jahren Parallelbus am A8 auch nur so wenig Hardware, welche die Leistungsfähigkeiten des Systems voll ausnutzt. Und gibt es mal etwas in dieser Richtung, dann wird es gern madig gemacht, weil Argumente fehlen.

Naja, war der Versuch eines Denkanstoßes.

Trotzdem finde ich die BT-Experimente super und bin gespannt auf die Vorführung, wenn es soweit ist.

Ich mag´ den Parallelbus auch, aber Fakt ist doch nun auch, dass der SIO auch am A 800, 1200 XL und XEGS vorhanden ist. Mit PBI sieht´s da eher mau aus, oder? Und dann sieht der PBI beim XE auch noch anders aus als beim XL, da kann ich dann schon verstehen, dass Entwickler bei einem so kleinen Markt lieber auf SIO setzen, das kann halt universeller genutzt werden.

GoodByteXL hat geschrieben:Fakten: SIO mit getunter Hard- und Software bei Pokey Divisor 0 leistet max. ca. 11 KB/s, ansonsten 1,2 KB/s. Parallelbus ohne Hardwaretuning bis zu 10 Mal so schnell, je nach Auslegung des Geräts.

Durch das "bis zu" ist die Aussage zwar nicht falsch (jaja, wie war das noch mal mit den DSL Verträgen :), aber der Vergleich hinkt doch ziemlich - ich nehme an Du hattest da die ca 80kB/sec bei den IDE Interfaces im Hinterkopf.

Das IDE Protokoll ist absolut primitiv, sprich der Atari braucht so gut wie nichts zu tun, die CPU ist dabei rein damit beschäftigt die Daten zu schaufeln. Der Code dafür ist einfach eine Schleife mit 256 (oder 512) Durchläufen von "LDA IDEDATA; STA BUFFER,X". Simpler geht's nicht :)

SIO mit dem POKEY sieht da schon ganz anders aus. Die CPU muss dabei für jedes Byte den Empfang bestätigen, das Status-Register auf Fehler checken und die Checksumme berechnen. Eigentlich auch nicht alluzu kompliziert, aber die CPU ist da bei Divisor 0 schon absolut am Limit. Ich hab da monatelang getüftelt den SIO Code so weit zu optimieren daß Übertragungen mit Divisor 0 überhaupt stabil möglich sind.

Die in der PC Welt verbreiteten Protokolle (USB, Netzwerk etc) sind nun aber ungleich komplizierter als das Ansprechen des POKEY. Der naive Ansatz das in Software am Atari erledigen und gleichzeitig Übertragungsraten über sagen wir mal 1kB/sec haben zu wollen ist damit von vornherein zum Scheitern verurteilt. Das packt der 6502 einfach nicht.

Will man mehr als die 11k haben, muß die Anbindung zum Atari so simpel wie möglich sein, die Hardware also das gesamte Protokoll implementieren (und geeignet umsetzen).

Einfach irgendeinen Microcontroller an den PBI zu hängen geht leider auch nicht so einfach. Der muss ja nicht nur das Protokoll abwickeln sondern auch 100% zuverlässig innerhalb max. 200ns den PBI bedienen können. Das braucht schon "richtige" Hardware Unterstützung.

Ein gangbarer Weg wär zB ein mittlerer FPGA mit Hardware ARM Core (oder evtl anderem Soft-Core), die Logik im FPGA macht das Gateway zwischen PBI und ARM und stellt dem Atari ein einfaches Interface zur Verfügung während der ARM Netzwerk oder USB bedient. Geht evtl sogar noch kleiner, mit kleinerem FPGA und Microcontroller.

Also: machbar ist es schon, aber die Lösung ist ungleich aufwändiger (und damit wohl auch deutlich teurer) als die primitiven IDE Interfaces die wir zur Zeit haben (IDE Plus, SIDE etc).

so long,

Hias

cas hat geschrieben:* Ethernet-Schnittstelle mit TCP/IP in der Hardware (also das kein TCP/IP Stack im Atari notwendig ist), mit Socket API und IPv6

Der Multiplexer ist zwar eine schöne Idee, aber ich will keinen Extra Master-A8 laufen haben, sondern alle sollen gleichberechtigt sein.

Hallo Walter

GoodByteXL hat geschrieben:...die Verbindung per Parallelbus anbinden, wären Netzwerkballerspiele etc. in einer ganz anderen Qualität machbar. Mal abgesehen von weiteren, mehr anwenderorientierten Entwicklungsmöglichkeiten

Was soll da gross über's Netzwerk geschickt werden? Man brauch doch nur:

1) Wer bin ich?
2) Wo bin ich?
3) In welcher Richtung bewege ich mich?
4) Wie schnell bewege ich?

Plus wahrscheinlich irgend 'ne Synchronisation. Der Rest kann sich jeder Rechner selber ausrechnen. Da ja nicht viel über's Netzwerk verschickt wird, bleibt mir dann auch genug Zeit, um das was den Atari zum Atari macht (Graphics, Sound) besser aus zu nutzen. Eventuell lädt sich jedes Gerät (aus dem Speicher, von 'ner Festplatte, CD, Speicherkarte) dazu dann noch die Daten nach.

Tschüß

Mathy

Hallo Andreas, Leute

andreasb hat geschrieben:Der Multiplexer ist zwar eine schöne Idee, aber ...

Laut der Anleitung zum Multiplexer, muss man in jeden Slave-A8 das OS austauschen gegen das Multiplexer-OS. Heißt also: Entweder ich bau kein Sonder-OS ein, oder ich muss jedes Mal umschalten.

Tschüß

Mathy

Moin,

skriegel hat geschrieben:Etwas, um den XL an moderne Monitore/TVs anschließen zu können. Meine Idee (habe ich schon öfter erwähnt) wäre eine externe Box, die an den Monitorport eines unmodifizierten Atari angeschlossen werden kann und dann verschiedene Ausgänge (VGA/DVI/HDMI/nochwasdolleres? ) bereitstellt und über Potis oder sonstiges Feinjustierungen am Bild erlaubt.
Und jetzt komme mir bitte keiner mit dem VBXE, das ist als reiner Grafikausgang zu teuer und als Erweiterung brauche ich es nicht (Andreas hat sehr schön erklärt, warum).

Eine Lösung dieses Problems kann nur in 2 (oder sagen wir mal drei) Optionen bestehen:

- Option 1 ist bereits verfügbar, kostete ca. 40 Euro und besteht aus einer externen kleinen Box, die FBAS und S-Video nach HDMI wandelt. Gibt´s bei eBay und Amazon für 40-50 Euro. Funktioniert einigermaßen, habe ich mir sagen lassen.
- Option 2: VBXE oder eine entsprechende Lösung
- Option 3: Selbstbau einer Option 1

Die Herausforderung besteht darin, daß die Grafikchips im Atari so designt sind, daß ein fertiges "Fernsehsignal" hinten raus kommt. Und damit bleibt die Bildqualität immer auf dem, was wir jetzt kennen. Entweder man bedient sich der Option 1, probiert ein paar Boxen des Massenmarktes durch bis man eine Kombination gefunden hat, die gut läuft (denn das HDMI nicht gleich HDMI ist (bzw. was die Sichtgeräte daraus machen), weiß mittlerweile auch jeder...).

Für Option 2 und 3 kommt man um folgenden Weg nicht herum:

- Digitalisieren des TV-Signales in hoher Qualität und natürlich in Echtzeit, d.h. mindestens 50 Frames/Sek.
- Skalieren auf die Zielauflösung
- Ausgabe auf HDMI

Hört sich banal an, aber dazu sind jede Menge Teile nötig. Mindestens ein FPGA, RAM und eine MCU, will man es vernünftig anpaßbar machen und ein OSD o.ä. anbieten. Wenn man mal die Basis der Teile auf dem VBXE nimmt, wird man so nie etwas zusammenbauen können (außer in Tausender Stückzahl), was im Endeffekt deutlich günstiger ist als jetzt ein VBXE. Und damit ist die Zielgruppe potentieller Interessenten sehr klein, was wieder den Aufwand nicht unbedingt rechtfertigt.

Ich hatte vor einiger Zeit ein Projekt entdeckt, das im Prinzip auch für den A8 umsetzbar wäre. Leider fehlt mir die Zeit, Kontakt mit dem Author aufzunehmen. Wenn Du die hast, kannst Du mal abklären, ob seine Lösung auch für uns einsetzbar wäre. Das nötige Altera DE1 Development-System kostet übrigens 150 US-Dollar plus Shipping und ggf. Zoll.

Projekt Nintendo N64 an HDMI via FPGA-Board

Gruß, Jürgen

Moin,

Bernd hat geschrieben:KEIN MODUL sondern eine umschaltbare OS Platine.
Verschiedene Betriebssysteme können in einem Flashspeicher vom Atari aus ablegt werden. Das zuletzt angewählte OS bleibt dabei auch nach aus/ein aktiv. Zugleich gibt es Anschlüsse für eine Stereo-Monoumschaltung, Speichergrößenverwaltung usw. Über eine Softwaremaske lässt sich alles steuern. Auf der Platine hätte vielleicht noch eine Speichererweiterung Platz. Dann gibt es keine Löcher mehr für irgendwelche Schalter am Atari.

Gibt es doch alles: Ultimate 1 MB. Günstig, gut, aktualisierbar. Und obendrein noch mit RTC und SDX.

Ich hatte bereits Ende 2010 angefangen, eine ähnliche Lösung zu basteln. Immerhin drei Prototypen-PCBs habe ich gemacht, aber mir fehlte immer die Zeit für das BIOS (die Hardware lief bereits fehlerfrei). Dann kam Sebastian und präsentierte die U1MB... da habe ich meine Lösung auf Eis gelegt. Seine Platine ist einfach chic, klein, kann unglaublich viel und der Preis von unter 50 Euro ist Hammer. Das ist weder Neid noch Groll, sonderen Respekt für eine tolle Lösung.

Dennoch werde ich meine "meine" Version mal fertig machen. Allein schon, um WUDSN zu nutzen

Gruß, Jürgen

Ich bin ja jetzt viele Monate sporadisch an dem Projekt SIO2IP dran (siehe hier).

Im Vorfeld habe ich mir schon einige Gedanken gemacht, wie man ein solches Device HighLevel gestalten sollte. Hier vielleicht meine Ergebnisse.

* Anforderungen / Anwendungsfälle
- Mein Ziel war/ist es, ein großes MMORPG auf den ATARI zu bekommen, also eine klassische Client/Server-Lösung.
- Weiterhin sollten Funktionen wie "RemoteBoot", FTP- und Kopierfunktionen enthalten sein.
- Ein Großteil der Intelligenz sollte das Device zur Verfügung stellen, der ATARI sollte primär nur mit einem "I:"-Handler arbeiten (=einfache Integration).
- Die Kommunikation sollte intern über Sockets laufen, der volle TCP/IP-Stack im Device gemanaged werden.
- zunächst nur IPv4-Unterstützung.
- Power durch den ATARI
- Minimale Ressourcenbelastung am ATARI, nutzbar auf allen 8Bit-Geräten
- Einfache SW-Upgrades
- Kein ewiges Umstecken / Blockieren von Ressourcen am ATARI
- preisgünstige Bauteile in DIL-Ausführung

Als Ergebnis der Punkte blieb mir als flexibelste Lösung die SIO übrig.

Die Hardware des Devices hatte am Ende:
- 10MBit Half-Duplex-Schnittstelle, damit das Device nicht "erschlagen" wird und ein riesen Buffer vorhanden sein muss.
- SIO2SD integriert
- Realtime-Clock (mitunter um auch Einstellungen permanent zu speichern)

*** Angedachter Ablauf ***
Zunächst wird wie bisher bei den SIO2SD bekannt ein Image gemountet und gestartet. Je nach Programm kann dieses den I-Handler installieren und ggf. den Rest an Software per TCP/IP aus dem Netz holen, andere Images per FTP / RemoteBoot von einem NAS o.ä. nachladen.
Diese Lösung beseitigt auch das Problem von AutoSensing einiger Switche, die doch ihre Zeit brauchen die 10Mit zu erkennen.
Da dies eine recht wahlfreie Lösung ist können die Anwendungsfälle alleinig durch die verwendete Software realisiert werden (Chats, Browser, Filesharing, Multiplayergaming...) und eine Implementierung ist ohne großen Speicheraufwand für die Kommunikation machbar (Open #1,4,2,"I:abbuc.de")

*** Herausforderungen
Interessant ist die Kommunikation der SIO, dessen Master der ATARI darstellt. Hier muss nun der ATARI sporadisch am Device anfragen, ob neue Daten vorliegen, da das Device per SIO keine Möglichkeit hat eine Art von Interrupt bereitzustellen. Auch hat man die Herausforderungen, dass Pakete eine recht große, variable Payload haben (MTU, Maximum Transmission Unit), dessen Inhalt schnell über 1k groß sein kann, je nach Anwendungsfall. Alle Standard-Funktionen (DNS, NTP, FTP...) müssen separat integriert, TCP / UDP gemanaged werden.

*** Warum kein Modul?
Ich bin kein Hardware-Guru, aber nach meinem Verständnis wird ein Modul beim Einschalten direkt in den Speicher eingeblendet und ist quasi sofort aktiv. Dies wiederum bedeutet, dass der Speicherbereich direkt belegt wird und eine entsprechende Software sofort aktiv, dessen Inhalt zunächst statisch ist. Dies entspricht nicht meiner Vorstellung, da es schon eine Art von Zwangsvorgabe darstellt.

*** Warum nicht PBI?
Der PBI schränkt zunächst den Gerätetyp ein (XL -> XE, siehe Freezer). Dies bedeutet verschiedene Geräte für unterschiedliche ATARI. Ferner ist das Stromproblem vorhanden, was weitere Ressourcen blockiert (Joystickport) oder einen Eingriff in den ATARI nötig macht.


*** Wo stehe ich heute?
Leider ist das Projekt seit einigen Monaten etwas auf Eis (Zeitmangel...)
Auf dem Entwicklungsboard hatte ich SIO2SD realisiert, die RTC lief und erste Ethernet-Funktionen waren aktiv (NTP-Sync, Ping...). Nun habe ich das Ganze auf eine Lochrasterplatine umgebaut, den Prozessor gewechselt und spiele mit dem Gedanken, das Device mit einem Touchscreen auszustatten, was leider etwas umfangreicher ist als ursprünglich gedacht. Auch hatte ich überlegt, von SD auf USB umzustellen.

Was gänzlich fehlt ist ein durchdachtes SIO-Protokoll. Vielleicht ist Marcin bei seiner SIO2PI schon etwas weiter und wir hätten eine Basis?
Alles in Allem ist noch so viel zu tun, dass ich eine weitere Entwicklungszeit von 10 Jahren schätze

Wenn mir das Projekt aber eines zeigt: Die Möglichkeiten eines solchen Gerätes sind enorm und durchaus im Rahmen des machbaren. Eine Bereicherung für die Community.

Gruß
Sven

Also ich wäre auch froh, es gäbe eine günstige Monitorlösung. Leider verstehe ich zu wenig von der Materie und kann deshalb keine schlauen Vorschläge machen.

Hallo

Wie wäre es mit einem PBI-Expander? Mehr Paralellbusse nutzen als nur eines?

Mathy hat geschrieben:Hallo Andreas, Leute

andreasb hat geschrieben:Der Multiplexer ist zwar eine schöne Idee, aber ...

Laut der Anleitung zum Multiplexer, muss man in jeden Slave-A8 das OS austauschen gegen das Multiplexer-OS. Heißt also: Entweder ich bau kein Sonder-OS ein, oder ich muss jedes Mal umschalten.

Ja, das ist vollkommen ok.

HiassofT hat geschrieben:

GoodByteXL hat geschrieben:Fakten: SIO mit getunter Hard- und Software bei Pokey Divisor 0 leistet max. ca. 11 KB/s, ansonsten 1,2 KB/s. Parallelbus ohne Hardwaretuning bis zu 10 Mal so schnell, je nach Auslegung des Geräts.

Durch das "bis zu" ist die Aussage zwar nicht falsch (jaja, wie war das noch mal mit den DSL Verträgen , aber der Vergleich hinkt doch ziemlich - ich nehme an Du hattest da die ca 80kB/sec bei den IDE Interfaces im Hinterkopf.

Jein! Natürlich kann ein optimiertes IDE-Interface im Lesemodus richtig fix sein. Das IDE Plus unter SDX auf einer Festplatte, die Partitionen mit 512-Byte-Sektoren hat, liest es bei mir bei DMA OFF 112KB/s. Das ist aber ein künstlicher Wert, gemessen mit SysInfo. In der Praxis ist es deutlich weniger, aber ATR-Images z.B. vom ABBUC-Clubmagazin booten darauf um einiges schneller, als von AspeQt über die SIO mit Pokey Divisor 0.

Wenn man nun eine SIO-Verbindung durch eine entsprechende Parallelbusverbindung ersetzen könnte, dürfte man im Lese- und Schreibbetrieb noch immer deutlich fixer als über SIO sein können. Vielleicht wäre ein Einblick in die Transferraten der USB-Cartridge hier hilfreich als Anhaltspunkt ...

Und Parallelbus heißt ja nicht, wie viele meinen - Parallelbusadapter ... 'ne Cart hängt auch an demselben, nur mit kleinerem Adressraum.

HiassofT hat geschrieben:...

Also: machbar ist es schon, aber die Lösung ist ungleich aufwändiger (und damit wohl auch deutlich teurer) als die primitiven IDE Interfaces die wir zur Zeit haben (IDE Plus, SIDE etc).

Ja, so ist das - und es wäre sicher ein interessantes Projekt. Der aktuelle Freezer, die aktuellen "Flash"-Cartridges, die USB-Cartridge und vor allem der Multiplexer zeigen auf, was geht.

Ich hoffe halt, dass mal jemand mit den entsprechenden Kenntnissen so etwas anfasst.

tfhh hat geschrieben:Moin,

Bernd hat geschrieben:...sondern eine umschaltbare OS Platine.
Verschiedene Betriebssysteme können in einem Flashspeicher vom Atari aus ablegt werden. ......

Gibt es doch alles: Ultimate 1 MB. Günstig, gut, aktualisierbar. Und obendrein noch mit RTC und SDX.

Ich hatte bereits Ende 2010 angefangen, eine ähnliche Lösung zu basteln. Immerhin drei Prototypen-PCBs habe ich gemacht, aber mir fehlte immer die Zeit für das BIOS (die Hardware lief bereits fehlerfrei). Dann kam Sebastian und präsentierte die U1MB... da habe ich meine Lösung auf Eis gelegt. Seine Platine ist einfach chic, klein, kann unglaublich viel und der Preis von unter 50 Euro ist Hammer. Das ist weder Neid noch Groll, sonderen Respekt für eine tolle Lösung.

Dennoch werde ich meine "meine" Version mal fertig machen. Allein schon, um WUDSN zu nutzen

Gruß, Jürgen

Hallo Jürgen,
die Ultimate 1 MB ist ein Hammer, auch vom Preis, ich benutze es selbst und habe einige davon. Es gibt da etwas was mir aber fehlt. Kannst du das OS ohne einen externen Brenner ändern und braucht man wirklich 1MB?
Bei den Versionen, die ich habe, geht es nicht.
Zur Funktion noch etwas: Die Echtzeituhr im Ultimate besitzt durch die Batterie einige gepufferte Speicherzellen. Das angewählte OS und die eingestellte Konfiguration wird dort hinterlegt. Falls mal jemand Probleme mit der OS Umschaltung hat, die Batterie ist dann erschöpft.

Viele Grüße,
Bernd

GoodByteXL hat geschrieben: Ja, so ist das - und es wäre sicher ein interessantes Projekt. Der aktuelle Freezer, die aktuellen "Flash"-Cartridges, die USB-Cartridge und vor allem der Multiplexer zeigen auf, was geht.

Ich hoffe halt, dass mal jemand mit den entsprechenden Kenntnissen so etwas anfasst.

Hallo Walter,
er geht noch schneller....
Der Grundgedanke, am Erweiterungbus des Ataris hängt ein inteligentes System mit SRam Speicher, beide teilen sich diesen, der interne Speicher des Ataris ist komplett abgeschaltet. Über eine definierte Schnittstelle gibt man den Befehl zum Speicherfüllen. Der 6502 wird über die HALT Leitung stillgelegt, der externe Chip übernimmt die Aufgabe. Die 64k bekommst du ihn einem Bruchteil der Zeit zum heutigen Stand gefüllt. Es ist nichts anderes als ein DMA Betrieb für den Arbeitsspeicher. Stell dir ein SIO2SD angepasst an die Schnittstelle, ein größerer Atmega sollte dafür reichen. Zur Umsetzung braucht man aber die Entwickler der Software dafür.

Bye,
Bernd

Moin,

Bernd hat geschrieben:Es gibt da etwas was mir aber fehlt. Kannst du das OS ohne einen externen Brenner ändern und braucht man wirklich 1MB? Bei den Versionen, die ich habe, geht es nicht.

Also das Flashen etc. ist kein Problem. Der "AtariGeezer" (AtariAge) hat dazu ein nettes Tool gebastelt, mit dem man auch die Incognito flashen kann. Damit Du (und andere) sich nicht durch AtariAge wühlen müssen, hier eine Kurzanleitung:

1. Tool downloaden, auspacken
2. Entweder vorhandenes 512 KB Flash-ROM der U1MB auslesen oder die Originalversion hier downloaden
3. 512 KB Dump im ROM Generator einladen
4. Gewünschte OS... BASIC...SDX... etc. ROM Files inkludieren
5. 512 KB Datei (geänderter Dump) als BIN File sichern für spätere Änderungen
6. Exportieren als SDX ATR-Image

Nun SDX in der U1MB aktivieren, das Image in D1: rein und booten... Rest läuft wohlbekannt.

Bernd hat geschrieben:Zur Funktion noch etwas: Die Echtzeituhr im Ultimate besitzt durch die Batterie einige gepufferte Speicherzellen. Das angewählte OS und die eingestellte Konfiguration wird dort hinterlegt. Falls mal jemand Probleme mit der OS Umschaltung hat, die Batterie ist dann erschöpft.

Hmm, hattest Du damit schon Probleme? Würde mich insofern wundern, als daß die 2025/2032 Batterien locker 8-12 Jahre halten bei der Dallas RTC, die verbaut ist.

Wenn Du eine der U1MB aus der ersten Charge (also von Sebastian noch selbst hergestellt) hast, dann ist der alte CPLD Code noch drauf. In diesem Fall funktioniert das Tool auch nicht, da die Speicherbereiche zwischen CPLD Code Version 1 und der aktuellen 2 sich total geändert haben - man kann auch das aktuelle BIOS nicht verwenden.

Auch gibt es einen Fehler im alten BIOS, der dazu führt, daß gelegentlich die Settings (z.B. Einstellung des gewünschten OS oder Speichergröße) zufällig geändert werden, was im ersten Moment nach Batteriefehler aussieht. Dies wurde in der 2. Version gefixt.

Die U1MB kann problemlos aktualisiert werden. Wenn Du (und andere Mitleser) keinen Xilinx-Flasher hast, kann ich entsprechende U1MB´s aktualisieren (für lau, nur ggf. Porto). Oder vor Ort am kommenden Samstag, ich bringe den Xilinx-Flasher mit

Gruß, Jürgen

Bernd hat geschrieben:

GoodByteXL hat geschrieben: Ja, so ist das - und es wäre sicher ein interessantes Projekt. Der aktuelle Freezer, die aktuellen "Flash"-Cartridges, die USB-Cartridge und vor allem der Multiplexer zeigen auf, was geht.

Ich hoffe halt, dass mal jemand mit den entsprechenden Kenntnissen so etwas anfasst.

Hallo Walter,
er geht noch schneller....
Der Grundgedanke, am Erweiterungsbus des Ataris hängt ein intelligentes System mit SRam-Speicher, beide teilen sich diesen, der interne Speicher des Ataris ist komplett abgeschaltet. Über eine definierte Schnittstelle gibt man den Befehl zum Speicherfüllen. Der 6502 wird über die HALT Leitung stillgelegt, der externe Chip übernimmt die Aufgabe. Die 64k bekommst du ihn einem Bruchteil der Zeit zum heutigen Stand gefüllt. Es ist nichts anderes als ein DMA Betrieb für den Arbeitsspeicher. Stell dir ein SIO2SD angepasst an die Schnittstelle vor; ein größerer Atmega sollte dafür reichen. Zur Umsetzung braucht man aber die Entwickler-Software dafür.

Ein guter Ansatz! Welche "Entwickler-Software" und ist das ein Problem? Als Laie nur vom Lesen her ist ein ATmega doch ein Standard.