Jump to content
flashjazzcat

Ultimate 1MB, Incognito, 1088XEL/XLD and SIDE/SIDE2 Firmware Version 3 Released

Recommended Posts

4 minutes ago, Mrarkus said:

Go to U1MB menu via RESET-HELP, L for loader. I attach an ATR image as D1:, then hit CTRL-X. SDX boots and shows D1:, and my AUTOEXEC.BAT on D3: has not executed.

This is because the loader automatically overrides the boot drive when mounting an ATR to D1: since it assumes the OS will need to boot from it. It's always worked this way, but I suppose the presence of the 'Boot SDX' option presents an interesting usage case.

 

You can get around this by jumping back into the BIOS setup menu and restarting the system with 'B' (which nukes the boot override), but that kind of defeats the object. I guess the SDX option should cancel the boot override? Open to suggestions, anyway.

 

Share this post


Link to post
Share on other sites
1 hour ago, flashjazzcat said:

 

Loader Fix.zip 116.91 kB · 3 downloads

 

Only Roy will probably notice the difference, and if he's named all his FAT partitions, even he won't notice anything. But if all is well, I will release updated firmware with this loader this evening. :)

This is helpful for any Altirra setup using U1M and mounted raw dumps made for the even the first test Numbers of years ago.

  • Like 1

Share this post


Link to post
Share on other sites
50 minutes ago, flashjazzcat said:

This is because the loader automatically overrides the boot drive when mounting an ATR to D1: since it assumes the OS will need to boot from it. It's always worked this way, but I suppose the presence of the 'Boot SDX' option presents an interesting usage case.

 

You can get around this by jumping back into the BIOS setup menu and restarting the system with 'B' (which nukes the boot override), but that kind of defeats the object. I guess the SDX option should cancel the boot override? Open to suggestions, anyway.

 

Got it. Personally, I would prefer if the SDX option did cancel the boot override. How often do you actually want to boot from D1: temporarily with SDX enabled? Not a big deal though!

Share this post


Link to post
Share on other sites
58 minutes ago, Mrarkus said:

Got it. Personally, I would prefer if the SDX option did cancel the boot override.

I agree with you. Since it would be messy to try and 'undo' a boot override after the event, I'm wondering if the loader should simply defer issuing a boot override until the moment a (non-SDX) restart is issued. At that point, if a bootable image (ATR or partition) is on D1:, the override could be issued to boot from drive 1 on the pending restart. Meanwhile, if 'Boot SDX' were called, the boot drive would not be changed at all.

 

How does this sound? I'm trying to account for all possible usage scenarios without over-complicating things or causing regressions.

Share this post


Link to post
Share on other sites
41 minutes ago, flashjazzcat said:

I agree with you. Since it would be messy to try and 'undo' a boot override after the event, I'm wondering if the loader should simply defer issuing a boot override until the moment a (non-SDX) restart is issued. At that point, if a bootable image (ATR or partition) is on D1:, the override could be issued to boot from drive 1 on the pending restart. Meanwhile, if 'Boot SDX' were called, the boot drive would not be changed at all.

 

How does this sound? I'm trying to account for all possible usage scenarios without over-complicating things or causing regressions.

That sounds nice and clean to me!

Share this post


Link to post
Share on other sites
10 minutes ago, Mrarkus said:

That sounds nice and clean to me!

I've tested this approach, and it seems to work well. However, it does require a change to the PBI BIOS as well, since the most recent BIOS doesn't actually clear the boot override flag after use. It used to, and I know I changed this behaviour for what appeared to be good reasons, but on balance I think the override should clear after the first reboot. It's certainly necessary to attain the behaviour we're looking for.

 

So: with these changes, a normal loader restart will always set the boot device to D1: if there's a disk image or partition on that drive. 'Boot SDX' doesn't touch the boot drive at all, regardless of what's on D1:. Despite the fact the boot override clears after use, you can still persistently boot images from D1: simply by calling a restart direct from the loader.

 

Share this post


Link to post
Share on other sites

The way it's been working....Isn't that the normal function of sparta x, to use internal car config or the set boot drive config unless you have such files on D1:  ?

making the choice follow the normal method as it has and allow for another option to 'force boot config drive' no matter what.

 

it can get confusing otherwise.

Share this post


Link to post
Share on other sites
7 minutes ago, _The Doctor__ said:

The way it's been working....Isn't that the normal function of sparta x, to use internal car config or the set boot drive config unless you have such files on D1:  ?

SDX looking for CONFIG.SYS on CAR: first before seeking it on disk has nothing to do with what's being discussed. Many people have their SDX boot drive (i.e. CONFIG.SYS) on - for example - D3:, and this is achieved by the PBI BIOS setting DUNIT early in the boot process. But when you jump into the loader and want to boot an ATR on D1:, you probably don't want to have to screw around with the boot drive settings first. For this reason, the loader temporarily forces the system to boot from D1:. @Mrarkus observed that this isn't necessarily what one wants when using ATRs with SDX, particularly when explicitly exiting the loader via the 'Boot SDX' option. That's what I'm attempting to address.

 

Share this post


Link to post
Share on other sites

I use that function on side cart and the apt boot selected drive, I use what's loaded in drive 1 sometimes to override what I set in apt. how is that any different.

It is understandable if you choose boot sdx while exiting the loader that the drive unit should revert back to the choice Dwhatever: you set in your bios or in boot drive settings from within the apt/fdisk software. Is the BIOS toggle also writing the boot drive selection to the storage device for use by your software?

Most of this sounded like we are on the same page, and since sparta looking to config off whatever disk unit presented is at the heart of this, whether your bios or any other software/device alters such, is at the heart of how you might consider when and how you set the drive unit.

 

That's why I wondered why it didn't put the drive unit back, but could see how it could be useful that it doesn't. Making me thing a strict override or enforcement of BIOS set drive unit might be cool. What is currently considered an undesired result could be a desirable and useful thing. That's why I thought keep, name it whatever you wish that makes sense, and add the correction as main choice as that is the expected behavior.

 

I understand It's not written in a way pleasing, and least of of all as it's coming from me. But it's useful. I understand a person could just change it each and every time and choose which drive. But it looks to be a convenience issue. Doesn't really matter. If you fix it, the extra step is just fine as well.

Share this post


Link to post
Share on other sites
Posted (edited)
22 minutes ago, _The Doctor__ said:

Is the BIOS toggle also writing the boot drive selection to the storage device for use by your software?

No. The 'B' (boot) flag which may be applied to one partition, in the partition table, via FDISK is ignored unless you disable SDX while the 'Boot drive' is set to 'APT'. This is an iota more flexible than the IDE Plus, which ignores the boot flag in the partition table at all times.

 

22 minutes ago, _The Doctor__ said:

Most of this sounded like we are on the same page, and since sparta looking to config off whatever disk unit presented is at the heart of this, whether your bios or any other software/device alters such, is at the heart of how you might consider when and how you set the drive unit.

The precedence of CAR: over the mass storage device with regard to CONFIG.SYS doesn't really have anything to do with the matter Mrarkus brought up. For the purposes of the discussion, we're assuming the user has a custom CONFIG.SYS on a hard disk partition; the same partition referenced in the 'CONFIG.SYS' BIOS setting. He therefore expects CONFIG.SYS to be read from the specified drive every time he explicitly boots SpartaDOS X, regardless of whether he's also using disk images on other drives. It's as simple as that.

 

I really don't mind where observations or suggestions emanate from, how aesthetically pleasing the prose, nor who writes it, but I'm having difficulty understanding exactly what course of action you're suggesting. Currently the loader only sets a boot override when one actually mounts a volume, but the override is not cleared until one re-saves the BIOS configuration, refreshes the partition table, or power-cycles the machine. On reflection this seems a little counter-intuitive, since mounting an ATR, then later rebooting from the BIOS menu will still boot from the 'override' device, regardless of what the BIOS settings say. My suggestion is that the boot override should clear after first use, and that the override should only be put in place when the user reboots from the loader. If the user chooses 'Boot SDX' from the loader, no override should be issued. Meanwhile, if the user wishes to boot currently mounted ATRs a second time from a boot device which differs from the 'Boot Drive' setting in the BIOS, he need simply launch the loader and press CTRL+R.

 

I'm not suggesting any of this is obvious or especially easy to design, which is why I appreciate different points of view. The IDE Plus avoids a lot of complexity by completely shutting off access to all hard disk partitions when mounting disk images. The drawback of that is, of course, that you can't copy data between ATRs and APT partitions and vice-versa. With U1MB/SIDE, you can, but we have to deal with the extra complexity (from a design perspective) that comes with the extra flexibility.

 

Edited by flashjazzcat

Share this post


Link to post
Share on other sites
6 minutes ago, lemiel said:

Is U1MB now safe when flashing SIDE (1) ?http://www.atari.org.pl/forum/viewtopic.php?pid=251738#p251738

No. I shelved the idea of making UFLASH use the external SIDE banking register with the high order banking bit negated since it proved to be a bloody nightmare. If it was such a good idea, I guess the DLT flashers would already do it. :)

 

You should still use the latest UFLASH supplied with the new firmware, however, since it ensures that incompatible BIOS plugins cannot be installed.

Share this post


Link to post
Share on other sites
On ‎7‎/‎19‎/‎2019 at 3:11 PM, flashjazzcat said:

This thread will cover any installation and usability issues, and discussion of any further updates and fixes. Documentation has also been heavily revised, and we have the exciting prospect of ebiguy's excellent OSS language cart conversions for SIDE/SIDE2

Which one of the Side Oss roms should I use the Altirra Emulator.  Right now I get a crash or Not Present dialogue.

 

Share this post


Link to post
Share on other sites
Posted (edited)
12 minutes ago, rdea6 said:

Which one of the Side Oss roms should I use the Altirra Emulator.  Right now I get a crash or Not Present dialogue.

The emulator expects the full 512K image, so use SIDEOSS.ROM if emulating SIDE, and SIDE2OSS.ROM if emulating SIDE2. If no U1MB is present, just boot the cart in SDX mode and run SIDECFG.XEX to select the OSS cart, which you'll then enter from SDX via the CAR command. Works fine alongside the SIDE.SYS driver.

 

If U1MB is present, put the cart in loader mode as usual, enable the PBI BIOS, disable the ATR swap button and ensure 'SIDE Cart ROM' is enabled on the first page of the setup menu. Again, use SIDECFG.XEX to select the desired OSS cart. Works alongside the SIDE hard disk, ATRs, etc, regardless of whether SDX is enabled or not.

 

Note: the firmware doesn't bring the cart ROM back if it's been suppressed, so if you get 'Cartridge not present', power-cycle the machine and everything will appear.

Edited by flashjazzcat
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
On ‎7‎/‎23‎/‎2019 at 5:15 AM, flashjazzcat said:

The emulator expects the full 512K image, so use SIDEOSS.ROM if emulating SIDE, and SIDE2OSS.ROM if emulating SIDE2. If no U1MB is present, just boot the cart in SDX mode and run SIDECFG.XEX to select the OSS cart, which you'll then enter from SDX via the CAR command. Works fine alongside the SIDE.SYS driver.

I found my problem with my settings.  I had previously used the SDXuser Editor on the SIDE2OSS.ROM and destroyed it so I the got the original from the zip file and now all is better.  Now I need to get my user files back on the CAR: by adding the files to SDXside2.rom and appending the OSS.ROM to make a new SIDE2OSS.ROM.

Share this post


Link to post
Share on other sites

Yeah: don't use full 512K images in the SDX Imaging Tool. They will be mangled.

 

Will be releasing another update soon, fixing the bugs in loader v.3.00 and a couple of issues with enhanced density ATR handling.

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...