sry, habe die frage schon im software-bereich gestellt, ist aber mir zumindest unklar, ob ich´s mehr als hard- oder software-problem betrachten soll: ich programmierte meinen freezer mit sdx, läuft, wunderbar, danach dann action!, mac und basic xe geflasht, laufen auch solo wunderbar, aber wie kann ich - wenn überhaupt - nach dem booten mit sdx wieder auf die emulierten carts zugreifen, wenn ich nunmal gern unter sdx mit action oder mac65 rumfummeln würde. falls jetzt kommt: geht nicht!, dann gleich die fortsetzung des problems: wenn ich mein action!- oder mac-modul in den freezer xe einsetze und den atari mit der sdx-cart-emu starte, bootet er kurz ein paar sektoren und hängt dann, also auch "denkste!"
korrigiere: nach reset-taste booten und hängen nach laden von rtime8 und ramdisk-treiber...

läuft die chose evtl nur mit nem echten gebastelten sdx und der cart emu oder nem echten modul?

was tun?

ty
tot

Hi!

Tot hat geschrieben:sry, habe die frage schon im software-bereich gestellt, ist aber mir zumindest unklar, ob ich´s mehr als hard- oder software-problem betrachten soll: ich programmierte meinen freezer mit sdx, läuft, wunderbar, danach dann action!, mac und basic xe geflasht, laufen auch solo wunderbar, aber wie kann ich - wenn überhaupt - nach dem booten mit sdx wieder auf die emulierten carts zugreifen, wenn ich nunmal gern unter sdx mit action oder mac65 rumfummeln würde.

Das geht leider nicht. Der Freezer kann nur einen Cartridge Typ gleichzeitig emulieren (also entweder SDX oder BasicXE/Action). Dazu kommt dann noch, daß SDX auch nach dem Booten auf die Cartridge zugreift - einfach von SDX auf BasicXE wechseln geht also auch nicht.

BTW: Welche SDX Version benutzt Du?

wenn ich mein action!- oder mac-modul in den freezer xe einsetze und den atari mit der sdx-cart-emu starte, bootet er kurz ein paar sektoren und hängt dann, also auch "denkste!"
korrigiere: nach reset-taste booten und hängen nach laden von rtime8 und ramdisk-treiber...

Als erstes ist es mal wichtig, daß Du den rtime8 Treiber loswirst, der bringt die CartEmu im Freezer durcheinander. Wenn ich mich richtig erinnere, ist das beim neuen SDX (Version 4.4x für den Freezer) schon korrigiert.

Als nächstes müsste man sich genauer ansehen, wodurch es crasht. In der Kombination von 2 abschaltbaren Modulen ist das nicht so trivial. Bei der originalen SDX Cart fängt die SDX Cart einige der Adressen ab und kombiniert auch die Signale von der darauf gesteckten BasicXE/Mac Cart mit den eigenen. Hauptsächlich geht's darum, ob dem Atari signalisiert wird ob ein Modul eingesteckt ist oder nicht.

Beim Freezer ist das noch ein wenig komplizierter. Der kann dem Atari nicht signalisieren ob eine Cart da ist oder nicht und verwendet einen anderen Trick um die Cart einzublenden. Auch kann er nicht Zugriffe auf eine andere Cart abfangen bzw. Signale von der Cart mit eigenen verknüpfen - der Freezer hat (anders als SDX) keinen eigenen Anschluss für Carts.

Kurzum: es könnte unter Umständen funktionieren, aber garantieren kann man es nicht.

Wie schon geschrieben: gib mal Bescheid, welche SDX Version Du hast. Dann schau' ich nach und überlege noch ein wenig.

so long,

Hias

hi,

ich benutze 4.41, die letzte, soweit ich weiß. was den rtime8-treiber angeht, so habe ich mir die config nach manual so umgestrickt, daß sie den s2utime unterstützt und je nach laune boote ich con80 mit, sonst alles minimal:

device sparta osram
device sio
device ataridos
device jiffy (für die uhr)
device con80

würde - rein theoretisch - hardware-sdx mit der freezer-cart-emu laufen? und, wenn ich schonmal ne kompetenz befragen kann, hast du erfahrungen, ob der freezer mit myide(intern) laufen würde und dann auch carts emulieren könnte?

vielen dank

tot

sry, du wirst sicherlich bemerkt haben, ein sio2usb hängt mit drin, nur der vollständgkeit halber

testergebnisse:
selbst wenn ich die config.sys absolut minimiere auf spartados und sio-treiber, hängt der rechner nach´m booten. ich probierte noch mit den 3 möglichkeiten des sparta.sys rum, aber kein unterschied. mein vorläufiges fazit: geht nicht!

schade eigentlich, das reduziert für mich den sinn der cart-emu auf einzelapplikationen, aber für die programmiersprachen ist es mist. was nützen mir mac65, action und basicxe im freezer, wenn ich sie nur mit dem extern bootbaren spartados oder mydos verwenden kann, ich nunmal aber nach kurzer zeit der eingewöhnung spartadosX echt schätzen gelernt habe?

k, ich beginne es einzusehen

Hi!

Schon das Manual zu SDX 4.41 dazu ausgewertet?

Zum Freezer kann ich nix sagen, da ich nur mal den originalen in 1990 hatte. Scheint aber nach den bisherigen Erfahrungen nur als eine "Testplattform" für SDX gedacht zu sein.

MaxFlash ist da auch nicht viel besser. Richtig gut geht's nur mit einer echten Piggyback-Cartridge.

Die Config.Sys ist auf jeden Fall dafür nicht richtig, da OSRAM verwendet wird.

SpartaDOS X braucht in der Version 4.41 mind. 80K RAM, damit man damit die interessanten Features verwenden kann. BASIC XE noch einmal 64K und dann kommt erst die RAMDisk.

Weitere Schnickes benötigen weiteren Speicher. Ob das der Freezer kann, weiß ich nicht.

SDX Version 4.42 stellt noch mehr Leistung vor allem für Programmierer bereit, ist aber von einer virtuellen Plattform bisher nicht sinnvoll einsetzbar. Es setzt (immer noch) auf echte ATARI-Hardware auf.

Mehr Infos auf der JHV.

hi walter,

bin erst dieses jahr dem erlauchten kreis der freezerbesitzer beigetreten und habe mir den freezerXE besorgt. mein xe hat ja 320k und sonst läuft sdx auch super, die uhrzeit wird vom sio2usb sauber ausgelesen, kann per x-kommando sogar die numen-demo vom hd-atr starten, alles tutti. nur mein liebes altes action bleibt irgendwie aussen vor.
ich denke, ich werde mir demnächst die teile für ein hard-sdx besorgen und basteln, dann kann mich die cart-emu...hoffe ich zumindest..

das manual habe ich mehr überflogen, aber wie schon erwähnt nervt soweit nix außer meinen modulen und kyan-pascal, die wollen einfach nicht.

gibt es in der bauplanrubrik was in richtung "piggyback-selbstbau"?
hast du echtes sdx drin und gehen damit module oder die cart-emu?

danke

tot

Hi!

Cart-Emus für Sprachen brauche ich nicht, weil ich die Originale habe. Die File-Versionen funktionieren alle nur beschränkt, sollten die Cart-Emus darauf aufbauen, erklärt sich das von selbst.
Carts clonen ist aber kein Problem. BXL,BXE,ACTION & MAC/64 in einer Cart findet man des öfteren ...

SDX habe ich im Original in V 4.20 - .22. Das funzt prima mit aufgesteckter Cart - XL-Türmchen

4.42 fahre ich von MaxFlashCart zum Testen - im Moment läuft Beta-Test.

Hardware dafür - 128K-Cart - gibt's im Moment nur in Polen.
Versuche das zu ändern, da SDX m.E. das einzig vernünftige DOS für XL/XE ist.

Manual: Ohne intensives Lesen findet man keine optimale Konfiguration und kann auch die Leistung des DOS nicht abrufen. Es ist mehr als die GameDOSse wie 2.5 und so.

Für Programmierer sind eine Menge Infos drin.

GoodByteXL hat geschrieben:Cart-Emus für Sprachen brauche ich nicht, weil ich die Originale habe. Die File-Versionen funktionieren alle nur beschränkt, sollten die Cart-Emus darauf aufbauen, erklärt sich das von selbst.

Hallo Walter,

die Cart EMU im Freezer bildet eine Cart 100% nach, d.h. im Freezer (Flash-)ROM befindet sich eine 1zu1 Kopie des Cart-ROMs. Der Freezer bildet auch das Bankswitching fuer SDX und OSS-Carts in Hardware nach.

Man kann nur ueber die Cart-Emu immer nur ein ROM laden, und keine 'virtuellen' Tuermchen bilden. Technisch waere das vielleicht sogar moeglich (und nicht so abbruchgefaehrdet wie die echten Tuermchen).

Hias kann vielleicht sagen ob virtuelle Tuermchen ueber einen Firmwareupdate im Freezer moeglich sind.

hi walter,

wo Er recht hat, hat Er recht: konnte zumindest nochmal ein problem durch studium des manuals beseitigen, das "boot inidos.sys" kommando startet sdx aus der cart-emu des freezers, auch wenn ich/man den emu-switch auf off hat. hat den vorteil, daß ich nicht jedesmals beim einschalten erst die parameter der cart-emu eingeben muß und zeitgleich kann ich nach belieben andere disks booten, ohne daß sdx sich dazwischen hängt. aber auch so geht kein action-modul im freezer-slot, wenn ich das hd-image mit inidos drauf boote, danach mit 3.2 gebootet ist action sofort da, hatte irgendwie noch auf den schalter-zustand als lösung gehofft...denkste!

2be continued

tot

Hi!

Ich habe mir nun mal etwas genauer angesehen was hier schief geht. Leider habe ich kein Action/Mac/... Modul zum Testen, also mussten zur Analyse des Problems die technischen Infos genügen.

Das Einblenden des Cartridge Speichers ist erstmal kein Problem. Wenn ich den Action Code richtig verstanden habe schaltet er auch das Modul nicht ab (sondern wechselt nur die Bank in $Axxx). TRIG3/GINTLK sind von daher also kein Problem, und auch nicht von SDX 4.41 für den Freezer, dort wird auch nie direkt was gesetzt.

Durch die spezielle Art wie sich der Freezer in den Atari Speicher einblendet (der Freezer "gewinnt" hier immer, gleich ob es sich um das interne OS/Basic ROM, internes RAM oder eine eingesteckte Cartridge handelt). Insofern ist der Freezer also mit einer Cartridge "ganz unten" in einem "Cartridge Stapel" vergleichbar.

Das Problem ist aber nun die Bankumschaltung des Action (bzw Mac) Moduls. In dem Modul werden nur die Adressleitungen A0 und A3 ausgewertet. Das heisst, die Bankumschaltung erfolgt nicht nur durch die üblichen Adressen in $D50x (D500, D501, D508, D509 - der Zustand von A1 und A2 ist hier auch im Freezer egal) sondern auch durch Zugriffe auf alle anderen Adressen in D5xx. Insbesonders auch zB durch einen Zugriff auf $D54x und $D58x.

Diese Adressen ($D540 - $D58F) werden aber vom Freezer für die Bankumschaltung verwendet. Stellt nun SDX die Bank um (oder deaktiviert das Modul), wird gleichzeitig auch die Bank im OSS Modul geändert und das ist natürlich garnicht gut...

Beim originalen SDX Modul war das IIRC so gelöst, daß bei Zugriffen auf die Bank-Adressen ($D5Ex) das CCTL Signal zur draufgesteckten Cart auf Hi blieb - SDX hat diese Zugriffe also "abgefangen" und die darauf gesteckte Cart hat nichts davon mitbekommen.

Genau das kann der Freezer aber nicht machen. Er ist so designed, daß er rein mit den Signalen am PBI auskommt und damit sowohl an den XLs als auch an den XEs läuft.

Mit einer kleinen Modifikation an der Action/Mac Cart oder - wahrscheinlich einfacher direkt im Atari, am besten abschaltbar, sollte sich das Problem lösen lassen. Man muss den OSS Carts nur beibringen, daß sie nur auf die Adressen $D50x reagieren (statt $D5xx).

Das könnte man zB so lösen, daß man die CCTL Leitung auftrennt und sie zusätzlich mit den Leitungen A4-A7 OR-verknüpft: CCTL-neu = CCTL OR A4 OR A5 OR A6 OR A7. Dann ist das neue CCTL nur dann aktiv (LOW), wenn der Bereich $D50x angesprochen wird.

BTW: Die Freezer-Logik so umzubauen, daß sie "virtuelle Türme" unterstützt ist leider nicht so einfach möglich. Der eingesetzte Logik-Baustein ist schon rammelvoll, da passt nichts zusätzliches mehr rein. Man müsste also irgendwelche Teile (wahrscheinlich den Freezer) entfernen damit das klappt.

so long,

Hias

danke für die fundierte auskunft!

frage(n): ein selbstgebasteltes sdx 4.41 im atari kommt dann mit im freezer emulierten cartridges vermutlich auch nicht klar? hat das schon wer getestet? und wie verhält sich internes sdx mit einem modul ganz normal im slot des atari? läuft das? oder auch fehlanzeige?

das wäre sonst echt kacke, da stolpert man endlich über ein wirklich brauchbares dos nach all den jahren, und wenn man nun mal seine alten module einsetzen will, heißt es disk-dos booten - der bootvorgang mit sdx ist ein traum, 2-3 sekunden, fertig...haha, xp

naja, mal abwarten...

mfg tot

nachtrag: habe mal gemessen, mein atari braucht vom einschalten bis fertig mit sdx und uhrzeit und blabla 7 sekunden, da hat mein pc sogar schon die festplatten entdeckt 0.00179 ghz vs 2x3.6ghz

hi hias,

ich habe mal aus verzweilfung angefangen, mit mac65/ddt und dem freezer in meinem speicher herumzuschnüffeln, um der sdx-problematik zumindest einige geheimnisse zu entlocken.

es ist genauso, wie du sagst: solang ich die cart-emu auf off habe und ein atr mit sdx-inidos drauf boote, kommt "spartdos x not present" und ein blick mit dem freezer zeigt mir im bereich von a000-bfff den mac65-modul-code. wenn ich mit dem freezer den pc auf b022 setze und den freezer verlasse, so wird mac65 sauber initialisiert, aber ich habe kein dos, "dos" springt in den selbsttest.

mit eingeschalteter cart-emu beginnt der boot, ich seh auch im display des s2u die sektor-zugriffe, es kommt bestenfalls noch die meldung über die ramdisk, dann finis. der freezer zeigt mir zw. a000 und c000 dann wunderschön den code von sdx an.
was mich jetzt aber wundert: sollte nicht rein technisch sich dann zumindest sdx sauber initialisieren und erst beim "car" befehl abschmieren, oder versucht sdx schon beim boot-up die mac-cart zu initialisieren und schießt sich damit selbst durch den kopf? ich weiß, daß die module beim power-up gecheckt werden, ist ja so gesehen auch ein lauffähiges sdx da, wird denn bei 2 piggyback-modulen vom os das 2.modul auch gleich mitinitialisiert?

fragen über fragen, aber denkt an die sesamstraße ("wer nicht fragt, bleibt dumm")

ty

tot

moin,

wieder was neues: ich steckte mal testweise die alte atari-basic-cartridge meines 800er in den slot des freezer und startete sdx per emu, und siehe, das läuft.
jetzt bringen mich sowohl "basic" als auch "car" ins basic - ohne modul kommt "not present" bei "car" - scheint also erkannt zu werden.

also verkackt - wie hias so schön analysierte - irgendwas bei der kommunikation des sdx mit der bank-switch-oss-cart - std-8k-carts ohne gimmicks scheinen zu laufen, keine ahnung, wie es mit gato 128k aussieht. werde die gato-cart mal ausbuddeln und testen.

tot