GreyHobbit Posted March 8, 2019 Share Posted March 8, 2019 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 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted March 8, 2019 Share Posted March 8, 2019 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 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted March 8, 2019 Share Posted March 8, 2019 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 2 Quote Link to comment Share on other sites More sharing options...
GreyHobbit Posted March 8, 2019 Author Share Posted March 8, 2019 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] Quote Link to comment Share on other sites More sharing options...
GreyHobbit Posted March 8, 2019 Author Share Posted March 8, 2019 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 Quote Link to comment Share on other sites More sharing options...
GreyHobbit Posted March 8, 2019 Author Share Posted March 8, 2019 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 Quote Link to comment Share on other sites More sharing options...
GreyHobbit Posted March 8, 2019 Author Share Posted March 8, 2019 I've just successfully read a DD disk with this test version. Dual density not being detected yet. Geoff Quote Link to comment Share on other sites More sharing options...
HiassofT Posted March 8, 2019 Share Posted March 8, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted March 8, 2019 Share Posted March 8, 2019 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 2 Quote Link to comment Share on other sites More sharing options...
ijor Posted March 9, 2019 Share Posted March 9, 2019 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. Quote Link to comment Share on other sites More sharing options...
GreyHobbit Posted March 9, 2019 Author Share Posted March 9, 2019 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 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted March 9, 2019 Share Posted March 9, 2019 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. Quote Link to comment Share on other sites More sharing options...
ijor Posted March 9, 2019 Share Posted March 9, 2019 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. Quote Link to comment Share on other sites More sharing options...
HiassofT Posted March 9, 2019 Share Posted March 9, 2019 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 Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted March 9, 2019 Share Posted March 9, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
E474 Posted March 9, 2019 Share Posted March 9, 2019 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)? Quote Link to comment Share on other sites More sharing options...
ijor Posted March 9, 2019 Share Posted March 9, 2019 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? Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted March 9, 2019 Share Posted March 9, 2019 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... 1 Quote Link to comment Share on other sites More sharing options...
1050 Posted March 10, 2019 Share Posted March 10, 2019 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 andit'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. 1 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted March 10, 2019 Share Posted March 10, 2019 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 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.