What's the correct protocol for testing STATUS?

[hjalfi]

So, I've got this port of CP/M to the 6502. Previously I had it working on the X16. I recently tried it and found that it hangs on startup.

Seems the problem is this code, which reads a file from disk. (My structured programming macros should be obvious.)

    ldy #0
    zrepeat
	sty STATUS
        jsr ACPTR       ; read a byte
        sta (ptr), y

        inc ptr+0
        zif_eq
            inc ptr+1
        zendif

	lda STATUS		; check for EOF
    zuntil_ne

This isn't working because STATUS is $0289, which is the C64 value and used to be the X16 value. It's now $0287. It got moved in this commit: https://github.com/commanderx16/x16-rom ... bde23114f7

Okay, fine, clearly the exact location of STATUS is an implementation detail and I should be using READST to read the status from the kernal. Except... after an operation, the status is only set on error. That's why I have to reset it to 0 before calling ACPTR in the code above. But there's no API for doing this! What's the correct way of doing this? If I don't reset STATUS, my read immediately fails because STATUS is still 0x40 from the previous operation...

(I know it's possible to call READST+6 to set STATUS, but that seems. Um. Evil.)

[Ender]

Are you sure that's the cause of your issue? I asked on Discord if you really need to set STATUS to 0 before calling ACPTR, and this is the response. tldr; No, it was changed from the C64 behavior so that you don't.

nope, there was a discussion about a year ago in a github issue about whether to allow STATUS to accumulate errors by successive calls to ACPTR or other IEC calls. Interestingly the code had already been changed prior to that to reset status to 0 before every call.

This made it differ from C64 behaivor, and thus it completely broke VERIFY which was depending on that behavior. VERIFY is now fixed though.
long story short, behavior differs from C64 et al, and status gets reset by the kernal when calling ACPTR

[hjalfi]

If that's true, then there's a flaw in x16-emulator; the virtual filesystem code only updates STATUS on error conditions. I'll need to file a bug...