... ich habe da mal einige Probleme festgestellt im Zusammenhang mit Hias OS und Ultimate Utility Cartridge....
Habe in meinem A8 seit kurzem das Config4Bios von HardwareDoc installiert. Habe weiterhin eine 256kB RAM Erweiterung. Beim Starten von vielen Anwendungen der Cartridge hängt sich mein A8 auf und der Monitor bleibt schwarz - nur ein kompletter Neustart des Rechners hilft dann noch weiter. Wer kann mir da helfen?

UdoWy hat geschrieben:Beim Starten von vielen Anwendungen der Cartridge hängt sich mein A8 auf und der Monitor bleibt schwarz - nur ein kompletter Neustart des Rechners hilft dann noch weiter.

Kannst Du das OS selber neu flashen? Wenn ja, kann ich Dir schon mal eine Vorab-Version meines neuen Highspeed-Patches zukommen lassen. Hab' da ein paar Sachen geändert (u.a. auch die Page 1 Belegung von $0100-$010D auf $0108-$0115 verschoben), wäre interessant zu wissen ob damit das Modul läuft.

so long,

Hias

Hi Hias,

wenn wir von dem selben Hias-OS mit HS und (Affengriff) reden. Ich habe es auf einem XE und einem XL Rechner und kann nicht meckern.

ALLERDINSG mit dem Ultimate Utility Cartridge habe ich es noch nicht eingesetzt, dass werde ich am Montag nachholen.

Hi,

leider habe ich das OS noch nicht verbaut, kann Dir daher im Moment nichts genaues dazu sagen. Nur mal so ....
geht es mit den Erweiterungen (256k+ Config4Bios) und dem orig. OS ? Es muß nicht zwangsweise mit dem OS von HIAS zusammen hängen. Kann gut sein, dass der Phi2 "Auffrischer" versagt. Es scheint wirklich nicht oft zu passieren (bei zig Rechnern nur ein einziges mal) und daher würde ich es nicht ausschließen.

Kannst Du mal das Modul einstecken (egal mit welchem OS) und mit "0" in den Testmodus gehen! Starte bitte den Test "1" und lass ihn ein paar Runden drehen. Läuft er ohne Probleme durch ?

Oder .... es kann aber auch gut sein, dass Hias den Bereich um 0xc000 bis 0xcfff (RAM) herum nutzt und genau den nutzt das UUM ebenso. In dem Fall kann ich im Moment nicht viel ändern, dich nur auf ein anderes OS vertrösten.

Viele Grüße
Alexander

... also ich habe den Test mit "1", wie gewünscht unter dem Original Atari XL OS mehrmals durchlaufen lassen - hier treten keinerlei Probleme auf. RAM Erweiterung ist im Config4Bios eingeschaltet. Hier lassen sich alle getesteten Programme von der Ultimate Utility Cartridge (natürlich noch nicht alle 177 probiert!) starten ....

Koche hat geschrieben:Oder .... es kann aber auch gut sein, dass Hias den Bereich um 0xc000 bis 0xcfff (RAM) herum nutzt und genau den nutzt das UUM ebenso. In dem Fall kann ich im Moment nicht viel ändern, dich nur auf ein anderes OS vertrösten.

RAM benutzt der Patch nur von $0100-$010D. Im ROM belegt er $CC00-$CFFF, ausserdem sind SIO, sowie NMI-, Keyboard IRQ- und der Reset-Handler gepatcht.

Abgesehen von Kollisionen mit dem RAM Bereich hat bisher nur der gepatchte NMI Handler Probleme bereitet. Letzteres ist mit dem neuen Patch dann Geschichte, der NMI Handler bleibt original.

so long,

Hias

also Hias habe Dir PN wegen Patch geschickt....

Hallo Udo!

Mir sind da noch ein paar Fragen eingefallen. Ich hab' zwar selber keine Utility Cart, aber vielleicht kann mit den Infos ja wer anderer gegentesten oder wir können den Fehler etwas näher eingrenzen (Alexander sollte sich mit der Cart ja recht gut auskennen :-)

Bei welchen Anwendungen auf der Cart tritt das genau auf, welche funktionieren, welche nicht? Ein paar Beispiele sollten zum Testen genügen.

Tritt der Fehler reproduzierbar auf oder laufen die Anwendungen mal schon und mal nicht?

so long,

Hias

Also, es sollte sich reproduzieren lassen - da der /die Fehler jedesmal wieder auftreten. Wie gesagt habe es mit mehreren Programmen vom Ultimate Utility Cartridge (u.a. dem SysInfo2.2 - Punkt "j", oder auch MAC65 - Punkt "h") getestet. Der A8 hängt sich komplett auf, läßt sich nur noch mit einem kompletten Neustart (auch kein Kaltstart) neu booten. Unter Original Atari XL OS passiert das nicht. Auch mit ausgeschalteter RAM Erweiterung passiert das selbe, der A8 hängt sich komplett auf.
Übrigens danke, für die neue Version - werde sie so schnell wie möglich testen....

Hallo,

es beruhigt mich ja erst mal, dass das Modul in Ordnung ist. Tut mir leid, dass Dir das im ersten Moment nicht hilft.

Ich denke mal, es betrifft alle Programme, die andere Programme (wie bspweise das DOS) oder Programmteile gemeinsam nutzen. Der von dir genannten Mac65 Version hatte ich auch ein DOS verpasst, daher mag dortiges Fehlverhalten im ersten Moment irritieren.

Leider nutze ich Page 1 (0x100 bis 0x1xx) auch sehr gern und kollidiere da wohl etwas mit dem OS von Hias. Ich müsste noch mal genau nachsehen, aber auf 0x110 bis irgendwas liegt mein Entpackerstack und davor lege ich gern mal ein paar Dinge ab. In Deinem Fall handelt es sich um die Rücksprungadressen+Modulbank des einen fremden/entfernten Teil nutzenden Programms. Letztere werden wohl durch die Doppelnutzung verändert worden sein und beim Sprung zurück gehts ins Nirvana.

Sicherlich könnte Hias da etwas ändern, aber es wird allzeit Nischen-Programme oder Module geben, die mit dem neuen OS nicht wollen, für die man Änderungen vornehmen muss. Ob das immer und für alles gut geht ? Ich weiß es nicht.

Wie wichtig ist Dir die Sache den ? Ich kann bei mir sicherlich noch einiges verbessern. Und da ich im Programmstarter/kopierer seit kurzem wieder etwas Platz habe, wäre es durchaus möglich, diese Infos dort abzulegen.

Viele Grüße
Alexander

Da ich ja nun weiss das unter AtariXL OS alles läuft, ist es nicht so wichtig - währe halt nur schön nicht ständig hin-und herschalten zu müssen.
Außerdem empfinde ich HIAS OS als das beste.... Mein SIO2IDE (CF) kommt damit auch am besten zurecht.

Koche hat geschrieben:Sicherlich könnte Hias da etwas ändern, aber es wird allzeit Nischen-Programme oder Module geben, die mit dem neuen OS nicht wollen, für die man Änderungen vornehmen muss. Ob das immer und für alles gut geht ? Ich weiß es nicht.

Wie wichtig ist Dir die Sache den ? Ich kann bei mir sicherlich noch einiges verbessern. Und da ich im Programmstarter/kopierer seit kurzem wieder etwas Platz habe, wäre es durchaus möglich, diese Infos dort abzulegen.

So lange kein SIO-Aufruf zu einem Disk-Drive stattfindet sollte die "Kollision" bei $01xx eigentlich nichts ausmachen, denn nur dann (bzw. wenn der User einen der Shift+Control Hotkeys drückt) wird dorthin geschrieben.

Ich habe den Patch so ausgelegt, daß er sich im Falle einer Kollision deaktiviert (und erst per Hotkey wieder aktiviert werden kann):

Im alten Code habe ich in $0109 ein "enable" Flag nur wenn es 0 ist wird der Highspeed Patch verwendet (kann per Hotkeys auf 0 bzw $FF gesetzt werden).

Wird der Highspeed Patch verwendet, sind folgende Bytes in $01xx belegt:
$0100: Geschwindigkeit für aktuellen Zugriff (wird bei jedem SIO Aufruf gesetzt)
$0101..$0108: Tabelle mit den ermittelten Geschwindigkeiten D1-D8, wird beim ersten Zugriff gesetzt, danach nur gelesen
$0109: Enable Flag, wird immer ausgewertet, per Hotkey gesetzt
$010A..$010D: temporärer Buffer, wird bei der Ermittlung der Geschwindigkeit eines Laufwerks benutzt

Im neuen Code ist alles um 8 Bytes nach hinten verschoben (das ABBUC Menü schreibt zB irgendwas nach $0100/$0101 die dann die Tabelle durcheinanderbringt), mit dem neuen Code klappt es.

Also: so lange kein Disk-SIO-Aufruf stattfindet sollte eigentlich nichts schiefgehen...

so long,

Hias

Hi Alexander!

Koche hat geschrieben:Oder .... es kann aber auch gut sein, dass Hias den Bereich um 0xc000 bis 0xcfff (RAM) herum nutzt und genau den nutzt das UUM ebenso.

Dazu ist mir gerade noch was eingefallen:

Welche Bereiche benutzt Du denn in $Cxxx genau?

Beim original XL OS liegt der NMI Handler ja ab $C018 im ROM, beim HiSIO/NMI Patch aber ab $CF68.

Wenn Du nun (so wie ich bei meinem Software-Patch :-) das OS ins RAM kopierst und in $CC00-$CFFF eigenen Code/Daten ablegst kommt's beim nächsten NMI zum Crash.

Speicher im Atari ist wirklich knapp, und der internationale Zeichensatz bietet sich förmlich an (ähnlich wie der Stack). Würde mich nicht wundern, wenn das der Grund für die Inkompatibilität ist (eine Kollision mit dem Stack-RAM schliesse ich ziemlich aus, Probleme mit dem NMI sind da viel wahrscheinlicher).

BTW: Bei der Software die ich für Bernds aktuelles Modul geschrieben habe hab' ich auch ziemlich lange nach einem kleinen Stückchen im OS gesucht das noch unbenutzt ist. Bin dann im XL OS bei $CB65-$CBFF und im QMEG OS bei $FF80-$FFF5 fündig geworden und konnte dort noch meine ca. 80 Bytes Code reinquetschen.

so long,

Hias

Ein kurzer Test meinerseits ergab, das das UUC das OS ins RAM kopiert und an einigen Stellen in der Reset-Routine sowie in $CC00-$CFFF patcht. Es springt auch mitten in die Reset-Routine bei $C3D9. Das führt natürlich dazu, dass das Modul nicht mit allen Spezial-OSsen, die es so gibt, funktioniert - für das QMEG-OS ist z.B. der JMP $C3D9 tödlich.

Seltsamerweise gibt es aber nur Probleme, wenn man ein Tool zusammen mit einem DOS aus dem Modul startet. Ohne DOS geht es (zumindest bei MAC/65 und ACTION). Ich starte deshalb MAC/65 bzw. ACTION ohne das Modul-DOS, womit das DOS von D1: gebootet wird.

In der XDOS-Version auf dem Modul gehen außerdem die Befehl BON und BOF nicht - schade, es wäre mir ein leichtes gewesen, XDOS an das Modul anzupassen.

Hias hat geschrieben:Bei der Software die ich für Bernds aktuelles Modul geschrieben habe hab' ich auch ziemlich lange nach einem kleinen Stückchen im OS gesucht das noch unbenutzt ist. Bin dann im XL OS bei $CB65-$CBFF und im QMEG OS bei $FF80-$FFF5 fündig geworden und konnte dort noch meine ca. 80 Bytes Code reinquetschen.

Den Bereich ab $CB65 habe ich vorsichtshalber für meine Software nicht benutzt, da der beim OS des XEGS belegt ist (ich weiß aber nicht wozu). Mein Modultreiber liegen (zusammen mit dem Highspeed-SIO) ganz normal ab $CC00, wenn das ATARI-XL-OS aktiv ist. Der freie Bereich im QMEG-OS ist für den User-SIO-Treiber des QMEG-OS vorgesehen ($E4A1/2 zeigt darauf), den auch ich für den Modultreiber benutzt habe.

Hallo Hias, moin Dietrich,

0cc00 bis 0xcfff im Ram unter dem OS nutze ich Da wird es dann wohl doch daran liegen.

BON und BOF machen an sich nur für eingebundenen ROM Images in der "mit DOS" Version Sinn. Für alle anderen Anwendungen wird das Modul kurz vor Start der Anwendung sowieso abgeschaltet. BON und BOFF sind für diese eh sinnlos, ersteres vielleicht sogar gefährlich. (jemand vergisst die Bank wieder auszuschalten und startet die Anwendung erneut)

Also bleiben sie einzig für die "Spezialversionen" von Action, Mac, Basic XL interessant. Mit denen hatte ich anfangs gar nicht gerechnet und die kamen erst kurz vor Projektende dazu. Es ging hier letztlich auch nur darum ... funktioniert es, funktioniert es nicht. Problemlos anwenden lässt sich BON dann aber auch nicht. BOF macht keine Schwierigkeiten, klar. Aber hier schon bekomme ich vom Modul keinerlei Infos darüber, welche Bank vor dem abschalten aktiv war und kann diese dann auch nicht an BON weiterreichen. Welche Bank soll ich dann zuschalten ? Freilich muss es gehen. Schließlich geht es unter Sparta auch. Ich könnte angepasste DOS Versionen, die wissen, was sie (zu) (ein)schalten haben, hinzunehmen bzw., einfacher & sparsamer, nur die richtige Bank nach dem kopieren von XDOS in die BON Routine eintragen lassen. Wie gesagt, die 3 Programme kamen kurz vor Ende hinzu und waren an sich nicht geplant.

Viele Grüße
Alexander

Moin Moin,

HiassofT hat geschrieben:

Koche hat geschrieben:Sicherlich könnte Hias da etwas ändern, aber es wird allzeit Nischen-Programme oder Module geben, die mit dem neuen OS nicht wollen, für die man Änderungen vornehmen muss. Ob das immer und für alles gut geht ? Ich weiß es nicht.

Wie wichtig ist Dir die Sache den ? Ich kann bei mir sicherlich noch einiges verbessern. Und da ich im Programmstarter/kopierer seit kurzem wieder etwas Platz habe, wäre es durchaus möglich, diese Infos dort abzulegen.

So lange kein SIO-Aufruf zu einem Disk-Drive stattfindet sollte die "Kollision" bei $01xx eigentlich nichts ausmachen, denn nur dann (bzw. wenn der User einen der Shift+Control Hotkeys drückt) wird dorthin geschrieben.
[...]
Also: so lange kein Disk-SIO-Aufruf stattfindet sollte eigentlich nichts schiefgehen...

Also, ich habe das Ganze aus Interesse auch mal verifiziert... mit dem alten Hias-Patch 1.20 kann ich auch kein Sysinfo (Menü 2, Buchstabe "J") starten. Es erscheint garnicht erst der "Bitte warten" Hinweis mit dem Boulder-Dash-Männchen. Wie ich im Vergleichstest festgestellt habe, findet an dieser Stelle garkein SIO-Call statt, also evtl. beißen sich da noch andere Dinge.

Mit der neuen Version von Hias funktioniert alles. Ich habe zwei-drei Programme vom UUM gestartet, alles bestens. Und, der neue Patch arbeitet bei mir auch mit Divisor 0 absolut störungsfrei...

Gruß, Jürgen

... na, dann gibt es ja Hoffnung für mich - muß nur auf meinen UniversalPrommer warten damit ich den FlashRom im Bios4Config flashen kann ...

Hallo Jürgen!

tfhh hat geschrieben:Also, ich habe das Ganze aus Interesse auch mal verifiziert... mit dem alten Hias-Patch 1.20 kann ich auch kein Sysinfo (Menü 2, Buchstabe "J") starten. Es erscheint garnicht erst der "Bitte warten" Hinweis mit dem Boulder-Dash-Männchen. Wie ich im Vergleichstest festgestellt habe, findet an dieser Stelle garkein SIO-Call statt, also evtl. beißen sich da noch andere Dinge.

Mit der neuen Version von Hias funktioniert alles. Ich habe zwei-drei Programme vom UUM gestartet, alles bestens. Und, der neue Patch arbeitet bei mir auch mit Divisor 0 absolut störungsfrei... :D

Super, vielen Dank für's Testen!

Damit dürfte dieses Problem nun gelöst sein und wir können die Schuld auf den NMI Patch schieben :-)

so long,

Hias

UdoWy hat geschrieben:... na, dann gibt es ja Hoffnung für mich - muß nur auf meinen UniversalPrommer warten damit ich den FlashRom im Bios4Config flashen kann ...

Hallo Udo,
die Zusammenstellung der OSse kannst du nach der JHV auch mit deinem 512k Flash MegaCart machen......lass dich überraschen.
Deshalb sind die Bauteile auch gesockelt.

Viele Grüße,
Bernd

@Alexander: Das ist ein Missverständnis: BOF schaltet Modul und BASIC aus, BON schaltet das Modul aus und das BASIC an. Ein einfacher Poke, der das Modul abschaltet, wäre also ausreichend gewesen, damit BON und BOF funktionieren. Zwar schade, aber so schlimm ist das nun auch wieder nicht. Super ist jedenfalls, dass soooo viele Tools auf dem UUC drauf sind. Und sogar mit einem schicken Auswahlmenü

Welche Stellen hast Du insgesamt eigentlich genau wie gepatcht und welche "nicht offiziellen" OS-Routinen rufst Du auf? Wie schaltet man das Modul an (so dass bei Reset das Auswahlmodul kommt) und wie schaltet man es aus? Dann kann ich u.U. beim QMEG-OS 4.1 darauf Rücksicht nehmen.

Gruß Dietrich