AtariGeezer Posted January 26, 2014 Share Posted January 26, 2014 I'm afraid responses along the lines of "You know: I think I'll keep doing it my way, thanks" quickly make me lose interest, especially when the aim of the suggestion was to reach some kind of mutually advantageous compromise and to ensure compatibility in a way which best benefits the user. And if you had gone the way of the existing format of TRG and made uflash compatible in the first place, there would be no reason for me to make TRG compatible with uflash after the fact So from my point of view, one could say the same about your unwillingness to do so... But no biggie to me, I'll keep on using TRG and when I get out of my slump, I'll finish the stand-alone flasher tool... Take care and keep up the great work... Link to comment Share on other sites More sharing options...
Kyle22 Posted January 26, 2014 Share Posted January 26, 2014 Personally, I like uflash the way it is. Such a wonderful and welcome tool. I can't wait to have a reunion with my Atari group (S.A.G.E. [Erie, PA]) from 20 years ago. They will be amazed by the fact that we have flash in our Ataris, and even more amazed that we can flash it directly from the Atari. Link to comment Share on other sites More sharing options...
+Stephen Posted January 26, 2014 Share Posted January 26, 2014 You coders sure are a stubborn bunch 1 Link to comment Share on other sites More sharing options...
atari8warez Posted January 26, 2014 Share Posted January 26, 2014 (edited) I was always a staunch advocate of TRG, especially when it inspired a competing tool developed out of egoism and spite, and offering no extra (indeed less) functionality that TRG. Egoism and spite!... how about being challenged by a sentence like "if you don't like it write your own....".... and I obliged and wrote that tool without a single input from anybody figuring it out all by myself, simple as that. I also said at one point "that's it for me fellas, I have no intention to develop it further".... And I agree IMO the titles should be left alone, and editing should be confined to the 14 characters reserved for descriptions.... but gee!... this is not enough to start an ego war!... Edited January 26, 2014 by atari8warez Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 26, 2014 Author Share Posted January 26, 2014 (edited) And if you had gone the way of the existing format of TRG and made uflash compatible in the first place, there would be no reason for me to make TRG compatible with uflash after the fact So from my point of view, one could say the same about your unwillingness to do so... What precedent could possibly compel me to "follow the existing format of TRG"? Is there official API documentation floating around somewhere which stipulates that the 32-byte menu definitions should be editable in their entirety? Does said document - if it exists - have your name on it? Is there any convincing piece of anecdotal evidence to suggest that the free-form editing of the menu definitions was a careful design decision made with absolutely explicit, forward-thinking reference to "multi-language support?". I had paid no particular attention to the method employed by TRG for editing slot definitions until I read this post: Think I'll change The ROM Generator so that the 800/Colleen OS Slots only saves the proper 10k block so that the 2k padding and 1/4th (4k) SIDE/Fat32 Loader is stripped out of it. This should avoid some confusion... Prior to this, I can find no direct reference to TRG in this thread. And why would there be? However, the above remark set me thinking that compatibility might be desirable somehow, so I downloaded the tool and noticed a couple of things which seemed odd (having used, I should point out, a combination of hex editors and roughshod PBI / BIOS flashing tools for the past couple of years while writing the PBI BIOSes for Ultimate 1MB and Incognito). So, I suggested it "might be nice" if TRG used a (compatible) bounds-limited approach to editing the slot descriptions, rather than what struck me as a very peculiar way of handling things which - when it collided head-on with a much less peculiar way of handling things - would certainly result in menus even more messed up than the messed up menus a user of TRG would be capable of inadvertently creating without recourse to any additional tools. The rest, of course, is history, and ironically enough threatens to turn into a repeat performance of the Ray and Jay pantomime that went on around the time that TRG was first being developed. This latest twist is puzzling to me, though, for a number of reasons: It's not a pre-requisite that uflash and The ROM Generator should be compatible. The suggestion that they should be was made by you. With reference to the above, uflash is under absolutely no obligation to regress its own functionality by adhering to practices previously adopted by TRG, especially if said practices fail to sanitise the user's edits in a way which has seemed to me a basic necessity (and no more exceptional or taxing than - say - ensuring the editor's selection bar travels in the direction the user wants it to) since the early design stages of the latest tool. The incompatible implementation of slot description editing in uflash is not a deliberate act of non-compliance, since TRG sets no sensible precedent with which to comply or to disregard. Regarding precedents, one might (to again give voice to an exceptionally uncomfortable truth) consider the technique employed by The Ultimate ROM Builder as a suitable precedent, since it has every right to be considered as such, if only for the fact it implements the functionality we are discussing in what is demonstrably the correct way, and actually looks (though it pains me to say this) like it was quite well thought out. These are the simple facts. The once intense rivalry between Ray and Jay concerns me not one bit, and nor does the fact that for either to concede that the other's tool was doing something in a better way than the other would to this day constitute a small miracle. I may have previously misjudged the motivation behind Ultimate ROM Builder, in fact. This is my own fault for not paying more careful attention to the design of the two tools when they were first released. ...there would be no reason for me to make TRG compatible with uflash after the fact ... and indeed these is no reason to do so. This would kind of be the main bullet-point I'm trying to get across here. ...I'll finish the stand-alone flasher tool... Providing this is done without recourse to gradient fills, it can only signify positive things. And yet more reasons to make no alterations to TRG. You coders sure are a stubborn bunch Not stubbornness on my part: just an unwillingness to break my own software. Is that somehow unreasonable? So - hopefully that's that dealt with. Hopefully we can get back onto the subject at hand - namely testing uflash. In fact not "hopefully": I absolutely insist. Personally, I like uflash the way it is. Such a wonderful and welcome tool. Thanks. EDIT: spent so long having to explain myself, nearly forgot the bloody website link: http://atari8.co.uk/uflash/ Edited January 26, 2014 by flashjazzcat Link to comment Share on other sites More sharing options...
Roydea6 Posted January 26, 2014 Share Posted January 26, 2014 The bloody link points to a beta5.zip and I thought you had made a #7 beta.. 1 Link to comment Share on other sites More sharing options...
atari8warez Posted January 26, 2014 Share Posted January 26, 2014 (edited) FJC said: Providing this is done without recourse to gradient fills, it can only signify positive things. Come on.....admit it you love gradient fills Edited January 26, 2014 by atari8warez Link to comment Share on other sites More sharing options...
AtariGeezer Posted January 27, 2014 Share Posted January 27, 2014 .... No need to get your panties in a bunch and go on such a rant Jon My mistake, I thought you would be professional and like the two apps work together since TRG came into existence first, but guess not, so I won't bother with you anymore... 'nough said... Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 27, 2014 Author Share Posted January 27, 2014 (edited) The bloody link points to a beta5.zip and I thought you had made a #7 beta.. Yes - I forgot to bump the bloody version number last time, Roy, but you'll note that the bloody ZIP files are often numbered by bloody test version, which is a numbering scheme subordinate to the beta # in the bloody "About" dialogue, and there was never a version released yet with a beta # higher than four. Edited January 27, 2014 by flashjazzcat 1 Link to comment Share on other sites More sharing options...
Roydea6 Posted January 27, 2014 Share Posted January 27, 2014 Ahh! Yes the #7 was a test version my bad. I was just put off by the #5 and not understanding your process. Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 27, 2014 Author Share Posted January 27, 2014 I was just put off by the #5 and not understanding your process. No problem. As soon as I understand my process, I'll describe it here. 1 Link to comment Share on other sites More sharing options...
+Larry Posted January 30, 2014 Share Posted January 30, 2014 Hi Jon- I got my Ultimate 1MB installed in an 800XL, and I'm ready to update the Ver 1 flash rom. I read your write-up at your site: "The above notwishtanding: uflash is currently beta software, and it's advisable - as when performing any flash maintenance on your Ultimate 1MB or Incognito - to ensure you have some means of disaster recovery available in the event that the main BIOS becomes corrupted. This could be an external PLCC flasher, or a cartridge capable of reprogramming the 512KB flash ROM. That said, uflash has performed reliably in testing." Any flash carts in particular that meet the requirements? The only one that I can think of is the MyIDE-II cart that contains a 512 KB flash rom. If that worked, it would be possible to use the MyIDE-II cart as a flash vehicle with the studio programmer. (???) Have you by any chance tried that with your MyIDE-II cart? I presume that I can dump the existing rom with UFLASH (with impunity) -or- that it is available as a 512K flash somewhere "just in case?" Edit: What a nice tool! I am always so impressed with the user-friendliness of your software. I was able to dump the rom, so I have that portion of a fail-safe taken care of. -Larry 1 Link to comment Share on other sites More sharing options...
Roydea6 Posted January 30, 2014 Share Posted January 30, 2014 (edited) Hi Jon- I got my Ultimate 1MB installed in an 800XL, and I'm ready to update the Ver 1 flash rom. I read your write-up at your site: "The above notwishtanding: uflash is currently beta software, and it's advisable - as when performing any flash maintenance on your Ultimate 1MB or Incognito - to ensure you have some means of disaster recovery available in the event that the main BIOS becomes corrupted. This could be an external PLCC flasher, or a cartridge capable of reprogramming the 512KB flash ROM. That said, uflash has performed reliably in testing." Any flash carts in particular that meet the requirements? The only one that I can think of is the MyIDE-II cart that contains a 512 KB flash rom. If that worked, it would be possible to use the MyIDE-II cart as a flash vehicle with the studio programmer. (???) Have you by any chance tried that with your MyIDE-II cart? I presume that I can dump the existing rom with UFLASH (with impunity) -or- that it is available as a 512K flash somewhere "just in case?" Edit: What a nice tool! I am always so impressed with the user-friendliness of your software. I was able to dump the rom, so I have that portion of a fail-safe taken care of. -Larry The SIC!Cart with a PLCC adapter fitted into the Rom slot can flash the Ultimate rom also. Edited January 30, 2014 by rdea6 1 Link to comment Share on other sites More sharing options...
+Larry Posted January 30, 2014 Share Posted January 30, 2014 Thanks, Roy. Took apart my MyIDE-II shell, and everything is soldered. Surprised by that since the earlier carts have PLCC, but that's what it is. -Larry Link to comment Share on other sites More sharing options...
Roydea6 Posted January 30, 2014 Share Posted January 30, 2014 Larry, Also this thread talks of a way to flash the rom chip with an AtariMax 8Mb cart... http://atariage.com/forums/topic/213473-u1mb-bricked/?p=2816137 Link to comment Share on other sites More sharing options...
+Larry Posted January 30, 2014 Share Posted January 30, 2014 Thanks, Roy. I've bookmarked that page "just in case." I went ahead and flashed my V1 rom with the image at Lotharek's site using Jon's utility. Worked just fine! Now I have SDX 4.46 on the Ultimate when I need it. Now to update and customize it just a bit more and I'll be set. -Larry 1 Link to comment Share on other sites More sharing options...
phoenixdownita Posted February 1, 2014 Share Posted February 1, 2014 Sorry, it's probably been said already but after 7 test versions I lost track. Is support for loading ROMs straight from FAT32 still pending on SIDELoader fixes or is it supposed to be working? Also, on a totally different note, would it ever be possible to have a tool to get a "ROM" for a given slot and U1MB or Incognito as targets and generate the relative XEXs to flash only that one ROM in the selected slot? More or less like the PBI 0.4 XEX flasher except with the possibility to specify ROM and slot and target platform so that we can create them on a self serving base, wouldn't mind if this would require uploading the ROM to fjc website and download the XEX after processing. I admit that if FAT32 support is coming then it is probably redundant, just asking. Link to comment Share on other sites More sharing options...
AtariGeezer Posted February 1, 2014 Share Posted February 1, 2014 Also, on a totally different note, would it ever be possible to have a tool to get a "ROM" for a given slot and U1MB or Incognito as targets and generate the relative XEXs to flash only that one ROM in the selected slot? This is what The ROM Generator will do as soon as I finish that part Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 2, 2014 Author Share Posted February 2, 2014 (edited) Is support for loading ROMs straight from FAT32 still pending on SIDELoader fixes or is it supposed to be working? It's still pending, subject to a small fix in the loader. I haven't been told it's fixed yet, so I assume it isn't. Also, on a totally different note, would it ever be possible to have a tool to get a "ROM" for a given slot and U1MB or Incognito as targets and generate the relative XEXs to flash only that one ROM in the selected slot? More or less like the PBI 0.4 XEX flasher except with the possibility to specify ROM and slot and target platform so that we can create them on a self serving base, wouldn't mind if this would require uploading the ROM to fjc website and download the XEX after processing. I admit that if FAT32 support is coming then it is probably redundant, just asking. It would be simplicity itself, since I've already written the necessary code to make it happen (as used in the stand-alone PBI flashers): I simply didn't imagine anyone would want a stand-alone flasher which could be customised in this way. Really it would be a case of amending some tables and tacking the desired ROM onto the end of the flasher. As you say, though, once you can run uflash from the SIDE loader, the above might seem rather redundant for all but those who want to create self-flashing distributable ROM slot content. Candle appears to already have a means to do this, and so do I, so that's the BIOS and PBI taken care of. But perhaps the facility might be useful for other sections of the chip. Certainly doable with a minimum of fuss, anyway, although it's not really going to be a major inconvenience for anyone to drop some ROM images alongside uflash in a FAT partition and fire up the tool from the loader. The objective there was to create something which allows chopping and changing of BASIC, OS, etc, from a collection of ROM images without first having to run said ROM images through some other preparative process. In addition, using a tool like uflash allows manual editing of the ROM slot's description at the moment you update the slot's content. A self-contained XEX for flashing BASIC and OS slots (i.e. those slots whose content is not predetermined) might sensibly also provide some means of carrying the desired slot description along with it as part of the payload, which will require meddling with the menu data in the BIOS during the flash process... and therefore the trusty tea-leaves predict that - depending on the implementation - such a thing may or may not end up being compatible with the tool already provided. Edited February 2, 2014 by flashjazzcat Link to comment Share on other sites More sharing options...
phoenixdownita Posted February 2, 2014 Share Posted February 2, 2014 (edited) In all honesty given uFlash supports full 512K I was looking forward to a XEX solution for the flashing of the whole content that doesn't depends on any FS support. The flasher XEX with embedded ROM that I hinted at would have also supported the whole bank. I could then have used any tool to generate the full ROM to be used with the flasher XEX [even just copy /b of the sections] and it could have been run from whatever source could jump start an XEX (assuming it is compatible with SDX on). I guess I like the fact that FAT32Loader on MyIDE2 can flash a selected MyIDE2 format ROM via CTRL-F, I am not sure that embedding such feature in SIDEloader is warranted although I think it could be a nice thing (for both U1MB/Incognito and SIDE2). So then the stand alone 512K XEX would be the next best thing. But if SIDELoader implements the MiniDOS fix in the foreseeable future there really is no need to put time and energy into a general purpose XEX based flasher with piggybacked ROM given that now we have uFlash for it. I wonder how hard would it be for uFlash to detect and support SIDE2? Edited February 2, 2014 by phoenixdownita Link to comment Share on other sites More sharing options...
+Larry Posted February 7, 2014 Share Posted February 7, 2014 Houston, we have a problem... I successfully updated the CPLD to V2 using the XILINX software. Then I used UFLASH to flash the entire V2 rom. Both operations were completed successfully (no errors or unexpected events), but even with the Ultimate SDX enabled, all I get is a black screen. (It boots SIO and MyDos and the SIDE SDX just fine.) I have cartridge versions of SDX that work fine, but in order to re-flash using UFLASH.XEX, the on-board SDX must be used. Any suggestions? -Larry Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 7, 2014 Author Share Posted February 7, 2014 (edited) Any suggestions? Don't attempt the same thing again till I've looked into it. Thanks for the report. I knew there must be some bugs in it somewhere. BTW: what's the reported type of flash ROM? I'll also need a link to the 512KB ROM you flashed to the chip. EDIT: just tried a whole ROM dump and reflash here and it worked fine, so I'll need that ROM... Edited February 7, 2014 by flashjazzcat Link to comment Share on other sites More sharing options...
+Larry Posted February 7, 2014 Share Posted February 7, 2014 Thanks, Jon! http://www.lotharek.pl/product.php?pid=67 This is the V2 rom on Lotharek's Ultimate page. -Larry Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 7, 2014 Author Share Posted February 7, 2014 (edited) Thanks Larry. Just done three machines: 1200XL (ST39SF040), 600XL (A29040), and 800XL (ST39SF040). No problems at all. As I said: what kind of chip is in your Ultimate? The single time I've experienced a bad flash with this utility was when updating the 1200XL when it still had an Amic 64KB sector PLCC in it. The chip had been removed and reinserted many times and I started getting consistent flash errors, which pointed to wear on the socket or chip legs, leading to poor contact. The solution - oddly enough - was putting the Amic chip in the 600XL (which had a brand new Ultimate board in it), and putting the 600XL's SST PLCC into the 1200XL. Anyway: it looks as if fate conspired against you in some way there, and you got a wonky bit somewhere in the BIOS area. If you're experiencing any kind of instability, my best suggestion would be to avoid complete chip flashes for the moment, since they're in any case pretty unnecessary now. Only a bad BIOS flash should brick the machine (PBI can be deactivated and SDX turned off if something went wrong), and if you're using a 4K sector ROM (as I think most are now), the BIOS will never be touched unless you explicitly update it. I didn't write the JEDEC library, but Candle told me in no uncertain terms that it is "guaranteed bug-free", and that's the code which actually erases sectors and clears bits in the flash ROM. I have absolutely no reason to doubt his claims, my only experience of failed flashing being that single instance described above. Anyway: if we know the type of flash chip involved, we can perhaps start diagnosing your issue. BTW: if you're completely stuck for a recovery strategy, you might try Trub's suggested method here: http://atariage.com/forums/topic/210066-u1mb-flasher-timeout-error/?view=findpost&p=2863129 Edited February 7, 2014 by flashjazzcat Link to comment Share on other sites More sharing options...
+Larry Posted February 7, 2014 Share Posted February 7, 2014 Hi Jon- Thanks for your help! Xilinx XC95144XL The flash chip (I think) is an AMIC A29040BL-70F (This guy has never been out of the PLCC socket.) -Larry 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