Bug with H: device when putting data and print to screen

[bugbiter]

A while ago I encountered a problem in Atari800win when printing to screen during an open write channel to H:

Part of the screen print gets written to the hard disc file! Thats the reason I only use altirra. But now I get the same thing on Altirra also. On my own computer there is no such behaviour but at work and here at my father-in-law's the bug is present.

 

Try that little program here:

 

running it should show this:

 

But when the bug is present it shows this:

 

It's very annoying and I haven't figured out what triggers it. Did anyone of you experience this or knows how to stop it?

Edited April 10, 2015 by bugbiter

[Kyle22]

You should post this bug report here: http://atariage.com/forums/topic/236488-altirra-260-released/page-5

 

I have also referred them to your post here.

[Rybags]

What if you do a similar program in Atari Basic?

 

Fairly sure the A800Win+ H: handler works by inserting into the device table and it relies on trapping certain entries into the OS Rom. Problems can occur with patched handlers and some custom OSes as well as if Ram rather than Rom is switched into the OS area.

[phaeron]

This is an issue with burst I/O. I'm surprised you ran into this with Atari800Win, because as far as I know that emulator doesn't do burst I/O on H:. Maybe I'm wrong.

 

Atari BASIC, and other BASIC interpreters that mimic it, take a shortcut when printing to IOCBs by jumping directly through (ICPTL,X)+1. For this reason, the PUT BYTE handler on CIO devices needs to read some parameters directly from the originating IOCB and do permission checks directly because CIO is bypassed. DOS in particular has to be careful because it attempts to do burst I/O optimization, where entire sectors can be written directly instead of transferring one byte at a time. Burst I/O is a cheat that mucks with the ZIOCB to directly access the user buffer from the PUT BYTE handler. This only works if it's actually CIO doing the transfer, so BASIC has to be excluded by checking whether the return address is within the OS ROM.

 

Altirra versions up through 2.50 attempt to do burst I/O for H: by default, controlled by a checkbox in H: setup. As you've found, this can cause issues with BASIC, and disabling the burst I/O option will bypass the problem. You should update to 2.60, which has this problem fixed. I added the missing return address check when I extended burst I/O support to H:/P:/R:/T:, which is now controlled by System > Acceleration > CIO Burst Transfers.

[bugbiter]

Thank the maker!