Hallo Thomas

Batchfile Enhancement von Torsten Karwoth gibt's bei mir auf meiner MyDOS Seite. BFE funktioniert aber warscheinlich nur mit MyDOS 4.50.

Software 80 Zeichen Emulator kenne ich keinen der nur mit MyDOS funktioniert, aber ich glaube es gibt da was, das alles in 80 Zeichen (Emulations-) Modus macht. Fragt sich nur wo?

Ein CLI für ein anderes DOS, warscheinlich DOS 2.5, gab es bei entweder ANTIC oder ANALOG Computing mal. Wenn ich mich nicht irre, war es ANALOG. Beide Magazine gibt es in elektronischer Form im Internet. Über Google findest Du die bestimmt.

Tschüß

Mathy

twh hat geschrieben:Howdy *,

kennt jemand einen dup.sys Ersatz für MyDos? Mir gefällt die menügestützte Arbeitsweise von MyDos nicht sehr gut. Ein Grund warum ich mich bisher immer das inkompatible SpartaDos benutzt habe.

kennt ihr ein solches tool?

sowas wie:
d1:>mkdir blah
d1:>cd blah

evtl. noch mit Batch files und einen Software 80Zeichen Mode. Das wär's doch, hm??

\twh

Ich kenne ein solches Tool nicht, aber habe es auf meiner To-Do Liste.

Abwarten. Vielleicht finde ich Zeit.

Ciao

Carsten

Hallo Thomas

Also, die Software aus ANTIC und ANALOG Computing steht schon mal hier http://kevin.atkinson.dhs.org/atari/mag/

Jetzt müßen wir nur noch suchen, wo das richtige File ist. Wenn ich mein 8 Bit System fertig hätte, währe das warscheinlich kein Problem. Nur hab' ich heute noch nichts daran machen können. Und ich muß von sechs SCSI-Geräten die Jumper richtig setzen damit alles läuft.

Also werd ich warscheinlich von Hand suchen müßen. Und da man dabei ziemlich schnell ziemlich viel andere Sachen findet, und es jetzt schon halb eins ist, und ich morgen arbeiten muß, muß das leider noch etwas warten.

Tschüß

Mathy

Ein weiteres DUP.SYS für MyDOS wäre der Toms Navigator. Ein Norton Commander Clone für MyDOS 4.50. Für die täglichen Filesortierarbeiten und kopieren/laden von Programmen sehr gut und schnell zu bedienen. Lediglich für Einstellungen am DOS.SYS braucht man das MyDUP.SYS, denn der Navigator enthält keine Konfigurationsbefehle.

Aber ein "Turbo-DUP auf MyDOS" wäre cool. Wobei es ja noch SpartaDOS und BeweDOS gibt, wenn es die Commandline sein soll. Die sind nur leider nicht DOS 2.5 kompatibel, wenn ich das erichtig verstanden habe.

Gruss,
Stefan

Beetle hat geschrieben:Aber ein "Turbo-DUP auf MyDOS" wäre cool. Wobei es ja noch SpartaDOS und BeweDOS gibt, wenn es die Commandline sein soll. Die sind nur leider nicht DOS 2.5 kompatibel, wenn ich das erichtig verstanden habe.

Sparta-Dos, Real-Dos und Bewe-Dos sind alle Atari Dos 2.5 kompatibel. Diese DOS Versionen bringen ihre eigenen, optimierten Dateisysteme mit (Unterverzeichnisse, Diskette > 130 KB, Datum/Uhrzeit im Dateieintrag). Aber wenn man diese Dateisysteme nicht nimmt, können diese DOS Versionen auch mit einfachen DOS 2.5 SD und MD Disketten umgehen, lesen und schreiben.

Ciao

Carsten

cas hat geschrieben:(...)Bewe-Dos sind alle Atari Dos 2.5 kompatibel.(...) Aber wenn man diese Dateisysteme nicht nimmt, können diese DOS Versionen auch mit einfachen DOS 2.5 SD und MD Disketten umgehen, lesen und schreiben.

Ciao

Carsten

Bewe-DOS selbst liest und schreibt keine ATARI-DOS-Disketten, bringt aber ein Tool mit (MENU.EXE oder .COM), das das kann, das muss seinen eigenen Dateisystem-Handler mitbringen.
Das war u.a. ein Grund, warum ich mich für MyDOS entschieden habe, als ich mit BOSS-X angefangen hatte.

hmm,
das erwähnte CLI ist auf Analog-disks zu finden. Es stammt von BBK (Bryan Schappel und Barry Kolbe). Wie alle uralten CLi`s ist es für DOS 2.0 und DOS 2.5 gedacht, dürfte evtl. aber auch mit MyDOS funkt. Nur: Subdirs u.a. Spezial-Befehle des MyDOS unterstützt es natürlich nicht... sondern nur die ganz normalen DOS 2.0 befehle...

Es gibt noch div. andere CLI`s für DOS 2 und DOS 2.5 - aber auch dort ist nix mit subdirs und so... also musst du hoffen, dass jemand mal sowas für MyDOs macht... Gruss, Andreas Magenheimer.

P.S.: Bei Interesse kann ich dir die CLI`s mal mailen, schreib an:
amp at abbuc point de

atarixle hat geschrieben:

cas hat geschrieben:(...)Bewe-Dos sind alle Atari Dos 2.5 kompatibel.(...) Aber wenn man diese Dateisysteme nicht nimmt, können diese DOS Versionen auch mit einfachen DOS 2.5 SD und MD Disketten umgehen, lesen und schreiben.

Ciao

Carsten

Bewe-DOS selbst liest und schreibt keine ATARI-DOS-Disketten, bringt aber ein Tool mit (MENU.EXE oder .COM), das das kann, das muss seinen eigenen Dateisystem-Handler mitbringen.
Das war u.a. ein Grund, warum ich mit für MyDOS entschieden habe, als ich mit BOSS-X angefangen hatte.

Jau, mein Fehler, hatte ich vergessen. Aber Sparta-DOS und Real-DOS koennen Dos 2.5 Disketten lesen und schreiben.

Ciao

Carsten

Moijn zusammen!

Diese nette Diskussion bestaetigt mich mal wieder (hach, Arroganz kann schoen sein ...) darin, dass SpartaDOS das einzig professionelle DOS ist. Warum also Features nachprogrammieren und in andere DOS-Systeme reinwuergen ?
Geschickter waere doch ein neues Tool fuer SpartaDOS zu schreiben.

Oder noch besser: SpartaDOS X re-engineeren und verbessern und neue Features einbauen.

Das auf einer Platine zusammen mit Flashdisk, Freezer und verschiedenen OS waere mal ein Ansatz, den ich richtig gut faende.

Guus hat in dieser Richtung schon experimentiert und kann qualifiziert beitragen.

Ok, bevor das Argument hochkommt: Fuer Spiele und Spieler ist es nicht attraktativ - andererseits kann man neue Spiele auch so schreiben, dass sie unter SpartaDOS laufen.

Desgleichen fuer Anwendungen, Tools, Utilities.

Ich finde es eine echte Resourcenverschwendung, dass so viele kreative Koepfe sich in zig verschiedenen Kleinprojekten letztendlich verzetteln, anstatt einen echten Standard auf professioneller Grundlage zu schaffen.

Warum soll etwas heute noch DOS-2.5-kompatibel sein? Weil das 1985 mal der ATARI-Standard war?

TurboDOS XL/XE und SpartaDOS sind M.E. die einzigen jemals zuende programmierten DOS fuer den 8-Bitter. Alle anderen Ansaetze sind niemals zuende gefuehrte Projekte und weisen mehr Probleme als Nutzen auf. Allen voran MyDOS, aber auch die ATARI DOS oder TOpDOS, SuperDOS, fehlt nur noch Sisyphus-DOS!

Als Anwender baue ich auf SpartaDOS, DOS 2.5 ist fuer Spiele ...
Wenn z.B. MyPicoDOS auf SpartaDOS aufsetzen wuerde, liessen sich eine Menge Softwareprobleme damit loesen, denke ich, und mehr Medien verwenden ...

GoodByteXL hat geschrieben:Warum soll etwas heute noch DOS-2.5-kompatibel sein? Weil das 1985 mal der ATARI-Standard war?

Ja, genau deswegen. Schließlich will ich, egal mit welchem DOS, meine alten ATARI-Disketten lesen können.

GoodByteXL hat geschrieben:Wenn z.B. MyPicoDOS auf SpartaDOS aufsetzen wuerde, liessen sich eine Menge Softwareprobleme damit loesen, denke ich, und mehr Medien verwenden ...

Darüber hatte ich auch schon nachgedacht. Der Haken an der Sache ist aber, daß das Disk-Format von SpartaDos komplett anders ist und man prinzipbedingt nicht drum herum kommt zusätzliche Buffer im RAM (für die Sektor-Link-Map) zu reservieren.

Niedriger Speicherbedarf ist andererseits aber ein KO-Kriterium wenn man MyPicoDos zum Laden von Spielen (wohl der Haupt-Einsatzbereich) verwenden will.

Ich bin mit MyDOS auch nicht wirklich glücklich und verwende es nur dort, wo es nicht anders geht, zB für meine MyIDE CF Card. Wenn ich mit Disketten (bzw ATR Images bis 180k) arbeite, nehme ich immer noch TurboDos. Datum plus Uhrzeit bei den Dateien zu haben wäre natürlich schon sehr praktisch - das ist mit den 2.x kompatiblen DOSen aber nicht machbar. Mit SpartaDos habe ich mich nie näher beschäftigt, was zT aber auch daran liegt, daß ich nie eine Blackbox o.ä. besessen habe.

so long,

Hias

GoodByteXL hat geschrieben:Moijn zusammen!

Diese nette Diskussion bestaetigt mich mal wieder (hach, Arroganz kann schoen sein ...) darin, dass SpartaDOS das einzig professionelle DOS ist. Warum also Features nachprogrammieren und in andere DOS-Systeme reinwuergen ?
Geschickter waere doch ein neues Tool fuer SpartaDOS zu schreiben.

Oder noch besser: SpartaDOS X re-engineeren und verbessern und neue Features einbauen.

Das auf einer Platine zusammen mit Flashdisk, Freezer und verschiedenen OS waere mal ein Ansatz, den ich richtig gut faende.

Guus hat in dieser Richtung schon experimentiert und kann qualifiziert beitragen.

Ok, bevor das Argument hochkommt: Fuer Spiele und Spieler ist es nicht attraktativ - andererseits kann man neue Spiele auch so schreiben, dass sie unter SpartaDOS laufen.

Desgleichen fuer Anwendungen, Tools, Utilities.

Ich finde es eine echte Resourcenverschwendung, dass so viele kreative Koepfe sich in zig verschiedenen Kleinprojekten letztendlich verzetteln, anstatt einen echten Standard auf professioneller Grundlage zu schaffen.

Warum soll etwas heute noch DOS-2.5-kompatibel sein? Weil das 1985 mal der ATARI-Standard war?

TurboDOS XL/XE und SpartaDOS sind M.E. die einzigen jemals zuende programmierten DOS fuer den 8-Bitter. Alle anderen Ansaetze sind niemals zuende gefuehrte Projekte und weisen mehr Probleme als Nutzen auf. Allen voran MyDOS, aber auch die ATARI DOS oder TOpDOS, SuperDOS, fehlt nur noch Sisyphus-DOS!

Als Anwender baue ich auf SpartaDOS, DOS 2.5 ist fuer Spiele ...
Wenn z.B. MyPicoDOS auf SpartaDOS aufsetzen wuerde, liessen sich eine Menge Softwareprobleme damit loesen, denke ich, und mehr Medien verwenden ...

Sparta DOS benutzt klar das bessere Dateisystem für Medien über 180 KB.

Leider ist der Quellcode für Sparta-Dos oder Bewe-Dos nicht verfügbar, im Gegensatz zu MyDOS, bei dem der Quellcode verfügbar ist.

Ich würde gerne an einem Projekt "Next Generation DOS" mitarbeiten, aber ein DOS von Grund auf neu Programmieren ist eine umfangreiche Aufgabe.

Man könnte sich sicher bei anderen 6502 basieren DOS Versionen anderer 8Bit Computer bedienen, bei denen der DOS Quellcode offenliegt, aber das Resultat wäre dann weder zu Sparta- noch zu DOS 2.5 kompatibel.

Vielleich sollten wir vom ABBUC mal Jiri Bernasek um die Offenlegung des Bewe-DOS Quellcodes bitten.

Ciao

Carsten

Hallo Matthias, hallo Carsten!

Ja, es ist schade, dass die Sources für SpartaDOS und Bewe-DOS nicht zur Verfügung stehen.

IMHO wäre es einen neuen Anlauf wert, da heranzukommen. Das Rad neu erfinden wäre Kräfteverschwendung.

Wenn ich den Umzug hinter mir habe und meine beiden Söhne auf ihrer neuen Spur sauber laufen, werde ich mich mal in Richtung SpartaDOS damit befassen.

Wer kennt denn Jiri persönlich, um da mal vorfühlen zu können?

@Matthias:
lässt sich denn aus SpartaDOS im Rahmen des reverse engineering nicht der Teil herausschnitzen, der die Speicherverwaltung und Medienverwaltung beinhaltet, um ihn dann für MyPicoDOS umwidmen zu können?

Im SpartaDOS Construction Set ist ja auch ein leistungsfähiges GameDOS enthalten. Ggf. solltest du da mal nach Öl bohren ...

Hallo Walter!

GoodByteXL hat geschrieben:Ja, es ist schade, dass die Sources für SpartaDOS und Bewe-DOS nicht zur Verfügung stehen.

IMHO wäre es einen neuen Anlauf wert, da heranzukommen. Das Rad neu erfinden wäre Kräfteverschwendung.

Grundsätzlich ACK. Mit BeweDos könnte das evtl. klappen, bei SpartaDos sehe ich da nicht die geringste Chance.

Bei SpartaDos gibt's ja die ewig lange Diskussion, wer nun eigentlich irgendwelche Rechte daran hat. Tom Hunt hat mal geschrieben, daß ihn die Sache nicht interessiert, Lance Ringquist hatte (in Bezug auf rtdos) geschrieben, daß er den SpartaDos Code nur unter einer "closed source" Lizenz weitergeben würde, und Stephen Carden kocht sein eigenes Süppchen und programmiert and Real.Dos, das er dann als Shareware oder kommerzielles Programm veröffentlichen will.

Die Situation bei SpartaDos ist meiner Meinung nach völlig verfahren, es gibt zum Teil persönliche Streitereien zwischen den Beteiligten und die rechtliche Situation ist komplett unklar.

@Matthias:
lässt sich denn aus SpartaDOS im Rahmen des reverse engineering nicht der Teil herausschnitzen, der die Speicherverwaltung und Medienverwaltung beinhaltet, um ihn dann für MyPicoDOS umwidmen zu können?

Im SpartaDOS Construction Set ist ja auch ein leistungsfähiges GameDOS enthalten. Ggf. solltest du da mal nach Öl bohren ...

Auf Grund der rechtlichen Streitereien möchte ich bei SpartaDos lieber nichts reverse engineeren und dann (auch wenn's nur ein paar Zeilen Code wären) in meine eigene Software einbauen.

Ich habe die Beschreibung des SpartaDos Disk Formats, einziger Punkt wäre, daß ich das einfach implementieren müsste. Klar, das ist aufwändig, aber durchaus machbar. Abgesehen vom Aufwand (der mich natürlich schon etwas davon abgehalten hat damit anzufangen) bleibt aber immer noch das Speicherproblem:

Bei MyPicoDos habe ich ziemlich viel getrickst, um die oberste belegte Speicheradresse so weit wie möglich nach unten zu drücken. Deshalb ist die Highspeed SIO Routine auch abschaltbar (das spart nochmal ein paar Hundert Bytes). Dadurch laufen jetzt sehr viele Programme mit MyPicoDos.

Falls ich SpartaDos Support mit einbaue, würden - ganz grob gesagt - nur mehr die Programme laufen, die auch jetzt mit aktivierter Highspeed SIO Routine funktionieren (wegen dem notwendigen Speicher für die Buffer, aber eben ohne Highspeed) und bei aktivierter Highspeed SIO Routine würden dann wiederum einige Programme, die jetzt mit Highspeed funktionieren, nur mehr ohne Highspeed laufen. Ich bin mir da nicht ganz sicher, ob sich der Aufwand überhaupt lohnt.

so long,

Hias

Hallo Matthias!

Die rechtliche Situation in Sachen SpartaDOS hast du prima für alle Leser hier zusammengefasst.

Das sollte uns aber nicht davon abhalten, durch reverse engineering Erkenntnisse darüber zu gewinnen, wie da was gemacht wurde. Das könnte die Ideen befördern, wie man dann mit den modernen Möglichkeiten an Technik die aktuellen Probleme in Sachen Speicherbedarf, Bank Switching, Routinenspeicher, Highspped-Routine, etc. zu lösen hat, damit es auch funktioniert.

Code kopieren war nicht die Idee.

So wäre z.B. das was SpartaDOS(X) macht gepaart mit den Funktionen aus dem Speeder PLus OS und einer Hardware mit Flashspeicher etc. etwas gänzlich neues in Sachen ATARI. Und das in einer Cart!

Und MyPicoDOS liesse sich beschleunigen, ohne irgendwelche Softwaretricks.

BTW: Highspeed spielt im Zusammenhang mit Festplatten, Flashspeicher und SIO2PC nicht wirklich eine Rolle. Wie gesagt, das Speeder Plus OS (http://home.allgaeu.org/aklinner/Texts/029/029-090.htm) löst da für mich die Probleme, sogar mit MyDOS.

Und ich muss in dem Zusammenhang nochmal anbringen: mir geht es nicht um Spiele sondern um Anwendungen. Die Mühe, Spielesampler auf Images zu bringen und zu flashen mache ich mir nicht; dafür fehlt mir Interesse und Zeit.

Wenn aber z.B. jemand SynFile+ oder SynCalc als Grundlage für ein Programmierprojekt im Zusammenhang damit anginge, könnte man aus dem XL/XE einiges für Heimanwendungen herausholen.

Auch die GEM-Oberflächen wie Diamond OS, SAM, Desktop ATARI oder Boss ließen sich damit entscheidend verbessern.

Insofern könnte sich Aufwand in dieser Sache schon lohnen.

Aber vielleicht kann ja Jiri ein wenig Licht in das Dunkel bringen.

Hallo Walter!

GoodByteXL hat geschrieben:Das sollte uns aber nicht davon abhalten, durch reverse engineering Erkenntnisse darüber zu gewinnen, wie da was gemacht wurde.

OK, das ist eine gute Idee und kann durchaus ein paar Denkanstöße liefern. Als alter Hacker mache ich sowas eh öfters mal, schon rein aus Interesse. Einigermassen geübt bin ich da auch drin :-)

So wäre z.B. das was SpartaDOS(X) macht gepaart mit den Funktionen aus dem Speeder PLus OS und einer Hardware mit Flashspeicher etc. etwas gänzlich neues in Sachen ATARI. Und das in einer Cart!

Klar, eine Cart wäre fein, aber damit ist man ziemlich eingeschränkt. Ein DOS oder ein paar Programme kriegt man da locker rein, aber OS-Erweiterungen (wie zB Highspeed SIO) gehen damit nicht mehr. Solches Zeugs muß ins OS rein, und das lässt sich extern nur relativ schwer realisieren. Am PBI könnte es klappen, aber dann muß man eine komplette PIA mit drauf setzen bzw. sie simulieren (damit das OS auch abschaltbar ist). Spätestens wenn der Atari intern eine Ramdisk hat die PB7 mit verwendet (CompyShop RD und so ziemlich alle >512k) wird's dann aber Probleme geben.

BTW: Highspeed spielt im Zusammenhang mit Festplatten, Flashspeicher und SIO2PC nicht wirklich eine Rolle. Wie gesagt, das Speeder Plus OS (http://home.allgaeu.org/aklinner/Texts/029/029-090.htm) löst da für mich die Probleme, sogar mit MyDOS.

Grundsätzlich ACK. Eine Highspeed SIO gehört auf jeden Fall ins OS mit rein, auch wenn man hauptsächlich mit Harddisk arbeitet so freut man sich spätestens beim nächsten Kopieren von einer richtigen Disk oder von SIO2PC über die höhere Geschwindigkeit.

Aber vielleicht kann ja Jiri ein wenig Licht in das Dunkel bringen.

Das hoffe ich auch, wäre wirklich sehr schön den Sourcecode zu einem DOS zu haben!

Nochmal wegen MyPicoDos: Wofür verwendest Du es hauptsächlich?

Für den Großteil der "normalen" Anwendungen nehme ich ein richtiges DOS (da kommt man eh nicht drum rum), MyPicoDos nehme ich hauptsächlich um File-Games zu laden bzw um mal schnell eben ein selbstgeschriebenes Programm am Atari zu testen, welches auch ohne "richtige" DOS-Funktionen auskommt.

so long,

Hias

Hi Matthias!

Vielleicht habe ich bildlich nicht so richtig getroffen ...

Klar, eine Cart wäre fein, aber damit ist man ziemlich eingeschränkt. Ein DOS oder ein paar Programme kriegt man da locker rein, aber OS-Erweiterungen (wie zB Highspeed SIO) gehen damit nicht mehr. Solches Zeugs muß ins OS rein, und das lässt sich extern nur relativ schwer realisieren. Am PBI könnte es klappen, aber dann muß man eine komplette PIA mit drauf setzen bzw. sie simulieren (damit das OS auch abschaltbar ist). Spätestens wenn der Atari intern eine Ramdisk hat die PB7 mit verwendet (CompyShop RD und so ziemlich alle >512k) wird's dann aber Probleme geben.

Eine 'Cart' ist nicht nur fein sondern wirtschaftlich betrachtet ein Muss. Wenn etwas für den 8-Bit-ATARI erfolgreich laufen soll, muss es ohne "Einbau" funktionieren. Die Masse der Hobby-User bevorzugt einfache Plug&Play-Sachen. Da der ATARI P'n'P von Haus aus drauf hat, wäre es ungeschickt darauf zu verzichten.

Siehe z.B. die FlashCart. Sie wäre niemals so erfolgreich, wenn man da nicht so einfach mit umgehen könnte.

Und SpartaDOS X z.B. hat die Routinen für HighSpeed wohl mit in der Cart. Sie werden dann per Aufruf in der Batch-Datei initialisiert. Wie das genau abgeht, weiss ich als Anwender nicht. Aber der Effekt ist m.E. optimal.

Und alle anderen Features müssen in der 'Cart' untergebracht werden. Eine vorhandene Speichererweiterung muss einfach unberücksichtigt bleiben. Wenn in der Cart z.B. 1 MB mit drin ist, wird es sicher ein paar Spezis geben, die dann auch noch die zusätzlichen 64K des 130XE oder die 256K der XY-Erweiterung verwenden wollen. Darauf sollte in der Entwicklung keine Rücksicht genommen werden, da es zuviele Variationen diees Themas gibt. Eine Komplettlösung entwickeln die alles ersetzt (DOS, OS, SRAM, Freezer, Monitor, SIO2PC, IDE), das ist es.

Ich bin mir im Klaren darüber, dass das alles andere als einfach ist. Aber 'einfache' Sachen kann sogar ich machen ;o).

Nochmal zusammengefasst: Alle gewünschten Erweiterungen in einer Cart oder einem Modul für den PBI unterbringen erschlägt alle Variationen und Insellösungen. Und wenn jeder 8-Bit-Anwender vom 400er bis zum XEGS so ein Teil verwenden könnte, wäre das phantastisch, aber da die Masse ohnehin XL/XE hat (schätze mal 90plus %) wäre das Spektrum damit klar abgegrenzt.

Ich persönlich würde eine Lösung für den PBI bevorzugen. Eine Abgespeckte Version in einer Cart (wahrscheinlich müsste das OS dann extra gesteckt werden) ließe sich aber sicher besser an den/die ATARIanerIn bringen.

Man hat halt noch Träume

MyPicoDOS verwende ich hauptsächlich als 'Game'-DOS auf 1,44MB-Disks am HDI von Erhard. Dafür ist es prima. Da lassen sich dann auch die Programme starten, die mit dem GamesDOS vom SpartaDOS nicht laufen. Für Sampler auf kleineren Disks verwende ich meist SpartaDOS oder TurboDOS, aber nur wenn sie nicht von Festplatte laufen.

Hi Walter!

GoodByteXL hat geschrieben:Ich persönlich würde eine Lösung für den PBI bevorzugen. Eine Abgespeckte Version in einer Cart (wahrscheinlich müsste das OS dann extra gesteckt werden) ließe sich aber sicher besser an den/die ATARIanerIn bringen.

Hier nochmal ein wenig Brainstorming:

Wie schon erwähnt, ein gewisses Problem sind alle die Dinge, die "intern" im Atari ablaufen und von denen man "außen" nichts merkt. Wenn wir interne Ram-Erweiterungen ignorieren, kommen als nächste Punkte die Cartridges dran.

Eine Lösung dafür wäre, einen Cart-Slot direkt auf der Erweiterung unterzubringen. Den Slot im Atari darf/kann man dann nicht mehr benutzen. Um das ganze wasserdicht zu machen, wäre es am besten auch gleich die 64k (internen) RAM auf der Erweiterung unterzubringen. Damit könnte man die gesamte MMU Logik auf die Erweiterung verschieben, vom Atari würden dann nur mehr die CPU, Custom Chips und die I/Os benutzt werden. Alles andere wäre auf der Erweiterung drauf.

Für einen "nackten" Atari ist so eine Erweiterung auf jeden Fall ganz nett, selbst einen 16k 600XL könnte man so in ein paar Sekunden voll erweitern. Nachteil daran ist aber, daß man bezüglich anderer Erweiterungen stark eingeschränkt ist - der PBI ist nun ja belegt, interne Erweiterungen sind auch nicht mehr möglich.

Bezüglich des IDE/Harddisk Interfaces bin ich auch sehr unschlüssig welche wir da nehmen sollten. Es gibt eine Menge solcher Erweiterungen, aber meiner Meinung nach nicht die ideale. Jede hat ihre Stärken und Schwächen, was zum Teil aber auch einfach nur an der Software liegt. Ein einfaches Interface ähnlich wie das MyIDE, kombiniert mit einer Konfigurations-Software ähnlich der BlackBox wäre schon mal recht fein.

Da kommt dann aber schon wieder der nächste Punkt: die leidigen Timing-Probleme mit den Ataris. Am PBI liegt leider kein PHI0 an, ohne dem wird's sehr schwer irgendwelche einfachen IDE Interfaces zu bauen, die dann auch noch halbwegs kompatibel zu den erhältlichen Festplatten sind.

Intern könnte man das einfach so lösen, daß die MMU komplett raus kommt, stattdessen gibt's einen Adaptersockel von der Erweiterung zum MMU-Sockel, die Erweiterung selber wird in den CPU-Sockel gesteckt. CPU kommt dann in einen leeren Sockel auf der Erweiterung.

so long,

Hias