Closed Whammo closed 2 years ago
It makes me wonder how BASIC deals with this?
To me it looks like a OPEN that returns with carry set would result in an immediate CLOSE? http://unusedino.de/ec64/technical/aay/c64/rome1be.htm
Special case. Performs CLR and RESTORE after adjusting Memtop. to be avoided- trashes what was BASIC zero page.
umm... so do i get it right... the open actually succeeds? and then $f0 is passed to BASIC, which handles that by resetting BASIC memory (kind of)?
IF NO file or device open error, OPEN 2 always succeeds and always returns from the Kernal call with, $f0 in A, carry set, and 0 in ST. Carry is set not for error, but for call to set MEMTOP. OPEN 2 from BASIC checks A for $F0 after OPEN then knows it's #2 and rather than ERROR performs CLR and RESTORE and returns to the basic prompt.
I don't like to complicate OPEN for this, because it's supposed to be quite a low level word, where all error handling can be left to the user.
But maybe it's appropriate to add a special case in IOABORT for the value of $F0?
Another thing I am curious about... "RS-232 OPEN initializes various RS-232 lines and creates two 256-byte buffers at the top of memory" What location is that? In the docs for $283-284, I read that it's $a000 .. does that mean the durexForth dictionary will be overwritten? (currently the default location is also at $a000)
I considered using IOABORT. But decided it was six of one, half dozen of the other. But making sense of my obtuse forth assembly in OPEN leads me to agreement upon IOABORT. Kernal OPEN sets rs232 buffers at MEMTOP default $A000. then sets MEMTOP 2 pages lower. Set MEMTOP in durexforth.asm to rs232 buffer location desired.
Maybe it is just best to introduce a separate rs-232 module that does the necessary patches for things to work?
On Sun, 9 Jan 2022 at 02:18, Whammo @.***> wrote:
I considered using IOABORT. But decided it was six of one, half dozen of the other. But making sense of my obtuse forth assembly in OPEN leads me to agreement upon IOABORT. Kernal OPEN sets rs232 buffers at MEMTOP default $A000. then sets MEMTOP 2 pages lower. Set MEMTOP in durexforth.asm to rs232 buffer location desired.
— Reply to this email directly, view it on GitHub https://github.com/jkotlinski/durexforth/pull/424#issuecomment-1008206191, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAY34OYURF3XG7M4JXAOAMTUVDO4XANCNFSM5LQUDRLA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>
I will do IOABORT, leave this open and then we can decide either or neither.
i guess a rs232 module could also look as simple as this?
require turnkey
\ move wordlist away from rs232 buffers
$9e00 top!
: open open dup $f0 = if drop 0 then ;
That is quite true. It never occurred to me to stack a call like ": open open ..." very forthy.
...instead of including "turnkey" it is perhaps more elegant to just put the buffers somewhere nice... maybe allocate 512 bytes from HERE for the purpose..? i don't know what's best...
Sure- I don't even foresee an issue if HERE is under BASIC.
If carry set, check if it's device 2. if it is, and a contains 240, we're go,
Clear carry andzero accumulator If carry set and it's device 2 and A doesn't contain 240 it's a file or device open error,If carry clear it's not rs232 OPEN