Jump to content
candle

FAT32 XEX loader

Recommended Posts

I never had much luck with the stock MyIDE firmware. I had to use the MyIDE tools from within Parallels for the brief period I used it.

 

Mr. Atari released a new version of his MyIDE firmware/Os. Without SDX it works like a charm, really. The only problem is the FAT32. initialization. That is a stripped-stripped-stripped version of FAT32 boot sector, and no MBR. I already told Mr. Atari it is really some 'kindness' of Windows that it does accept it.

 

What you described is still interesting ( I already knew it) but it is not a solution indeed. The Mac doesn't even see my CF card as soon as I plug it in. And in terminal there is no volume either. (using diskutil -list)

 

My advice is to use 'factory' standard FAT32. This is: with mbr, and all the needed partition information. Mr. Atari uses a certain amount of the CF card for FAT32, the other space is just for MyIDE partitions and images. My advice would be: create a REAL smaller partition for FAT32, so the MyIDE space is un-allocated. That is by far the safest way of doing this. It prevents that the MyIDE space filled with MyIDE partitions and images will be formatted by accident.

 

I understand his problem, that the MyIDE OS is fuller than full. He has no space left for anymore. I suggested to use an external tool to make it 100% compatible for FAT32.

Share this post


Link to post
Share on other sites

No wonder he's running into problems if he insists on placing the partition editor in the OS...

 

Note - the approach taken by the APT partition editor is to simply write the MBR partition table to the disk. This is pretty easy. Leave it to windows to actually format the partition as FAT32 - it'll then write its own bootsector, etc. I'm sure there's often a degree of confusion surrounding all this. CF cards come - in general - with a simple floppy boot record in LBA 0. This is no use at all if you want to have the card shared between FAT32 and Atari partitions. The card needs a partition table. This is what the APT FDISK program (optionally) creates.

Share this post


Link to post
Share on other sites

Yeah it works good. You tell it you want a fat32 partition.. It then asks how big you'd like the APT partition to be.. When its done, you stick it in the PC, and the PC actually recognizes the size of the volume to be the CF card's formatted size, minus the size of your APT partition.. You then format it FAT32 with the PC, and throw your files on it.. Stick it back in the ATARI, and you can access the atari partition from SDX, or run the fat32 loader and access the files.. Stick it back in the PC, and it's just the fat32 partition it sees..

 

Could not ask for a more simple/automated solution..

  • Like 1

Share this post


Link to post
Share on other sites

APT really does work great and plays nice with the rest of the world. It's an example of how it's supposed to be done. If a PC OS treated HD's the way that the MyIDE OS does, people would be up in arms.

 

Using the MBR like you're supposed to is really the only way to do this "right". Even if he chooses not to adopt APT....if he just used the MBR to define a "MyIDE" partition that just represents what chunk of the disk MyIDE is allowed to use. He can write to, format, divide the space in that partition up any way he wants. APT and MyIDE could even coexist on the same volume then without much fear. This would also make backing up the Atari side of things easier.

 

It would not take a whole lot of effort, in fact the way he did things was probably the hard way. You don't need to format the FAT32 partition from the Atari. Kinda pointless. Looking for a MyIDE partition ID in the MBR and just using the start and end as the range he can read/write to might have been easier in the long run than trying to cobble together a non-standard mutant disk. It would certainly be cleaner.

  • Like 2

Share this post


Link to post
Share on other sites

Using the MBR might also make writing cross-platform utilities for reading/writing the Atari partitions a lot easier without as much voodoo and headscratching involved.

 

Now, if I formatted a CF card on a PC/Mac with a MBR and 128MB FAT32 partition at the beginning of the disk with the rest unallocated, would this drive work fine with his current firmware or would a mess be made?

Share this post


Link to post
Share on other sites

Have to agree with the above. All this cross-platform compatibility was, I think, one of the objectives of the APT design, although we've had precisely one publicly released implementation so far (i.e. mine, for SIDE and MyIDE). APT is perhaps not perfect (I doubt any partitioning design is), but it's extremely flexible and scalable and can be exceptionally "light" if this is what the implementation requires (after all, one need only use the fifteen drive mapping slots, and then the design is not dissimilar to the old IDEa KMK/JZ layout, and yet ostensibly compatible with SIDE's partitioning software). I can understand the curators of existing, well established hardware maybe not having the time or inclination to jump ship and adopt APT, but to bin your old partitioning scheme and implement yet another new, incompatible scheme for a device which already has APT drivers written for it (the SDX MyIDE driver), and which has versions of the XEX loader specifically written for it, is - to me - astoundingly pig-headed. Even I'm starting to become confused by the myriad partitioning schemes available for the MyIDE hardware, and the notion that these proprietary formats are also [gulp] applicable to the SIDE hardware makes me wonder what is the point of attempting to draw up standards intended to save time and inconvenience for programmers, developers and users alike. I only hope Zaxon can make the SIDE carts breed like rabbits.

Edited by flashjazzcat
  • Like 1

Share this post


Link to post
Share on other sites

My advice is to use 'factory' standard FAT32. This is: with mbr, and all the needed partition information. Mr. Atari uses a certain amount of the CF card for FAT32, the other space is just for MyIDE partitions and images. My advice would be: create a REAL smaller partition for FAT32, so the MyIDE space is un-allocated. That is by far the safest way of doing this. It prevents that the MyIDE space filled with MyIDE partitions and images will be formatted by accident.

 

So if I formatted a CF card on a PC or Mac with a real MBR, 128MB FAT32 partition at the beginning of the disk, 128MB APT partition next with the rest unallocated, this drive would likely work fine with the current MyIDE OS as it would use the unallocated space and ignore the space used by the standard MBR partitions?

 

I hate doing such a thing but it might be a workable temporary kludge until MyBIOS starts using APT or at least using the MBR. I use SDX most of the time but I want to be able to boot disk-based DOS as well. Booting ATR images would be nice too.

 

--Kevin

Share this post


Link to post
Share on other sites

i would like to stay on the topic for a while

if someone want to make personal rant over how myide software good is - please go ahead - but i highly doubt that Sijmen (Mr.Atari) reads this to take that into consideration

Share this post


Link to post
Share on other sites

i belive rants have their points when heard

ranting out and alone makes little sense

 

no need to apologise Jon

(ie starting new thread with that rant would be great ;D)

Share this post


Link to post
Share on other sites

Hmmm... patched OS with APT driver built in. Any takers? :)

 

I'll take it if you write it! That would actually be a big help with the cartridge interfaces for folks that want to boot something other than SDX at times, use SIDE-Loader and still have a relatively normal disk layout that standards-compliant OS's on the PC end won't vomit on. Would make writing apps to manipulate Atari filesystems on the PC side a little safer and easier.

 

Sorry for ranting on your loader thread candle :-) Sijmen's choices with MyIDE disk layout aren't your problem or side loader's.

 

Now an actual on-topic question.... would it be possible to integrate FAT16 support in SIDE-Loader for folks who got burned the same way I did while formatting but don't understand what happened? Would it be a lot of work? Not really critical at all but it might be less painful for some initially.

Share this post


Link to post
Share on other sites

probably it wouldn't be much work, as this would only change find_next_cluster and get_starting_cluster, plus some init

if i would start with fat16 and wanted to have fat32 now i would be in trouble by now

Share this post


Link to post
Share on other sites

Read and processing the information read :-)

My first FAT32-approach is indeed too quick&dirty.

Runs fine on Win-XP and during testing at myplace.

Sole reason being to support Candle's fat32 loader on a single media.

 

Have to dig into MBR-settings and learn :-/

This surely saves me some valuable OS-space having to remove the FAT32-formatter.

 

Thanks and catch you Later!

Share this post


Link to post
Share on other sites

i belive rants have their points when heard

ranting out and alone makes little sense

 

no need to apologise Jon

(ie starting new thread with that rant would be great ;D)

 

It's not a rant Sebastian... you'll know rant when you see it. :) In any case, remarks aren't exactly lonely.

 

Hmmm... patched OS with APT driver built in. Any takers? :)

 

I'll take it if you write it! That would actually be a big help with the cartridge interfaces for folks that want to boot something other than SDX at times, use SIDE-Loader and still have a relatively normal disk layout that standards-compliant OS's on the PC end won't vomit on. Would make writing apps to manipulate Atari filesystems on the PC side a little safer and easier.

 

I have no desire to gain kudos from such an undertaking, and I don't have much time to spend on it. I'm busy with GUI, which takes precedence over everything at the moment. However - especially in light of easy custom-OS installation these days, with Ultimate 1MB, etc - I think it's worth doing. If people want it, at the very least I need a complete, compilable assembly listing of the XL / XE OS (with PBI routines intact for now). Ideally, someone else should do it, but this may be one of those situations whereby if you want something doing, etc... but I'm sure there's no need to reinvent the wheel.

Share this post


Link to post
Share on other sites

Read and processing the information read :-)

My first FAT32-approach is indeed too quick&dirty.

Runs fine on Win-XP and during testing at myplace.

Sole reason being to support Candle's fat32 loader on a single media.

 

I deal with MS systems a lot as they make money but I don't use them personally though I have a Win7 VM I run on occasion for games and a couple of utilities. No Mac or Linux port of IL2-Sturmovik unfortunately.

 

Have to dig into MBR-settings and learn :-/

This surely saves me some valuable OS-space having to remove the FAT32-formatter.

 

It's not so bad, Wikipedia actually has a good article on it that breaks it down pretty well. There's large chunks you likely don't need. 440 of the 512 bytes is all x86 boot code for example.

 

Maybe some of the routines you used for the FAT32 formatter could be reused for some utilities to move files back and forth between FAT32 and MyDOS?

 

Thanks and catch you Later!

 

Thank YOU for looking into this!

Share this post


Link to post
Share on other sites

I have no desire to gain kudos from such an undertaking, and I don't have much time to spend on it. I'm busy with GUI, which takes precedence over everything at the moment.

 

Sounds like Sijmen himself volunteered above..... at least to try to implement MBR support. I would happily stuff his OS on an EPROM and have it switchable with a stock OS at that point. Full APT support would be even better but if MyIDE partitions and APT can at least coexist "the right way" with a proper partition, that's a big leap forward.

 

I'm looking forward to seeing that GUI running :-)

Share this post


Link to post
Share on other sites

MBR support is trivial if you keep the code which creates it outside of the "BIOS". The fact is that without the benefit of some PBI RAM to switch in, an HDD handler which is part of a custom OS is always going to be slightly limited. Hats off to Sijmen for creating something which works in those circumstances. I'll certainly have a crack at an APT implementation if I ever get time - it would be a challenge if nothing else.

 

Anyway - let's hope these incompatibilities get ironed out. :)

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

Okay, I got a working MBR/FAT32/MyIDE setup on a beta 4.7 MyBIOS :-)

 

Now, to be compatible with APT I like to know what it uses in the MBR.

 

As test I have created this on a 128Mb CF-card.

 

1 sector MBR

255 sectors reserved

$18000 sectors FAT32

$25700 sectors for MyIDE

 

Were does APT fit in?

 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 0B 00 00 00 00 01 00 00 00 80 01 00 00 00

00 00 26 00 00 00 00 81 01 00 00 57 02 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

Share this post


Link to post
Share on other sites
This should explain everything, Sijmen. The partition type for APT in the MBR is $7F. Anything you're not sure about, ask away - we'll be only to glad to help.

Share this post


Link to post
Share on other sites

Can you cut/paste an 512 byte example of a MBR with FAT32 and APT?

(just like I did with FAT32/MyIDE)

I found the $7F remark on the pdf, not sure I understand the rest.

I used $26, just because wikipedia says: reserved :?

 

Or, What would APT do when it reads the MBR a have cut/paste?

Share this post


Link to post
Share on other sites

Here's the MBR from a CF card I'm using:

 

Offset	  0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
00000000   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000010   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000020   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000030   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000040   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000050   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000060   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000070   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000080   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000090   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
000000A0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
000000B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
000000C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
000000D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
000000E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
000000F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000100   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000110   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000120   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000130   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000140   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000150   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000160   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000170   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000180   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
00000190   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
000001A0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
000001B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01				  
000001C0   01 00 06 00 01 3E 3F 00  00 00 00 88 0E 00 00 3F
000001D0   C1 FF 7F 0F 01 11 3F 88  0E 00 00 00 10 00 00 00
000001E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00				  
000001F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 AA

 

The card has a 952,320 sector FAT32 partition starting at LBA 63, and an APT at 952,383 which is 1,048,576 sectors long (the "wasted" sectors are because of my attempt to make everything line up on CHS boundaries for the sake of legacy drivers on the PC). You can see the $7F entry and all the attendant CHS tuples (again, set for legacy compatibility only).

 

As for the driver, since the MBR is not mandatory, on initialisation it needs to read LBA 0 of the disk and check for an MBR (using a combination of the magic bytes at the end of the sector and detection of legal partition table entries). If it finds an MBR, it should then look for the APT entry and extract the start sector of the Atari container (this links to the root sector of the APT chain itself). If there's no MBR, it may be that the root of the APT resides in LBA 0, so that condition should also be tested for.

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

Ok, this is usefull information, thanks.

The CHS boundaries are MyIDE-wise needed too, so that is a releave ;-)

I need some more reserved space, but that is no problem.

But I was NOT planning to setup CHS-parameters for legacy reasons...... (due to space limitation is the BIOS).

 

Hmmmmm, when I setup a FAT32 (0c) and a $26 partition, how does APT handle this card?

Would it reduce FAT32-space for it usage or destroy the $26 partition?

 

The new version will always write a MBR, reserving all space for MyIDE ($26).

Or add room for FAT32 and APT (if possible).

2nd hmmmm.

 

Later,

Sijmen.

Share this post


Link to post
Share on other sites

Yep - setting up the CHS tuples required a fair bit of math, and I wrote integer multiplication and division routines for the purpose. I would not like to try and write a partition editor which sits in the OS...

 

APT should totally ignore partition table entries it doesn't recognize, but the partition editor might not play well when first setting up the card. Send me some MBRs and I'll do some tests when you're ready.

 

Believe me, getting the MBR initialisation routines right (especially when KMK asked me to make the MBR optional) was quite a headache - and I had a reasonably large amount of code space to play with (far from unlimited, though, since the editor had to fit on CAR: in 8KB chunks). It's tight.

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