bug fixes Ultimate 1MB, Incognito, 1088XEL/XLD and SIDE/SIDE2 Firmware Version 3.02 Released

[JR>]

3 hours ago, rosapoP said:

how do i boot a DOS with with the SIDE2 in the machine?
if the SIDE2 is in the machine the SDX option just boots the atari selftest. ?

Slide the switch on the front of the SIDE2 cart to the up position.

[Faicuai]

4 hours ago, rosapoP said:

how do i boot a DOS with with the SIDE2 in the machine?
if the SIDE2 is in the machine the SDX option just boots the atari selftest. ?

Ok, I've done this test like a million times, so let's start from the beginning:

 

1. Do you have Ultimate/1MB installed on your machine?

2. If you don't, is your machine STOCK?

3. If not, what mods does it have?

 

Sorry if yo have already implied this, but I could not find a clear answer.

[rosapoP]

My problem is solved. by the helpful replies of DrVenkman
I downloaded SDX from http://sdx.atari8.info/ booted it up from my SDrive-MAX.(i did not know the SDX ATRs were bootable)

then used that to run uflash.xex from the SIDE2 ATR.

i have U1MB installed. SDX was not booting with the SIDE2 cartridge inserted. now it boots SDX just fine.

[_The Doctor__]

Welcome to the world of Atari, everything doesn't run straight out of the box...  the great news is, once you master all of this stuff you will be able to handle just about anything the planet can throw at you. Awesome hobby for today.

Edited August 29, 2019 by _The Doctor__

[+DrVenkman]

10 hours ago, rosapoP said:

My problem is solved. by the helpful replies of DrVenkman
I downloaded SDX from http://sdx.atari8.info/ booted it up from my SDrive-MAX.(i did not know the SDX ATRs were bootable)

then used that to run uflash.xex from the SIDE2 ATR.

i have U1MB installed. SDX was not booting with the SIDE2 cartridge inserted. now it boots SDX just fine.

I guess I’m confused. If you have an Ultimate 1Mb, you can boot SpartaDOS X from the U1MB, you should have been able to copy the SIDE2 ATR to the FAT32 partition, then mount that disk in the loader as D1:  Boot SDX on the U1MB and run UFLASH from D1: and then flash the SIDE2 cart from there. If you can’t boot SDX with the SIDE2 cart inserted, the switch on the cart is in the wrong position and/or you’ve got the U1MB set incorrectly. 

Are you using Jon’s BIOS on your U1MB? 

[flashjazzcat]

Much confusion here, and I don't think it's down to stuff 'not working out of the box'. Broadly speaking, you want to be booting SDX from the device you want to flash. If you want to flash U1MB, boot SDX from U1MB. If you want to flash SIDE, boot SDX from SIDE. The way the query was framed, it seemed to me that the SDX ROM on the SIDE cart was corrupted and was therefore hanging the machine. This definitely makes it a little difficult to recover, although there could be ways around it... none of which are worth the bother if an EPROM programmer is already on the desk.

 

SIDE is just a cartridge with two base banks, each selected by a switch position. It will boot SDX or the loader unless some external entity (or a modified OS) prevents this. Ultimate 1MB can prevent either SDX or the loader from booting since U1MB can completely suppress the (any) cartridge ROM, as well as selectively turning off the SIDE ROM. As Herb points out: with U1MB, there is no need to boot SDX from the SIDE cartridge anyway (and if you enable SDX on U1MB and SIDE while the SIDE ROM is enabled in the BIOS, the system will hang).

 

In any case: I don't think I fully understand the initial problem or the solution here.

[Mr Robot]

I think it gets a bit over confusing when people are new to all these upgrades having SDX bootable from so many different places. 

[flashjazzcat]

34 minutes ago, Mr Robot said:

I think it gets a bit over confusing when people are new to all these upgrades having SDX bootable from so many different places. 

Possibly so, yes, although in this context there are only two places. In any case: what with the perceived complexity, it's also confusing for me when the issue isn't expressed in especially great detail.

 

Discounting patched OSS ROMs in the context of the beginner, the general rule of thumb I repeat time and time again is that if you're using a SIDE cartridge in an U1MB machine, the ROM on the cartridge is not used. The latest U1MB firmware even does extra hand-holding here by suppressing not only the loader on the cartridge, but the SDX ROM too. So providing the PBI HDD is enabled with 'ATR button' in the BIOS, you cannot go wrong regardless of which position the SIDE switch is in. There's even a 'SIDE HDD defaults' setting as of version 3.00 of the U1MB firmware: choose that, and the current profile is populated with optimised defaults for SIDE HDD operation, and the SIDE ROM is automatically turned off.

 

I realise this doesn't specifically pertain to updating the SIDE ROM itself, but if the objective is just to get things working, it should help.

 

[rosapoP]

My problem was if the SIDE2 cartridge was in the machine any option to boot SDX just dumped me into the selftest.
Solved by finding a way to get uflash running with disk access and reflashing the SIDE2.

 

 

[flashjazzcat]

38 minutes ago, rosapoP said:

My problem was if the SIDE2 cartridge was in the machine any option to boot SDX just dumped me into the selftest

I see. If the SDX ROM is going to go bad, that's probably the best way for it to do so (rather than crashing the machine).

[flashjazzcat]

Following a brief discussion about the Q-Meg OS in another thread, I started to wonder how useful it would be if the U1MB/Incognito firmware could force the OS to boot from a drive other than D1: even when the HDD is disabled. And oddly enough, only hours later, I had occasion to do just that when I wanted to boot the Atari from a RespeQt-hosted ATR on D2: in order to run some bootable diagnostics on a 1050 with the drive ID set to D1:. Of course I could have changed the 1050's drive ID, and as it happens (since the computer had a SIDE cartridge plugged into it and the HDD enabled), I could have done so since the BIOS's 'Boot drive' setting can target any drive number regardless of whether it represents a hard disk partition or not. But I totally forgot that at the time.

 

But this set me thinking that it would be rather nice if the firmware could boot from other drive numbers even if the HDD was disabled (which is necessarily the case if some cartridge other than SIDE is to be plugged into the computer). Normally the 'Boot drive', 'CONFIG.SYS' and 'D1: Redirect' options are dimmed and inaccessible when the HDD is disabled. Moreover, the 'D1: Redirect' feature only works on HDD partitions (which is to say, the drive represented by the 'Boot drive' setting and 'D1:' must both point to hard disk partitions: in that case, references to D1: will be directed to 'boot drive' and vice versa), so even when the HDD is enabled, one cannot - for example - redirect IO between a floppy drive (nor even an FAT-hosted ATR) and a hard disk partition, or swap a pair of floppy drives, etc.

 

I wondered how other devices approached this, and it turns out that the IDE Plus 2.0's 'Boot drive', 'CONFIG.SYS' and 'D1: swap' functions are independent of the hard disk itself: one may disable 'IDE interface', and the two boot options and the swap option will function on serial drives (this is not dependent on high-speed SIO being handled by the IDE Plus firmware on any given drive, either).

 

So: I've coded up an experimental version of the U1MB firmware which allows the three boot/redirection settings to be active independently of the HDD and the HSIO driver. It looks like this:

 

 

Only the last three items on the HDD menu are now dependent on the hard disk being activated. The three items above 'Hard disk' (all of which were previously subordinate to it) now function the same whether the hard disk is enabled or disabled. You don't even have to have the HSIO driver enabled: if it's turned off, the firmware will alter DUNIT on the fly and just hand control back over to the OS SIO handler or another PBI-hosted driver.

 

That's all fine and dandy, and in the screenshot, I'm booting DOS 2.5 from a serially-connected ATR on D3:, but since 'D1: redirect' is enabled, the OS sees this volume as 'D1:'. Any reference to 'D3:' is redirected to whatever (if anything) is connected to D1:.

 

But... I see some potential regressions with this approach:

1. In the current firmware, setting 'Boot drive' to 'APT' causes the system to boot from whatever boot drive setting is stored in the hard disk's partition table (as set by FDISK via the 'B' flag). I guess this is rarely used, but I know it is useful to and used by some nevertheless. This causes us a problem, since the hard disk doesn't even have to be active in the experimental firmware for the 'Boot drive' setting to be acted upon. If the HDD is off and the boot drive is set to 'APT', the setting makes no sense and I guess it would have to fall back to some sane value (i.e. D1:). But this seems potentially confusing.
2. In the current firmware, the system will always (generally) boot from D1: unless the HDD is enabled, at which point one's 'Boot drive' and 'CONFIG.SYS' settings become active (if SDX is enabled, the latter value is used). Likewise the 'D1: swap' setting. So: enabling and disabling the HDD inherently switches between two stored sets of parameters: normal OS behaviour and 'HDD' boot behaviour. But if the boot settings remain active regardless of whether the HDD is enabled or not (as they do in the case of the IDE Plus 2.0), this contextual switch functionality is lost. Your system will try to - for example - boot from D3: regardless of whether the SIDE cart is connected and the HDD enabled or not (until you edit settings or switch config profiles).
3. Since 'D1: swap' will also function on FAT hosted ATRs in the experimental build, one could easily lose track of what the Hell is what when references to D1: go to - say - D5:, references to D5: go to D1:, and you have just used the ATR button to swap two ATRs residing on... D1: and D5:.

The last point explains why I hitherto confined 'D1: swap' to HDD partitions and nothing else.

 

In any case, I am just throwing the idea out there and inviting commentary and opinions. I have made changes in the past which have immediately spoiled someone's usage patterns and been obliged to quickly reverse the changes. So while the ideas presented above seem to me to improve flexibility, I've also outlined some potentially less welcome side-effects which could easily prove surprising. Perhaps none of this is important at all: if my explanation makes no sense, you're probably not using the features under discussion and can probably safely ignore the whole matter. But for those who do use the boot and redirection features, I would be most interested to hear from those who prefer things the way they are, and from those who think the experimental changes I outline above sound like a good idea.

 

[_The Doctor__]

an ICD MIO allows you to swap all types of drives HDD,Floppy,Ramdrive, or no intervention at all in and out of dunit(some think of them as slots and numbers)... so long as you can pull up the menu and see it (either by select key or software) you can easily keep track of things and can bop in and out without losing anything on most DOS variants.

SDX has it's own mapper and it is possible to map one drive to another on the MIO and then that drive to another on the SDX drive map... but since they are distinctly different in look and feel you kind of know what you've done (although in a senior moment you might think wtf! until it dawns on you what you did)

 

The Black Box also had the ability to exchange drives slot and numbers (though it's  HDD/Serial Floppy/PBI Floppy)

again you can hit a button or call via software to swap drive type and drive numbers... and SDX can map about as well....

 

So with that in mind.... if someone like myself can handle it as did just about anyone else who has used the either of these device (or IDE + for that matter)

- I believe the user base should be able to handle such things without too much confusion... they don't have to use it in that case and it won't hurt a thing that it's available to all the others who will use it.

 

Once you can assign a boot drive at will it makes it so much easier to test and recover floppies without constantly powering drives on and off or changing drive select switches...

 

As a final though, thumbs up on adding the functionality, one step closer to making one device that does it all.

Edited September 18, 2019 by _The Doctor__

[flashjazzcat]

Here's a video demonstration which may help get across what I'm trying to explain:

 

 

[Mr Robot]

Commented on the video.

 

Too. Many. Places. To. Comment.

[Lastic]

4 hours ago, flashjazzcat said:

Here's a video demonstration which may help get across what I'm trying to explain:

 

 

 

I for one would like the additional possibility to redirect seperately for floppies since that's what I've been doing these past days

 

As _The_Doctor_ said, it broadens the possibilities of the U1MB but of course one has to take into account that it might complicate future updates.

I leave at your mercy Jon

[_The Doctor__]

Here's what we're used to...

Here's Black Box the MIO. Any drive can be any unit in any slot. Notice the 720K drive images... swapping those in at D1: allows games that would not run off a hard drive to do so as they act as if it were a floppy  (Largely no issues, it's conceivable something could break it but generally that would be something that dislikes all PBI devices period)

This also mean any floppy can be drive 1. You'll notice my drive 1 is actually the external ram drive in this instance.

 

Not sure of the implementation involved within the fjc BIOS but this is a largely repetitive process so clever re use might make it possible to do it in his as well without eating up much space. You really don't need all the drive sector parms et al since that already handled elsewhere. Just a list of this unit is that ID (A-O)

 

The really cool thing would be the ability to use Drives A-O and not being limited to 9 (BB) or 8 (MIO rev 1.1 down).... since D0: is off limits that's 15 drives...

 

if the fjc bios allows, an external program could provide the user interface to do this as a cold set up and save....

not sure if it will ever be transparent like the BB or MIO as the locking mechanism on the u1m and incognito is kind of set it lock boot...

should be possible to make just this part exposed though and leave the rest locked, but that might be a candle thing

Edited September 18, 2019 by _The Doctor__

[+DrVenkman]

8 hours ago, flashjazzcat said:

Here's a video demonstration which may help get across what I'm trying to explain:

Jon - I watched your video tonight after work. I think it's an interesting change and worth exploring with a public "test" build for a few folks. I'd like to see how it works in practice for my particular usage patterns before I comment much further. There might be downsides for me given how I use my machines, though I can't really think of any off-hand without using it for a week or two to see.

 

[+DrVenkman]

Another comment and slight aside: I'm currently testing a PokeyONE (*) as the right-channel POKEY in a stereo setup in my 1088XLD prototype board. Thanks to the recursive search functionality built into the Loader now, a search for the string "stereo" turns up 85 different ATR and XEX demo files to play with, and that's before I go hit Pigwa or someplace else to look for more.  

 

(*) PokeyONE is an FPGA-based implementation of a subset of the POKEY chip. Originally designed and marketed to arcade collectors and business owners, it provides sound, random-number generation and potentiometer support only. It does not do serial I/O or keyboard scan. However, as the second chip in a stereo configuration, it seems to work great so far! 

[flashjazzcat]

16 hours ago, Lastic said:

I for one would like the additional possibility to redirect seperately for floppies since that's what I've been doing these past days

Excellent - I will see what can be done.

12 hours ago, DrVenkman said:

I think it's an interesting change and worth exploring with a public "test" build for a few folks.

Sounds like a plan. I still haven't released firmware with the XF551 speed polling fix (although version 3.03 is already on Lastic's machine, since it clearly benefited from an early release build), and Marius since then pointed out an additional small bug: $80 returned by the format command when formatting is attempted on a hard disk partition (it should return $8B: NAK). So release 3.04 is pretty much ready to go as soon as these boot/redirection ideas are fully explored.

12 hours ago, DrVenkman said:

Thanks to the recursive search functionality built into the Loader now, a search for the string "stereo" turns up 85 different ATR and XEX demo files to play with, and that's before I go hit Pigwa or someplace else to look for more.

Yes: the search facility has kind of matured of late. Initially it was confined to the logged directory and would just send the cursor to the first entry matching the search term. Then it was extended to explore the directory tree, but was severely limited since it could process no more than 256 folders in total. Then that total was bumped up to 4,096, and then further enhanced so that in real-world scenarios, a virtually unlimited number of folders can be scanned. Of course it starts to grind a bit when you get into four figures, but I managed to find the benchmark results (using the 900MB atarionline.pl archive) posted in the beta tester thread back in April:

 

42 matches in 5,411 folders / 17,441 files: 4m 09s

70 files/s, 21 folders/s. 4,200 files/min, 1,260 folders/min.

[flashjazzcat]

My testing of IDE Plus 2.0 (a great reference point for solid functionality) the other day seems to have been heavily flawed. It turns out that:

• The Boot drive setting works with SIO drives, but only if the IDE interface (HDD) is enabled
• The CONFIG.SYS setting likewise only works when the IDE interface is enabled
• D1: swap appears only to work when the IDE interface is enabled and both D1: and the boot drive setting refer to HDD partitions

Which is... pretty much 100 per cent the way the current U1MB firmware currently works.

[Mr Robot]

Don't you hate it when that happens

[flashjazzcat]

49 minutes ago, Mr Robot said:

Don't you hate it when that happens

Yes, especially when the bogus testing data partly motivated my experiments.

 

[wildstar87]

I had a question on one of the files in the zip file.  Under the ATR directory, there is a firmware.atr file that is much bigger than all the others.  Give what's in the readme, this is supposed to be a minimal image, that doesn't update anything else.  I'm wondering why it's so much bigger than all the rest of the files?

[flashjazzcat]

8 hours ago, wildstar87 said:

I'm wondering why it's so much bigger than all the rest of the files?

Because it has a lot more stuff on it. Basically everything on the other ATRs, totalling about 2MB of content.

[wildstar87]

Is that the one I should be flashing, instead of the 1088 full?