Jump to content
IGNORED

Strange Emulator Behavior


Recommended Posts

I have encountered some strange behavior while writing some Atari BASIC code.  This little code snippet reads 34 bytes from Sector 1 of a disk and then prints them out.  The code works under Altirra 3.90 as seen in the first picture but fails under A800WinPlus 4.x in the second picture.  They are both trying to read the same disk but only one emulator is running at a time.

 

image.thumb.png.2d3893f36c08069ad42d91d22964db15.png

image.thumb.png.06b3f54eda3d39f3f87a8acc68932490.png

 

I know someone out there will look at this and know exactly what the problem is but I cannot see it.  Any ideas?

det_sd.bas

Link to comment
Share on other sites

It's the way the disk handler is written, usually when you want to read a sector your buffer is one sector in size.

 

In Altirra for some reason it's ok with a buffer of 34 bytes, if you change the buffer size to 128 bytes it works 

in Atari800Win, I changed the code in a few places to make CGF$ 128 bytes, also it's probably best if you

change line 3050 to use LEN(CFG$)

 

3000 REM |     DETECT SPARTA DISK
3001 CLR :DNUM=2
3005 DIM CFG$(128):SECT=1
3010 POKE 768,49:POKE 769,DNUM:POKE 770,
82:POKE 771,64
3030 CFG$=" ":CFG$(128)=CFG$:CFG$(2)=CFG
$
3040 Z=ADR(CFG$):HI=INT(Z/256):LO=Z-256*
HI:POKE 772,LO:POKE 773,HI
3050 POKE 774,7:POKE 776,LEN(CFG$):POKE
777,0
3060 X=INT(SECT/256):POKE 779,X:POKE 778
,SECT-X*256
3070 X=USR(ADR("hLYd"))
3071 REM   DEBUG PRINT
3072 ? DNUM:FOR Z=1 TO 34:? ASC(CFG$(Z,Z
));:? ",";:NEXT Z

Link to comment
Share on other sites

It's not actually the disk handler that determines this behavior, it's the emulator's SIO patch or device emulation. The disk handler is actually not involved as this code is calling SIOV and not DSKINV.

 

On a real SIO-based disk drive, this "works" because the drive doesn't know the length that was passed to SIO and will send 128 bytes back regardless. SIO copies the requested 44 bytes into the buffer, and then inteprets byte 45 as the checksum. Altirra's SIO patch simulates this behavior. I say "works" because this also results in SIO retrying the command and returning a checksum error, which are ignored by the above program. It also causes the drive to continue chattering on the SIO bus after the OS has stopped listening, which can result in another quickly issued command failing. For these reasons, it's much better to just use a correctly sized buffer.

 

The behavior you're seeing in Atari800Win is from its SIO patch, which rejects the short read entirely. If you disable the SIO patch, then it too will return sector data. However, the former behavior is not unprecedented on real hardware since it is possible that D1: is implemented by a PBI device that does see the transfer length specified to SIO, such as a BlackBox / IDE+2 / U1MB. It is possible for the PBI software handler to reject the request outright in the same way as the A8WP SIO patch.

 

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...