flashjazzcat Posted February 3, 2014 Share Posted February 3, 2014 Maybe so you can solder wires on the fly ... not sure it is any more convenient but it allows to have any cable soldered directly with much ease .... but soldering nonetheless. If that turned out to be the genuine reason behind omission of the header, I could do nothing but laugh uncontrollably for 5-10 minutes. Fingers crossed it was just left off on the blithe assumption that a CPLD update would not be required. Indeed, on the newer boards, I suppose it probably won't. Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted February 3, 2014 Share Posted February 3, 2014 It's a snug fit, mind you. You'll bend some pins as the Dupont ends are for 2.54mm pitch, in my case rather than hard plastic the Dupont wires end had a soft rubber cover which due to the tight fit I almost ripped open, hence the idea of building an adapter with a 2.00mm 10pin header connector cable. I bought 2 for 1$ o something like that, shipped, just need to find the time to solder it to a perfboard and use a more commonly found 2.54mm header on the other side. I haven't decided what header type yet, a straight single line for the Dupont wires or a 14pin double line for the std xilinx cable .... will see what I have available when the time comes. Hmmm, okay... I searched ebay for "2.0mm pitch 10 pin cable", but the cables I bought aren't listed. But I did find eBay Auction -- Item Number: 151125961978 "40P Dupont Prototype cables 2.54 to 2.0mm pitch" that can be used if the others are too snug... Quote Link to comment Share on other sites More sharing options...
+Larry Posted February 3, 2014 Author Share Posted February 3, 2014 Isn't that what needle-nose pliers are for? I'll bet that I can make them fit... But I do have a "plan B" just in case. But here is a question for Jay -- if I read correctly, your Generator will update the V1 rom? So if I fill all the "slots" on the generator, I can gain some of the functionality of V2 (or at least add the OS and carts that I want)? I presume that any slots not filled (XEGS slots, for example) are blanked out or left as-is? Or does *something* have to appear in every slot of the Generator? -Larry Quote Link to comment Share on other sites More sharing options...
+Stephen Posted February 3, 2014 Share Posted February 3, 2014 If that turned out to be the genuine reason behind omission of the header, I could do nothing but laugh uncontrollably for 5-10 minutes. Fingers crossed it was just left off on the blithe assumption that a CPLD update would not be required. Indeed, on the newer boards, I suppose it probably won't. It was mentioned (I believe by Lotharek) that they were left off due to that particular part being hard to find. I don't have the post and honestly I don't feel like searching for it. Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted February 3, 2014 Share Posted February 3, 2014 (edited) Isn't that what needle-nose pliers are for? I'll bet that I can make them fit... But I do have a "plan B" just in case. But here is a question for Jay -- if I read correctly, your Generator will update the V1 rom? So if I fill all the "slots" on the generator, I can gain some of the functionality of V2 (or at least add the OS and carts that I want)? I presume that any slots not filled (XEGS slots, for example) are blanked out or left as-is? Or does *something* have to appear in every slot of the Generator? -Larry If you are using a 512k V1 ROM, The ROM Generator can be used to update the SDX, Basic, XEGS Game and OS Slots. You can not use a V2 Bios, PBI or SIDE Loader until you update the Xilinx with the V2 JED. If you dont use a 512k ROM, each Slot needs to be filled... Edited February 3, 2014 by AtariGeezer Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 4, 2014 Share Posted February 4, 2014 (edited) It was mentioned (I believe by Lotharek) that they were left off due to that particular part being hard to find. I don't have the post and honestly I don't feel like searching for it. Nor do I. If reasons were given, I never saw them. All I know is I have a few of the headers in question in a bag here, and they were sent from Poland. If I wanted more, I'd order them from the same supplier in Poland (they're in stock, and cost c. 0.25 EUR each). Same place I order the Harting connectors for the proper OS/MMU cables. I recall Lotharek saying that they were once hard to find as well, but now they're not, so who knows... Edited February 4, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+Larry Posted February 5, 2014 Author Share Posted February 5, 2014 IIRC, there were two "batches" of Ultimates from Candle. If that is true, was there a difference in the CPLD and/or the rom between Batch #1 and Batch #2? If the CPLD's were the same, but the roms were different, is the 2nd rom posted somewhere? If so, I'll try to flash my V1 with the 2nd rom. -Larry Quote Link to comment Share on other sites More sharing options...
Marius Posted February 5, 2014 Share Posted February 5, 2014 Hi Larry, Yesterday I found out that the second batch from candle indeed had the V2 CPLD bios. The first batch is V1. I am sure about this, since I replaced my batch #1 u1mb with batch #2 u1mb. With this newer batch I can use my SIDE. I think it has a very big potential, and I'm testing a lot of things… but at this moment I must say it is not working yet as expected. SDX works good, but I'm not a SDX user. The PBI driver of FJC works also very well. But the ATR compatibility needs improvement. Perhaps I'm dealing with some other problems, so I can not tell exactly what is going on. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2014 Share Posted February 5, 2014 (edited) Thanks to Prowizard's uniquely pragmatic testing (for which boundless thanks are owed), and after some hours of fault-finding, I've discovered that most ATR compatibility problems stem from what I would consider "non-standard" double-density ATRs which have padding directly after the three single density boot sectors. It appears the lion's share of ATRs do not have this padding, but yet it's now obvious that some do. Without recourse to the actual ATR file size from within the PBI BIOS, I'll have to figure out some other way to intuit whether this padding exists or not, and whether it is interleaved with the boot sectors (haven't yet come across such an arrangement, however). Furthermore, one of the (SpartaDOS) ATRs which ProWizard sent me has a paragraph count in the header which corresponds not to the size of the ATR file but to the number of sectors it contains. Having finally had occasion to study a cross-section of problematic ATRs (few examples with reproducible issues having been forthcoming until now), while the aim of "improved compatibility" is certainly worthwhile, I have to conclude that the bastardisation of the ATR format is clearly to blame here when the implementation has simply followed the documented file structure. Without recourse to the FAT file size (which is not passed via the API), I'll have to recommend that ATRs which deviate from the ATR spec simply not be used. I'll speak to Candle about it and see if anything can be done (the obvious solution being to pass the ATR's actual file size to the driver so I can then perform a series of tests to decide which variant of the file format is being used). Edited February 5, 2014 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
HiassofT Posted February 5, 2014 Share Posted February 5, 2014 Hi Jon! Thanks to Prowizard's uniquely pragmatic testing (for which boundless thanks are owed), and after some hours of fault-finding, I've discovered that most ATR compatibility problems stem from what I would consider "non-standard" double-density ATRs which have padding directly after the three single density boot sectors. It appears the lion's share of ATRs do not have this padding, but yet it's now obvious that some do. Without recourse to the actual ATR file size from within the PBI BIOS, I'll have to figure out some other way to intuit whether this padding exists or not, and whether it is interleaved with the boot sectors (haven't yet come across such an arrangement, however).Your best bet would be to add some code to check the file size and then reject those broken DD ATRs with sizes != 16+384+x*256. For example the original SIO2PC software created 720*256 bytes DD ATRs which had some extra 384 byte at the end of the file. The content of this padding was what was currently on the heap at this address. It's next to impossible to distinguish these broken ATRs from other broken ATRs that have padded boot sectors. I've also come across several ATRs (IIRC created by K-boot or something similar) with a wrong (factor 2 or so too large) paragraph count. Since these were all SD ATRs a simple solution is to truncate the (emulated) sector size to the actual file size. If you spit out an error or warning people will know that they have a broken ATR and can fix it (there are various ATR fixer programs around, for example one made for the SIO2USB). so long, Hias 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2014 Share Posted February 5, 2014 (edited) Your best bet would be to add some code to check the file size and then reject those broken DD ATRs with sizes != 16+384+x*256. Hi Matthias! This was exactly my thinking, but unfortunately the current API only requires that the caller pass the first cluster of the ATR file, the LBA address of the host volume's FAT, and the LBA of the cluster area's start. Without the file size in bytes, I have nothing to compare the header against. Sure I can trace the FAT chain quickly, but this still doesn't tell me how many bytes of the last last cluster are occupied by the file. Nevertheless, it should be easy to detect the second deviant case (paragraph count = file size in bytes) by tracing the FAT. It would be much better to simply know the exact file size, however. For example the original SIO2PC software created 720*256 bytes DD ATRs which had some extra 384 byte at the end of the file. The content of this padding was what was currently on the heap at this address. It's next to impossible to distinguish these broken ATRs from other broken ATRs that have padded boot sectors. I've also come across several ATRs (IIRC created by K-boot or something similar) with a wrong (factor 2 or so too large) paragraph count. Since these were all SD ATRs a simple solution is to truncate the (emulated) sector size to the actual file size. It's certainly a minefield. I expected problems with non-standard ATRs, but it appears they are more widespread than I initially supposed. The file size seems to be a must-have. If you spit out an error or warning people will know that they have a broken ATR and can fix it (there are various ATR fixer programs around, for example one made for the SIO2USB). The thing is that once the exact manner in which the ATR is "broken" can be deduced, the file can probably be quite happily managed by the firmware (although the EOF padding cannot be differentiated from padded boot sectors, as you say). EDIT: turns out I was mistaken about the paragraph count in one of ProWizard's ATRs equating to the number of sectors at least. So it's just the padding we need to worry about. Edited February 5, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2014 Share Posted February 5, 2014 Right: I think I've worked out the formula for padding detection. Number of sectors in the ATR is calculated as follows (assuming DD with SD boot sector compensation): ((paragraphs-24) / 16 ) + 3 For a 720KB disk without non-standard padding (183,936 bytes excluding header), the paragraph count should be 11,496. So: ((11496-24) / 16) +3 = 720 Now, (11496-24) / 16 = 717. (717 x 256) + 384 = 183,996 bytes. So the calculation yields the same paragraph count as in the header. Deduction: no padding. For a 720KB disk with 384 bytes of padding (184,320 bytes excluding header), the paragraph count should be 11,520. So: ((11520-24) / 16) +3 = 721 (11520-24) / 16 = 718. (718 x 256) + 384 = 184,192 bytes. This does not equal the total file size described in the header. Deduction: padding. Quote Link to comment Share on other sites More sharing options...
Marius Posted February 5, 2014 Share Posted February 5, 2014 @Hias: Unfortunately ... I have tested all my ATR's with the Tool from Thomas Grasel, and they do not report an error, although they still do not work with the SIDE FAT32 ATR loader. I have my CF card (SIDE) here and I run the ATR HELP TOOL SUITE directly on this CF card, and it reports: no invalid ATR-files found. I think that the operation of this tool is ok, and I'm really puzzled why some of my ATR's simply do not work. I even have not working SD ATR's on SIDE now. Quote Link to comment Share on other sites More sharing options...
Marius Posted February 5, 2014 Share Posted February 5, 2014 Thanks to Prowizard's uniquely pragmatic testing (for which boundless thanks are owed), Well thank you for all your efforts in this driver(s)! I used to spent all my time in beta-testing MyIDE, but you know how that ended I really like to do some serious testing in several setups and circumstances. So if you have something that you really want to test call me 1 Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted February 5, 2014 Share Posted February 5, 2014 (edited) Well, the old SIO2PC 3.x version also has a bug, when creating Medium/Enhanced density disks, they are saved as 140k ATR images (instead of 130k). On the A8 I always use the sector-copy-program MyCopier V1.c with these faulty images, since you can manually set enhanced density there (most if not all other sector-copy programs see the 140k ATR images as single density / 90k) and then I simply copy them back to real disks or correct sized ATR images. -Andreas Koch. Edit: For incorrect DD (180k) ATR images I often use ACVT to repair them - but afaik this is a 16Bit PC program (running under MS-DOS for me)... http://www.atarimax.com/jindroush.atari.org/asoft.html Edited February 5, 2014 by CharlieChaplin Quote Link to comment Share on other sites More sharing options...
Marius Posted February 5, 2014 Share Posted February 5, 2014 Well, the old SIO2PC 3.x version also has a bug, when creating Medium/Enhanced density disks, they are saved as 140k ATR images (instead of 130k). On the A8 I always use the sector-copy-program MyCopier V1.c with these faulty images, since you can manually set enhanced density there (most if not all other sector-copy programs see the 140k ATR images as single density / 90k) and then I simply copy them back to real disks or correct sized ATR images. -Andreas Koch. Ah this finally solves the mistery for me! I indeed had a few old 140K atr's in my collection, and I didn't remember when or why I created them, or where I got them from. They must indeed have been created in the beginning-time of all this Sio2PC related stuff. Thanks for that info! Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted February 5, 2014 Share Posted February 5, 2014 Back when I started writing my ATR Tools app, I found many ATR and XFD images that had the extra 384 byte padding problem. On DD images, some have 256 byte sectors on the first 3 sectors, while some others were padded at the end of file... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2014 Share Posted February 5, 2014 I even have not working SD ATR's on SIDE now. Try not to draw too many conclusions from the hasty fixes I'm sending you in PMs. I've just sent you another. The previous one was comprehensively broken. Quote Link to comment Share on other sites More sharing options...
+Larry Posted February 5, 2014 Author Share Posted February 5, 2014 Hi Larry, Yesterday I found out that the second batch from candle indeed had the V2 CPLD bios. The first batch is V1. (snip...) Hi Marius- Thanks. So I'll need to wait a bit to flash my V2 cpld and rom. -Larry Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted February 6, 2014 Share Posted February 6, 2014 Since the Ultimate1mb interface has basic on rom, could I take the Basic Eprom out of the Computer without effecting the running of the computer.. I would like to put it into a computer that has version B basic so the other 800xl could have Basic version C also. Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted February 6, 2014 Share Posted February 6, 2014 Since the Ultimate1mb interface has basic on rom, could I take the Basic Eprom out of the Computer without effecting the running of the computer.. I would like to put it into a computer that has version B basic so the other 800xl could have Basic version C also. Yep, I removed mine from the 800xl and 130xe when I installed the U1MB's... 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 6, 2014 Share Posted February 6, 2014 I've just sent ProWizard a copy of the PBI BIOS which appears to detect and work quite nicely with DD ATRs with 384 bytes of padding right after the boot sectors. Several other improvements have also been made which greatly increase compatibility with SpartaDOS 3.x and RealDOS (both of which use $3D/3E during their boot process). Once ProWizard and I have done more testing, I'll put this ROM out as part of the complete APT update. About the only drawback I can see with the ATR fix is that it will break ATRs with padding at the end of the file which previously worked OK. 1 Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted February 6, 2014 Share Posted February 6, 2014 RE: JTAG cable, I went with a pitch adapter and the help of a chopped up paper clip Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 6, 2014 Share Posted February 6, 2014 Got the padded ATRs fully working now in the Ultimate PBI BIOS, but I wonder how common they actually are? It took a fair chunk of code. My old build of Altirra won't even handle a DD ATR with 384 bytes of padding after the boot sectors. 2 Quote Link to comment Share on other sites More sharing options...
+Larry Posted February 20, 2014 Author Share Posted February 20, 2014 An update and some new questions: First, thanks to Jon's efforts, the new UFLASH 1.0 successfully programs my Atarimax (Bright) rom. Programmed the first try with zero issues. My new ST roms should be here today or tomorrow, so I'll replace the "loaner" rom with the current OEM version and reprogram. * BASIC from the Ultimate no longer overrides other devices -- so the MyIDE and MyIDE-II carts now work fine. * The IDE+2 works fine with MyDos or either of the built-in SDX versions. (The IDE+2 drive apparently overrides the Ultimate's SDX -- my IDE+2 drive with MyDos on it boots to MyDos, even if the Ultimate SDX is enabled.) That's not any kind of a complaint, but is slightly surprising. * The amount of ram that MyDos now sees appears to be stable -- it was not consistent before I re-flashed this AM. More to do yet, but progress... @Jon- look for a donation as evidence of my appreciation for your hard work on our behalf. -Larry 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.