Jump to content
IGNORED

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.

 

Link to comment
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
Link to comment
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!

Link to comment
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.

Link to comment
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!

Link to comment
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.

 

Link to comment
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.

Link to comment
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.

 

Link to comment
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.

Link to comment
Share on other sites

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
Link to comment
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.

Link to comment
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.

 

Link to comment
Share on other sites

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
Link to comment
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.

Link to comment
Share on other sites

  • 5 months later...

I finally got around to installing and updating my Ultimate 1MB, and SIDE2 cart.

 

I found one odd thing that I don't know if it is related to @flashjazzcat's firmware (as I had not tested with older firmware), is that SIDE2 with or without U1MB will not load the uav.xex binary that is provided for use in setting up the Ultimate Atari Video upgrade.  I ended up using an Ultimate cart in order to load that XEX.

 

I'm still new to the U1MB, SIDE2, etc so I'm not sure if this is due to the location in RAM/etc where UAV.XEX loads and if that is colliding with something or not, but wanted to see if anyone else ran into this and to let others know in case they try to do the same and it fails.

 

  • Like 2
Link to comment
Share on other sites

40 minutes ago, cwilbar said:

I found one odd thing that I don't know if it is related to @flashjazzcat's firmware (as I had not tested with older firmware), is that SIDE2 with or without U1MB will not load the uav.xex binary that is provided for use in setting up the Ultimate Atari Video upgrade.  I ended up using an Ultimate cart in order to load that XEX.

It appears that the loader is so fast that there is no opportunity for the OS VBI to copy the value $22 from SDMCTL to DMACTL. I think an extra delay after opening the screen editor will allow it to work just fine.

Capture.PNG.3b73bec757b58073eab4f0ce2a3b7784.PNG

The program enters a loop waiting for ANTIC to start firing DLIs, but DMACTL never gets set up properly unless the shadow update code in the VBI has had a chance to run, which it appears it hasn't.

 

Thanks for that!

  • Like 2
Link to comment
Share on other sites

11 hours ago, flashjazzcat said:

I think an extra delay after opening the screen editor will allow it to work just fine.

Which it does. Here's a Release Candidate for U1MB firmware v.3.05 which includes this fix:

U1MB_Firmware_3.05_RC_110120.zip

 

I knew I was procrastinating for some reason. :) If you need the loader for the SIDE cart, let me know, but I expect to release everything in a matter of days anyway.

Edited by flashjazzcat
wrong word
  • Like 3
Link to comment
Share on other sites

On 1/10/2020 at 5:44 PM, flashjazzcat said:

It appears that the loader is so fast that there is no opportunity for the OS VBI to copy the value $22 from SDMCTL to DMACTL. I think an extra delay after opening the screen editor will allow it to work just fine.

Capture.PNG.3b73bec757b58073eab4f0ce2a3b7784.PNG

The program enters a loop waiting for ANTIC to start firing DLIs, but DMACTL never gets set up properly unless the shadow update code in the VBI has had a chance to run, which it appears it hasn't.

 

Thanks for that!

Will there will be new firmware for SIDE2 cart as well as U1MB (as both the U1MB and SIDE2 (when used w/o U1MB) experienced the problem) ?

Not pressing for me, as my SIDE2 is pretty much mostly for my U1MB system (eventually systems ? ).

 

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, cwilbar said:

Will there will be new firmware for SIDE2 cart as well as U1MB

Absolutely!

 

Updates coming for:

 

U1MB (including 1088XEL/XLD)

Incognito (including COLLEEN.SYS driver)

SIDE/SIDE2 (loader and SIDE.SYS driver)

MYIDE/MYIDE2 (MYIDE.SYS and MYIDE2.SYS drivers)

 

Plus updated APT tools (FDISK, etc) and (at last) new APT ROM for the old IDEa interface.

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

@flashjazzcat You have so much great code under your control, so I wondered if you have any provision in place for say, a fire at your house, or worse? Wanted to ask this before, but are you willing to place it on github/gitlab under a permissive license? I'm sure a lot of people would like to contribute! If some of the code makes you money, I understand you want it to stay closed (similar to U1MB, Sophia, etc.. CPLD/FPGA code). But well, one can ask, right? :)

 

Link to comment
Share on other sites

38 minutes ago, ivop said:

You have so much great code under your control, so I wondered if you have any provision in place for say, a fire at your house, or worse?

Yes: it's hosted on an off-site repository so even if there was just a smoking hole in the ground here, there'd still be a recent backup copy. :)

39 minutes ago, ivop said:

Wanted to ask this before, but are you willing to place it on github/gitlab under a permissive license? I'm sure a lot of people would like to contribute!

I wondered if this was about more than redundant backups. :) But no: right now I'm not too interested in open-sourcing everything, to be honest. Aside from the fact the firmware is now sold on commercial products, I have a bit of an ambivalent attitude towards open source in general. Sometimes it can be a really great thing, but too often I have seen projects thrown open only to subsequently sit untouched for years. During my own research, I have stumbled on many promising open source 8-bit projects whose authors lost interest, and rather than being taken up by someone else, the stuff just ended up forgotten.

 

Quite honestly - and this may not be a popular view - I'd rather not see derivative forks right now, either; I created the plugins so that users could add their own functionality, but maybe there's some control-freak stuff going on here too. :) Nearly five years since I first started writing this firmware, it's turned into something of a personal statement. :)

  • Like 7
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...