Custom CIO Handler and DOS 2.0/2.5 DUP?
von tschak909 » So 3. Mai 2020, 19:36For anyone who can answer.
I have a CIO handler, that I've ported entirely to assembler (using AMAC), and it works. It loads just above the memlo that is imposed by DOS XL 2.30 with two double density disks ($2300), and with this, I am able to test and work through the rest of the CIO handler actions and debug without the weird side effects imposed by the C prototype version.
In addition to the attached files here, I've uploaded my current work to the #FujiNet repo:
https://github.com/FujiNetWIFI/atariwif ... production
However, I've noticed a bit of an issue, What about DOS 2.0/2.5?
Specifically,
If I load at MEMLO (e.g. $1CFC or similar), then DUP will clobber my code. Normally, for devices like R: this is fine, because they're not being used by the DUP potentially for file operations (like copying or loading binary files), so DUP can swap back in via MEM.SAV, and things don't go awry. However...if I try to binary load using NDEV.COM in DOS 2.0, the DUP has overwritten my handler, and it doesn't know to swap the overwritten memory back in. whoops.
The solution I had done, to continue debugging on DOS 2.0, was to make a version that assembled roughly at MEMHI, which puts it out of reach of the DUP, and then things work. But this isn't ideal.
Is there a better solution? or am I going to have to patch a version of DOS 2.0/2.5 to add the N: handler for those who want to use it? (roughly 975 bytes + 2K of buffers.)
What's the right decision, here?
---
Für alle, die antworten können.
Ich habe einen CIO-Handler, den ich vollständig auf Assembler (mit AMAC) portiert habe, und er funktioniert. Er lädt gerade über dem Memlo, das von DOS XL 2.30 mit zwei Platten doppelter Dichte ($2300) auferlegt wird, und damit bin ich in der Lage, den Rest der CIO-Handler-Aktionen zu testen und durchzuarbeiten und zu debuggen, ohne die seltsamen Nebenwirkungen, die von der C-Prototyp-Version auferlegt werden.
Zusätzlich zu den hier angehängten Dateien habe ich meine aktuelle Arbeit in das #FujiNet-Repo hochgeladen:
https://github.com/FujiNetWIFI/atariwif ... production
Mir ist jedoch ein kleines Problem aufgefallen: Was ist mit DOS 2.0/2.5?
Im Besonderen,
Wenn ich bei MEMLO lade (z.B. $1CFC oder ähnliches), dann wird DUP meinen Code verprügeln. Normalerweise ist das für Geräte wie R: in Ordnung, weil sie vom DUP nicht potenziell für Dateioperationen (wie das Kopieren oder Laden von Binärdateien) verwendet werden, so dass DUP wieder über MEM.SAV einlagern kann und die Dinge nicht schief gehen. Wie auch immer ... wenn ich unter DOS 2.0 versuche, Binärdateien unter Verwendung von NDEV.COM zu laden, hat das DUP meinen Handler überschrieben, und es weiß nicht, wie es den überschriebenen Speicher wieder einlagern soll. whoops.
Die Lösung, die ich gemacht hatte, um das Debugging unter DOS 2.0 fortzusetzen, bestand darin, eine Version zu erstellen, die sich grob bei MEMHI zusammensetzt, wodurch sie außerhalb der Reichweite der DUP liegt, und dann funktionieren die Dinge. Aber das ist nicht ideal.
Gibt es eine bessere Lösung? oder werde ich eine Version von DOS 2.0/2.5 patchen müssen, um den N:-Handler für diejenigen hinzuzufügen, die ihn benutzen wollen? (ungefähr 975 Bytes + 2K Puffer).
Was ist hier die richtige Entscheidung?
-Thom
I have a CIO handler, that I've ported entirely to assembler (using AMAC), and it works. It loads just above the memlo that is imposed by DOS XL 2.30 with two double density disks ($2300), and with this, I am able to test and work through the rest of the CIO handler actions and debug without the weird side effects imposed by the C prototype version.
In addition to the attached files here, I've uploaded my current work to the #FujiNet repo:
https://github.com/FujiNetWIFI/atariwif ... production
However, I've noticed a bit of an issue, What about DOS 2.0/2.5?
Specifically,
If I load at MEMLO (e.g. $1CFC or similar), then DUP will clobber my code. Normally, for devices like R: this is fine, because they're not being used by the DUP potentially for file operations (like copying or loading binary files), so DUP can swap back in via MEM.SAV, and things don't go awry. However...if I try to binary load using NDEV.COM in DOS 2.0, the DUP has overwritten my handler, and it doesn't know to swap the overwritten memory back in. whoops.
The solution I had done, to continue debugging on DOS 2.0, was to make a version that assembled roughly at MEMHI, which puts it out of reach of the DUP, and then things work. But this isn't ideal.
Is there a better solution? or am I going to have to patch a version of DOS 2.0/2.5 to add the N: handler for those who want to use it? (roughly 975 bytes + 2K of buffers.)
What's the right decision, here?
---
Für alle, die antworten können.
Ich habe einen CIO-Handler, den ich vollständig auf Assembler (mit AMAC) portiert habe, und er funktioniert. Er lädt gerade über dem Memlo, das von DOS XL 2.30 mit zwei Platten doppelter Dichte ($2300) auferlegt wird, und damit bin ich in der Lage, den Rest der CIO-Handler-Aktionen zu testen und durchzuarbeiten und zu debuggen, ohne die seltsamen Nebenwirkungen, die von der C-Prototyp-Version auferlegt werden.
Zusätzlich zu den hier angehängten Dateien habe ich meine aktuelle Arbeit in das #FujiNet-Repo hochgeladen:
https://github.com/FujiNetWIFI/atariwif ... production
Mir ist jedoch ein kleines Problem aufgefallen: Was ist mit DOS 2.0/2.5?
Im Besonderen,
Wenn ich bei MEMLO lade (z.B. $1CFC oder ähnliches), dann wird DUP meinen Code verprügeln. Normalerweise ist das für Geräte wie R: in Ordnung, weil sie vom DUP nicht potenziell für Dateioperationen (wie das Kopieren oder Laden von Binärdateien) verwendet werden, so dass DUP wieder über MEM.SAV einlagern kann und die Dinge nicht schief gehen. Wie auch immer ... wenn ich unter DOS 2.0 versuche, Binärdateien unter Verwendung von NDEV.COM zu laden, hat das DUP meinen Handler überschrieben, und es weiß nicht, wie es den überschriebenen Speicher wieder einlagern soll. whoops.
Die Lösung, die ich gemacht hatte, um das Debugging unter DOS 2.0 fortzusetzen, bestand darin, eine Version zu erstellen, die sich grob bei MEMHI zusammensetzt, wodurch sie außerhalb der Reichweite der DUP liegt, und dann funktionieren die Dinge. Aber das ist nicht ideal.
Gibt es eine bessere Lösung? oder werde ich eine Version von DOS 2.0/2.5 patchen müssen, um den N:-Handler für diejenigen hinzuzufügen, die ihn benutzen wollen? (ungefähr 975 Bytes + 2K Puffer).
Was ist hier die richtige Entscheidung?
-Thom