Jump to content
flashjazzcat

New (alt) BIOS for Ultimate 1MB/Incognito

Recommended Posts

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

 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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... 

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
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.

  • Like 3

Share this post


Link to post
Share on other sites

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 by flashjazzcat

Share this post


Link to post
Share on other sites

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 by flashjazzcat

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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. :D

 

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.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

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 by flashjazzcat
  • Like 10

Share this post


Link to post
Share on other sites

Great work Jon (as always).

 

Edited by Kyle22
forgot to mention Newcastle Brown is AMAZING.
  • Like 1

Share this post


Link to post
Share on other sites

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 by mikro

Share this post


Link to post
Share on other sites
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.

  • Like 1

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