#2097 Extraneous CHKIN calls lose data on host filesystem

[Mark Reed]

When reading from the host filesystem, calling CHKIN() with the input channel already set causes the next byte from the input stream to be consumed and discarded. This doesn't happen when using e.g. a mounted disk image, only the host filesystem.

Tested on macOS with 3.8 and Linux with 3.7.

This BASIC program demonstrates the problem.

100 rem demo of chkin bug on hostfs
110 a=49152
120 for i=0 to 21
130 : read b
140 : poke a+i, b
150 next i
160 input "filename";f$
170 print
180 print "with single chkin:"
190 print
200 open 1,8,2,f$
210 sys a
220 close 1
230 print
240 print
250 print "with chkin before each chrin:"
260 print
270 poke a + 17, 238: rem change branch target to redo chkin each loop
280 open 1,8,2,f$
290 sys a
300 close 1
310 print
320 print
330 data 162, 1, 32, 198, 255, 32, 207, 255, 32, 210, 255, 32, 183, 255, 41, 64
340 data 240, 243, 32, 204, 255, 96

[Mark Reed]

Note: calling CLRCHN before calling CHKIN also prevents the problem.

[gpz]

It would be nice if you could provide that testcase written completely in asm... this way its a bit hard to read (and to adapt for the testbench)

[Mark Reed]

OK, I just discovered that true drive emulation was on, Turning it off prevents the behavior, so this may be invalid. I thought the combination of "-virtualdev8 -iecdevice8 -device8 1" was enough, but apparently +drive8truedrive is also needed.

I was going for ease of runnability, since you can just paste the basic into the emulator, but if, after the truedrive reveal, you still want the test code in assembly, I can provide that.

[gpz]

Yeah, enabling both leads to strange side effects... the only reason why it wasnt reworked yet is that noone fully understands the related code :)

And yes, it would be great if you could provide the code in a single asm file - that makes it easier to include in the testbench (in particular easier to read for whoever is going to look at it)

[Mark Reed]

Ok, here's a test program in assembly. it creates a test file, reads it back to verify it against memory, then does so again with the extra CHKINs that trigger the bug.

[gpz]

thanks! added the test here https://sourceforge.net/p/vice-emu/code/45405/

I will close this ticket however - for now this is a "won't fix" - for the future the plan is to rework the UI logic so you can only ever enable vdrive OR TDE, never both.