AtariSIO/atarixfer disk density detection

[GreyHobbit]

I have been trying to use atarixfer with one of Lotharek's 1050-2-PC/SIO2PC USB adaptors and a 1050 with US Doubler. So far, atarixfer seems to identify every disk as 90K SD formatted, even disks I believe to be 1050 Dual Density and Double Density disks.

With double density disks this means that sectors above 3 fail to read, and dual density disks only transfer the first 720 sectors.

An example of the output with debugging enabled is:

$ lotharek-switch 1050
successfully switched interface to 1050-2-PC mode


$ atarixfer -d -l -s 2 -T s -1 -r DD_Disk.atr 
atarixfer 0.30-190111 
(c) 2002-2019 Matthias Reichl <hias@horus.com> 
using userspace driver 
activated realtime scheduling 
mlockall(2) succeeded 
checking highspeed capability 
detected ultra speed drive: pokey divisor 10 (52160 baud) 
possibly Happy 1050: enabling fast writes 
Happy command $48 (AUX=$20) failed 
get percom block ... OK 
D1: get percom block : 90k (SD) 
[128 BytesPerSec, 720 Sectors] 
single density disk 
starting to read disk 
    4 
error reading sector 4 from disk [atari error 142]

Am I missing a configuration option or doing something obviously wrong? It works great for SD disks but I'm having no luck with disks of any other density.

I have already modified the 1050-2-pc/sio2pc with the hardware mod on Lotharek's website.

Thanks

Geoff

 

[HiassofT]

Interesting. I haven't tested with a US-Doubler so far, will have a look at what's going on with it later.

 

Can you try with the "-x" option? That's needed on XF551 which has also issues with density detection - maybe that'll help on US-Doubler, too.

 

so long,

 

Hias

[HiassofT]

Could you test if this version works?

 

https://www.horus.com/~hias/atari/atarisio/testing/atarisio-190308.tar.gz

 

I couldn't test myself yet but according to the Altirra hardware reference manual the US Doubler doesn't set the percom block after detecting the disk density so that check won't work.

 

I've added a new option, "-u" to workaround this issue, it simply skips the get percom block check and falls back to using the get status command for detecting the disk density.

 

Note: the change is completely untested so far, please report back if it works.

 

so long,

 

Hias

[GreyHobbit]

Thanks for the quick response, I appreciate your help.

 

I had tried the -x option earlier but it did not make any obvious difference.

 

I tried the test version but it doesn't seem to recognise the -u option. I will try to uninstall first then recompile the tools.

 

Geoff

 

$ atarixfer
atarixfer 0.30-190308
(c) 2002-2019 Matthias Reichl <hias@horus.com>
usage: [-f device ] [options] -r|-w imagefile


options:
  -f device     use alternative AtariSIO device (default: /dev/atarisio0)
  -r imagefile  create ATR/XFD/DCM image of disk
  -w imagefile  write given ATR/XFD/DCM image to disk
  -d            enable debugging
  -e            continue on errors
  -p            use APE prosystem cable (default: 1050-2-PC cable)
  -l            use Lotharek 1050-2-PC USB cable
  -R num        retry failed sector I/O 'num' times (0..100)
  -s mode       high speed: 0 = off, 1 = XF551/Warp, 2 = Ultra/Turbo, 3 = all
  -T timing     SIO timing: s = strict, r = relaxed
  -u            enable workaround for US Doubler format detection bug
  -x            enable workaround for XF551 format detection bugs
  -q            send 'quit' command to flush buffer and stop motor
  -1 ... -8     use drive number 1...8


$ atarixfer -u -x -d -l -s 2 -T s -1 -r DD_Disk.atr
atarixfer 0.30-190308
(c) 2002-2019 Matthias Reichl <hias@horus.com>
atarixfer: invalid option -- 'u'
forgot to catch option 63
using userspace driver
activated realtime scheduling
mlockall(2) succeeded
checking highspeed capability
detected ultra speed drive: pokey divisor 10 (52160 baud)
possibly Happy 1050: enabling fast writes
Happy command $48 (AUX=$20) failed
reading sector 4 ... failed [atari error 146]
get percom block ... OK
D1: get percom block : 90k (SD)
[128 BytesPerSec, 720 Sectors]
single density disk
starting to read disk
    1
error reading sector 1 from disk [atari error 146]

 

[GreyHobbit]

I did a clean compile and get the same as above. The error reading sector 4 in the above output occurred until I tried a dual density disk (which was still identified as single density) but then when I tried again with the DD disk, sector 4 was read ok. It still identifies the disk as single density, though.

 

Geoff

[GreyHobbit]

I added a u to the third arg in the getopt call in atarixfer and recompiled. I'm getting a bit further now.

 

I'll run some tests with this but I don't think it's properly detecting dual density yet.

 

Thanks again

Geoff

[GreyHobbit]

I've just successfully read a DD disk with this test version. Dual density not being detected yet.

 

Geoff

[HiassofT]

Sorry, I messed up. Added the option handling and density detection code but forgot to add "-u" to the list of recognized options.

 

Could you try this version?

https://www.horus.com/~hias/atari/atarisio/testing/atarisio-190308a.tar.gz

 

Edit: ah, just noticed you found the bug yourself, too - thanks for the feedback. I'll have a look at the enhanced density issue.

 

so long,

 

Hias

Edited March 8, 2019 by HiassofT

[HiassofT]

The US Doubler really is a beast. Not only does it not set the percom block, it also doesn't set bit 7 of the first byte in the get status result if an enhanced density disk is inserted, like the 1050 or Happy do. At least it sets bit 5 of the status byte in case of a double density disk :-)

 

So the only reliable way to distinguish between single and enhanced density seems to be to check if a sector > 720 is readable. I've now implemented that in atarixfer (checking for sector 1040) and testing with my Mega Speedy in US Doubler mode worked fine.

 

Could you try this (hopefully last) version?

https://www.horus.com/~hias/atari/atarisio/testing/atarisio-190308b.tar.gz

 

so long,

 

Hias

[ijor]

Hi Hias,

 

The US Doubler really is a beast. Not only does it not set the percom block, it also doesn't set bit 7 of the first byte in the get status result if an enhanced density disk is inserted, like the 1050 or Happy do. At least it sets bit 5 of the status byte in case of a double density disk :-)

So the only reliable way to distinguish between single and enhanced density seems to be to check if a sector > 720 is readable. I've now implemented that in atarixfer (checking for sector 1040) and testing with my Mega Speedy in US Doubler mode worked fine.

 

 

I can't test it right now, but I think the USD does set bit 7 of the status byte when sensing an enhanced density disk.

[GreyHobbit]

That latest version seems to be working, and detecting all densities. I'll do some more testing tomorrow, it's getting a bit late in the evening...

 

Thanks for all your help, now I can get stuck into seeing how many of my 20-30 year old floppy disks are still readable!!

 

Geoff

[+Nezgar]

Interesting, I did not know of this quirk. I just checked a real USD 1050 using the HAPPY.COM from RealDOS, and can confirm that the PERCOM block returned is identical, no matter if the inserted disk is SD, ED, or DD, even if the disk has been accessed a little by DOS first in the associated density after insertion.

 

 

A Happy 1050 does in fact return the correct data for all three densities:

                          SD   ED   DD
Density                   $00  $04  $04
Sector/Track high byte    $00  $00  $00
Sector/Track low byte     $12  $1A  $12
Byte/Sector high byte     $00  $00  $01
Byte/Sector low byte      $80  $80  $FF

Might be interesting to compare the behaviour of other copy programs... For example, looking at CopyMate 4.3 just now, I see it does a get PERCOM, then a Read of Sector 4, presumably to detect if disk is DD (no get-status). But others like MyCopy R 2.1 seem to figure out SS/ED/DD from only a get-status, and no get-PERCOM.

[ijor]

Interesting, I did not know of this quirk. I just checked a real USD 1050 using the HAPPY.COM from RealDOS, and can confirm that the PERCOM block returned is identical, no matter if the inserted disk is SD, ED, or DD, even if the disk has been accessed a little by DOS first in the associated density after insertion.

The USD returns whatever you configured with the "O" command, and not what was sensed with the current disk.

 

But again, it does set the density bit 7 when issuing the status command. There is no need to read a sector for detecting the density, at least not with a USD.

[HiassofT]

But again, it does set the density bit 7 when issuing the status command. There is no need to read a sector for detecting the density, at least not with a USD.

Odd, this is not what I'm seeing here, testing with Mega Speedy in stock 1050 and US Doubler mode

 

Could it be that there are different ROMs around? I'm using this dump here http://ftp.pigwa.net/stuff/collections/nir_dary_cds/ROMS/ROMS_HW/1050%20Upgrades/UsDoubler_ok.bin

 

so long,

 

Hias

[+CharlieChaplin]

Mycopier 1.c and 2.1 check for ED by reading sector 1040...

(e.g. if you set Enhanced to "on" in version 1.c).

Edited March 9, 2019 by CharlieChaplin

[E474]

Hi,

 

Is the 1050 enhanced density the only density with 1040 sectors (+), that is, do some of the more obscure disk sizes like the 720k Thoms drive (also) support high numbered sectors, e.g. would a read on sector 1040 also work on this drive (not sure about sector size, e.g. 128/256/512 byte sectors)?

[ijor]

Odd, this is not what I'm seeing here, testing with Mega Speedy in stock 1050 and US Doubler mode

...

Could it be that there are different ROMs around? I'm using this dump here http://ftp.pigwa.net/stuff/collections/nir_dary_cds/ROMS/ROMS_HW/1050%20Upgrades/UsDoubler_ok.

Definitely an issue with the ROM version. Seems that "UsDoubler_ok" is not so ok, at least for this purpose.

 

I think Nezgar has been collecting different ROM versions. Nezgar?

[+Nezgar]

Definitely an issue with the ROM version. Seems that "UsDoubler_ok" is not so ok, at least for this purpose.

 

I think Nezgar has been collecting different ROM versions. Nezgar?

 

Indeed I have.

 

UsDoubler_ok.bin from pigwa, CRC32 of 4C53A1A8 is of unknown origin, and through disassembly has been found to have issues that could cause data corruption, and should not be used. It's unfortunate, because it provides a faster stepper rate for Tandon mechs. Maybe the PERCOM reporting is yet another thing someone tried to 'fix' on this one, but broke other things...

 

The other two ROM's are the only ones that should be trusted - one verified original from ICD EPROMs (I've yet to verify a MASK rom, but I'm pretty confident its the same), and a recent minor patch to the ICD original for drives with WST mechs.

 

See this previous post for details, and further supporting links: http://atariage.com/forums/topic/283132-1050-is-that-an-icd-in-your-socket-or-are-you-happy-to-see-me/?p=4120404

 

Maybe someday someone can patch the faster tandon stepping rate found in the untrusted ROM into the verified ICD ROM. I'm sure it's simple (probably only a few bytes hexedit), just a bit beyond my abilities at this time...

[1050]

2AC5 A953       1370     LDA #'S     ;* new routine to show E
2AC7 8D0203     1380     STA DCOMND  ;* in menu screen
2ACA 8C0103     1390     STY DUNIT   ;*
2ACD 8648       1400     STX TMP1    ;*
2ACF 2053E4     1410     JSR DSKINV  ;*
2AD2 0EEA02     1420     ASL DVSTAT  ;*
2AD5 A900       1430     LDA #0      ;*
2AD7 6900       1440     ADC #0      ;*
2AD9 F004       1450     BEQ TDS     ;*
2ADB A945       1460     LDA #'E     ;*
2ADD D010       1470     BNE DKSNGD  ;*
2ADF            1480 TDS ;           ;*
2ADF 0EEA02     1490     ASL DVSTAT  ;*
2AE2 0EEA02     1500     ASL DVSTAT  ;*
2AE5 6900       1510     ADC #0      ;*
2AE7 F004       1520     BEQ LDS     ;*
2AE9 A944       1530     LDA #'D     ;*
2AEB D002       1540     BNE DKSNGD  ;*
2AED            1550 LDS ;           ;*
2AED A953       1560     LDA #'S     ;*
2AEF            1570 DKSNGD ;        ; old label left in play
2AEF AC0103     1580     LDY DUNIT   ;*
2AF2 A648       1590     LDX TMP1    ;*
2AF4 9D4D2B     1600     STA D1STAT+1,X
2AF7 B9CB07     1610     LDA DRVDEF-1,Y
2AFA 4A         1620     LSR A
2AFB A92D       1630     LDA #'-
2AFD 9002       1640     BCC DKSSD
2AFF A93D       1650     LDA #'=
PAGE 33     MyDOS 4.55     beta4                        D:MDUP2.M65
2B01            1660 DKSSD
2B01 9D4E2B     1670     STA D1STAT+2,X

My solution used system routines and locations and

it's quite possible I got lucky with a good copy of

USD code as well? But here it works perfect.

 

I can see that I could tighten the code by just

using BCC instead of the loading and adding of zero

above.

Proof of concept sort of deal then.

[HiassofT]

UsDoubler_ok.bin from pigwa, CRC32 of 4C53A1A8 is of unknown origin, and through disassembly has been found to have issues that could cause data corruption, and should not be used. It's unfortunate, because it provides a faster stepper rate for Tandon mechs. Maybe the PERCOM reporting is yet another thing someone tried to 'fix' on this one, but broke other things...

 

The other two ROM's are the only ones that should be trusted - one verified original from ICD EPROMs (I've yet to verify a MASK rom, but I'm pretty confident its the same), and a recent minor patch to the ICD original for drives with WST mechs.

Thanks a lot for the info! I tested with the ICDUSDREVL.BIN and can confirm enhanced density disk detection is working fine with it (it sets bit 7 in the status byte).

 

I'll keep the current check in atarixfer (might refactor it a bit) as it won't hurt on US Doublers with the correct firmware but helps people with the buggy one.

 

I went through the "us-doubler" folder on my harddrive from 2014 when I was creating the Mega Speedy, looks like I was comparing disassemblies of both ROM dumps as well. Not 100% sure why "UsDoubler_ok.bin" ended up in slot 1 of my Mega Speedy, maybe I thought a file with "ok" in it's would have a better chance of being okay than one with "err".

 

so long,

 

Hias