New (alt) BIOS for Ultimate 1MB/Incognito

[flashjazzcat]

Much will depend on whether U1MB is even present. Forget about using the HDD with anything other than SDX if not.

 

[rcamp48]

You cannot use the HDD with Forem XE PRO anyways , it disables the Basic XE cart, which is needed for FXEP, you have to disable the HDD, other settings that are OK are the U1MB BIOS, its OK, SDX has to be disabled as well , I do believe there are a couple of other settings when running FXEP, the good news is that you CAN run the full 1 Meg, I wonder if it is worth incorporating a ramdisk into the setup? I was thinking about that.

 

AS for FXEP I will be shifting focus off of it, and onto Wildcat 8, I am getting the Developers package that will give me the plus pack , then I can modify Wildcat 8 to run ATASCII at 40 columns, I guess you do what you know best eh? I will still work on scripting for FXEP but not actually run it constantly, running it has already been done and i see no point on doing that anyways. I can get a working copy up and running for a short time but there is only so much time in the day and I want to focus on Wildcat 8.

 

[rcamp48]

14 minutes ago, flashjazzcat said:

Much will depend on whether U1MB is even present. Forget about using the HDD with anything other than SDX if not.

 

You can however create hard drives within SD 3.2G and have the Fujinet use them as ATRs that are max 16.8 Megs, 8 of them if done right, that is possible I have already done that.

 

[flashjazzcat]

3 minutes ago, rcamp48 said:

You can however create hard drives within SD 3.2G and have the Fujinet use them as ATRs that are max 16.8 Megs, 8 of them if done right, that is possible I have already done that.

Yes, but that's not the 'HDD' I'm referring to; I'm talking about the SIDE3 HDD (i.e. the SD card). There's nothing to prevent the use of FujiNet, SIO2IDE, SIO2SD, or any number of external devices to host large serial-IO connected ATRs accessible to any DOS which can handle large volumes.

[flashjazzcat]

I should caveat that by adding that when I get the new SIDE3 loader finished, you'll be able to boot straight into a DOS with BASIC XE or any cartridge you like present and use the SD card for storage without U1MB being present at all.

[+bf2k+]

1 hour ago, flashjazzcat said:

Much will depend on whether U1MB is even present. Forget about using the HDD with anything other than SDX if not.

 

I have a U1MB but only for the Extended Memory.  U1MB SDX is turned off. U1MB PBI is turned off. (Maybe PBI should be on?)

 

At any rate, I have FXEP running on this U1MB machine using the IDE2Plus for disk... it works fine.

 

Now I am trying to shift gears to SIDE 3 but I cannot get it to boot to SD3.2g which is on the APT.

[flashjazzcat]

26 minutes ago, bf2k+ said:

I have a U1MB but only for the Extended Memory.  U1MB SDX is turned off. U1MB PBI is turned off. (Maybe PBI should be on?)

Yes, PBI HDD needs to be turned on, but you first need to flash the SIDE3 plugin and PBI BIOS. Thereafter, you'll be able to use APT hard disk partitions and FAT-hosted ATRs with BASIC XE and Sparta 3.x to your heart's content.

27 minutes ago, bf2k+ said:

At any rate, I have FXEP running on this U1MB machine using the IDE2Plus for disk... it works fine.

You'll be able to remove the IDE+ when you get things set up with U1MB/SIDE3.

[+bf2k+]

5 hours ago, flashjazzcat said:

Yes, PBI HDD needs to be turned on, but you first need to flash the SIDE3 plugin and PBI BIOS. Thereafter, you'll be able to use APT hard disk partitions and FAT-hosted ATRs with BASIC XE and Sparta 3.x to your heart's content.

 

And it almost works.... boots from the APT drive 1 SD3.2g partition and executes the batch file which loads the ramdisk, loads the rs232 handler, loads AMP9600 and then hits the CAR command to go into Basic XE.  I know that Basic XE is there (v4.1) because I can see it in the SIDE3 loader.  I also can see the D1: partition right below it.  However the CAR command causes BASIC XE to attempt to load the BASICXE.OSS file for extended stuff and that screen locks up and never recovers... 

[flashjazzcat]

6 minutes ago, bf2k+ said:

However the CAR command causes BASIC XE to attempt to load the BASICXE.OSS file for extended stuff and that screen locks up and never recovers... 

I've seen these BASICXE.OSS crashes before and I have absolutely no idea what causes them. BASIC XE experts are welcome to comment.

 

[rcamp48]

14 minutes ago, flashjazzcat said:

I've seen these BASICXE.OSS crashes before and I have absolutely no idea what causes them. BASIC XE experts are welcome to comment.

 

I was actually thinking of purchasing a side 3 cart, can I run a real Basic XE with the side 3 cart? does it use the expansion port or the cartridge port? Russ

 

[flashjazzcat]

3 minutes ago, rcamp48 said:

I was actually thinking of purchasing a side 3 cart, can I run a real Basic XE with the side 3 cart? does it use the expansion port or the cartridge port?

SIDE3 sits in the cartridge port, but the idea is that this causes no problem since it emulates most cartridges, including BASIC XE.

 

 

This should all be ready relatively soon.

[flashjazzcat]

Just had an interesting random thought about FAT file systems while optimising the cluster allocator in the loader. Some years ago when I was working on the GOS/GUI, I wanted an efficient means of dynamically allocating and deallocating linked list nodes (implemented as arrays with corresponding prev/next index arrays). So I made the free node pool itself a forward-linked list.

 

Now it just occurred to me: if only they'd done the same thing in FAT16/32. As things stand, free cluster seeks are especially arduous on FAT32 volumes since if the 'last allocated cluster' hint happens to point to a cluster which does not have a lot of free space following it, you inevitably end up doing lengthy linear seeks on a potentially enormous file allocation table. And when a cluster is deallocated, it may be buried deep inside a huge slab of allocated space.

 

What they could have done is arranged the empty FAT as a linked list of free clusters, so: cluster 2 points to cluster 3, cluster 3 to cluster 4, etc, and the head pointer would initially point to cluster 2. To allocate a cluster, pull the first cluster off the free list and point the head at the next node. To deallocate a cluster, put it at the head of the free list. Free cluster seeks would be an absolute cinch.

 

Of course, this would require a means other than setting all bits to zero of marking a cluster 'free', potentially halving the usable cluster count (unless you decided to simply have no 'free' marker on individual cluster entries at all, and put total trust in the head pointer), and I suppose the whole thing is a non-issue unless you're trying to manage a 64GB FAT32 volume with a 1MHz CPU.

 

Anyway: just wanted to throw that out there as a conversation point. I realise exFAT's bitmap was the chosen solution to the problem described above, but might not the free cluster list be more efficient?

Edited February 11 by flashjazzcat

[flashjazzcat]

Addendum: use the second FAT copy as-is as a verification check (i.e. all free clusters have all bits set to zero in the second FAT, so when pulling a cluster off the free list, we also check it's marked zero in FAT number 2, just in case the head pointer or a node in the free list got corrupted). Keep a running free cluster count in the BPB (as per FAT32), and you have a safe and highly efficient allocation mechanism with a minor change to the file system.

 

Oh well, too late now...

 

Edited February 13 by flashjazzcat

[Mclaneinc]

How is the dev'ing going, Jon?

 

With all the crap at your door, I'm stunned you have time for it.. I hope your good lady is fairing better as well.

 

Paul..

[flashjazzcat]

5 minutes ago, Mclaneinc said:

How is the dev'ing going, Jon?

 

With all the crap at your door, I'm stunned you have time for it.. I hope your good lady is fairing better as well.

it's going well - thanks.  Technical discussions help keep me motivated, but I guess hypothetical improvements to FAT aren't everyone's (anyone's) cup of tea.

 

I could choose any one of half a dozen pressing priorities to focus on at the moment, so when I'm coding, it's because I arbitrarily picked that one.

 

Deborah's doing well, thanks. She has a couple of days off for Valentine's Day, and we're going to wander into Newcastle tomorrow. Haven't been up there for years.

[flashjazzcat]

I think this milestone is worth sharing. I wasn't going to bother facilitating copying files between different FAT partitions until well after the beta was released, at least not until Friday when I realised simply obtaining the free cluster count on a FAT partition in the MBR partition menu would require a context switch between the 'open' FAT partition and the one selected in the list. So, I went ahead and added file system contexts; I was expecting this to be a massive headache, but it wasn't quite as bad as expected. Think of this as essentially the equivalent of the unit ID ('D1:', 'D2:', etc) pertaining to logical FAT volumes. Now, when a file is opened, the file control block stores a copy of the file system indexed by the unit number, and every time the file context is switched, the file system context is also switched if the incoming file context relates to a different FAT volume.

 

Anyway: as an example, here's a file (the command processor, in fact) being copied from a FAT32 partition to a folder on a FAT16 partition and then launched:

 

 

Edited February 13 by flashjazzcat

[Beeblebrox]

@flashjazzcat Amazing progress! Thanks for sharing. 

[Kyle22]

Great work Jon (as always).

 

Edited March 15 by Kyle22
forgot to mention Newcastle Brown is AMAZING.

[mikro]

I have an interesting issue. A year later, after I (re-)fixed my XEGS, I've decided to look after U1MB updates. So I find the 4.05 version, decided to play it safe, so I dumped my QMEG into a ROM file and overwrote the whole thing with ULTIMATE.ROM. Everything went well, I saw my profile has been reset, no problem. Tried new GOS, fine. Go back to the menu, I basically leave everything as is, just save the profile and reboot back to SDX. New SDX version, sweet. Start UFLASH.XEX and boom -- Unidentified hardware! Tried manual selection, nope.

 

As it worked virtually seconds before flashing, I assume it must be somehow software related?

 

EDIT: Phew, mystery solved. It was caused by the Ultimate Atari Cartridge presence. Interesting. Is it a known incompatibility? (I tried to boot also the older update ATR and it refused to acknowledge U1MB presence as well... perhaps UFLASH/BIOS stores some vital data into cartridge memory region? If so, it's still interesting that it didn't complain during flashing)

Edited March 17 by mikro

[flashjazzcat]

27 minutes ago, mikro said:

It was caused by the Ultimate Atari Cartridge presence.

You should make sure any third-party cartridges are removed before flashing, since UFLASH updates the ROM by writing to the left cartridge area. It's perfectly possible that an external cartridge could be circumstantially suppressed inadvertently, so you might get away with it on the odd occasion, but it is definitely not recommended.