How to set up Ultimate 1MB in Altirra

[morelenmir]

Nearly a year later and I seem to have this almost running.

 

The problem I have encountered is with the side loader. Firstly I have updated the 'SpartaDOSX', the 'PBI BIOS' and the 'SIDELoader' flashes - all using 'uFlash' and all to the newest versions that are on old FJC's spiffy new site!

 

Now, this is the process I have followed:

 

1. Checked the 'Enable IDE hard disk' checkbox in the 'System->Hard disk' dialog.
2. Created a new 128MB *.VHD image using 'System->Hard disk...->Create VHD Image'.
3. Next I selected the 'SIDE2' item in the 'Hardware' Drop-down listbox - obviously.
4. I now reboot Altirra, which after hand-shaking goes in to SDX.
5. I now use enter the 'FDISK' command at the SDX command-line.
6. Inside FDisk I select 'Disk->Initialize...' drop-down menu-item.
7. At the following dialog I select 28mb for a FAT partition and give the rest to APT.
8. Using the 'Parition->Insert' menu-item I create a 20MB APT partion, designate it as drive 3/C and mark it bootable.
9. Shift+F5 for cold reboot.
10. Back in SDX drive 3/C is visible and I format.
11. Now I close Altirra entirely.
12. In windows I go to 'Computer-management->attach VHD' and point it to the new *.VHD image that Altirra created.
13. Windows mounts the *.VHD and recognized the two paritions - one 28MB FAT partition and one 100MB APT parition, although obviously windows does not know the latter.
14. Windows insists I format the first FAT parition before I cna use it, which I do using FAT32.
15. Once formatted the FAT partition is now fully visible to windows.
16. I copy an *.ATR on to it, 'Koronis Rift' and rename it "KoroRift.atr" to be compliant with the 8.3 naming scheme.
17. I now go back in to the 'Computer Management' MMC snap-in and detach the *.VHD, without deleting it of course.
18. I restart Altirra, pause the simulation and then go to the 'System->Hard disk...' dialog.
19. Checking the 'Enable IDE Hard disk' checkbox again, I point it to the *.VHD image and select 'SIDE2' once more from the 'Hardware' drop-down listbox.
20. I then cold-reset Altirra.
21. Back in SDX the *.VHD is again functioning and the APT partition visible.
22. I now select Cold-Reset while holding in Help and the Ultimate1MB menu appears.
23. I press and hold 'L' which after a moment brings up the SIDELoader menu as it should.
24. At this point everything fails as the SIDELoader cannot seem to see the 'KoroRift.atr' that I copied on to the FAT partition...

It may be important to this process to note I have the VBXE simulation also enabled.

Edited May 6, 2015 by morelenmir

[flashjazzcat]

The FAT might be too small. The loader uses the standard MS method to establish the file system, and this is done according to the cluster count. The loader might assume FAT16 and then come unstuck because it clearly isn't. If you ZIP up the VHD and email it to me, I'll check.

[morelenmir]

I'm clearly a bit dense this morning FJC! I can' seem to find your email URL, so have attached the zip to this post.

Ultimate1MB - SIDE2 - 28MB-FAT_100MB-APT.zip

[flashjazzcat]

Thanks! I didn't inspect the boot record yet, but Windows refuses to format the volume as FAT32 since it's too small. This suggests the loader isn't handling FAT16 too well. My advice: make a bigger FAT partition (256MB or so) and you should get the option to format FAT32. I can see you want to use the FAT16 partition as an external APT volume, and that's fine too: just make a big FAT32 and an APT in FDISK on the A8, then use Windows Disk Management to shrink the FAT32 or use unoccupied space to add a 32MB FAT16 partition as well. Then you can go back into FDISK on the A8, hook up the FAT16 volume as an external partition (for use with the SDX FATFS.SYS driver), and keep the FAT32 volume completely separate for all your ATRs and XEXs with long filenames.

[morelenmir]

I will give that a try FJC. I'm not sure why I went for such a small simulated drive - I chose 20mb for the individual partitions as that was the size of the old Supra machine. It seems the SIDE2 has a 4GB CF drive so I will aim at that. When making the *.VHD it is okay to use the 'dynamic volume' type?

 

Another question that occurred to me is; does the 'SIDELoader' work with *.ATX VAPI clones?

 

Update - it seems Altirra will not let me make a 4GB *.VHD image... Which is strange! But Altirra will work with a 4GB image if it is made externally in windows - which is stranger still!

 

Second Update - Yep! That works as 'Koronis Rift' is recognized on the new, 1GB FAT32 volume. I can also then go on to delete the FAT32 in windows then create a 990mb FAT32 volume and a 32MB FAT16 volume. Back in Altirra and FDISK, both new external volumes are recognized. Does the FATFS.SYS driver only work with FAT16? Does it matter in which order the FAT32 and FAT16 volume appear on the *.VHD?

 

Not an update, just my incompetence!: Where can I get hold of the FATFS,SYS driver? I cannot seem to find it! Also - and this is where my stupid really bites - I assume I load it by creating an AUTOEXEC.BAT file in the designated boot drive of my SDX installation. Fine... Except how do I write a text file in SDX??? There doesn't seem to be an SDX equivalent of 'EDIT.COM'. I have never thought of that before!

Edited May 6, 2015 by morelenmir

[flashjazzcat]

There's no explicit type ID in a FAT volume, so whatever software is deciding whether it's FAT12, FAT16 or FAT32 has to base its decision on cluster and volume size. So even if you managed to format the 28MB volume as FAT32, there's a possibility the loader would still think it was FAT16 and read the FAT incorrectly. I'm sure a larger volume will work.

 

Not sure about the VHD: never tried, but Phaeron will be able to tell you for sure.

 

The disk image handling works only with ATRs. I could look at making it handle other formats, but no-one ever asked yet. It seems most stuff is either XEX or ATR.

[fujidude]

I just tried setting up a 64MB vhd. I was planning to have it evenly split between Atari APT and FAT32. Turns out I could not format FAT32 in Win. So I mounted the vhd in a VM running Linux and attempted to use GParted. And I got an error that it needs to be aty least 33MB. See attached pic.

[flashjazzcat]

There you go then.

[morelenmir]

The disk image handling works only with ATRs. I could look at making it handle other formats, but no-one ever asked yet. It seems most stuff is either XEX or ATR.

 

There are quite a lot of images available in 1:1 *.ATX now - I tend to use them exclusively as they are perfect clones which was why it took me a whiie of searching through my archive to find a basic *.ATR.

[flashjazzcat]

I've just had a look at the specification and although it all makes sense, it looks like it would be quite code-heavy to implement inside an 8KB PBI ROM, especially bearing in mind I only have about 2KB left. The format seems to me absolutely emulator-focused.

[morelenmir]

Fair enough FJC - I see what you mean. I suppose it would be easy enough to make *.ATR copies of my images in Altirra and then write them on to the FAT16 portion of a CF card. Basic I would use the emulator as a middle step.

 

So.. in regards that FATFS.SYS process... I found the driver itself in the SDX support disk. I also found a text editor called 'kedit' - which performs a trick I thought previously impossible by making the Linux 'vi' seem user-friendly!!! BUT, it works. So. I create a config.sys in the MAIN folder of my boot volume. The only lines I have in the file are 'DEVICE FATFS' and 'MERGE' - which I believe should mean the contents of this config.sys are merged with the contents of the one in the CAR: volume and so the existing configuration is kept.

 

So. I reboot and at the top of the screen get 'Missing Disk' and then 'Config error (154):DEVICE FATFS'

 

I guess what is happening is, despite the 'merge' command the boot volume config.sys is replacing the CAR: one, so the SIDE driver is not being loaded. But at least shouldn't FATFS be working?

 

Update: Well, I thought it might be easier just to modify your SDX flasher disk, so it included the DEVICE FATFS line in the config.sys that lays inside the user-area of the ROM. Which I did and then reflashed. And all seems well. FATFS is now loading. Sadly I tried this approach only AFTER I had attempted to used SDXImager on the main rom image for the ultimate1MB directly. The one I had spent about a day customizing, updating and uFlash'ing things like games and programming languages and the like. Once I had changed the user-area config.sys in that gestalt ROM Altirra would no longer boot... More than a little annoying! I have included this now-mangled *.ROM file in case you can tell what SDXIMager did to it to stop it working.

Ultimate1MB v2 (SDX447&APT, PBI BIOS v1.0, SIDELoader, custom).rom

Edited May 6, 2015 by morelenmir

[flashjazzcat]

I haven't used "MERGE" before, so the SDX manual will have to be consulted there. It sounds as if there's no SPARTA.SYS or SIO.SYS driver referenced in CONFIG.SYS, hence "Missing Disk" and the subsequent inability to locate the FATFS driver. Again, if you want to send a ZIP across, feel free.

 

I'm puzzled why you would want to try and install the SIDE.SYS driver when you already have the PBI BIOS of Ultimate 1MB active. This renders SIDE.SYS unnecessary. On a system without Ultimate 1MB's PBI BIOS, the SIDE driver is the only means of accessing the hard disk, and since the hard disk can't be accessed until SIDE.SYS is installed, the driver must be located on the CAR: device (i.e. the SDX cart). That's why the SDX ROMs for SIDE, SIDE2, MyIDE/Flash and MyIDE II hosted on my website all have the driver on the cart, and the driver is referenced from the CONFIG.SYS on the cart.

 

Using the set-up you appear to have (Ultimate 1MB and SIDE), you're free to place CONFIG.SYS on the hard disk.

 

Since you have flashed the SDX build on my website to Ultimate 1MB, you should find FATFS.SYS and other useful stuff right on the CAR: device.

 

Oh... and you've done me a favour by mentioning KEDIT. I had no idea Konrad had released that on the toolkit, and as a consequence I need to check it out ASAP.

Edited May 6, 2015 by flashjazzcat

[fujidude]

error

Edited May 6, 2015 by fujidude

[fujidude]

Morelenmir, if it helps you out, I've attached my SDX config files. You may need to edit them for your own purposes. It's just as a model. My setup is Altirra, U1MB, SDX 4.47, SIDE 2 style HDD via the U1MB, VBXE, XEP80 too just for fun, etc. The key thing is to put the files into a folder on your boot drive's root folder called SPARTA.DOS. Yes, that direcctory name must have the .DOS on it. SDX will give you a boot menu. There is no need to use the merge facility. Just edit the files exactly how you want them. Make some new ones. Remember, you can still reference the CAR: device in these files if that's where you want to load stuff from. In fact, I think that is the default unless you point to somewhere else. By putting new versions of device drivers and such on disk and loading those, it saves you from having to rebuild your SDX ROM image (and then your U1MB ROM image incorporating it) if you don't feel like doing that. You'll notice in my files that some references are to things stored on the disk and not the car.

 

 

[flashjazzcat]

Hmmm... note that it's strongly recommended to have CAR: as the first device in the main search path unless you propose for some reason to migrate the entire content of the cart to disk. Searching the current directory (";") first, followed by a list of others will dramatically slow down the system, especially if you happen to log an SIO drive once in a while. The CAR: device is searched so quickly that it doesn't really harm to leave it at the front of the path, unless CAR: happens to be devoid of files. The fact the DIR command itself was moved out to an external command on CAR: kind of underlines this. You can always run a program from disk even if it happens to have an identical name to one on CAR: by preceding the name with a period (denoting the current logged directory).

Edited May 6, 2015 by flashjazzcat

[fujidude]

fjc: the reason I have a place on disk before car: is because car: may have an older version of a file. So the problem isn't that it would be devoid of files, but rather that it might have an undesired version of a file. I haven't had very good luck rolling my own SDX for the U1MB so far, so this allowes me to just put the updated version in /bin or /drivers and it automatically gets preferred over car:.

 

The reason I have the current directory 1st, is because most of the stuff I run isn't in one of the centraly located places that is in the path. If I put every executable I had into the /bin folder it would be way too many things in there and not organized the way I like (putting executables with support files or categories). I don't notice a slow problem really. I do think you have a good point about running stuff with a period though. I will probably remove the current directory from the path.

Edited May 7, 2015 by fujidude

[morelenmir]

I'm still a bit wooly on the whole 'PBI drive' situation and that was going to be my next question!

 

Using tools like KEdit is a real culture shock! I do not doubt the programmer is highly skilled - its a testament to that when you consider how much functionality he has built in to the programme given the limitations of the system. As I say it feels VERY similar to Vi and I feel almost... I don't know, like someone coming to computers totally fresh when I try to use it. A fascinating experience.

[flashjazzcat]

fjc: the reason I have a place on disk before car: is because car: may have an older version of a file. So the problem isn't that it would be devoid of files, but rather that it might have an undesired version of a file. I haven't had very good luck rolling my own SDX for the U1MB so far, so this allowes me to just put the updated version in /bin or /drivers and it automatically gets preferred over car:.

I understood the intention, but having a cart without outdated SDX system files isn't ideal. It's hard to know how that could even happen if you've installed the latest SDX version, or flashed the latest APT-specific build from my website. If the intention is also to add drivers and applications to CAR which are not already on any of the existing builds, then the SDX Imaging tool for Windows (from the SDX website) makes adding files very easy. Flashing the resulting ROM should also be a five minute job using UFlash or the stock SDX flasher.

 

The reason I have the current directory 1st, is because most of the stuff I run isn't in one of the centraly located places that is in the path. If I put every executable I had into the /bin folder it would be way too many things in there and not organized the way I like (putting executables with support files or categories). I don't notice a slow problem really. I do think you have a good point about running stuff with a period though. I will probably remove the current directory from the path.

Yeah: there's nothing wrong with having the current directory in the list, but I wouldn't want to give the impression that it's optimal to reference it at the front of the search path. This will result in a lot of needless thrashing around on the logged volume (and any other folders on disk referenced by the path) before the system can even find, for example, the "DIR" command on CAR:. You won't notice it so much on a hard disk, but you'll certainly notice it should you log a floppy or SIO device and invoke a directory listing with SDX 4.47.

 

I'm still a bit wooly on the whole 'PBI drive' situation and that was going to be my next question!

Using tools like KEdit is a real culture shock! I do not doubt the programmer is highly skilled - its a testament to that when you consider how much functionality he has built in to the programme given the limitations of the system. As I say it feels VERY similar to Vi and I feel almost... I don't know, like someone coming to computers totally fresh when I try to use it. A fascinating experience.

I know that Konrad had undertaken development on (IIRC) a disassembled copy of the A8 version of VI65 (again, IIRC), but I was not aware he had completed his work. I assume that's what this is. Quality is assured.

Edited May 7, 2015 by flashjazzcat

[morelenmir]

So... FJC... The PBI disk drive.

 

Obviously if I was just using the SIDE2 alone I would still have a pseudo disk drive - the cartridge would emulate it using a CF card. Now with the Ultimate1MB; among many other treats you gain a PBI device. I assume this means it emulates a hard-drive connected to the parallel bus slot at the back. Could you explain simply why that is preferable? Obviously in reality the Ultimate1MB still needs the SIDE2 to provide this feature and it is still using the same cartridge/CF card to do so. This has got me a little confused. This is also the reason why I am still using a SIDE driver as you noticed - simply because I didn't know I didn't need to! Ignorance is never pretty.

 

Next question. Why, when I use 'SDXImager' to edit-in-place and change the contents of the user-area of the 'gestalt' ROM of the Ultimate1MB will Altirra no longer boot and indeed not just that, but crash totally at start up? As you mention it is much quicker to use this tool to edit the SDX ROM that has been flashed to the simulated Ultimate1MB than going through the whole SDX flasher disk/uFlash approach.

[flashjazzcat]

Could you explain simply why [the PBI hard disk] is preferable?

1. It's bootable. You can boot any DOS straight from the hard disk, using a stock OS. You can also boot from a mounted ATR disk image (see below)

2. It consumes no user RAM (all the driver code is banked in and out under the OS math pack)

3. It supports (among other things) dynamic partition mounting and ATR disk image mounting, neither of which the soft-driver allows

4. It can be used with any DOS which supports hard disks

 

Obviously in reality the Ultimate1MB still needs the SIDE2 to provide this feature and it is still using the same cartridge/CF card to do so.

It seems a little odd at first, but all the SIDE2 cartridge is providing in the PBI scenario is a compact flash card slot and IDE registers mapped at $D5xx, and NOTHING else at all. SDX and the upper (external) cart space on the cartridge are completely inactive. Normally a PBI hard disk would require all the lines on the PBI bus in order to map the math pack in and out, etc, but because Ultimate 1MB is in a position to map what it wants in and out over the OS ROM, we effectively took an external PBI BIOS (such as you would find on the MIO or IDE Plus) and put it inside the machine. All the SIDE2 provides is the physical IDE hardware.

 

Why, when I use 'SDXImager' to edit-in-place and change the contents of the user-area of the 'gestalt' ROM of the Ultimate1MB will Altirra no longer boot and indeed not just that, but crash totally at start up? As you mention it is much quicker to use this tool to edit the SDX ROM that has been flashed to the simulated Ultimate1MB than going through the whole SDX flasher disk/uFlash approach.

Editing the whole 512KB Ultimate 1MB ROM image in the SDX Imager is not what I was suggesting. You should only edit the 256KB SDX ROM image, then flash it to the Ultimate 1MB (the upper 256KB of whose ROM is filled with other vital things, such as the BIOS). So: edit the SDX part in the SDX Imager, save it, boot Altirra, run uFlash, select the SDX slot, navigate to your edited SDX image, and flash that.

[morelenmir]

An excellent explanation FJC! I will mull over what you have written and then return with any further questions. MANY thanks indeed.

[fujidude]

 

I understood the intention, but having a cart without outdated SDX system files isn't ideal. It's hard to know how that could even happen if you've installed the latest SDX version, or flashed the latest APT-specific build from my website. If the intention is also to add drivers and applications to CAR which are not already on any of the existing builds, then the SDX Imaging tool for Windows (from the SDX website) makes adding files very easy. Flashing the resulting ROM should also be a five minute job using UFlash or the stock SDX flasher.

 

It's not that I'm unwilling to make a small effort to create my own custom ROM. Like I said, I've had problems rolling my own. It seems morelenmir also has had the same thing happen. I agree that the ideal situation is to have as much "on board" the cartridge as possible. As soon as I get a bit more time to fiddle with it I'll give it another go. There is a pretty good chance if I run into problems again I will be jumping in here waving my arms about looking for some of the excellent help I know you and others can provide.

 

 

Yeah: there's nothing wrong with having the current directory in the list, but I wouldn't want to give the impression that it's optimal to reference it at the front of the search path. This will result in a lot of needless thrashing around on the logged volume (and any other folders on disk referenced by the path) before the system can even find, for example, the "DIR" command on CAR:. You won't notice it so much on a hard disk, but you'll certainly notice it should you log a floppy or SIO device and invoke a directory listing with SDX 4.47.

 

Yeah, I'm running on hard disk (emulated under Altirra of course), so I don't notice much in the way of slow. Also I have the 65816 CPU at 21MHz emulated so that helps too. And before you ask, yes, when I run into problems I switch back in the good ole stock CPU to eliminate it as a cause of issue. Thanks for the help. I'll likely be needing more coming up.

Edited May 7, 2015 by fujidude

[morelenmir]

 

It's not that I'm unwilling to make a small effort to create my own custom ROM. Like I said, I've had problems rolling my own. It seems morelenmir also has had the same thing happen...

 

Did you also get the flat crash from Altirra? I found it odd that "SDXImager" could read the whole Ultimate1MB ROM well enough to identify the SDX part of it correctly and even what was in the user area - BUT on writing back changes to the user-area it must have muddled the ROM in some way which led to the crash. I guess it was probably a checksum-error or something along those lines.

[flashjazzcat]

I'm going to reiterate what I said earlier: Do not load the Ultimate 1MB ROM into the SDX Imager!

 

SDXImager is intended for editing the SDX ROM ONLY (hence its name). This takes up the lower half of the Ultimate ROM. You need to load the 256KB SDX ROM for Ultimate into the SDXImager, make the changes, save the SDX image, and then flash it to Ultimate's SDX slot using uFlash (which also allows you to extract the content of the SDX slot should you need to).

 

Do it this way and you should experience no problems whatsoever.

Edited May 7, 2015 by flashjazzcat

[morelenmir]

No worries FJC - I wasn't going to!!! I was just commenting it was odd that the Imager could load the SDX rom, but not put it back where it finds it!!!

Edited May 7, 2015 by morelenmir