flashjazzcat Posted December 21, 2018 Author Share Posted December 21, 2018 Am part way through changing the loader's memory layout so that a right-slot or 16K cart which isn't suppressed (which happens only on Incognito machines when the loader is active) is completely avoided by code and data. Even on an U1MB machine, Monkey Wrench II was crashing the loader on exit because the code which re-opens the OS screen editor after the loader re-enables the external cart was in the $8xxx area and the loader ended up jumping into the cart. Code and screen are all at the bottom of RAM now, and the FAT directory buffer extends right up to $7FFF or $9FFF depending on whether immovable RAM is found at $8000. So the loader on both U1MB and Incognito platforms should be immune to every kind of cartridge now. I'll look at the other issue over the weekend. 7 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted December 21, 2018 Share Posted December 21, 2018 (edited) Am part way through changing the loader's memory layout so that a right-slot or 16K cart which isn't suppressed (which happens only on Incognito machines when the loader is active) is completely avoided by code and data. Even on an U1MB machine, Monkey Wrench II was crashing the loader on exit because the code which re-opens the OS screen editor after the loader re-enables the external cart was in the $8xxx area and the loader ended up jumping into the cart. Code and screen are all at the bottom of RAM now, and the FAT directory buffer extends right up to $7FFF or $9FFF depending on whether immovable RAM is found at $8000. So the loader on both U1MB and Incognito platforms should be immune to every kind of cartridge now. I'll look at the other issue over the weekend. Beautiful work there! Please, also consider that one of the reasons this is important, is because, when booting RIGHT carts on the 800-i (under OS-b or upgraded XE OS), a non-contiguos RAM space is created, where $8000-9FFF MAY or MAY not be used (depending if right-cart self disappears), while leaving EMPTY (and writeable) the $A000-BFFF space, and all this with the LEFT-slot still empty!). This WILL NEVER happen on my XLs, unless you insert a Cart that physically ties itself up ONLY to the $8000-$9FFF address space at the XL cart-port, at the expense of eliminating the only available cart slot). Much to contrary / popular belief here, the above case has specific and welcome uses, for sure. And that is one of the reasons on why trying to protect the system's integrity while handling RIGHT-carts is welcome, especially under Incognito. Cheers! Edited December 21, 2018 by Faicuai Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 21, 2018 Author Share Posted December 21, 2018 As mentioned: normal BASIC suppression (inside of the PBI SIO call) works regardless. For the other method to work, I need to move the patch from $9xxx to some place below the cart window, but where neither SDX nor any OS will clobber it between PBI INIT being called and the OS calling CIO to open the screen editor. Suggestions welcome, but not the stack since I believe several custom operating systems already put stuff there. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 26, 2018 Author Share Posted December 26, 2018 OK: here's some beta firmware with the changes I described earlier. See the readme file for details of the changes since the July 2018 release. Basically: The loader's FMS driver (i.e. the thing that lets you access the FAT via D1: when you load an XEX direct from the loader) now supports paths and FAT subdirectories. It supports XIO 44 and 48 (CHDIR get GET CURRENT PATH respectively) in a manner generally consistent with SpartaDOS X. No long directory format or RAW directory access or any of that stuff; only what's needed to get full access to the entire FAT volume via the CIO. The supplied version of UFLASH - if run direct from the loader - supports subdirectories in the file selector (same way it does when run under SpartaDOS X). The BASIC suppression/PBI version notice patch has moved from $8000 to $5000. The presence of right 8K or 16K carts should no longer obstruct management of internal BASIC via the (renamed) 'BASIC State' setting in the main BIOS. Note that the method of BASIC suppression employed to facilitate no-BASIC ATR and HDD boots has not changed. The loader no longer runs code out of $8000-$9FFF. All RAM-based code has been moved towards the bottom of memory and the FAT directory buffer now starts at ~$5000 and extends up to the bottom of ROM, which is to say the loader's own ROM at $A000 or any other ROM at $8000 which can't be suppressed while the loader is active (which is really an Incognito-specific issue, although the U1MB benefits from the change too). There's another tool called 'CLI.XEX' which is a simple shell for testing FAT folder tree navigation when run direct from the loader. Incognito Beta Test 261218.zip Flashed to my own Incognito here without incident. Feedback appreciated. 4 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted December 26, 2018 Share Posted December 26, 2018 (edited) OK: here's some beta firmware with the changes I described earlier. See the readme file for details of the changes since the July 2018 release. Basically: The loader's FMS driver (i.e. the thing that lets you access the FAT via D1: when you load an XEX direct from the loader) now supports paths and FAT subdirectories. It supports XIO 44 and 48 (CHDIR get GET CURRENT PATH respectively) in a manner generally consistent with SpartaDOS X. No long directory format or RAW directory access or any of that stuff; only what's needed to get full access to the entire FAT volume via the CIO. The supplied version of UFLASH - if run direct from the loader - supports subdirectories in the file selector (same way it does when run under SpartaDOS X). The BASIC suppression/PBI version notice patch has moved from $8000 to $5000. The presence of right 8K or 16K carts should no longer obstruct management of internal BASIC via the (renamed) 'BASIC State' setting in the main BIOS. Note that the method of BASIC suppression employed to facilitate no-BASIC ATR and HDD boots has not changed. The loader no longer runs code out of $8000-$9FFF. All RAM-based code has been moved towards the bottom of memory and the FAT directory buffer now starts at ~$5000 and extends up to the bottom of ROM, which is to say the loader's own ROM at $A000 or any other ROM at $8000 which can't be suppressed while the loader is active (which is really an Incognito-specific issue, although the U1MB benefits from the change too). There's another tool called 'CLI.XEX' which is a simple shell for testing FAT folder tree navigation when run direct from the loader. Incognito Beta Test 261218.zip Flashed to my own Incognito here without incident. Feedback appreciated. F-Beautiful (!!!) I am returning from short vacations with kids, today, and will be testing over the next 24-48 hours... Based on results, I will seriously consider bringing RIGHT-cart boot-manager extensions for the XL/XE series, as well (e.g. ability to recognize and boot merged 8K+8K images with executable code on $8000-$9FFF space). A HUGE thanks for going the extra mile on what is ALREADY a master-piece!!! It will not go unnoticed... Edited December 26, 2018 by Faicuai 5 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted December 27, 2018 Share Posted December 27, 2018 I have installed it. No visible problems yet. 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 30, 2018 Author Share Posted December 30, 2018 I take it no issues have been found. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 2, 2019 Author Share Posted January 2, 2019 (edited) OK: while testing the firmware revisions with Faicuai's patched OS, I have discovered that Monkey Wrench II - by virtue of the fact the custom OS initialises the right cart - replaces the PBI BIOS display handler patch with its own patch. This is what causes BASIC suppression to fail: the patch the PBI BIOS put in place gets nuked before the OS even opens the display handler. So that particular scenario with that particular cart is a no fix, I'm afraid. Just hold down the Option key. I cannot find acknowledgement of more than half a dozen right cartridges ever existing, although ACE-80 is apparently among them. I imagine ACE-80 patches the handler address table as well and would be similarly unsuitable for testing PBI BIOS BASIC suppression. If anyone has or knows of another 8K right cart image I can use for testing (preferably one which does not modify the handler address table), I would be interested to hear about it. Another thing which occurred to me is that - in the presence of a standard 'left' 8K or 16K cart - the status of internal BASIC is surely of no importance anyway, since the OS will take care of it. And none of this affects the suppression of internal BASIC when launching an ATR or HDD partition from the loader anyway, regardless of whether a cartridge is present or not (since internal BASIC is then suppressed during the disk boot phase). Edited January 2, 2019 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted January 3, 2019 Share Posted January 3, 2019 What about the case of the SpectraView-1 cart? It's 2 chip OSS type cart. It REQUIRES the BASIC chip to be replaced by a custom ROM. The cart depends on the onboard ROM being there. Note: if anyone has a Spec-1 cart, internal ROM, or both, PLEASE DUMP THEM!!! Thanks. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 3, 2019 Author Share Posted January 3, 2019 I'm sure that'll work fine. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2019 Author Share Posted January 5, 2019 I realised the other night that there was no need to disable internal BASIC via the HATABS patch employed for the PBI version notice anyway. The PBI BIOS always gets a crack at the first SIO request regardless of whether any ATRs or hard disk partitions are mounted on the boot drive, so it was sufficient to simply move the BASIC check to the top of the SIO handler. This avoids the awkward issues with Monkey Wrench II. Here's an update (only the PBI BIOS has changed since last time): Incognito Beta Test 050119.zip 7 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted January 5, 2019 Share Posted January 5, 2019 (edited) I realised the other night that there was no need to disable internal BASIC via the HATABS patch employed for the PBI version notice anyway. The PBI BIOS always gets a crack at the first SIO request regardless of whether any ATRs or hard disk partitions are mounted on the boot drive, so it was sufficient to simply move the BASIC check to the top of the SIO handler. This avoids the awkward issues with Monkey Wrench II. Here's an update (only the PBI BIOS has changed since last time): Incognito Beta Test 050119.zip ROMA VICTOR !!! Talk about a sweet and elegant solution!!! It JUST WORKS!!! Monkey Wrench II now boots exactly as INTENDED and just as it does on similar conditions on OS-b (!!!) When flashing revised XE04-RC OS, then inserting right-cart (e.g. Monkey Wrench II), then setting Incognito BIOS to [sDX=OFF, Basic=OFF, PBI=ON, HD=ON] and pressing "B", followed by "D" and (say) "1" (with NO .ATR attached on APT or SIO sides), Monkey Wrench (or ANY other right-cart) now boots beautifully on A800-Incognito, FULLY initialized, with FREE $A000-$BFFF RAM, and WITHOUT Basic ever appearing, UNLESS you command so at Incognito BIOS, only (!!!) We now have FULL, COMPLETE support of LEF+RIGHT cart (or for just ANY right-cart), booting on XL/XE mode under Incognito's advanced BIOS, without compromising ANY functionality originally contemplated on Atari OS nor the BIOS itself. Simply BEAUTIFUL !!! Our work here is now done! Edited January 5, 2019 by Faicuai 8 Quote Link to comment Share on other sites More sharing options...
+mytek Posted January 5, 2019 Share Posted January 5, 2019 Jon does it again . 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 3, 2019 Author Share Posted February 3, 2019 (edited) Well, there were a lot more things which needed changing or fixing than I initially thought, but at last I'm close to releasing a firmware update which might warrant the adjective 'final'. 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 was thinking of renaming the 'ATR Swap Button' setting to 'SIDE Cartridge ROM' and reversing the logic, but I don't know if that would be better or worse. To make the button work, one would then have to disable the cartridge ROM. As it stands, one must disable the cartridge ROM by enabling the button. Really, I think things should have worked this way right from the beginning, but Candle was absolutely adamant that the SIDE cart's ROM should be totally redundant when the PBI HDD is enabled and I just went with the flow. The upshot is that until now, the SIDE loader on the cart would never boot if the PBI HDD was turned on, regardless of the button setting. Users are therefore conditioned to expected operation occurring regardless of the button setting. Imagine running a build of Action!, etc, off the SIDE cart under SDX with your PBI HDD, though. Any thoughts on the naming convention of the button option would be appreciated, anyway. As would any other thoughts on this change. Edited February 3, 2019 by flashjazzcat 9 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2019 Author Share Posted February 5, 2019 I'll take the general air of approval and lack of comment as license to proceed as I see fit. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted February 5, 2019 Share Posted February 5, 2019 LOL, I think the likes help to show some approval of the proposal. Looks to be a winner as most folks love flexibility. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2019 Author Share Posted February 5, 2019 LOL, I think the likes help to show some approval of the proposal. Yes: 'likes' are acknowledged: I'll take the general air of approval... Looks to be a winner as most folks love flexibility. Yes, but I wondered aloud if users (particularly those new to the hardware) would be completely thrown by the change in terminology. I can't tell whether posing the question is likeable, or the idea of confused users is likeable... you see what I mean. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted February 5, 2019 Share Posted February 5, 2019 (edited) I'd say do it, and put a BOLD typeface on such changes in the manual or quick guides. You'd of course have the monotonous task of skimming the documentation and making the appropriate changes and or addition of the notice where appropriate or needed. But it is well worth it. I'd say we would welcome the changes and they are likeable. As to liking confused users, hmmm not a form of schadenfreude I'm into, best to alert them in very clear bold text to pound it into their minds. A bit of retraining for most folks as it were... If anyone does Atascii manuals for all this- Now is the chance to use the INVERSE key! w00t!! Edited February 5, 2019 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2019 Author Share Posted February 5, 2019 OK - thanks. I appreciate the comment. Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted February 5, 2019 Share Posted February 5, 2019 I'm not sure how much use these ATR rotate buttons get in the real world, there aren't may titles that need it and most of those that do are games. I'd change the name of the option to Enable Cart ROM or something similar and reverse the logic. It doesn't make much sense to swap disks when the cart is enabled, any software being run from the cart space (Action! as your example) would allow access to all the drives anyway so why would anyone want to move D2 to D1 etc.? To me it would be obvious that the button would be disabled. 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2019 Author Share Posted February 5, 2019 (edited) The technical reason for the button being disabled when the SIDE ROM is left enabled is that the action of the button (reinstating bank 0 of the SIDE's external cart ROM in order to make the loader re-appear on the next system reset when the cart is used stand-alone) is monitored by the U1MB (which senses the cart ROM's attempt to reappear and sets the swap button flag while suppressing the ROM). This may not be obvious to all, but you're absolutely right in saying that it's just as easy to load up ATRs (or partitions, for that matter) at multiple mount points when using applications which allow access to multiple drives. Moreover, the fact the external loader (assuming the cart hasn't been flashed with some other ROM which allows a disk boot) now prevents the U1MB SDX from booting if the the ATR Swap Button is disabled (or 'SIDE Cart ROM' is enabled) is a pretty strong signifier that a setting needs changing, and doing so will automatically enable the button. Edited February 5, 2019 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted February 5, 2019 Share Posted February 5, 2019 Yeah, you wouldn't expect to boot SDX if you have the SiDE cart rom enabled any more than you would expect SDX to load if you have the ultimate cart inserted. The cart overrides all that functionality, it doesn't make sense for some of it to still work if the rest is disabled. I think its pretty amazing that you can enable ATR loading at all while the internal cart is enabled. I'd be happy with just APT partitions showing up and losing the FAT32 partition of the CF card completely while the Cart ROM is enabled, the fact it _is_ available but the swap button doesn't work is a non-issue. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2019 Author Share Posted February 5, 2019 (edited) SDX will boot just fine if the content of the external SIDE cart ROM allows a disk boot (which the default content - the loader - does not; same as the Ultimate Cart, etc), but yes: I think most users could be expected to make that association. The fact that all this is possible is entirely down to the 8K of code in the PBI handler ROM. Somehow that PBI ROM is still not 100 per cent filled. I don't think being able to re-purpose the SIDE's external cart and use it alongside ATRs and the HDD is that exciting owing to the fact there's not much you can flash to it at the moment, but it's there and I see no reason not to make it available. All we need now is a cartridge with some RAM on it into which the loader can stuff banked cart ROMs before setting the banking scheme in software and then this combo will account for almost every conceivable need all from the same loader menu. Edited February 5, 2019 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 5, 2019 Author Share Posted February 5, 2019 Pending design. Moving the setting here makes room for mystery feature in the HDD menu without requiring menu scrolling. 6 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted February 5, 2019 Share Posted February 5, 2019 I've often thought the menu option that says "SpartaDOS X" on that screen should say "Boot To" and the options should be "SpartaDOS X", "Graphical OS", "Loader", and "None" Adding "Side Cart ROM" would make a logical addition to that option. I've not yet hit a situation where I want any of those options to be enabled at the same time. 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.