E474 Posted February 14, 2020 Share Posted February 14, 2020 Hi, In the Altirra Reference Manual, page 189, it says that the US-Doubler, Super Archiver and Indus GT drives, in particular, can't be relied on to return a valid Percom block. Do these drives only support Singled Sided Double Density disks at most, e.g. 720 x 256 byte sectors? Are there any drives that support larger sized disks but also can't be relied on to return a valid Percom block (or any other drives that are also unreliable)? Am asking as I am trying to test when to trust a Percom block. Thanks! Quote Link to comment Share on other sites More sharing options...
Alfred Posted February 19, 2020 Share Posted February 19, 2020 USD in my experience generally returns a valid block, and yes it only supports DD on one side. Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 19, 2020 Share Posted February 19, 2020 The question is not so much whether it returns a valid block than whether it returns the correct block. The USD ROM I have seems to store different data for the active density vs. the PERCOM block, so changing the disk changes the status flags but not the returned PERCOM block. Test program is attached, which prints the status byte followed by the PERCOM block while re-reading the disk. percombl.obx 1 Quote Link to comment Share on other sites More sharing options...
E474 Posted February 22, 2020 Author Share Posted February 22, 2020 Hi, Thanks very much @Alfred and @phaeron for the replies (and attachment) - I have been testing with my own code and have found that my "clone" US-Doubler does return a Percom block, but will often return a single density (720 sector) Percom block when there is a double density disk in the drive. So @phaeron is quite correct regarding "correct" vs "valid" - thanks! My disk detection routine is basically: get status (SIO DCMND $53) on source drive -- Y/positive result: drive exists -- Y/negative result: drive doesn't exist, stop read sector 1 on source drive -- Y/positive result: disk present in drive -- Y/negative result: disk not present in drive, stop read sector 4 immediate (DSTAT=0) just to set up XF551, ignore return code read sector 4, starting sector size of $80, doubling sector size and retrying until sector reads successfully (upper limit of 2K sized sectors) if sector 4 is 128 byte sector, see if it is single density (720 sectors) or enhanced density (1040 sectors) - I do this by reading from sector 721 and see if SIO return code is positive or negative. I'm not testing on the drive status at the moment, but I am going to add this test, though, IIRC, I have seen some suspect results with my US-Doubler. Also, if reading sector 721 gives an error, I plan on reading additional >721 sectors, just in case the disk is an enhanced density disk with a bad sector 721. if sector 4 size is >128 bytes, I get the Percom block, then compare the Percom block sector size against the actual size, if this matches, then the Percom block is most likely correct, if it doesn't match, then the drive is probably a US-Doubler, SuperArchiver or Indus GT, in which case I assume the disk is a double density single sided disk (720 * 256 byte sectors). I'm going to add a test to see if I can read a DD sector 721, just in case it is a larger capacity disk that doesn't return an accurate Percom block. I think this should cover most, if not all, disk types and drives, I have some additional error states such as drive supports double density but doesn't return a Percom block at all, but I'm not sure if these actually exist. Thanks again for the help, I will test the above attached file (percombl.obx) - is there any chance you can upload the source code for it too? Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 22, 2020 Share Posted February 22, 2020 Source attached. percombl.s system.inc 1 Quote Link to comment Share on other sites More sharing options...
E474 Posted February 22, 2020 Author Share Posted February 22, 2020 Hi, Thanks very much for the sources, I will sit down and give them a good read. Attached is an ATR with the executable I have been working on - it expects to be booted from drive 1, and assumes drive 2 is the source drive to check - it's quite bloated as it was a test using the ATR Maker sources for some subroutines. Thanks again! ATRMD_SD1.atr Quote Link to comment Share on other sites More sharing options...
E474 Posted February 23, 2020 Author Share Posted February 23, 2020 Hi, I have replaced the single density disk size test of reading sector 721/1040 with a test on the status byte instead, and it looks like my US-Doubler is not setting the highest bit of the status register when the disk is enhanced density (1040 sectors). My Lazer (Happy clone) does set the bit correctly. Can anyone with a genuine US Doubler verify this (maybe @Nezgar has the drives to do this?) - the attached ATR needs to be booted on Drive 1, test executable (TESTAPP.EXE) in ATR needs to be run against a floppy in drive 2 (sorry for hard-coding the drive number). It should be able to detect SD/ED/DD disks in drive 2 with a Happy or similar drive, but always return SD for SD/ED with a US-Doubler. Changed code goes like: TEST_FOR_ENHANCED_DENSITY_SECTORS JSR GET_DRIVE_STATUS JSR DISPLAY_SIO_STATUS JSR DISPLAY_DRIVE_STATUS_BUFFER LDA DRIVE_STATUS_BUFFER AND #$80 BEQ IS_720 SEC RTS IS_720 CLC RTS ; ; returns: ; ; SEC - could read enhanced density sectors ; CLC - could not read enhanced density sectors ; ; Thanks! ATM_SD.atr Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted February 23, 2020 Share Posted February 23, 2020 I learned the US Doubler does not report density correctly when querying the PERCOM block, only what was last programmed with the set-percom command. You can use the Atari's standard $53 get status command to determine detected density. This way you can determine density without having to actually read a sector from the disk. Bit 7 of status command response do determine FM/MFM (single/enhanced density) and maybe bit 5 for 128/256 bytes? As per this previous topic post, and subsequent clarification from @ijor and others. Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted February 23, 2020 Share Posted February 23, 2020 7 hours ago, E474 said: Can anyone with a genuine US Doubler verify this (maybe @Nezgar has the drives to do this?) - the attached ATR needs to be booted on Drive 1, test executable (TESTAPP.EXE) in ATR needs to be run against a floppy in drive 2 (sorry for hard-coding the drive number). It should be able to detect SD/ED/DD disks in drive 2 with a Happy or similar drive, but always return SD for SD/ED with a US-Doubler. I'm not at home to test with real hardware, but here is the results of Single, Enhanced/Dual, and Double Density with Altirra full drive emulation with the US Doubler ROM (CRC32 605B7153 - verified ICD code) on D2:, which should provide the same results: Single Density: Dual/Enhanced Density: Double Density: Quote Link to comment Share on other sites More sharing options...
E474 Posted February 23, 2020 Author Share Posted February 23, 2020 Hi, Thanks very much - I had forgotten about this thread, despite commenting on it! It looks like it must be a ROM issue as it is definitely not setting the status bit 7 for ED correctly on my hardware. I guess the best thing to do is check the status register, if it returns bit 7 true, then it is Enhanced Density, and if it returns bit 7 false, check if I can read sectors > 720 just in case. Btw, is there any chance this is a bug on particular releases of US Doubler ROMs, or is it only for copied versions (and if so, I wonder which ones). Perhaps it's worth mentioning in @phaeron's Altirra Hardware Reference Manual that some unofficial US Doublers do not set status bit 7 correctly for ED disks? Thanks for all the help. Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted February 24, 2020 Share Posted February 24, 2020 18 hours ago, E474 said: Perhaps it's worth mentioning in @phaeron's Altirra Hardware Reference Manual that some unofficial US Doublers do not set status bit 7 correctly for ED disks? Stick to the verified genuine ICD ROM with CRC32 605B7153, which works as intended. One day I'll get my website off the ground to document & consolidate the ROM research I've done the last few years. In the mean time, I'll keep referencing previous posts of mine. This is a good start reference: https://atariage.com/forums/topic/283132-1050-is-that-an-icd-in-your-socket-or-are-you-happy-to-see-me/?do=findComment&comment=4120404 The only other US Doubler ROM not referenced in that particular post at this time is CRC32 DA77F8C0 that may have been an early unfinished ICD release (or leaked release) which (quoting @phaeron) is "missing code in the density detection routine to set bit 7 of the first status byte when switching to ED". This sounds awfully like the symptoms you're describing @E474: https://atariage.com/forums/topic/298026-us-doubler-rom/?do=findComment&comment=4385410 Maybe time will tell if we can better determine the source of the CRC32 DA77F8C0 ROM... in the mean time, we can only promote awareness to use known good ROMs. 2 Quote Link to comment Share on other sites More sharing options...
E474 Posted February 24, 2020 Author Share Posted February 24, 2020 Hi, Unfortunately there's not much chance of replacing (or dumping) the US-Doubler as it's part of this setup: So, I would be inclined to note it in the Altirra Hardware Reference (if it was my document, which it isn't). Timewise, I think I got the upgrade in the second half of 1985 or first half of 1986, but I can't be more specific than that (not sure if that rules out any of the ROMs), and I don't know if there is a dated copyright message in the dump of the Lazer code. Having said all that, I think I will code for SIO get status not being 100% reliable, and for that matter get Percom block also not always returning a correct Percom block. Thanks! Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 24, 2020 Share Posted February 24, 2020 I try not to document behavior of unofficial clones/modded firmware in the hardware manual unless the mods are well known by themselves, since there are too many mods -- Indus GT has a large number of confusingly named modded versions, for instance. Otherwise, it adds to the confusion and people claim "the doc is wrong because I have drive X and it doesn't behave this way." If we can get corroboration that the alternate USD ROM is actually an early official published version, then I could document that behavior for US Doubler. 1 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.