Here is a "phantom block" edge case I encountered on one of my many trips to the Moon. I am logging it here for future generations to marvel at.
A phantom block is a burst of cycles ("squawk") on the tape which happens to resemble a &2A sync byte, and which may therefore be incorrectly interpreted by MOS as the start of a real CFS block. This CSW was made using Quadbike from a vanekp WAV recording of Arcadians:
Using a clean, digital tone source, and by judicious selection of volume levels, phantom blocks can be made to show up on actual hardware, so here is my Model B:
(Actually loading the game does work -- despite the Data? error, MOS picks up the following "Arcadians" file just fine.)
Because Chris is a predictable swot, beebjit (left) matches the hardware, and will also load the game:
Spot the odd man out on the right, though. This build of B-Em is in fact now using the ACIA code from beebjit (which is looking promising), but in a great irony it exhibits mysteriously different results from beebjit for this test. (TOH's phantom block mitigation has been disabled here; enabling it would indeed strip this fake block out, and the load would then succeed.)
Loading the game fails on B-Em-TOHv3.3. Block 00 of the "Arcadians" file is being missed by MOS -- the first block recognised by the CFS is block 01. Perhaps B-Em's receive shift register in the ACIA somehow finishes half-full after the phantom block, which means it bungles recognition of the sync byte (&2A) that heralds the start of block 00. I don't know yet.
I suspect this discrepancy could in fact safely be ignored. TOH's phantom block mitigation (which will be enabled by default) will make this problem go away, but I'm flagging this obnoxious edge case here for any interested parties.
A phantom block is a burst of cycles ("squawk") on the tape which happens to resemble a &2A sync byte, and which may therefore be incorrectly interpreted by MOS as the start of a real CFS block. This CSW was made using Quadbike from a vanekp WAV recording of Arcadians:
Using a clean, digital tone source, and by judicious selection of volume levels, phantom blocks can be made to show up on actual hardware, so here is my Model B:
(Actually loading the game does work -- despite the Data? error, MOS picks up the following "Arcadians" file just fine.)
Because Chris is a predictable swot, beebjit (left) matches the hardware, and will also load the game:
Spot the odd man out on the right, though. This build of B-Em is in fact now using the ACIA code from beebjit (which is looking promising), but in a great irony it exhibits mysteriously different results from beebjit for this test. (TOH's phantom block mitigation has been disabled here; enabling it would indeed strip this fake block out, and the load would then succeed.)
Loading the game fails on B-Em-TOHv3.3. Block 00 of the "Arcadians" file is being missed by MOS -- the first block recognised by the CFS is block 01. Perhaps B-Em's receive shift register in the ACIA somehow finishes half-full after the phantom block, which means it bungles recognition of the sync byte (&2A) that heralds the start of block 00. I don't know yet.
I suspect this discrepancy could in fact safely be ignored. TOH's phantom block mitigation (which will be enabled by default) will make this problem go away, but I'm flagging this obnoxious edge case here for any interested parties.
Statistics: Posted by Diminished — Tue Oct 15, 2024 9:58 pm