Jump to content
IGNORED

New (alt) BIOS for Ultimate 1MB/Incognito


Recommended Posts

One thing which will hopefully be considered an improvement, at least in terms of flexibility, is the ability to use the ROM of the SIDE/SIDE2 cartridge alongside the U1MB PBI hard disk. This will be at the expense of the ATR swap button (which still works just the same when the external cartridge is turned off), but will allow the use of the previously redundant 256KB of banked cartridge ROM while the hard disk is in use. Not that there's much to put there yet, but hopefully some conversions will be forthcoming. We'll see.

 

Anyway: the only thing that worries me is that having the ATR Swap Button 'Enabled' is now ESSENTIAL to preventing the SIDE cartridge's loader from booting instead of U1MB's SDX ROM or a disk-based DOS on a partition. Leaving the swap button disabled has never previously served any practical purpose whatsoever, since the external cart ROM was always suppressed by the PBI HDD regardless. But now that disabling the button allows whatever is on the cart to boot while the HDD is active, I worry about people becoming hopelessly confused by the fact they must enable the ATR Swap Button in order to stop the loader on the SIDE cart from booting instead of SDX or an attached disk or HDD volume.

 

I do not have a SIDE2 cart, nor do I plan to get one, so none of this has much effect on my system. What I do wonder, though, is if the ATR SWAP changes will have any adverse effects on UNO Cart or Ultimate Cartridge operations?

Link to comment
Share on other sites

 

I do not have a SIDE2 cart, nor do I plan to get one, so none of this has much effect on my system. What I do wonder, though, is if the ATR SWAP changes will have any adverse effects on UNO Cart or Ultimate Cartridge operations?

 

None at all. Unless SIDE2 is connected, the HDD is enabled, and 'SIDE Cart ROM' is set to disabled, all cartridges work 100 per cent normally.

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

On the 1088XEL build there as a short delay in the boot process to allow the keyboard to become enabled before the machine starts up. Would it be possible to have the delay time configurable by the user? I ask because I have a Raspberry Pi0W powering up at the same time and I'd like to get it to start up and be offering drives in RespeQt before the XEL starts looking for the drives.

 

If this time were settable I'd put some effort into getting the pi to boot as fast as possible, which is apparently something like ~4 seconds. To me, a ~4 second delay would be fine but I know I'm in the minority.

Link to comment
Share on other sites

On the 1088XEL build there as a short delay in the boot process to allow the keyboard to become enabled before the machine starts up. Would it be possible to have the delay time configurable by the user? I ask because I have a Raspberry Pi0W powering up at the same time and I'd like to get it to start up and be offering drives in RespeQt before the XEL starts looking for the drives.

 

If this time were settable I'd put some effort into getting the pi to boot as fast as possible, which is apparently something like ~4 seconds. To me, a ~4 second delay would be fine but I know I'm in the minority.

 

The existing delay appears to be in the ~4s range and if you enable the splash screen, it's ~7s between power-on and OS boot. Surely this is more than adequate?

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

 

The existing delay appears to be in the ~4s range and if you enable the splash screen, it's ~7s between power-on and OS boot. Surely this is more than adequate?

 

Well, whether it turned out to be adequate or not, I have added further control to the splash screen. Now it's possible to have it display only at power-up, so it may be used to prolong the power-on delay without getting in the way later on. Of course the option to display it at every BIOS restart or not display it at all remains.

 

Apologies for the delay with the U1MB/SIDE/Incognito firmware update in general. The time seemed right to make major improvements to the loader as more ideas suggested themselves, and although space was limited and there was some indecision over what should go in, I am reasonably happy with the result. And I have other neglected projects - both old and new - to focus on. :)

 

In any case: simply testing everything and preparing it for upload will take long enough, so please bear with me.

  • Like 9
Link to comment
Share on other sites

Well, whether it turned out to be adequate or not, I have added further control to the splash screen. Now it's possible to have it display only at power-up, so it may be used to prolong the power-on delay without getting in the way later on. Of course the option to display it at every BIOS restart or not display it at all remains.

Apologies; I haven't had time to build a fast booting Pi and mess with timing to see how long it takes to get from power on to RespecQT enabled, I have a few other projects I am working on which have taken up my time. You are correct (as ever) the delay as it stands is longer than 4 seconds so should be sufficient but RespecQT requires a working X environment, which potentially adds significantly to the boot time. A headless RespecQT with a web interface would be a much quicker proposition but that isn't currently available.

 

I totally understand the delays, too many projects, too little time. I'm interested to see what features you have decided to add to the loader!

Link to comment
Share on other sites

Quick question - thought I would put it here as opposed to private.

 

Is there any reason we would not use Sparta 449c now?

 

Also Jon, no pressure at all. Why would I want to use the different size builds? Nothing soon down the pipe with the GUI correct? So why or what would I use the 192 vers the others at the moment?

 

James

Link to comment
Share on other sites

Is there any reason we would not use Sparta 449c now?

None at all as far as I'm concerned. There has been some FUD reported concerning strange behaviour with disk IO, but I've observed or experienced no issues whatsoever using 4.49c for some two years or however long it's been around.

 

Why would I want to use the different size builds? Nothing soon down the pipe with the GUI correct? So why or what would I use the 192 vers the others at the moment?

The GUI pipe is a long one, and there is stuff down the other end of it, but unless you want to play with the demo, there's no particular reason not to go for a 320K SDX ROM instead. Personally I can't see a practical reason for filling up 320K on the CAR: volume (and nor would I want to become dependent on such a large CAR: device, since it intrudes on space I will use for the GOS), so it makes no immediate difference either way to me, but your mileage may vary.

 

Regarding the firmware update: I have now finished amendments to the loader, and all that remains is to finish testing and evaluate the final Incognito and 1088XEL/XLD firmwares on real hardware. Unfortunately my most heroic tester has been otherwise occupied of late, and so many changes have been made since he last had hands on the loader, I am again reluctant to hurry the release. But documentation is finished and I imagine the filming of a few tips-and-tricks videos will be a useful means of uncovering any issues. A couple of people have volunteered to do some testing in the meantime, and if anyone else wishes to join them, they should send me a PM.

 

  • Like 5
Link to comment
Share on other sites

  • 2 weeks later...

Anyone having problems running the S_VBXE driver with the July 2018 U1MB firmware update on a Rapidus/VBXE machine? One user reported the driver failing to detect the FX core, and I was able to reproduce and fix the issue on my own Rapidus machine. However, the fix apparently doesn't work on the machine belonging to the use who reported the problem. I'm therefore interested to know if anyone else experienced the issue, since the problem was only just reported some nine months after the firmware was released.

Link to comment
Share on other sites

OK: After four days, I'll take this as a) No-one here runs Rapidus with the July 2018 U1MB firmware, or b) they do, but there was no problem. :)

 

I am keen to hear from owners of Rapidus/U1MB/VBXE equipped machines who would be willing to test the forthcoming update and establish if any (apparently rare) issues with software attempting to detect the VBXE FX core have been properly dealt with. Right now I have one complaint received nine months after the firmware was released, and one reproducible issue on my own hardware which was fixed with a simple code change. However, the person who reported the issue is no further forward with things yet.

 

Unfortunately I can't release the new update until I know one way or another whether my fix is universally effective.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

I received my CF card from Lotharek today and finally started up my SIDE II.

From what I see the ATR emulation from the SIDE loader works fine and requires the PBI BIOS being active.

Thanks to all involved parties, U1MB and SIDE II is a great combination.

But when PBI BIOS is active, I see all format commands to real drives on the SIO fail with error 138 after just a few seconds.
Could it be that there is a bug in the PBI BIOS? The regular OS sets longer timeouts for the format SIO command than form normal sectors.

Link to comment
Share on other sites

I received my CF card from Lotharek today and finally started up my SIDE II.

From what I see the ATR emulation from the SIDE loader works fine and requires the PBI BIOS being active.

Thanks to all involved parties, U1MB and SIDE II is a great combination.

But when PBI BIOS is active, I see all format commands to real drives on the SIO fail with error 138 after just a few seconds.

Could it be that there is a bug in the PBI BIOS? The regular OS sets longer timeouts for the format SIO command than form normal sectors.

 

Curious as to what firmware you are running?

Link to comment
Share on other sites

I can't get the Tempest Xtreem .XEX demo to run (http://www.atarimania.com/game-atari-400-800-xl-xe-tempest-xtreem_23225.html). When I press Return, the screen clears, there's a quick flash, then back to clear screen. It ran with the firmware that was originally on the SIDE2 (Lotharek, white PCB) and U1MB (black PCB). Currently using SIDE Loader v2 230718 and U1MB v2 250718 firmware. Anyone able to get it to run with the new firmware?

 

Also, the file list seems to be filtering by file type. Sometimes I remember folders being non-empty when copying files from the PC but it shows up as empty on the Atari. Would it be possible to toggle this off so that I can see all of the files and possibly force a file to load, or somehow indicate that there are more files than being currently shown so I know it's not a CF compatibility issue?

Edited by wt808
Link to comment
Share on other sites

I received my CF card from Lotharek today and finally started up my SIDE II.

From what I see the ATR emulation from the SIDE loader works fine and requires the PBI BIOS being active.

Thanks to all involved parties, U1MB and SIDE II is a great combination.

But when PBI BIOS is active, I see all format commands to real drives on the SIO fail with error 138 after just a few seconds.

Could it be that there is a bug in the PBI BIOS? The regular OS sets longer timeouts for the format SIO command than form normal sectors.

 

FWIW, with the PBI BIOS active as my usual practice, I just formatted double-density floppies in two different Happy 1050's configured as D1: and D2:, then copied over files from an APT partition mounted as D7: to both floppies. No issues on either drive, either formatting or writing the files to the floppy disks.

Link to comment
Share on other sites

I can't get the Tempest Xtreem .XEX demo to run (http://www.atarimania.com/game-atari-400-800-xl-xe-tempest-xtreem_23225.html). When I press Return, the screen clears, there's a quick flash, then back to clear screen. It ran with the firmware that was originally on the SIDE2 (Lotharek, white PCB) and U1MB (black PCB). Currently using SIDE Loader v2 230718 and U1MB v2 250718 firmware. Anyone able to get it to run with the new firmware?

It works with the pre-release firmware which will be released shortly. Likely the demo does something inadviseable and luck is what allows it to run with the original loader. The latest loader is more compatible with poorly-behaved software, however (the Bash! demo being another example, which only worked with the original loader by virtue of it loading the executable more slowly than mine; Bash! works with the latest version as well).

 

Also, the file list seems to be filtering by file type. Sometimes I remember folders being non-empty when copying files from the PC but it shows up as empty on the Atari. Would it be possible to toggle this off so that I can see all of the files and possibly force a file to load, or somehow indicate that there are more files than being currently shown so I know it's not a CF compatibility issue?

I'd prefer not to, since there's a limit to how many filenames can be stored in the buffer at one time (250, to be exact), and displaying content which the loader can't do anything with is just going to clutter things up. You're not going to be forcing anything to load, either, if its file extension isn't XEX, EXE or COM. If it's a valid executable with a different file extension, you could perhaps rename it.

 

The action the loader performs when RETURN is pressed on a file is also based on the extension of a file, so I wonder what the loader is supposed to do when you press enter on a file of an unrecognised type (i.e. load it or mount it).

 

Longer directories are viewable (in segments) in the upcoming version of the loader, and if a more compelling argument for the listing of unregistered file types is presented, I might perhaps change my mind, but with eight bytes of code space left and (I has assumed) a few days remaining until I intend to release the version which will deal with your other complaint, it would have to be a good one. :)

 

Ironically, the first version of my loader (back in 2015) actually listed ATR files greyed out when the host machine had no U1MB (and thus no means of mounting ATRs), and this approach was met with general disapproval from users on the grounds that it would be better not to display content which cannot be acted upon. I changed it, and that the was the last I ever heard of the matter.

 

FWIW, with the PBI BIOS active as my usual practice, I just formatted double-density floppies in two different Happy 1050's configured as D1: and D2:, then copied over files from an APT partition mounted as D7: to both floppies. No issues on either drive, either formatting or writing the files to the floppy disks.

I'm still unclear from Peter's original query whether formats are actually failing or whether they work but he simply objects to the length of the timeout. The high-speed SIO driver is an extremely faithful implementation of Hias' code, and I don't recall timeouts being adjusted according to the SIO command or the format command being treated differently to any other.

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

I'm still unclear from Peter's original query whether formats are actually failing or whether they work but he simply objects to the length of the timeout. The high-speed SIO driver is an extremely faithful implementation of Hias' code, and I don't recall timeouts being adjusted according to the SIO command or the format command being treated differently to any other.

 

Well, he said the format operations fail, so ...? Anyway, nothing failing here with real floppies as the SIO device in question.

 

I've had some weird issues with RespeQt lately but since I've been using the ebiguy/Josch fork that adds Happy/Archiver and enhanced printer support, I haven't been willing to try narrowing things down beyond that. With the stock RespeQt R4, I've not had any issues at all.

Link to comment
Share on other sites

Well, he said the format operations fail, so ...? Anyway, nothing failing here with real floppies as the SIO device in question.

Yes: he said they 'fail with error 138 after just a few seconds', and it was impossible for me to tell from that whether he had deliberately left the media out of the drive in order to test error conditions and found the timeout to be too short, or whether the formats were failing while disks were present. I'm not sure what difference it makes either way, but hopefully he'll come back and be a little more specific. Currently I have no idea whether he's using recent or aged firmware (bearing in mind I wrote the PBI BIOS about eight years ago and have released about a dozen versions of it since then). Fortunately everything is clearly versioned. :)

 

I've had some weird issues with RespeQt lately but since I've been using the ebiguy/Josch fork that adds Happy/Archiver and enhanced printer support, I haven't been willing to try narrowing things down beyond that. With the stock RespeQt R4, I've not had any issues at all.

I've been a bit remiss in not testing the latest RespeQt versions, but I promised to rectify that soon. I've been using r4 (can't be more specific than that, since that's all it says) for a long time at divisor 0 and have had no problems with communications in either direction. I don't use SIO2SD or real disk drives much any more, though, so maybe the reported issue concerns different hardware (again: who knows at the moment).

 

I can say that the PBI HSIO implementation hasn't changed for two years or so (basically since SIO2BT support was added), so the entire user base would have to have been wearing blinkers for some fundamental problem to have been overlooked (of course this is entirely possible). :D

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

Sorry for the incomplete information in my initial question.

I've verified the issue with version 2.0 of the BIOS and SIDE loader.

This is what I do:

- PBI BIOS with HISIO is active

- Enter the SIDE Loader

- Configure D1 as regular SIO with a real drive and a DOS 2.5 DUP Disk
- Mount an ATR as D2 and reboot.

- DOS/DUP are booted from D1
- Put a new empty disk into D1
- Use "J - Duplicate Disk" to copy from D2 to D1

- As a first step the target disk is formatted. The format command is sent to the dirive and the drive starts formatting.

- The Atari does not wait for the formatting to end but stop with error 138 after around 10 seconds.

- Note: If I use a SIO2USB drive as D1: formatting is fast enough so the error does not occur. The probably also is true for Happy Drives as formatting works differently there. But it occurs with and standard 1050.

  • Like 1
Link to comment
Share on other sites

Thanks for the detailed info Peter. I can duplicate this odd behaviour, and the strangest thing of all is that it's dependent not on the HSIO driver, but on a FAT-hosted ATR being mounted on a drive number adjacent to that of the drive being formatted. Most peculiar indeed. :)

  • Like 3
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...