Jump to content
IGNORED

In-place Ultimate 1MB / Incognito ROM editor and flash tool


flashjazzcat

Recommended Posts

Applying a 64k upgrade to the 600XL first, can you use a 1064 in addition to that?

Can the Ultimate be fitted into a 600XL case? Any conflicts with the 64k upgrade?

Can The Simple Stereo be fitted into a 600Xl case?

 

Yes the U1MB can be fitted into a 600XL, and no, there will not be a conflict with the 64K upgrade, in fact it is needed for U1MB installation.

Link to comment
Share on other sites

Testing uflash on a stock 130XE with IDE+2, SDX enabled, the software loads and freezes with a black screen, reboot required. I realize that there is no hardware to flash in this config, but I was expecting uflash to display its GUI and say that the hardware was not found just like it does when it's run without IDE+2. Anyway, just to let you know....

 

http://youtu.be/H-wbidXYK0o

Edited by atari8warez
Link to comment
Share on other sites

Applying a 64k upgrade to the 600XL first, can you use a 1064 in addition to that?

Can the Ultimate be fitted into a 600XL case? Any conflicts with the 64k upgrade?

Can The Simple Stereo be fitted into a 600Xl case?

No room for a hard drive so its probably stuck with the SIO2SD option

1. Yes (since the 1064 completely maps out the internal RAM).

2. Yes and no.

3. Yes.

4. Buy a SIDE2 and use it with Ultimate as the hard disk. Job done.

 

:)

Link to comment
Share on other sites

ok, sorry about that, it was some sort of file corruption issue I guess, somehow the ATR i have copied uflash.xex from had a bad file..

all is good now and I can now actually test with my U1MB in my 600XL. Deleted the videos from youtube by the way...

Edited by atari8warez
  • Like 1
Link to comment
Share on other sites

@FJC That U1MB or Incognito not found message came here up too (before I flashed my U1MB with your entire 512K U1MB ROM!) and man... do you hate that 130xe? Why are you trying to hit through the keyboard? Poor 130XE... you should type gently on that machine. It isn't his fault remember ;)

Link to comment
Share on other sites

Are there any pictures available where people did mount their U1MB in the 600XL. Was drilling required?

 

In the 800XL I used a hole that was already there... and I only used ONE screw to mount the u1mb inside the 800xl.

 

I did not open up my 600XL yet for investigation.

Link to comment
Share on other sites

Marius I did not mount mine with the stands, I've just let it float inside the machine, there are enough cables under the upgrade to keep it away from the mainboard. The problem with the 600XL installation is that the keyboard is so close to the back of the machine there is not enough clearance for an upgrade like U1MB, so I hot glued a piece of clear hard plastic, cut to the size of the board, on top of the battery to keep the top of the board or the battery from touching any metal parts inside. Since I am not going to bounce the 600XL around like a ball, I think just letting it lose inside the case will work fine, well at least it did so far :) I am sure if I put my mind to it i could find some place to mount it permanently too but that's another future project for me.

 

post-15627-0-75152600-1393020871_thumb.jpg post-15627-0-71823800-1393020873_thumb.jpg

Edited by atari8warez
Link to comment
Share on other sites

@a8w Yeah... you don't want to know how one of my 600XLs looks like. It's a rat's nest. I added some cool extra's to this one a few years ago (one of the upgrades is the 512K Sram upgrade from Hiassoft, which is an excellent upgrade by the way).

 

I really love the looks of the 600xl. Only problem is that most of the PAL 600XL's do have a terrible keyboard. On my main 600XL I replaced the keyboard with one of a spare 800XL. I think I'll do that with another 600XL too, and then add U1MB to it. My only problem is, I always hated the spaghetti 600XL, so I really wanted to do it nice this time with the U1MB... but If I read your solution I'm afraid my 600xl will end up like that too.

 

But hot glue... omg... you must be kidding right ;)? I hate that stuff. It always releases from where it should have been after a while. I think this over. Must be a better way right ;)

 

Perhaps is unsoldering the sockets from the mainboard, and soldering the connectors direct to the PCB an idea. This will give a few mm extra space. Hmmmm.....

Link to comment
Share on other sites

@a8w Yeah... you don't want to know how one of my 600XLs looks like.

 

Well yeah, it is not the best solution for sure, one place where I can mount it is where the RF modulator used to be (I removed mine and using S-Video instead), but I was too lazy to rebuild the cables when I've done the upgrade, as I said one day I will get back to it and do it right, I guess hot glue can hold the sheet until then :)

 

Posted photos above....

 

And oh, 600XL is my favorite 8 bit too, mostly love the compact size and yet it still has all the amenities an 800XL offers (after the 64K upgrade of course ;) ), and now with the U1MB it is way better then my other two 800XLs

Edited by atari8warez
Link to comment
Share on other sites

@FJC That U1MB or Incognito not found message came here up too (before I flashed my U1MB with your entire 512K U1MB ROM!) and man... do you hate that 130xe? Why are you trying to hit through the keyboard? Poor 130XE... you should type gently on that machine. It isn't his fault remember ;)

 

No, it's not the 130XE I have an issue with. ;) Actually the keyboard backplate isn't screwed on (been cleaning it), so I had to hit the keys hard to make them register.

 

Regarding the "not found" message: it's quite natural to see this when updating a very old ROM which includes a BIOS which lacks the ID bytes which UFLASH looks for when identifying the hardware. There are no easy ways to perform the test solely by investigating the hardware itself, so I look for the ID bytes which Candle includes in the more recent BIOSes (and without a BIOS, the hardware will not boot anyway). When these magic bytes are not found, you'll see the "not found" message. Previously, the program would not run at all, but Candle suggested I add the facility to manually select the hardware, which I duly did.

 

Similarly, "Ultimate or Incognito not found" will be displayed when there is actually no Ultimate or Incognito hardware present at all, as we have seen. Seems like sensible and consistent behaviour to me. :)

 

In situations when the hardware cannot be automatically identified for one reason or another, I rely to some extent on the user knowing whether he has an Atari XL/XE or 800 under his hands, and whether said machine contains the required upgrades. Post-it notes or adhesive stickers applied to the case are probably useful if uncertainty prevails regarding the model of the machine or what upgrades it contains. :D

Edited by flashjazzcat
Link to comment
Share on other sites

@Jon

 

Is there a reason that for UFLASH to work, the SDX present must be the Ultimate SDX? In other words, so long as SDX is found (say from the IDE+2), can't that work for UFLASH?

 

I'm asking because on one of my roms, SDX can't be enabled. This is the AMIC rom, and I'd like to try flashing it again.

 

-Larry

Link to comment
Share on other sites

Good question Larry. UFLASH requires access to the SDX base register, since it's this register which is used to switch the Ultimate ROM banks. This is presumably also why the built-in SIDE loader only works when SDX is enabled. But while testing the forthcoming APT update (which - God willing - will be ready tomorrow) last night, I noticed that if I boot the MyDOS version of the APT toolkit disk using MATR (having placed the ATR in a FAT16 partition, in this case), UFLASH works perfectly well under MyDOS. I assume this is because MATR issues a "COLD /N" command to SpartaDOS X, which deactivates SDX in a different way to turning it off via the Ultimate BIOS menu.

 

The upshot of this is that as long as SDX is enabled in the BIOS menu, even if it won't boot, if you are able to boot the computer using MyDOS, you should be able to use UFLASH. Of course, since UFLASH runs the operating system in RAM, it cannot be used with SpartaDOS 3.x and RealDOS (nor with SDX when using OSRAM). Trouble is, if SDX is enabled in the BIOS but the DOS boot bank is corrupted, the computer will likely just hang anyway.

 

The flashing situation will be further simplified when Candle completes an update to the SIDE loader, which will allow UFLASH to read ROMs direct from the FAT. You'll then be able to drop the tool and all the large ROMs you want into a FAT partition and run UFLASH right from the SIDE loader.

Edited by flashjazzcat
Link to comment
Share on other sites

Yes, well whatever tickles your funny-bone, but the tool does rely on a reasonably recent BIOS in order to recognize the hardware automatically. If one is absolutely determined to find a fault in the program, I guess this fits the bill. :D But hopefully a one-time BIOS upgrade isn't too much of an inconvenience, nor the three extra keystrokes required to manually select the hardware type. :)

Link to comment
Share on other sites

Yes, well whatever tickles your funny-bone, but the tool does rely on a reasonably recent BIOS in order to recognize the hardware automatically. If one is absolutely determined to find a fault in the program, I guess this fits the bill. :D But hopefully a one-time BIOS upgrade isn't too much of an inconvenience, nor the three extra keystrokes required to manually select the hardware type. :)

I'm and absolute U1MB noob and have some maybe really silly questions:

 

I have this old U1MB from the first batch with the original CPLD logic (which I don't plan to update anytime soon as I neither have a SIDE cart nor a 2mm IDC JTAG connector).

 

Is it safe to update to the current BIOS using uflash and then use uflash to update the various OS slots? I want to be sure that I don't brick my U1MB.

 

Another question: If I manage to brick SDX to a point where the Atari won't boot with SDX enabled or brick all OS slots I'm kind of lost (can't use uflash anymore), right?

 

If that's the case, I'd have a small feature request: could you maybe build a stripped-down flasher without any bells and whistles that just flashes a rescue image (BIOS, a stock OS, SDX) from, lets say, D1: over SIO and include that in the BIOS? No need to customize things at this point, keep it simple, just a small tool to debrick the U1MB.

 

so long,

 

Hias

Link to comment
Share on other sites

I have this old U1MB from the first batch with the original CPLD logic (which I don't plan to update anytime soon as I neither have a SIDE cart nor a 2mm IDC JTAG connector).

 

Is it safe to update to the current BIOS using uflash and then use uflash to update the various OS slots? I want to be sure that I don't brick my U1MB.

AFAIK, the main BIOS works just fine without the PBI logic in the CPLD. Maybe Candle can confirm?

 

Another question: If I manage to brick SDX to a point where the Atari won't boot with SDX enabled or brick all OS slots I'm kind of lost (can't use uflash anymore), right?

Yes. If you wreck the main BIOS, it's also bricked.

 

If that's the case, I'd have a small feature request: could you maybe build a stripped-down flasher without any bells and whistles that just flashes a rescue image (BIOS, a stock OS, SDX) from, lets say, D1: over SIO and include that in the BIOS? No need to customize things at this point, keep it simple, just a small tool to debrick the U1MB.

Yes: a recovery tool sounds like a sensible idea. Fortunately it's envisaged that main BIOS (and PBI) flashes are rare, and since you also have four OS slots, it should now be relatively difficult to brick the device. I've been using the tool day in, day out, for over a month now on five different machines and haven't bricked anything yet, but nevertheless, it's sensible to have contingency measures at the ready. ;)

Edited by flashjazzcat
Link to comment
Share on other sites

AFAIK, the main BIOS works just fine without the PBI logic in the CPLD. Maybe Candle can confirm?

Thanks for the info, I'll wait for some definitive confirmation or until I have a plan B.

 

Yes: a recovery tool sounds like a sensible idea. Fortunately it's envisaged that main BIOS (and PBI) flashes are rare, and since you also have four OS slots, it should now be relatively difficult to brick the device. I've been using the tool day in, day out, for over a month now on five different machines and haven't bricked anything yet, but nevertheless, it's sensible to have contingency measures at the ready. ;)

I'm quite sure that your software is safe and sound and works 100% reliably. But, as we all know, we must not forget rule number one of software engineering: never underestimate the creativity (or stupidity) of the users, and never ever forget about the powers of our good old friend Murphy :)

 

From time to time I manage to screw things up really badly, and in these (rare) occasions it's nice to have some plan B to get things back up and running.

 

Speaking of a plan B: what are the minimum system requirements of your flasher? Would it work on a 48k system with Rev. B OS and no mathpack and basic? I can imagine updating a 16k OS slot in a flash with 64k blocksize needs some RAM buffer...

 

If such an environment would be OK (maybe for a minimal recovery flasher), debricking an U1MB (even if the flash is completely erased or trashed) could be done quite easily with a Turbo Freezer:

 

Just toggle the "oldrunner" switch and you have a 48k system with Rev B OS, no mathpack, and a U1MB in unconfigured state. At this point you can do a normal (serial) boot. Not sure what the powerup config of the U1MB is (regarding SDX registers and such), but a proper U1MB config could either be done in the (rescue) flasher or, if this is too late, manually using the freezer debugger (it can intercept the reset vector, so no code of any OS/flash/cart will be executed after powerup).

 

What do you think?

 

so long,

 

Hias

Link to comment
Share on other sites

Yes, well whatever tickles your funny-bone, but the tool does rely on a reasonably recent BIOS in order to recognize the hardware automatically. If one is absolutely determined to find a fault in the program, I guess this fits the bill. :D But hopefully a one-time BIOS upgrade isn't too much of an inconvenience, nor the three extra keystrokes required to manually select the hardware type. :)

 

Gee man!, I thought you had at least a bit of sense of humor... you managed to find something offending in this one liner too... amazing :)

Link to comment
Share on other sites

Thanks for the info, I'll wait for some definitive confirmation or until I have a plan B.

 

 

Hias, if you have a programmer you already have a plan 'B', actually I would say you have a plan 'A', just build a complete ROM image with either Ultimate1MB Rom Builder or Rom Generator and flash the whole thing with your programmer in one shot and you're done in 2 minutes. If you want to mess around with your U1MB later for other reasons you could do so with the in-place flasher and you would already have a complete backup ROM in case Murphy raises his ugly head... :)

Edited by atari8warez
Link to comment
Share on other sites

But, as we all know, we must not forget rule number one of software engineering: never underestimate the creativity (or stupidity) of the users, and never ever forget about the powers of our good old friend Murphy :)

 

From time to time I manage to screw things up really badly, and in these (rare) occasions it's nice to have some plan B to get things back up and running.

Of course you're quite correct, and while I wait in vain for reports of a repeatable bug (and nobody is more surprised than me about this), I get the distinct impression that text-mode GUIs and friendly interfaces bring out the lazy in some users, to the extent that they'll run the software on a machine which lacks the required upgrades. :)

 

Moreover, as the developer, I am not beyond remarkable feats of user stupidity, even when using my own software. So I can heartily agree with the need for tools to compensate for the human condition.

 

Speaking of a plan B: what are the minimum system requirements of your flasher? Would it work on a 48k system with Rev. B OS and no mathpack and basic? I can imagine updating a 16k OS slot in a flash with 64k blocksize needs some RAM buffer...

You imagine right. The design of the flasher depends entirely on the presence of extended RAM, since such memory is always present (or available, at least) on the target hardware. It also depends on reading all of the ROM data to be flashed into extended RAM prior to the update, since DOS (assuming SDX) might well be obliterated by the flash; same goes for the OS which - although used sparingly (and there are no FP calls) - is run in RAM (as per the Incognito BIOS flasher which Candle usefully showed me a couple of months back).

 

If such an environment would be OK (maybe for a minimal recovery flasher), debricking an U1MB (even if the flash is completely erased or trashed) could be done quite easily with a Turbo Freezer:

 

Just toggle the "oldrunner" switch and you have a 48k system with Rev B OS, no mathpack, and a U1MB in unconfigured state. At this point you can do a normal (serial) boot. Not sure what the powerup config of the U1MB is (regarding SDX registers and such), but a proper U1MB config could either be done in the (rescue) flasher or, if this is too late, manually using the freezer debugger (it can intercept the reset vector, so no code of any OS/flash/cart will be executed after powerup).

Interesting. I think I'll speak to Candle about this at length, since the BIOS is his department and he'll be able to explain the minimal conditions to run - say - a bootable recovery flasher or diagnostic cart.

 

Gee man!, I thought you had at least a bit of sense of humor... you managed to find something offending in this one liner too... amazing :)

I'm laughing on the inside. At least with via your use of the term "one liner" you have confirmed my suspicions.

 

Hias, if you have a programmer you already have a plan 'B', actually I would say you have a plan 'A', just build a complete ROM image with either Ultimate1MB Rom Builder or Rom Generator and flash the whole thing with your programmer in one shot and you're done in 2 minutes. If you want to mess around with your U1MB later for other reasons you could do so with the in-place flasher and you would already have a complete backup ROM in case Murphy raises his ugly head... :)

Clearly Murphy has just raised his head. I think Hias is asking for an in-place recovery solution which doesn't require external equipment; otherwise, I imagine he has the wherewithal to appreciate that the device can be recovered with any old valid ROM image and a USB programmer. If a back-up image of the chip content is required, you can use uflash to dump the entire ROM to disk. If you use one of the other mentioned tools to prepare the ROM on the PC and then amend slots in situ with uflash (or "mess around" with them, as per your contrived attempt at negative advertising), your backup on the PC then unfortunately becomes invalid, unless the mentioned tools have some way of which I'm unaware to remotely reach out to the Atari and retrieve the content of the modified ROM.

 

Nevertheless, kudos for the desperate plug. Hope you see the humour in that. ;)

Edited by flashjazzcat
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...