New (alt) BIOS for Ultimate 1MB/Incognito

[Kyle22]

I have a Sunrise Z-1000B and a Needham's SA-20 as well as the TL-866. I haven't used the other ones in years. I only power them occasionally to (hopefully) prolong the life of the capacitors. You can't beat the TL-866 for the cost. The only time I would ever need to use those big programmers is if I needed to burn a PAL chip, or read some old EPROM.

[Lumpy01]

So I attempted flashing my Incognito's three roms with FJC's latest release but I always get an invalid file signature error when I do the bios. Also, the OS rom names are garbled in the display. I'm using the Uflash that is included with his latest December release. The other two roms flashed fine. It's just the bios that's giving me a hard time. Any ideas?

 

[morelenmir]

I have a Sunrise Z-1000B and a Needham's SA-20 as well as the TL-866. I haven't used the other ones in years. I only power them occasionally to (hopefully) prolong the life of the capacitors. You can't beat the TL-866 for the cost. The only time I would ever need to use those big programmers is if I needed to burn a PAL chip, or read some old EPROM.

 

I certainly think for most Atari modding needs the 866 is going to do all I will likely ever need doing. Apparently it is very good for auto electronics as well, although I hasten to admit I know absolutely nothing about motorcars!

 

Generally though, one area I would like a bit more coverage is from local support. Even though I bought my - second - unit from a 'local' seller I am pretty sure they were at best a UK shop front for a far-east seller. The one I tried to buy back in July from a different merchant never showed up, although the chap did refund me when I finally got in touch over it. Nonetheless I was still a bit unsure in trying for a second time. Worst of all the manual/help document seems to be only available in Cantonese. I thought this might be an artefact of downloading the online drivers and software, but the distro that came on the mini CDr is also exclusively in foreign characters. All this to one side though, I am very happy with this device - especially after cross-flashing. I just wish I could read up on it and learn how it properly works!

 

In regards advice for the Ultimate1MB/Incognito flashing issues that people seem to be experiencing at the moment; I have two new, blank eprom IC's which can be had for just under £1 each from Farnel and many others I suspect. My current work-flow is to update an Altirra emulation with FJC's newest releases and then save the completed 512kB BIOS firmware as a file. I then use the 866 to flash this image to the eprom and swap it out with the IC currently in service. That way not only am I largely proof from any future bricking incidents, but I spread the flash wear out over a rolling set of three inexpensive eproms which should greatly prolong their lives. I would recommend something similar for anyone who is looking to stay absolutely up to date.

[Kyle22]

Just don't wear out the sockets

[flashjazzcat]

So I attempted flashing my Incognito's three roms with FJC's latest release but I always get an invalid file signature error when I do the bios. Also, the OS rom names are garbled in the display. I'm using the Uflash that is included with his latest December release. The other two roms flashed fine. It's just the bios that's giving me a hard time. Any ideas?

 

ImageUploadedByTapatalk1452642542.181687.jpg

This looks like a software issue. It's a while since I updated an Incognito from the original BIOS to the new one, but the messed up OS ROMs suggest something got out of sync. It's a headache supporting two generations of BIOS in the same application, and testing the Incognito upgrade process is pretty inconvenient since the device is not emulated.

 

One possibility that jumps out is that your original BIOS is so old it lacks the signature bytes UFLASH needs to sync to the firmware type. Solution there would be to use UFLASH 1.0 to update to the most recent original firmware prior to upgrading to the second generation BIOS.

 

Regarding external programmers: I agree with what Kyle says. You don't want to be pulling and inserting the flash ROM on a routine basis. The Ultimate in my 1200XL took a lot of punishment when I was developing the original PBI BIOS, before UFLASH existed (that's why I wrote it). Since then, the USB programmer has only been required in response to bugs not caught in emulation which result in a non-booting system on the first real hardware test. In place flashing is otherwise pretty routine on five machines (four Ultimate, one Incognito). A USB programmer is a must have for emergencies but should not be required for point BIOS updates. If it is, hardware or software is not where it needs to be.

Edited January 13, 2016 by flashjazzcat

[Lumpy01]

Hey FJC. I was upgrading from your previous 2nd gen release not from the original 1st gen BIOS. That's why I'm so baffled. Uflash managed to flash all three roms perfectly just a couple months ago. Not sure what to do now.

[flashjazzcat]

Well that's even more puzzling. Uflash is not correctly ID'ing your firmware: it thinks it's the original BIOS for some reason.

 

I'll upload a complete 512KB ROM tomorrow which will bypass any signature checks: that should get you back on song.

[Kyle22]

I think that it would be good to start a repository of known good 512K ROM images. This would help the brickers with burners, as well as the Altirra guys.

Please!!! only submit known, working ROMs.

 

Just a thought...

 

[morelenmir]

Just don't wear out the sockets

 

An excellent point - would you believe I was genuinely looking at the ZIF PLCC32's on eBay just after I typed that last post??? Great minds and all that!!! I guess it might be a bit of a pain to rework the Ultimate1MB board, but well worth doing all the same if one is going to need to pop the eprom out regularly.

 

I think that it would be good to start a repository of known good 512K ROM images. This would help the brickers with burners, as well as the Altirra guys.

Please!!! only submit known, working ROMs.

 

Just a thought...

 

 

Also an excellent point!!! I will whip up a working 512kB image tomorrow, free of my idiosyncratic requirements for the SDX User Space and config.sys file. Although - with that said maybe it might be a good thing to have known 'flavours' as it were; a bare ROM with minimal/no custom config, also one for those who have installed an VBXE along with their Ultimate1MB and so on? Just so long as they are clearly labelled and known good on real hardware.

 

 

Regarding external programmers: I agree with what Kyle says. You don't want to be pulling and inserting the flash ROM on a routine basis. The Ultimate in my 1200XL took a lot of punishment when I was developing the original PBI BIOS, before UFLASH existed (that's why I wrote it). Since then, the USB programmer has only been required in response to bugs not caught in emulation which result in a non-booting system on the first real hardware test. In place flashing is otherwise pretty routine on five machines (four Ultimate, one Incognito). A USB programmer is a must have for emergencies but should not be required for point BIOS updates. If it is, hardware or software is not where it needs to be.

 

I'm going to have to disagree with you on this one FJC. For me it is well worth the potential bother of reworking a ZIF socket to not have to go through three frustrating weeks of bricked machine again. I stand by my recommendation, at least until we know things are absolutely rock solid.

[flashjazzcat]

I'm going to have to disagree with you on this one FJC. For me it is well worth the potential bother of reworking a ZIF socket to not have to go through three frustrating weeks of bricked machine again. I stand by my recommendation, at least until we know things are absolutely rock solid.

Don't recommend to other users in this thread that it's better to constantly pull the chip and use a USB programmer than to use an in-place flasher. Anyone not using ZIF sockets will eventually start bending pins on the PLCC or damaging the socket on the Ultimate 1MB. You ran into one bug (as far as I know, the only person who did) which was quickly fixed and eventually recovered by using an external programmer, and if you don't want to acknowledge that the issue you ran into was fixed (or test the software in order to verify the issue is fixed, now that you have a programmer) and prefer to use a programmer 100 per cent of the time, that's your prerogative. But it's not a recommended course of action for flashing BIOS updates.

 

These flash ROMs are also guaranteed for at least 10,000 write cycles, so unless you're updating the BIOS a hundred times a day, there's little practical gain in rotating chips in the manner described.

Edited January 13, 2016 by flashjazzcat

[flashjazzcat]

Hey FJC. I was upgrading from your previous 2nd gen release not from the original 1st gen BIOS. That's why I'm so baffled. Uflash managed to flash all three roms perfectly just a couple months ago. Not sure what to do now.

Here's the ROM content pulled straight from my Incognito:

 

Incognito_ROM_New_BIOS.rom

 

If using UFLASH, put the highlight on the name of the flash ROM (top entry), and then navigate to the ROM file.

 

I think that it would be good to start a repository of known good 512K ROM images. This would help the brickers with burners, as well as the Altirra guys.

The user worried about mishaps might also dump the entire ROM using UFLASH before commencing an update, thereby producing a USB and emulator-friendly backup of what's already on their device.

[morelenmir]

Don't recommend to other users in this thread that it's better to constantly pull the chip and use a USB programmer than to use an in-place flasher. Anyone not using ZIF sockets will eventually start bending pins on the PLCC or damaging the socket on the Ultimate 1MB. You ran into one bug (as far as I know, the only person who did) which was quickly fixed and eventually recovered by using an external programmer, and if you don't want to acknowledge that the issue you ran into was fixed (or test the software in order to verify the issue is fixed, now that you have a programmer) and prefer to use a programmer 100 per cent of the time, that's your prerogative. But it's not a recommended course of action for flashing BIOS updates.

 

I am glad I was the only user who suffered a bricked machine.

 

I have thanked you, sincerely Jon for every release you have made - the many ones that came before the bug, the ones that corrected it and the ones which added features afterwards. I'll thank you again here for all the work you do and still mean it profusely.

 

I stand by what I have said and I don't think there is anything more I can add without reading as argumentative.

[flashjazzcat]

Good. Hopefully common sense prevails.

[morelenmir]

Good. Hopefully common sense prevails.

 

Never take that bet old son!!! :)

[flashjazzcat]

I am glad I was the only user who suffered a bricked machine.

Likely because the bug only surfaced after a system reset and ONLY if the SIDE HDD was in use, so it was still possible to power up the machine and perform a perfectly safe update. Presumably this is the same reason the issue went unreported for several months despite the firmware being in widespread use.

Edited January 13, 2016 by flashjazzcat

[morelenmir]

Likely because the bug only surfaced after a system reset and ONLY if the SIDE HDD was in use, so it was still possible to power up the machine and perform a perfectly safe update. Presumably this is the same reason the issue went unreported for several months despite the firmware being in widespread use.

 

Yeah, the very specific order of operations required to manifest the bug only became likely - for me at least - when using the new SIDELoader because MATR did not require the intervening soft-reset.

 

This is quite similar to how the bug in the famous 'Therac25' case-study became apparent. Not the bug itself obviously, but the way you needed to have a very specific and to some extent unlikely sequence of events occur before an underlying problem intervened.

[flashjazzcat]

Yep. Don't forget you can hold "L" on powerup to boot directly to the loader.

[morelenmir]

Yep. Don't forget you can hold "L" on powerup to boot directly to the loader.

 

That is good to know! I was wondering if there is any slightly more streamlined way to access the loader and this will certainly answer that in many situations.

 

At the end of the day it would be very nice if the SIDELoader could completely replace the need for a real 1050/etc or SIO2SD. Given it needs to exist in the same system memory as the work you may be doing - in a programming language for instance or other application - will limit just how much of this is possible. I think the sequence of operations necessary to access the SIDELoader and then cold reboot after a new disk image is 'inserted' will probably blank or overwrite the memory occupied by the user's work?

[flashjazzcat]

If you put the splash screen up, the available shortcuts are displayed at the bottom of the screen. They are available regardless of whether the splash screen is shown, however. So you can also boot with Help pressed (or Start, if you changed the hot-key) and go straight to setup, then press "L" which will also start the loader the first time the OS boots (also circumventing the fixed PBI bug).

 

So: the three ways to launch the loader are to press "L" on startup, launch from setup, or set the machine to boot direct to the loader by default.

 

As previously written: if I had around 32KB of ROM space in the main BIOS plus plenty of RAM, the loader could have been integral instead of appearing as a 16KB external cartridge. That'll have to wait for the next generation of all-singing RAM upgrade, however. AFAIK the SIO2SD client tool is also launched as an application (and doesn't reside in RAM as a TSR), so you can't use it to - for example - change mount assignments while using a word processor (although you can control mounts via the buttons on the device in that situation). In any case, it's not especially difficult to work around the various compromises imposed by the hardware, and I would not be without an SIO2xx device (in this case, SIO2PC) to use alongside Ultimate/SIDE.

 

SDX users (as previously written, and described in the documentation) may also use the command-line tool provided to mount 8.3 ATRs in a FAT16 volume from the SDX prompt in a non-destructive manner, requiring no reboot.

 

Oh: and if you have the splash screen on but get bored waiting for it to clear before the OS boots, hit space to get rid of it.

Edited January 13, 2016 by flashjazzcat

[flashjazzcat]

So I attempted flashing my Incognito's three roms with FJC's latest release but I always get an invalid file signature error when I do the bios. Also, the OS rom names are garbled in the display. I'm using the Uflash that is included with his latest December release. The other two roms flashed fine. It's just the bios that's giving me a hard time. Any ideas?

 

ImageUploadedByTapatalk1452642542.181687.jpg

Just looking at your picture there: where's UFLASH's "Options" menu gone? You appear to be using the wrong version of the software, which would explain your troubles. Type "UFLASH.XEX" at the SDX prompt to ensure you're not launching v.1.0 of the flasher (which may reside on the CAR: device). The old version has no concept of the new firmware and while it will flash the PBI BIOS and loader, it will choke on the new main BIOS.

[Wrathchild]

I can agree with FJC's diagnosis as I've seen that too. If just 'UFLASH' is run (without the .XEX extension) then the older version is loaded and this displays the alternative OS slot names as corrupted.

 

A question though, as the UFLASH issue crops up a lot what would be the approach to get the SDX version updated?
Does that need to be included in the next SDX ROM slot release or can the current image be patched and provided here for people to update?

 

I have recently managed to update my Incognito with the latest three files but wanted to highlight an issue I encountered in case that helps anyone else.

 

My approach to performing the upgrade was as follows:

1) Use Altirra's disk explorer utility to open an ATR and place the ROM files downloaded from this thread and UFLASH.XEX to that image.

2) Copy the ATR to an SD Card used in my SIO2SD device, mount to either D1 or D2.

3) Boot the Atari 800 with SDX enabled.

4) Run UFLASH.XEX from the right SIO drive.

5) Move the selection to the correct slot (e.g. PBI BIOS) and then hit enter.

 

This is where I initially had an issue. The file dialog that opens queried the SIO2SD but locked up, i.e. didn't present any files.

No key presses were accepted and so a power off and on again was needed to retry.

Eventually I chose another SIO rate in to SIO2SD settings and this allowed the file list to load and display correctly and I could continue.

 

6) Pick the correct file for the slot you are upgrading and the flash upgrade is performed.

7) Repeat for the other slots and then choose reboot from the UFLASH file menu, but I think a Power Off/On is recommended here just to be sure.

 

Regards,

Mark

Edited January 13, 2016 by Wrathchild

[flashjazzcat]

I can agree with FJC's diagnosis as I've seen that too. If just 'UFLASH' is run (without the .XEX extension) then the older version is loaded and this displays the alternative OS slot names as corrupted.

 

A question though, as the UFLASH issue crops up a lot what would be the approach to get the SDX version updated?

Does that need to be included in the next SDX ROM slot release or can the current image be patched and provided here for people to update?

If I could have foreseen that people would completely disregard the ".XEX" extension of developmental, disk-based versions of UFLASH, I would never have placed it on CAR: in the first place. I'll think carefully about doing so again. In any case, the newer version of UFLASH won't find its way onto CAR: until it's complete (version 1.0 being the only non-beta release so far), and it requires a special build process here (three OVL files and a special loader).

 

This is where I initially had an issue. The file dialog that opens queried the SIO2SD but locked up, i.e. didn't present any files.

No key presses were accepted and so a power off and on again was needed to retry.

Eventually I chose another SIO rate in to SIO2SD settings and this allowed the file list to load and display correctly and I could continue.

The SDX SIO driver appears to cause a lock-up when there's overrun caused by the baud rate being too high. I've experienced this with The Last Word as well, when the NMI which runs the progress bar causes issues with high-speed SIO. SDX includes a tool for setting the NMI threshold (i.e. the baud rate at which NMIs are completely masked during SIO). In any case, it's a DOS issue in this instance, since the flasher uses nothing but standard CIO calls and runs no custom NMIs during SIO.

Edited January 13, 2016 by flashjazzcat

[fujidude]

Me personally, I wouldn't bother having UFLASH in the CAR: device. I would just run it from disk. It's much easier to update a disk based program file than to rebuild a ROM image.

[Roydea6]

I would vote to rename the UFLASH filename to include it's version number ((example) uflash14.xex)).

[flashjazzcat]

I've been doing that with the firmware files (including revision numbers), so it probably wouldn't hurt, despite the fact the flasher changes very infrequently in comparison to the ROMs. Of course it won't help in a various situations, such as when the user gets sick of typing the number and renames the file "UFLASH.COM" and then wonders why the wrong version starts up. The garbage in the ROM slots might offer a clue that something's not right, although it's human nature to place user error at the bottom of the list of possibilities.