bugbiter Posted April 10, 2015 Share Posted April 10, 2015 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted April 11, 2015 Share Posted April 11, 2015 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 11, 2015 Share Posted April 11, 2015 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 11, 2015 Share Posted April 11, 2015 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. 2 Quote Link to comment Share on other sites More sharing options...
bugbiter Posted April 11, 2015 Author Share Posted April 11, 2015 Thank the maker! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.