jkotlinski / durexforth

Modern C64 Forth
Other
230 stars 28 forks source link

A much complicated OPEN for device 2 weirdness. #424

Closed Whammo closed 2 years ago

Whammo commented 2 years ago

If carry set, check if it's device 2. if it is, and a contains 240, we're go, Clear carry and zero 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

.C:3b96  20 C0 FF    JSR $FFC0
.C:3b99  90 0A       BCC $3BA5
.C:3b9b  A6 BA       LDX $BA
.C:3b9d  E0 02       CPX #$02
.C:3b9f  D0 07       BNE $3BA8
.C:3ba1  C5 F0       CMP $F0
.C:3ba3  D0 03       BNE $3BA8
.C:3ba5  18          CLC
.C:3ba6  A9 00       LDA #$00
.C:3ba8  A6 8B       LDX $8B
jkotlinski commented 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

Whammo commented 2 years ago

Special case. Performs CLR and RESTORE after adjusting Memtop. to be avoided- trashes what was BASIC zero page.

http://unusedino.de/ec64/technical/aay/c64/rome0f9.htm

jkotlinski commented 2 years ago

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)?

Whammo commented 2 years ago

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.

jkotlinski commented 2 years ago

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)

Whammo commented 2 years ago

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.

jkotlinski commented 2 years ago

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: @.***>

Whammo commented 2 years ago

I will do IOABORT, leave this open and then we can decide either or neither.

jkotlinski commented 2 years ago

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 ;
Whammo commented 2 years ago

That is quite true. It never occurred to me to stack a call like ": open open ..." very forthy.

jkotlinski commented 2 years ago

...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...

Whammo commented 2 years ago

Sure- I don't even foresee an issue if HERE is under BASIC.