Jump to content
IGNORED

New (alt) BIOS for Ultimate 1MB/Incognito


Recommended Posts

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.

 

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

 

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

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

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

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

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

 

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

 

Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
  • Thanks 1
Link to comment
Share on other sites

  • 1 month later...

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

  • 1 year later...
3 hours ago, Donald Dennis said:

How is the JED 2.0 update applied? I've not been able to get it to install.

Depends on which you are talking about, the U1MB or the Incognito.

 

You need a Xilinx programmer unit and cable to flash in both cases. Plus of course the rather temperamental Xilinx software, which I could only get to work on windows 10.(It doesn't like 11 much, although there are ways as you will see). 

 

Here is Jon's (FJC's) video which happens to include a section on how to flash the incognito Jed for example, set to start 9.57mins in):

 

Edited by Beeblebrox
Link to comment
Share on other sites

On 9/18/2023 at 1:39 AM, Beeblebrox said:

Depends on which you are talking about, the U1MB or the Incognito.

 

You need a Xilinx programmer unit and cable to flash in both cases. Plus of course the rather temperamental Xilinx software, which I could only get to work on windows 10.(It doesn't like 11 much, although there are ways as you will see). 

 

Here is Jon's (FJC's) video which happens to include a section on how to flash the incognito Jed for example, set to start 9.57mins in):

 

Each time I've had to update one, usually one of Candle's black-masked ones, I have to re-learn the process.

 

As for this thing, My Goodness it is just SICK.  I LOVE it. 

 

jeff

Link to comment
Share on other sites

  • 1 month later...

How about, in addition, the splash-screen color should be the same as the color of the selected profile?

 

That is!
1. quick selection of the profile on splash-screen (without entering the menu).
2. splash-screen color corresponds to the color in the currently selected profile.

 

Is it possible to do this?
 

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