GoodByteXL hat geschrieben:

skriegel hat geschrieben:- Module können ohne weitere Hardwareänderung nicht mit dem IDE Plus 2 genutzt werden, weder im Modulschacht des Interfaces noch im Modulschacht des Atari. Beschreibung der nötigen Änderung folgt.

Das stimmt nicht! Siehe letztes Foto zu diesem Beitrag im anderen Thread: viewtopic.php?f=15&t=5947&start=86

Habe ich geändert. Irgendwas stimmt mit meinem Mac65 Modul nicht. Läuft auf allen Rechnern einwandfrei, aber mit IDE Plus 2 nur am 130 XE, nicht an den XLs. Spielemodule laufen aber.

skriegel hat geschrieben:

GoodByteXL hat geschrieben:

skriegel hat geschrieben:- Module können ohne weitere Hardwareänderung nicht mit dem IDE Plus 2 genutzt werden, weder im Modulschacht des Interfaces noch im Modulschacht des Atari. Beschreibung der nötigen Änderung folgt.

Das stimmt nicht! Siehe letztes Foto zu diesem Beitrag im anderen Thread: viewtopic.php?f=15&t=5947&start=86

Habe ich geändert. Irgendwas stimmt mit meinem Mac65 Modul nicht. Läuft auf allen Rechnern einwandfrei, aber mit IDE Plus 2 nur am 130 XE, nicht an den XLs. Spielemodule laufen aber.

Das Modul ist in Ordnung - aber mit den OSS-Supercartridges geht das nicht.

Wenn die Adapterplatine für die fehlenden Signale des IDE Plus 2 im Modulschacht steckt und das MAC65 Modul im Sockel des IDE Plus 2,
gibt es mit SDX 4.44 keine Probleme. SDX meldet sich, mit car startet der MAC65. Boote ich mit der gleichen Konfiguration von einer Partition
MyDos 4.53, erscheint die Meldung vom MAC65, dabei wird die Schrift kurz in dunkelblau angezeigt, anschließend schaltet der Bildschirm
in schwarz um, nix mehr ist zu sehen. Da scheint noch ein Bug im Bios zu stecken.... Fehler tritt im 800XL und 800XE auf. Der MAC65 ist ein
Originalmodul, kein Nachbau...

Steckt das Modul im Schacht vom 800XL, erscheint die MAC65 Meldung unter MyDos, danach sind jedoch alle Tasten ohne Funktion.
Mit SDX funzt es....

Bernd

PS: Testen kann ich erst wieder nächstes Wochenende, fahre heute los zu einem Seminar in der Nähe von Starnberg.

skriegel hat geschrieben:

GoodByteXL hat geschrieben:

skriegel hat geschrieben:- Module können ohne weitere Hardwareänderung nicht mit dem IDE Plus 2 genutzt werden, weder im Modulschacht des Interfaces noch im Modulschacht des Atari. Beschreibung der nötigen Änderung folgt.

Das stimmt nicht! Siehe letztes Foto zu diesem Beitrag im anderen Thread: viewtopic.php?f=15&t=5947&start=86

Habe ich geändert. Irgendwas stimmt mit meinem Mac65 Modul nicht. Läuft auf allen Rechnern einwandfrei, aber mit IDE Plus 2 nur am 130 XE, nicht an den XLs. Spielemodule laufen aber.

Das Modul ist in Ordnung - aber mit den OSS-Supercartridges geht das nicht. -> Ergänzung: Die OSS-Supercartridges (andere habe ich nicht) laufen nicht, wenn man sie in den Cart-Slot des 800XL steckt und hinten ein IDE V2 draufsteckt. Die OSS-Supercarts müssen "auf dem SDX-Modul" stecken, um funktionieren zu können. Fehlen wie beim 800XL am PBI die zum Steuern der OSS-Cart notwendigen Signale, lässt sich die OSS-Supercart von dem SDX auf dem IDE V2 Plus nicht steuern. Da OSS-Supercarts wie SDX auf das RAM unter dem OS zugreifen, tritt ein Konflikt auf und nichts geht mehr. Intern benötigt die OSS-Supercart CCTL zum korrekten Bank Switching in der Cart. Da dieses Signal am PBI des XL nicht vorhanden ist, funktioniert auch die OSS-Supercart bei abgeschaltetem SDX auf dem Cartport des IDE V2 Plus nicht. Wer die OSS-Supercarts am XL mit IDE V2 Plus nutzen will, sollte das 8-adrige Zusatzkabel oder bei deaktiviertem "IDE-SDX" eine im XL eingesteckte SDX-Cartridge oder ein internes SDX im XL verwenden. Für das Kabel erhält mein "Arbeits-800XL" einen Jumper.

Bernd hat geschrieben:Wenn die Adapterplatine für die fehlenden Signale des IDE Plus 2 im Modulschacht steckt und das MAC65 Modul im Sockel des IDE Plus 2, gibt es mit SDX 4.44 keine Probleme. SDX meldet sich, mit car startet der MAC65. Boote ich mit der gleichen Konfiguration von einer Partition MyDos 4.53, erscheint die Meldung vom MAC65, dabei wird die Schrift kurz in dunkelblau angezeigt, anschließend schaltet der Bildschirm in schwarz um, nix mehr ist zu sehen. Da scheint noch ein Bug im Bios zu stecken.... Fehler tritt im 800XL und 800XE auf. Der MAC65 ist ein Originalmodul, kein Nachbau...

Hm, da scheint tatsächlich ein Bug im BIOS zu stecken. Der Bug mit MAC/65 kann auch in der Konfiguration für die Speicheraufteilung liegen. Letzteres hatte ich bei SDX schon, wenn ich den Erweiterungsspeicher fix aufgeteilt hatte. Dann kann das System den notwendigen Speicher für den MAC offenbar nicht korrekt konfigurieren. Von daher lasse ich in der "Config.Sys" immer erst die Speicherfresser 'ran und zuletzt den Treiber für die RAMDisk, der dann nimmt, was noch übrig ist.

Hallo Walter

Bist Du dir ganz sicher dass es am CCTL liegt? CCTL ist nämlich nur die Auscodierung für den Bereich $D5xy. Diese Auscodierung kriegt man mit etwas Elektronik auch hin.

Tschüß

Mathy

Da ich schon einige male angemorst worden bin, ob man das Zusatzkabel für den Cartridge-Port auf dem KMK IDE V2 Plus unbedingt braucht ...

JEIN

Wer die volle Funtkionalität des Cartridge-Ports braucht, z.B. um FlashCarts zu beschreiben oder die Programmiersprachen von OSS (ACTION!, MAC/65, BASIC XL, BASIC XE, wahrscheinlich auch The Writer's Tool) zu benutzen, braucht es. Denn diese Cartridges müssen zwingend auf dem externen Cartridge-Port am Interface aufgesteckt werden.

Wer originale Spiele-Cartridges (Joust, Pac-Man, etc.) verwenden will, braucht es nach meinen bisherigen Testerfahrungen nicht. Diese kann man wie gewohnt in den Cartridge-Port des XL 600/800XL stecken, schaltet das IDE-Interface beim Booten mit der dafür im BIOS festgelegten Tastenkombination aus und das Spiel wird gestartet.

Was ich noch nicht testen konnte: Anwendungscartridges (ATARI Artist, ATARI Lab, ATARI Schreiber etc.), die ein DOS brauchen, um die Ergebnisse der Anwendung speichern zu können.

Im BIOS des Interface sind einige Routinen vorhanden, die ein einfaches Handling von Cartridges auch über den externen Cartridge-Port des Interfaces ermöglichen. Mit simplen Cartridges (2-8KB) sollte es funktionieren. Ob es mit den XE Supercartridges geht, kann ich nicht testen, da ich keine habe. Vermutlich aber nicht, da sie wie die OSS-Module mit Bank Switching arbeiten.

Moin,

GoodByteXL hat geschrieben:Im BIOS des Interface sind einige Routinen vorhanden, die ein einfaches Handling von Cartridges auch über den externen Cartridge-Port des Interfaces ermöglichen. Mit simplen Cartridges (2-8KB) sollte es funktionieren. Ob es mit den XE Supercartridges geht, kann ich nicht testen, da ich keine habe. Vermutlich aber nicht, da sie wie die OSS-Module mit Bank Switching arbeiten.

Habe ich getestet, funktioniert nicht. Es funktionieren "ohne Kabel" nur Standardmodule, alle Module, die das CCTL Signal benötigen (für Bankswitching, Modul an/aus etc.) funktionieren nur, wenn "das Kabel" angeschlossen wird.

Ich habe (hatte ich ursprünglich angekündigt) eine Lösung entwickelt, die nachträglich entsprechende Signale zur Verfügung stellt. Dazu wird ein GAL 22V10 benötigt. Es ist aber deutlich einfacher, die Signale mit einem "Dummy-Modul" aus dem Modulschacht herauszuführen - und diese Lösung ist auch 100% kompatibel.

Meine Lösung basiert darauf, über einen Adressdecoder und etwas Logik die entsprechenden Signale (CCTL/S4/S5) nachträglich zu generieren, was kein Problem ist, denn am PBI liegen alle Signale an. Wird ein Zugriff auf den Modulbereich erkannt und RD4/RD5 ist high, wird EXTSEL gesetzt (DRAM im ATARI wird ausgeblendet) und das ROM via S4/S5 eingeblendet. Das funktioniert alles gut, einziges Problem ist, daß RD5 via TRIG3 nicht abfragbar ist und dies könnte bei Flash-Tools Probleme machen (habe ich noch nicht verifiziert). Und es darf natürlich kein Modul im Modulschacht des XL stecken.

Da für diese Lösung eine kleine Platine nötig ist (Lochraster langt), ist der Aufwand ungleich höher (ok... man kann es natürlich auch fliegend verdrahten, auch machbar). Eingriffe am KMK-IDE v2 sind NICHT erforderlich - da habe ich einen netten "Trick": Bei Reichelt gibt es noch 16 Bit ISA Slots zu kaufen (Reichelt-Artikel-Nummer: STECKER 62-254), so einer wird dann auf die unbenutzen Kontaktzungen für ECI/Modulport am XE gesteckt, dort liegen alle Signale an, so daß nicht einmal gelötet werden muß am KMK-IDE v2.

Falls ernsthaftes Interesse an dieser (nicht 100, sondern nur 95-98%) Lösung besteht, mach ich einen Artikel fertig.

Gruß, Jürgen

Hi!

tfhh hat geschrieben:Meine Lösung basiert darauf, über einen Adressdecoder und etwas Logik die entsprechenden Signale (CCTL/S4/S5) nachträglich zu generieren, was kein Problem ist, denn am PBI liegen alle Signale an. Wird ein Zugriff auf den Modulbereich erkannt und RD4/RD5 ist high, wird EXTSEL gesetzt (DRAM im ATARI wird ausgeblendet) und das ROM via S4/S5 eingeblendet. Das funktioniert alles gut, einziges Problem ist, daß RD5 via TRIG3 nicht abfragbar ist und dies könnte bei Flash-Tools Probleme machen (habe ich noch nicht verifiziert). Und es darf natürlich kein Modul im Modulschacht des XL stecken.

Konkret für SDX und das IDE Interface ist es einfacher wenn ihr bei der Variante mit der Modul-Adapterplatine bleibt.

Die Lösung mit EXTSEL hat den Nachteil, daß sich damit nur das RAM im Atari ausblenden lässt, nicht aber das eingebaute Basic. RD4/RD5 schaltet sowohl RAM als auch BASIC ab.

Bei der Entwicklung der neuen Turbo Freezer Logik habe ich mich nun auch genauer mit dem SDX Banking und der Passthrough/Stackable Cart Funktion von IntSDX (und den darauf basierenden neueren Lösungen) auseinandergesetzt und bin dabei über ein paar Sachen gestolpert, die ich vorher nicht so genau wusste:

(Int-) SDX leitet CCTL "ungefiltert" durch, d.h. bei einem Zugriff auf die SDX Bank-Register wird gleichzeitig auch das Banking einer aufgesteckten (zB OSS Cart) verändert. Vorher hatte ich vermutet, daß SDX seine eigenen Adressen rausfiltert und CCTL der aufgesteckten Cart nur bei den unbelegten Adressen setzt. Mit der Vermutung lag ich aber falsch :-)

Dafür klinkt sich SDX in S4, S5, RD4 und RD5 ein und kontrolliert damit das aufgesteckte Modul. Insgesamt gibt es dabei 3 Modi:
- SDX an, das aufgesteckte Modul ist dann automatisch aus. S4/S5 zum Modul sind High, RD4 und RD5 kommen vom SDX, die RD4/RD5 Leitungen zum Modul sind unterbrochen.
- SDX aus, aufgestecktes Modul an: S4/S5/RD4/RD5 vom aufgesteckten Modul sind mit den Leitungen zum Atari verbunden.
- SDX aus, aufgestecktes Modul aus: Damit hängt garnichts mehr an den Sx/RDx Leitungen zum Atari. Damit kann SDX jedes beliebige aufgesteckte Modul abschalten (auch solche die sonst nicht abschaltbar sind), ohne daß es irgendwas über die Funktionsweise (zB Banking) des Moduls wissen muss - und man hat Zugriff auf das eingebaute Atari Basic oder auf das Atari-RAM im Basic/Cart Bereich.

Walter hat ja einen Screenshot gepostet, irgendwie ist es lustig, daß man bei einem eingesteckten Modul trtozdem ins interene Basic kommen kann :-) Achja: der neue Freezer kann das mittlerweile auch, ich bin zum Testen zwischen Mac/65 und Atari Basic geweckselt :-))

so long,

Hias

HiassofT hat geschrieben:...Walter hat ja einen Screenshot gepostet, irgendwie ist es lustig, daß man bei einem eingesteckten Modul trtozdem ins interene Basic kommen kann ...

vermute mal, das du den Screenshot von Altirra meinst ...
Das geht aber mit SDX erst seit der Version 4.17 von 1988
Wer also mit 2 verschiedenen Programmiersprachen quasi gleichzeitig arbeiten will, kann das mithilfe von SDX sehr gut handeln.

GoodByteXL hat geschrieben:

Bernd hat geschrieben:Wenn die Adapterplatine für die fehlenden Signale des IDE Plus 2 im Modulschacht steckt und das MAC65 Modul im Sockel des IDE Plus 2, gibt es mit SDX 4.44 keine Probleme. SDX meldet sich, mit car startet der MAC65. Boote ich mit der gleichen Konfiguration von einer Partition MyDos 4.53, erscheint die Meldung vom MAC65, dabei wird die Schrift kurz in dunkelblau angezeigt, anschließend schaltet der Bildschirm in schwarz um, nix mehr ist zu sehen. Da scheint noch ein Bug im Bios zu stecken.... Fehler tritt im 800XL und 800XE auf. Der MAC65 ist ein Originalmodul, kein Nachbau...

Hm, da scheint tatsächlich ein Bug im BIOS zu stecken. Der Bug mit MAC/65 kann auch in der Konfiguration für die Speicheraufteilung liegen. Letzteres hatte ich bei SDX schon, wenn ich den Erweiterungsspeicher fix aufgeteilt hatte. Dann kann das System den notwendigen Speicher für den MAC offenbar nicht korrekt konfigurieren. Von daher lasse ich in der "Config.Sys" immer erst die Speicherfresser 'ran und zuletzt den Treiber für die RAMDisk, der dann nimmt, was noch übrig ist.

Der Bug ist an anderer Stelle zuhause ...

Verlässt man mit "DOS" unter SDX die jeweilige Programmiersprache, wird automatisch das File BASIC.SAV oder CAR.SAV auf einer vorhandenen RAMDisk angelegt. Alternativ kann man in einer CFG-Datei beim Booten festlegen, dass die Sicherung auf einem physikalischen Laufwerk erfolgt. Z.B. bei mir derzeit mit
SET BASIC=B:\MEMSAV\BASIC.SAV
für das eingebaute ATARI BASIC und mit
SET CAR=B:\MEMSAV\CAR.SAV
für die 4 OSS Programmiersprachen ACTION!, BASIC XL, BASIC XE und MAC/65.

Falls mal wirklich der Rechner komplett RESETted werden muss, ist der RAMDISK-Inhalt wech ...
Auf Medium bleibt der erhalten und wird beim nächsten Sprung ins Modul wieder geladen. Sehr praktisch beim Programmieren.

Schaltet man von einer auf die andere OSS-Sprache um und springt mit CAR wieder ins Modul, meckert SDX über ein verändertes Memlo, das man dann gepflegt ignorieren kann, wenn die alte Sicherung nicht mehr gebraucht wird, und es mit einer neuen Sicherung überschreiben kann. RETURN genügt dafür.

Dabei tritt aber ein Problem auf: MAC/65 hängt sich auf, wenn bereits ein File CAR.SAV existiert. Man muss zuerst manuell die CAR.SAV löschen und dann in den MAC/65 hüpfen.

Das passiert ab und an auch, wenn man neu bootet und in den MAC springt. Entweder haben sich dann alte Daten in der RAMDISK (weil sie geschützt war) erhalten oder der MAC/65 hat solche Daten "gefunden" und kann sich dann nicht passig initialisieren.

Nachtrag:
Diese Macke des MAC/65 konnte ich bisher nur durch aus- und wieder einschalten des ATARI erfolgreich überwinden. Der MAC/65 nutzt auch andere Adressen im ATARI, nicht nur im Erweiterungsspeicher. Die Initialisierung ist "ungewöhnlich" und wenn man vom MAC ins DOS und wieder zurückspringt kann dieses Problem auch auftreten. Ich hatte bei der Bearbeitung des SDX-Manuals eine Info dazu bekommen, kann sie im Moment aber nicht lokalisieren.