Directory Reading (aka, EOF detection)

[Mike]

There's no difference in the number of calls but there is a difference in the number of cycles. To reach FACPTR from CHRIN takes 28 cycles, from ACPTR it takes 3. That's for each byte received.

This poses an interesting philosophical question, because we all face questions about what level of abstraction we want to work at.

ACPTR, CIOUT, LISTEN, SECOND, TALK, TKSA, UNLSN and UNTLK only work on the serial bus, only with the standard IEC protocol, and they are not vectored.

Using those calls instead of SETNAM, SETLFS, OPEN, CLOSE, CHKIN, CHKOUT, CHRIN, CHROUT and CLRCHN ties a program to that exact protocol and robs it of any chance to work with a faster implementation of the serial protocol (JiffyDOS or SJLOAD), or with IEEE-488 cards, or with an altogether different implementation of a CBM DOS-like device driver like Kananga's FE3 RAM Disk.

All that in the name of a few cycles saved per transmitted byte? Really?

[chysn]

All that in the name of a few cycles saved per transmitted byte? Really?

The tone seems a bit harsh, I wouldn't want anybody discouraged from putting ideas forward. I'd never even thought about ACPTR before, so I'm glad to have learned a bit about it, even though I think the benefit of following a standard pattern outweighs what little is saved.

The fact of the matter is, if an hundred people play my game on VICE around the clock until Christmas, each opening the file browser every fifteen minutes, they'll have collectively lost the amount of time it took me to research and discuss switching to ACPTR here. And I'm perfectly fine with that. I'm game for more.

[Mike]

The tone seems a bit harsh, I wouldn't want anybody discouraged from putting ideas forward.

I take your point. Though, it is perhaps all too easy to get carried away by something that superficially presents an advantage, and miss out on the deeper consequences. At least that's the impression I got when srowe followed up on his initial recommendation with another two posts without mentioning the other side of the coin. He is around here long enough to know better.

Similar concerns can be raised at one point when someone begins a discussion about undocumented opcodes on the NMOS 6502 or self-modifying code like these were the best things since sliced bread.

One popular 'victim' of the use of those lower-level IEC routines is the DOS wedge utility on the Test/Demo disk. It implements the command channel I/O and directory read routines with ACPTR, etc. - which made it utterly fail with the FE3 RAM Disk. Kananga put quite some work into the RAM Disk to make the core command set work with the more common file I/O calls, and we were somewhat disappointed that an otherwise good tool like the DOS wedge falls over such a little detail.

[Mike]

CLALL only resets the file table on the VIC, it does absolutely nothing to close the channels open on any external device.

Also regarding another thread, where chysn and I discussed that behaviour of CLALL, here's a small routine that could be called at program exit to "clean up" possibly open channels:

Code: Select all

.CLALL
 JSR $FFCC     ; CLRCHN
.CLALL_00
 LDX $98
 BEQ CLALL_01
 LDA $0258,X
 JSR $FFC3     ; CLOSE
 BCC CLALL_00
.CLALL_01
 RTS

Like CLALL, it also restores KERNAL I/O to keyboard and screen, but instead to simply clear the file descriptor table by setting the number of open files to zero, it explicitly calls CLOSE on all open files it finds in the table.

The routine can be used on its own, alternatively it could serve as replacement for the original CLALL routine by redirecting the vector ($032C) to it.