New (alt) BIOS for Ultimate 1MB/Incognito

[flashjazzcat]

...is there any existing or planned software for the Atari itself that would allow you to create floppy disk image *.ATR's on the FAT32 partition natively? I know this is a very complicated, multilayered topic with questions of sector-size incompatibility and filename length problems for the A8-side with FAT32, while FAT16 could potentially be managed via an RW version of FATFS.SYS but then you lose user-friendly filenames on the PC-side and so on and on. To my mind that is the only thing 'missing' from the SIDELoader - and obviously not 'missing' at all as the SIDELoader is primarily that, a loader. Even it were physically possible to enhance the BIOS code so *.ATR images could be created on a FAT32 CF partition on the A8, mounted in the SIDELoader and then formatted/written to as if one were using an SIO2SD/PC-USB I very much doubt it could be done inside 500bytes!!!

As soon as the SDX FAT driver is R/W, you'll be able to create ATRs in a FAT16 partition. Not sure if FAT32 support is envisaged, but FAT16 is perfectly adequate. I was going to write a R/W FAT FMS module for the SIDE loader which would have been silently loaded when starting an XEX (overwriting the integral read-only FMS), but it seemed like a lot of work when all most people want is to be able to load a ROM when running UFLASH from FAT.

 

Note that long FAT filenames (LFNs) aren't confined to FAT32: they're implemented in FAT16 in exactly the same way, which is why you can use FAT16 or FAT32 with the SIDE loader. Nor are long filenames mandatory with FAT32. The SDX driver will be confined to 8.3 short filenames, but if that's limiting, just add files to the FAT using the PC's card reader. I don't think Candle envisaged the original SIDE loader as something whose FAT volumes you would populate on the A8 itself. The whole reasoning behind using FAT was speed and convenience (not to mention LFN support). Copying MBs of ATRs into FAT partitions on the A8 kind of neuters one of the main perceived advantages of SIDE over other popular IDE controllers: namely not having to copy XEXs and ATRs into partitions formatted using a file system which the PC cannot natively understand.

 

Aside from the in-situ creation of ATRs in FAT partitions (remembering there is no real distinction between FAT16 and FAT32 as far as the loader is concerned), you can mount an ATR using the loader, then format it and write to it just as if it were mounted via SIO2SD/SIO2PC/etc. The PBI BIOS even implements a dummy format command which does nothing but return a perfunctory bad sector list. This allows disk operating systems which insist on successful completion of a format prior to writing out a blank file system to successfully initialise disks.

 

Another question has just sprung to mind. I was reading issue 32 of Page 6 which has a very interesting section of DIY expansions to the XL's and XE's. It talks about 'using the PBI as a device' and mentions for this you must have a 2k 'device handler' programme that somehow occupies the same space as the floating-point ROM. Is this the same thing as the PBI BIOS for the U1MB?

Yes: the U1MB PBI BIOS comprises a multi-bank 2KB math pack overlay and some RAM under the hardware region. U1MB cheats a bit regarding the IO RAM since instead of mapping its own RAM under $D1xx and $D600-D7FF, it maps the portion of the Atari's base RAM occupying the same address space (which is normally inaccessible since it's obscured by the hardware registers). Prior to the PBI-enabled JED, the main BIOS already used $D600-D7FF for the screen display and internal variables, and to implement the PBI BIOS, Candle enabled more RAM (at $D1xx and $D5xx). The PBI BIOS and main BIOS always shared the 512 byte area at $D600, but more recent firmware versions see both firmware components using $D1xx, which is why the V2 JED is required. I thought Candle's use of normally in-addressable base RAM as IO RAM to be quite clever and opportunistic (given the PBI functionality was dreamed up long after the hardware was finalised), although it's not to every purist's tastes and may be the cause of compatibility issues with other upgrades which weren't adequately tested with U1MB for whatever reason. In any case, this is why a) U1MB needs the 600XL to be upgraded to 64KB first, and b) there are only 2 x 512KB SRAMs on the board.

[morelenmir]

As soon as the SDX FAT driver is R/W, you'll be able to create ATRs in a FAT16 partition. Not sure if FAT32 support is envisaged, but FAT16 is perfectly adequate. I was going to write a R/W FAT FMS module for the SIDE loader which would have been silently loaded when starting an XEX (overwriting the integral read-only FMS), but it seemed like a lot of work when all most people want is to be able to load a ROM when running UFLASH from FAT.

 

Note that long FAT filenames (LFNs) aren't confined to FAT32: they're implemented in FAT16 in exactly the same way, which is why you can use FAT16 or FAT32 with the SIDE loader. Nor are long filenames mandatory with FAT32. The SDX driver will be confined to 8.3 short filenames, but if that's limiting, just add files to the FAT using the PC's card reader. I don't think Candle envisaged the original SIDE loader as something whose FAT volumes you would populate on the A8 itself. The whole reasoning behind using FAT was speed and convenience (not to mention LFN support). Copying MBs of ATRs into FAT partitions on the A8 kind of neuters one of the main perceived advantages of SIDE over other popular IDE controllers: namely not having to copy XEXs and ATRs into partitions formatted using a file system which the PC cannot natively understand.

 

Aside from the in-situ creation of ATRs in FAT partitions (remembering there is no real distinction between FAT16 and FAT32 as far as the loader is concerned), you can mount an ATR using the loader, then format it and write to it just as if it were mounted via SIO2SD/SIO2PC/etc. The PBI BIOS even implements a dummy format command which does nothing but return a perfunctory bad sector list. This allows disk operating systems which insist on successful completion of a format prior to writing out a blank file system to successfully initialise disks.

 

 

Yes: the U1MB PBI BIOS comprises a multi-bank 2KB math pack overlay and some RAM under the hardware region. U1MB cheats a bit regarding the IO RAM since instead of mapping its own RAM under $D1xx and $D600-D7FF, it maps the portion of the Atari's base RAM occupying the same address space (which is normally inaccessible since it's obscured by the hardware registers). Prior to the PBI-enabled JED, the main BIOS already used $D600-D7FF for the screen display and internal variables, and to implement the PBI BIOS, Candle enabled more RAM (at $D1xx and $D5xx). The PBI BIOS and main BIOS always shared the 512 byte area at $D600, but more recent firmware versions see both firmware components using $D1xx, which is why the V2 JED is required. I thought Candle's use of normally in-addressable base RAM as IO RAM to be quite clever and opportunistic (given the PBI functionality was dreamed up long after the hardware was finalised), although it's not to every purist's tastes and may be the cause of compatibility issues with other upgrades which weren't adequately tested with U1MB for whatever reason. In any case, this is why a) U1MB needs the 600XL to be upgraded to 64KB first, and b) there are only 2 x 512KB SRAMs on the board.

 

Ideally I would like a system that you could replace both SIO2PC-USB and the SIO2SD - that is allowing you to create *.ATR's in situ if you need to - for instance to create 'dungeon' and 'world' disks for 'Wizards Crown' as a random example - but also be able to access the same storage space from the PC to transfer disk images of things like BIOS updates and whatever else. Those are the two usage situations I envision - and in the same totally idealized world I could see the SIDELoader itself being accessed via some sort of 'overlay menu', which when called up in a similar way to the U1MB config menu that freezes and preserves the current execution state of the A8 processors, allows management of currently mounted images or the creation of new ones/their dismounting and deletion then drops seamlessly back down to SDX or whatever and restores the CPU state on close to allow you to use the newly created/edited *.ATRs as if they were real drives. However, just the former would be a very big win! In fact I thought I might be on to something along those lines via the 'MKATR' tool from the SDX toolkit disk. This works perfectly to create blank images, but obviously can only in normal circumstances place them on an APT partition. That would be absolutely fine if you could then use MATR or the SIDELoader to mount them from there. Unfortunately I found that both those utilities do not allow you to 'enter' the APT file system to look for a specific *.ATR image to mount. Instead they try to mount the entire APT partition as a disk. Is there any possibility they could be slightly altered to allow them to function in the same way as when they are pointed at a FATxx file system? I do appreciate though the tremendous strictures you are under due to the tiny space available for the SIDELoader at least. Maybe MATR being non-embedded might have more future in this regard? Incidentally I think that application is massively under-appreciated and I like it a great deal personally, not least due to the automatic 80-column display support it offers if the hardware is available at runtime.

 

I was also reading a post you made some time ago in regards the IDE Plus 2.0. I seem to recall the reason that device has a quantity of its own on-board RAM is not to provide an expansion at all, but specifically for the uses of its file system control software. If the Ultimate1MB had come with some dedicated on-board RAM in addition to the 1MB specifically for memory expansion would that have made your job any easier? Perhaps that might be something Candle and Lotharek consider for any potential 'Ultimate1MB II'?

Edited August 30, 2016 by morelenmir

[flashjazzcat]

Ideally I would like a system that you could replace both SIO2PC-USB and the SIO2SD - that is allowing you to create *.ATR's in situ if you need to - for instance to create 'dungeon' and 'world' disks for 'Wizards Crown' as a random example - but also be able to access the same storage space from the PC to transfer disk images of things like BIOS updates and whatever else. Those are the two usage situations I envision - and in the same totally idealized world I could see the SIDELoader itself being accessed via some sort of 'overlay menu', which when called up in a similar way to the U1MB config menu that freezes and preserves the current execution state of the A8 processors, allows management of currently mounted images or the creation of new ones/their dismounting and deletion then drops seamlessly back down to SDX or whatever and restores the CPU state on close to allow you to use the newly created/edited *.ATRs as if they were real drives. However, just the former would be a very big win!

Note that the U1MB BIOS setup menu does not preserve (or "freeze") the state of the CPU, but intervenes immediately following a chip reset. Of course being able to launch the SIDE loader in the same manner would still be useful, providing the underlying application is reset protected (otherwise you just end up dumped at the DOS prompt after the OS has reinitialised). It's possible to trap the OS keyboard handler into interrupting mainline code and transferring control to another program and then restoring the stack, registers, frame buffer, etc, but this fails if the underlying application doesn't use the OS keyboard handler. The ideal solution is a PBI IRQ, which the later versions of IDE Plus 2.0 possess. The hardware, in that case, facilitates exactly what you describe, but since the IDE Plus 2.0 loader can already be launched on reset without an OS restart (AFAIK), it's perhaps not that high on anyone's wish list. The idea that I might write a loader which reacted to the IRQ button was bandied around for a while, but since I have no familiarity with the inner workings of the IDE Plus 2.0 firmware and since I have already invested large amounts of time in U1MB/SIDE, nothing short of a considerable bounty would tempt me to undertake such a project.

 

As for ATR creation using U1MB/SIDE: anything which involves writes to the file system immediately requires something double the size of a read-only file system driver, which is the prime reason it was ommitted.

 

In fact I thought I might be on to something along those lines via the 'MKATR' tool from the SDX toolkit disk. This works perfectly to create blank images, but obviously can only in normal circumstances place them on an APT partition. That would be absolutely fine if you could then use MATR or the SIDELoader to mount them from there. Unfortunately I found that both those utilities do not allow you to 'enter' the APT file system to look for a specific *.ATR image to mount. Instead they try to mount the entire APT partition as a disk. Is there any possibility they could be slightly altered to allow them to function in the same way as when they are pointed at a FATxx file system? I do appreciate though the tremendous strictures you are under due to the tiny space available for the SIDELoader at least. Maybe MATR being non-embedded might have more future in this regard? Incidentally I think that application is massively under-appreciated and I like it a great deal personally, not least due to the automatic 80-column display support it offers if the hardware is available at runtime.

As previously mused upon, IDE Plus 2.0 mounts ATRs in the native file system, while U1MB/SIDE uses FAT. In neither case was the decision accidental, and both approaches have their pros and cons. If one approach appeals over the other, then this forms a compelling reason to purchase one HDD solution over the other. The SIDE loader is able to navigate the APT, which itself may contain dozens of partitions, much as if they were disk images. Indeed, mounting of both partitions and ATRs is accomplished using the exact same API. IDE Plus 2.0, meanwhile (AFAIK), is as yet unable to dynamically mount partitions at all, and even if/when it is able to do so, it may well employ some proprietary API (as it is, IDE Plus's ATR mounting API is neither public nor documented to the best of my knowledge: it may be that the IDE Plus loader simply alters the drive tables directly in RAM without any form of abstraction).

 

Extending things to work the IDE Plus way would require at the very least a read-only SDFS driver, for which there is no room in the SIDE loader. It would make sense to also handle serial drives, and open APT partitions according to their mount points, which would really complicate things given the SIDE loader is also able to mount and unmount the very same partitions.

 

MATR, meanwhile, when viewed alongside the new SIDE loader, is an unholy, kludgy mess which would probably benefit from being re-written as an offshoot of the SIDE loader than debugged and developed as is.

 

I was also reading a post you made some time ago in regards the IDE Plus 2.0. I seem to recall the reason that device has a quantity of its own on-board RAM is not to provide an expansion at all, but specifically for the uses of its file system control software. If the Ultimate1MB had come with some dedicated on-board RAM in addition to the 1MB specifically for memory expansion would that have made your job any easier? Perhaps that might be something Candle and Lotharek consider for any potential 'Ultimate1MB II'?

Lack of IO RAM is the primary reason I did not attempt to make the SIDE loader "non-destructive" like the main BIOS setup utility. While the loader's frame buffer (just like that of the main BIOS setup tool) would fit in the existing 800 or so bytes, there remains no room for any additional data structures (such as the list of FAT files itself, which can occupy some 20KB or more in the current loader). 32KB of RAM paged in 512 byte chunks at $D600-$D7FF would have been quite sufficient, and more ROM space would also have been beneficial.

 

What we have at the moment, of course, is new firmware retro-fitted to the original hardware, doing things the original hardware was not necessarily expected to do (such a providing OS-agnostic high-speed serial IO, etc). At some stage, the software begins to exhaust the board logic somewhat. I thought of dumping the entire base 64KB of RAM to either an extended bank or to a FAT partition, then running the loader, then reversing the process, then returning to the underlying application... but all this would consume another six months of time, break backwards compatibility and create a number of awkward problems, and provide some kind of solution to a question which has been posed by only two or three users.

 

Perhaps features spoken about may find their way into "U1MB 2.0" should such a thing ever be created.

[flashjazzcat]

At least, following a laborious flattening of the main PC spread across two days, I now have a almost everything back in place, plus a fully populated device tree.

[morelenmir]

Note that the U1MB BIOS setup menu does not preserve (or "freeze") the state of the CPU, but intervenes immediately following a chip reset. Of course being able to launch the SIDE loader in the same manner would still be useful, providing the underlying application is reset protected (otherwise you just end up dumped at the DOS prompt after the OS has reinitialised). It's possible to trap the OS keyboard handler into interrupting mainline code and transferring control to another program and then restoring the stack, registers, frame buffer, etc, but this fails if the underlying application doesn't use the OS keyboard handler. The ideal solution is a PBI IRQ, which the later versions of IDE Plus 2.0 possess. The hardware, in that case, facilitates exactly what you describe, but since the IDE Plus 2.0 loader can already be launched on reset without an OS restart (AFAIK), it's perhaps not that high on anyone's wish list. The idea that I might write a loader which reacted to the IRQ button was bandied around for a while, but since I have no familiarity with the inner workings of the IDE Plus 2.0 firmware and since I have already invested large amounts of time in U1MB/SIDE, nothing short of a considerable bounty would tempt me to undertake such a project.

 

As for ATR creation using U1MB/SIDE: anything which involves writes to the file system immediately requires something double the size of a read-only file system driver, which is the prime reason it was ommitted.

 

 

As previously mused upon, IDE Plus 2.0 mounts ATRs in the native file system, while U1MB/SIDE uses FAT. In neither case was the decision accidental, and both approaches have their pros and cons. If one approach appeals over the other, then this forms a compelling reason to purchase one HDD solution over the other. The SIDE loader is able to navigate the APT, which itself may contain dozens of partitions, much as if they were disk images. Indeed, mounting of both partitions and ATRs is accomplished using the exact same API. IDE Plus 2.0, meanwhile (AFAIK), is as yet unable to dynamically mount partitions at all, and even if/when it is able to do so, it may well employ some proprietary API (as it is, IDE Plus's ATR mounting API is neither public nor documented to the best of my knowledge: it may be that the IDE Plus loader simply alters the drive tables directly in RAM without any form of abstraction).

 

Extending things to work the IDE Plus way would require at the very least a read-only SDFS driver, for which there is no room in the SIDE loader. It would make sense to also handle serial drives, and open APT partitions according to their mount points, which would really complicate things given the SIDE loader is also able to mount and unmount the very same partitions.

 

MATR, meanwhile, when viewed alongside the new SIDE loader, is an unholy, kludgy mess which would probably benefit from being re-written as an offshoot of the SIDE loader than debugged and developed as is.

 

 

Lack of IO RAM is the primary reason I did not attempt to make the SIDE loader "non-destructive" like the main BIOS setup utility. While the loader's frame buffer (just like that of the main BIOS setup tool) would fit in the existing 800 or so bytes, there remains no room for any additional data structures (such as the list of FAT files itself, which can occupy some 20KB or more in the current loader). 32KB of RAM paged in 512 byte chunks at $D600-$D7FF would have been quite sufficient, and more ROM space would also have been beneficial.

 

What we have at the moment, of course, is new firmware retro-fitted to the original hardware, doing things the original hardware was not necessarily expected to do (such a providing OS-agnostic high-speed serial IO, etc). At some stage, the software begins to exhaust the board logic somewhat. I thought of dumping the entire base 64KB of RAM to either an extended bank or to a FAT partition, then running the loader, then reversing the process, then returning to the underlying application... but all this would consume another six months of time, break backwards compatibility and create a number of awkward problems, and provide some kind of solution to a question which has been posed by only two or three users.

 

Perhaps features spoken about may find their way into "U1MB 2.0" should such a thing ever be created.

 

Fair enough Jon - I am unsure what IO RAM is, but I think I understand everything else you say. At the end of the day I suppose so long as you have a working SIO2xxx device then it doesn't matter terribly. I do like the idea of the drop-down overlay menu though and stopping the machine - maybe I'll have a look at building one of Hias' open-source Turbo Freezer designs if I get really interested in that kind of thing. I guess from a practical standpoint I would find some kind of hybrid SIDE2/UltimateCart more immediately useful anyway - hopefully the totally reprogrammable nature of the latter will make that possible at some point.. I really miss not having access to a hard drive when I want to use one of the cartridge-based programming languages.

[flashjazzcat]

Fair enough Jon - I am unsure what IO RAM is, but I think I understand everything else you say.

It's just RAM (base RAM from the normally inaccessible area between $D000-$D7FF).

 

At the end of the day I suppose so long as you have a working SIO2xxx device then it doesn't matter terribly. I do like the idea of the drop-down overlay menu though and stopping the machine - maybe I'll have a look at building one of Hias' open-source Turbo Freezer designs if I get really interested in that kind of thing. I guess from a practical standpoint I would find some kind of hybrid SIDE2/UltimateCart more immediately useful anyway - hopefully the totally reprogrammable nature of the latter will make that possible at some point.. I really miss not having access to a hard drive when I want to use one of the cartridge-based programming languages.

Much must depend on how you use the machine, since my last remaining SIO2SD has been shut in the drawer for the past couple of years (but enjoyed an outing recently while I was testing divisor 0 SIO), the prime link to the PC now being SIO2PC/RespeQt. It may simply be that I spend too much time testing and not enough time using, since I'm sure I'd have run into a situation by now where it would have been handy to create or mount ATRs on the fly without an OS restart were I not completely engrossed in cross-assembly, testing and deployment. I stuck a KMK/JZ IDE interface inside my 1200XL with the expectation that I would use the freed up cartridge port when using cartridge based applications, but since doing so I have rarely had occasion to use anything other than the SIDE cartridge which is normally inserted anyway.

Edited August 30, 2016 by flashjazzcat

[tuf]

It's just RAM (base RAM from the normally inaccessible area between $D000-$D7FF).

 

 

Much must depend on how you use the machine, since my last remaining SIO2SD has been shut in the drawer for the past couple of years (but enjoyed an outing recently while I was testing divisor 0 SIO), the prime link to the PC now being SIO2PC/RespeQt. It may simply be that I spend too much time testing and not enough time using, since I'm sure I'd have run into a situation by now where it would have been handy to create or mount ATRs on the fly without an OS restart were I not completely engrossed in cross-assembly, testing and deployment. I stuck a KMK/JZ IDE interface inside my 1200XL with the expectation that I would use the freed up cartridge port when using cartridge based applications, but since doing so I have rarely had occasion to use anything other than the SIDE cartridge which is normally inserted anyway.

 

Speaking of internal solutions, does the KMK/JZ internal interface still exist and is it available somewhere? I'd like a totally internal interface as an option for a U1MB 800XL. I love my SIDE and my MIO (and eventually even my IDE+2.0) but I love the clean look of the 800XL even more - internal SIDE anyone?! That might be the inspiration I need to stick the Incognito in an 800...

[flashjazzcat]

The KMK/JZ IDEa wasn't really intended as an internal upgrade but the board is clean, free of clutter, and has mounting points in the corners. I modified it somewhat, nevertheless. Unfortunately the device is years old and no longer manufactired (mine was second hand). You could fit an IDE+ internally (it's been done). I once suggested Candle produce an "internal SIDE" but nothing came of it.

[+mytek]

I once suggested Candle produce an "internal SIDE" but nothing came of it.

 

I'm working on a way to do that for my custom case project.

 

On the SIDE2 there are two holes that pass thru the CF plastic holder and the pcb, which I intend to use for mounting. I also replaced the slide switch and the HD led with headers for external connection.

 

 

I will also need to create an edge card jumper of some sort, possibly with two custom pcb's connected by a ribbon cable.

 

Will be interesting to see how this all works out. But yes it would have been considerably easier if there already was an internal SIDE2 version as you mentioned.

 

- Michael

[flashjazzcat]

All that's really needed is a set of IDE registers (including alternate status register) decoded at the correct address, a buffer, and a compact flash connector. The rest of the SIDE cart (RTC, ROM, cart logic) is totally redundant when used with U1MB. So the board could be very simple; something like the old internal MYIDE.

[morelenmir]

Is there any possibility that one (or more!) profile slots could be added to the BIOS? I have just lately started using the profile system a lot and it would be very useful indeed if I could store setups for the different uses of my machine - 1: Everything enabled and SIDE2 attached, 2: PBI and U1MB SDX disabled, boot from SIDE2 SDX, 3: Standard 130XE Memory setup, OMNIMON XL OS slot and ASM editor slot, no PBI, 4: totally standard machine with all U1MB, SIDE2, VBXE features disabled and so on. Even just a 3rd profile slot would make a big difference.

[flashjazzcat]

There's room in NVRAM for one or two more, but not much room for code to handle it. I'll put it on the possibilities list.

[morelenmir]

There's room in NVRAM for one or two more, but not much room for code to handle it. I'll put it on the possibilities list.

 

Excellent Jon - many thanks!!!

 

Given how tight space is becoming on the U1MB I am looking more and more enviously at the tons of free room the 'IDE Plus 2.0' offers!!!

[flashjazzcat]

Well, it's not the size that counts, but what you do with it.

 

Reached a decision regarding the 65C816 stuff (since it looks like there's light at the end of the tunnel regarding Rapidus): it'll be handled using some external soft-loaded module when the time comes (there are hooks in the PBI BIOS for this). Therefore I can finally release the firmware update shortly (any other feature requests will have to be pushed back to future versions, since I'm too fatigued to risk breaking stuff).

[morelenmir]

That sounds like good news Jon!!!

 

Part of me would really like to play around with a Rapidus, especially the new utilities which the SDX fellows have given us. However they cost too much given the serious stability problems I have read about in this thread and elsewhere. I have no doubt Lotharek and Candle will sort it all out in time though; maybe something to catch up with in a couple of years. I really want to give that new SDX linear Ramdisk driver a go though!

Edited September 1, 2016 by morelenmir

[Aking]

graphic os not booting anymore?

[flashjazzcat]

graphic os not booting anymore?

 

Still working here. Did you not reset the SDX ROM size to 256KB, flash it with SDX 4.48, and thereby obliterate the first 64KB of the GOS ROM?

[Aking]

flashed sdx 4.48 from official site

how can i recover gos ?

[flashjazzcat]

flashed sdx 4.48 from official site

how can i recover gos ?

 

Not easily until I get the shorter SDX 4.48 ROMs prepared and uploaded, which I might manage by this evening. Currently preparing the U1MB/SIDE/Incognito firmware update.

 

BTW: Did you update SDX using UFLASH? It should have warned you that the official SDX ROM was too big (with the GOS enabled, UFLASH expects a 192KB SDX ROM).

Edited September 12, 2016 by flashjazzcat

[Aking]

Sorry to hear that, i updated with the official 4.48 page installer

[flashjazzcat]

"Final" firmware update for U1MB, Incognito and SIDE/SIDE2

Ultimate 1MB

Incognito

SIDE/SIDE2

 

Development and testing has been quite laborious, but much has changed and if any issues are found, please let me know and I'll fix things ASAP. Even UFlash has received a slight overhaul, and this is an ongoing process (since I am keen to eventually drop support for multiple generations of firmware).

 

SDX 4.48 custom APT ROMs to follow, perhaps tomorrow evening, time permitting. These will include an updated version of FDISK and the other APT tools, and the SIO2BT configuration tool I forgot to put in the firmware update.

 

Documentation (user manaul and developer/techincal) is updated too, so be sure to check that out. I included the Rapidus plugin in this release too, since it looks like all the equipment will eventually work well together, and I've added hooks for HDD transfer code in fast RAM. The 65C816 modules are a project for the future.

Edited September 12, 2016 by flashjazzcat

[tuf]

"Final" firmware update for U1MB, Incognito and SIDE/SIDE2

 

 

Fantastic - your dedication to this hardware is greatly appreciated, and your software is first class! Much appreciation and can't wait to get home and go play with it.

[tuf]

By "it" I meant the new software

[morelenmir]

"Final" firmware update for U1MB, Incognito and SIDE/SIDE2

 

Ultimate 1MB

 

Incognito

 

SIDE/SIDE2

 

Development and testing has been quite laborious, but much has changed and if any issues are found, please let me know and I'll fix things ASAP. Even UFlash has received a slight overhaul, and this is an ongoing process (since I am keen to eventually drop support for multiple generations of firmware).

 

SDX 4.48 custom APT ROMs to follow, perhaps tomorrow evening, time permitting. These will include an updated version of FDISK and the other APT tools, and the SIO2BT configuration tool I forgot to put in the firmware update.

 

Documentation (user manaul and developer/techincal) is updated too, so be sure to check that out. I included the Rapidus plugin in this release too, since it looks like all the equipment will eventually work well together, and I've added hooks for HDD transfer code in fast RAM. The 65C816 modules are a project for the future.

 

EXCELLENT Jon!!! Many, many thanks as ever for this work - I cannot wait to test it out.

 

One question - is this new version of uFlash numbered '1.29'? Also, you mentioned new APT tools and utilities would be coming shortly. Just to make the SDX upgrade process a little easier would you mind putting the new programmes separated in their own archive somewhere, perhaps even ideally as a PC-readable *.RAR or *.ZIP? That would really be a huge help when it comes to updating my custom SDX ROM contents on the hard-drive before using SDXImager to wrap them all up in a *.ROM.

 

Again hugely well done on this and many thanks. If you are seeing the problems with the Rapidus settling down then I'm going to have to be very careful or I'll end up seriously wanting one!!! Just the PBI extension you mention sounds intriguing.

[spookt]

"Final" firmware update for U1MB, Incognito and SIDE/SIDE2

 

 

 

 

As ever Jon many, many thanks for all of the hard work!

 

A quick (possibly stupid question) - is it possible to flash from the loader using an Incognito? I've updated the BIOS, PBI, and loader from SDX but wanted to try flashing the GOS. I dropped the latest UFLASH.XEX, the 192Kb SDX image and the GOS image into a directory on my CF card, but when I load uflash it doesn't recognise the hardware. Just wanted to know if I was doing something daft or if it just won't work.