New (alt) BIOS for Ultimate 1MB/Incognito

[Roydea6]

6 hours ago, flashjazzcat said:

If anyone has time to give this a spin I would appreciate it. I'm not aware of any issues and this firmware is hot off my own 800 here, but I thought it would be useful to have a copy out in the wild while I work on updating the documentation and preparing ROMs for U1MB, SIDE, etc.

 

I spun it some and only problem I found right off was the MOUNT /U D1: option from the older toolkit could not find a drive to dismount, nor did ATRMNT /U

 

[flashjazzcat]

3 hours ago, Roydea6 said:

I spun it some and only problem I found right off was the MOUNT /U D1: option from the older toolkit could not find a drive to dismount, nor did ATRMNT /U

 

No doubt they fail to set DSTATS to the value expected by the latest firmware. I will remember to correct those tools.

[Roydea6]

@flashjazzcat

 

Just a quick query about the FDISK program ..  Under the Properties tab what is the FIRMWARE slot achieve or do for the CF card.

 

[flashjazzcat]

1 hour ago, Roydea6 said:

Under the Properties tab what is the FIRMWARE slot achieve or do for the CF card.

It creates a firmware partition which currently isn't used by anything anywhere. It's there for completeness, though, since there's provision for it in the APT spec. Conceivably, it could be used to store configuration info for host adapters which don't have NVRAM, for example. The implementation is buggy, however, since the firmware partition isn't sorted into the correct position in the partition table. That's fixed in the pending update, which I will hopefully release soon now that a certain individual has taken a break from sending me hair-trigger bug reports about the v.3.02 firmware (all of which turned out to be problems between the chair and the desk). Unfortunately the same individual appears to have no interest in testing the v.3.05 update, but I expect he'll do that some months or years after its release.

[R.Cade]

On 11/17/2019 at 5:48 PM, flashjazzcat said:

 

 

If anyone has time to give this a spin I would appreciate it. I'm not aware of any issues and this firmware is hot off my own 800 here, but I thought it would be useful to have a copy out in the wild while I work on updating the documentation and preparing ROMs for U1MB, SIDE, etc.

 

I updated mine today (updated all 3 BIOS parts included) and had an issue running the "MEGA" ATR images.

 

In the 3.02 BIOS, I can select the menu disk in D1 and one of the MEGA disks in D2, then CTRL-R to boot. Normally, it would show an empty menu, but I could Atari-Reset and "b" again and it would come right up.

 

In this new one, even this does not work anymore and I always get a blank menu. I flashed back to 3.02 and it works again (with the above reset workaround). 

 

Edited March 8, 2020 by R.Cade

[flashjazzcat]

1 hour ago, R.Cade said:

the "MEGA" ATR images

Can you link me to these, and I will have a look to see if I can replicate an issue (I have no idea what the 'mega' ATRs are or where to obtain them). Thanks!

[flashjazzcat]

4 hours ago, R.Cade said:

"MEGA" ATR images

Do you mean these?

If so, I have just attempted to boot DISK1.ATR on an U1MB system and it crashes with both the current pre-release firmware and with firmware 3.02. But your usage case sounds different (mounting a 'menu disk' on D1: which I don't see anywhere in these archives and cataloguing the game disk on D2:).

 

So: if you would link to the content in question or simply upload an example of it, I would appreciate it a lot.

 

PS: top tip. I also downloaded the archive with the individual executable files in directories, and for the most part these run just fine straight from the SIDE Loader (cutting out the rigmarole of the workaround you already described).

Edited March 8, 2020 by flashjazzcat

[R.Cade]

3 hours ago, flashjazzcat said:

Can you link me to these, and I will have a look to see if I can replicate an issue (I have no idea what the 'mega' ATRs are or where to obtain them). Thanks!

Here you go. They are otherwise known as the "Yogi/Jellystone" collection. I've been dragging them around forever.

 

You mount the menu in D1 and one of the game disks in D2 and go.

 

http://www.oldgamesfinder.com/?m=8&q=Yogi's Mega Games 001

 

[flashjazzcat]

19 minutes ago, R.Cade said:

Here you go. They are otherwise known as the "Yogi/Jellystone" collection. I've been dragging them around forever.

 

You mount the menu in D1 and one of the game disks in D2 and go.

 

http://www.oldgamesfinder.com/?m=8&q=Yogi's Mega Games 001

Thanks! I could have looked forever and never found these.

 

Anyway: just tested with the latest firmware on an emulated U1MB machine and it works exactly as you describe with v.3.02. So I'll quickly flash 3.10 to my Incognito 800 and if that works as well, we'll have to assume this was an issue with the beta which has been silently fixed.

 

EDIT: The reason for the workaround is necessary to get the files to appear is that the menu doesn't set the OS boot flag before it attempts to read D2:. On the first reboot, the loader has set a boot drive override (D1:) which causes the unit number to be repeatedly written to DUNIT until the boot phase is finished. The second time you restart the OS, the boot override isn't there, and D2: requests pass through unaltered.

 

I'll see if there's an easy way to overcome this, although it's technically the fault of the loader (despite the fact the software could not have foreseen this situation back in 1996).

Edited March 8, 2020 by flashjazzcat

[flashjazzcat]

OK: I pondered it for a while and decided it's reasonable for the PBI BIOS not to change DUNIT if it is already >1 on entry. The only other side-effect of this I can imagine is if the host OS allows independent boot drive selection, it may override the setting in the BIOS, but it does fix the 'Yogi's Mega Games' loader issue and allows the file catalogue to appear properly on the first reboot direct from the loader. So: no need for the messy workaround.

 

[R.Cade]

Glad I may have been able to help with testing and compatibility in some small way. Many of the games don't work from this collection, but I am sure that is because they just overwrite the loader somehow.

 

Thanks for all your work on this BIOS and porting your SIDE loader to all these different devices. I can't imagine the man hours that have gone into it- it's quite an achievement. 

[R.Cade]

On 3/8/2020 at 3:05 PM, flashjazzcat said:

Do you mean these?

If so, I have just attempted to boot DISK1.ATR on an U1MB system and it crashes with both the current pre-release firmware and with firmware 3.02. But your usage case sounds different (mounting a 'menu disk' on D1: which I don't see anywhere in these archives and cataloguing the game disk on D2:).

 

So: if you would link to the content in question or simply upload an example of it, I would appreciate it a lot.

 

PS: top tip. I also downloaded the archive with the individual executable files in directories, and for the most part these run just fine straight from the SIDE Loader (cutting out the rigmarole of the workaround you already described).

You know, oddly, these 16M images work for me on my 3.02 Incognito, unless the ones I have are different/newer.

 

I chose the first ATR and it has trouble with the hi-speed detection and reads the directory contents wrong, but if you press the number key for the disk (1 in this case) it reloads it all OK and the images mostly work fine after that.

 

[flashjazzcat]

28 minutes ago, R.Cade said:

You know, oddly, these 16M images work for me on my 3.02 Incognito, unless the ones I have are different/newer.

 

I chose the first ATR and it has trouble with the hi-speed detection and reads the directory contents wrong, but if you press the number key for the disk (1 in this case) it reloads it all OK and the images mostly work fine after that.

Yes: now you bring it up again, they do work using the method you describe. I don't know what I was doing the other night, but I can't get random titles to crash the way I could before. Even cataloguing DISK2.ATR on D2: from the menu of DISK1.ATR booted on D1: works, using the workaround you describe.

 

MyPicoDos's high speed SIO needs to be turned off, however (by pressing 'H' on the menu). If HSIO is left enabled (i.e. 'AUTO'), the FAT hosted ATRs are completely bypassed, since the menu is completely bypassing the OS IO routines.

Edited March 12, 2020 by flashjazzcat

[larryleffaovell]

On 3/8/2020 at 8:58 PM, R.Cade said:

Here you go. They are otherwise known as the "Yogi/Jellystone" collection. I've been dragging them around forever.

 

You mount the menu in D1 and one of the game disks in D2 and go.

 

http://www.oldgamesfinder.com/?m=8&q=Yogi's Mega Games 001

 

I'm using the "Yogi's megaimage" collection for years at a real machine and, while rotting at limited curfew, I'm on to re-pack these to Hias' MyPicoDOS-Images (with long filenames, turned off high speed).

While working on disk four, I've found some games that are crashing the machine (Atari800 emulator). Can anybody confirm this? I'd exchange these with working versions, then.

[R.Cade]

1 hour ago, larryleffaovell said:

I'm using the "Yogi's megaimage" collection for years at a real machine and, while rotting at limited curfew, I'm on to re-pack these to Hias' MyPicoDOS-Images (with long filenames, turned off high speed).

While working on disk four, I've found some games that are crashing the machine (Atari800 emulator). Can anybody confirm this? I'd exchange these with working versions, then.

Some of them don't work in some configurations, on some machines and some SIO speed settings. Some need BASIC, some don't. It's a hodge podge. I'm not sure you could redo the set working on all possible configurations, but maybe.

 

The only one I've replaced for sure on mine is Berzerk on disk 1.

[larryleffaovell]

1 hour ago, R.Cade said:

Some of them don't work in some configurations, on some machines and some SIO speed settings. Some need BASIC, some don't. It's a hodge podge. I'm not sure you could redo the set working on all possible configurations, but maybe.

 

The only one I've replaced for sure on mine is Berzerk on disk 1.

Yes, I found some Games that aren't working (not at all or not in PAL) and exchanged them. Will describe them in a changelog. What's wrong with Berzerk, as it's (Yogi original) working here with PAL, NTSC, Coleen and XL - at least with the Atari800 emulator.

[R.Cade]

5 hours ago, larryleffaovell said:

Yes, I found some Games that aren't working (not at all or not in PAL) and exchanged them. Will describe them in a changelog. What's wrong with Berzerk, as it's (Yogi original) working here with PAL, NTSC, Coleen and XL - at least with the Atari800 emulator.

It never booted for me on an XL. Black screen or scrambled...

 

 

[larryleffaovell]

On 4/1/2020 at 8:46 PM, R.Cade said:

It never booted for me on an XL. Black screen or scrambled...

 

 

Finished reorganising this stuff at Yogi's megaimages - Revisited 2k20

[mikro]

Hi,

 

I apologise in advance if this has been discussed or even announced before but nowadays I'm mostly a passive 8-bit user so I don't follow all the news so closely. Basically - I had the U1MB from Lotharek with firmware from 2016. Worked great, had a lot of fun with it. Today I wanted to update it (saw the news somewhere). Everything went smoothly except two QMEG-related issues:

• firmware.atr wont boot with QMEG enabled, regardless of SpartaDOX X option. It isn't mentioned anywhere, I think it should be.
• since I had so old firmware flashed, it seemed like a good idea to reflash everything (it's nice to have SDX from 2020!) however ... I lost my QMEG! For a world I can't remember how it got there in the first place. Was it default and changed sometime during the past years? (I guess replaced by Altirra OS?) Is there some ATR image with all the OSes available? firmware.atr focuses only on SDX versions as far as I can see.

[flashjazzcat]

21 minutes ago, mikro said:

firmware.atr wont boot with QMEG enabled, regardless of SpartaDOX X option. It isn't mentioned anywhere, I think it should be.

When you say 'boot with', what exactly are you expecting to happen? There is no DOS on the disk. You are expected to run the flasher from the SDX command line. Are you saying you cannot access the volume at all under QMeg?

 

I don't really propose to start documenting the peculiarities of third party operating systems. Does the QMeg documentation offer some explanation?

22 minutes ago, mikro said:

I lost my QMEG! For a world I can't remember how it got there in the first place. Was it default and changed sometime during the past years?

I think QMeg was on Candle's original ROM, along with the high-speed SIO patched OS which is no longer needed with my firmware.

24 minutes ago, mikro said:

Is there some ATR image with all the OSes available? firmware.atr focuses only on SDX versions as far as I can see.

There are so many Atari OS revisions and third party operating systems that I don't bother attempting to provide a selection other than the four I considered to be useful. You can flash any 16K OS ROM of your choosing to any of the four OS slots you like. If you don't wish to obliterate your collection of operating systems, best to selectively update the firmware and SDX ROM rather than flashing the entire chip.

 

I guess the QMeg home page hosts a suitable ROM. If you need more guidance, just shout.

[mikro]

7 hours ago, flashjazzcat said:

When you say 'boot with', what exactly are you expecting to happen? There is no DOS on the disk. You are expected to run the flasher from the SDX command line. Are you saying you cannot access the volume at all under QMeg?

Well, it does start with classic Atari ROM, right? So when QMEG offers its replacement, I would assume it still boots. To be honest, I don't know how SDX actually boots, is it some form of cartridge emulation or RAM disk?

 

To me, as an average Atari user, it was very confusing -- I booted the ATR, saw "Error: no DOS" and that was it. So I opened the manual and it said "Enable SDX and it will boot", so I did and it didn't work.

 

I guess I can create an ATR with QMEG on it somehow, just wanted to make sure I'm not going to do something more complicated than needed.

[_The Doctor__]

There is no official QMEG homepage last I knew...

The Qmeg 4, meh, Qmeg 3.2 okay...

What might you be missing since the primary purpose of providing 64+192k(256'quartermeg') is handled by just about any u1m/incognito/newell/rambo uppgrade or past 30 some whatever years about...

I can understand if you have 2nd PIA printer but so much has been yanked in 4 even pia printer won't work... I'm trying to figure on what version you had and why.

Edited June 4, 2020 by _The Doctor__

[mikro]

Actually, my desire to use QMEG is maybe totally anecdotal - I simple love its ability to recover from any state (SELECT+RESET) but sure, this is what U1MB BIOS offers as well (HELP+RESET). Then there's the inverted BASIC option (IIRC this is offered by U1MB BIOS as well) and then finally, its ability to boot from different disk drives with one (ok, two) key strokes.

 

Back in the day I loved to use its built-in ram disk for disk copying as well as its ability to boot from such ramdisk as with normal disk drive. Oh yes, and the built-in monitor for software inspection. So it can be still pretty useful, even with its 256K limitation.

[flashjazzcat]

4 hours ago, mikro said:

Well, it does start with classic Atari ROM, right? So when QMEG offers its replacement, I would assume it still boots. To be honest, I don't know how SDX actually boots, is it some form of cartridge emulation or RAM disk?

I don't really see what the problem is, unless there are significant differences between SDX and QMeg versions. In either case, if things don't work as expected, questions need to be directed at the SDX or QMeg people.

 

Just now, I flashed QMeg 4.4 to the Altirra OS slot in emulation, renamed the slot accordingly, mounted FIRMWARE.ATR on D1:, and booted. SDX came right up and from there it's easy enough to launch UFLASH and perform whatever flashing operations you need to do:

4 hours ago, mikro said:

To me, as an average Atari user, it was very confusing -- I booted the ATR, saw "Error: no DOS" and that was it. So I opened the manual and it said "Enable SDX and it will boot", so I did and it didn't work.

"Error: no DOS" suggests that SDX is disabled or suppressed somehow by the OS. Just use the stock OS to perform the flash update and install and revert to QMeg afterwards, in that case. As said: once current versions of SDX and QMeg are installed, I see no unexpected behaviour whatsoever.

 

If you're an 'average user', it might be best to start with a stock operating system rather than an advanced third-party replacement. The flashing instructions depend on nothing more than the ability of the user to check some settings in the U1MB setup menu, mount the ATR, boot SDX and run a program.

4 hours ago, mikro said:

I guess I can create an ATR with QMEG on it somehow, just wanted to make sure I'm not going to do something more complicated than needed.

Use UFLASH to flash this to one of the OS slots whose contents you don't mind losing, press 'N' to give the slot a suitable name, then CTRL+F to commit the name to flash memory:

qmeg44.zip

Alternatively, if you prefer an older version of QMeg, they are available here:

http://ftp.pigwa.net/stuff/mirror/www.atari.cuprum.com.pl/qmeg.htm

4 hours ago, mikro said:

I simple love its ability to recover from any state (SELECT+RESET) but sure, this is what U1MB BIOS offers as well (HELP+RESET).

Pro tip (which saves reading the manual). This setting gives you an OS coldstart with SELECT+RESET wherever you are at the time.

There's also a boot menu in the U1MB firmware, although this is primarily intended for use with HDD partitions and FAT hosted ATRs (for which you'll need a SIDE2 cartridge, which is a highly recommended companion to U1MB).

Edited June 4, 2020 by flashjazzcat

[mikro]

flashjazzcat, I didn't mean to imply that there is something wrong with your firmware. I just wanted to mention it, in case someone else falls into the same issue. Which seems not reproducible anyway (this leaves me really wondering how on earth is that possible - the only explanation I have is that 2016 FW and/or SDX had some feature missing which prevented SDX from booting with active QMEG).

 

My non-standard approach was due to the fact that I have QMEG active all the time and since there wasn't any warning about it in the manual, I expected it work out of the box, or, to be more precise, be independent on the OS installed.

 

Thank you for your test and detailed response, I really admire what you have done with this beautiful hardware addon.