U1MB + SIDE2 (on XEGS) issues

[flashjazzcat]

No possibility of posting MBR as I requested in the other thread?

[phoenixdownita]

Sorry, completely forgot about that request.

I'll post it later (I'm at work right now), just found HxD I'll use that to capture a couple of blocks of the disk and post.

 

Once more thanks for lending a helping hand.

 

[obviously the combo works http://atariage.com/forums/topic/215870-new-to-u1mbside2-osb/ or we would hear more complaints]

Edited December 12, 2013 by phoenixdownita

[flashjazzcat]

No problem man... when you get time. The fact the combo works makes me think we should explore ALL the less-obvious possibilities.

[St(r)yker]

[phoenixdownita]

Nice mod just 2 things that are different for me.

 

I have an NTSC XEGS and SIDE2. I hope SIDE vs SIDE2 makes no difference.

Funny thing is if I load SideLoader from SIDE2 then I can read the scrolling line at the bottom, if instead I load SideLoader thru U1MB ("L") I cannot as it is past the end of the screen ...

weird maybe it's sets the video to a different mode, more PAL-ish.

 

I will try the same setup:

no XEGS mode jumpper

SIDE PBI ID 5

XEGS Game slot as CAR1

Stock OS

 

I won't hold my breath though. At this point we are still missing someone with an NTSC XEGS to show that it really works and it is not just for PAL machines, although that would be strange.

[flashjazzcat]

Something I just noticed after all this time is that the SIDE loader can only be invoked from the U1MB BIOS menu (via the "L" key) if SpartaDOS X is enabled. Otherwise the machine just reboots. I'm sure there are excellent technical reasons for this which I have forgotten about.

 

Sooooo... ensure you have SDX enabled in the Ultimate menu.

[phoenixdownita]

Something I just noticed after all this time is that the SIDE loader can only be invoked from the U1MB BIOS menu (via the "L" key) if SpartaDOS X is enabled. Otherwise the machine just reboots. I'm sure there are excellent technical reasons for this which I have forgotten about.

 

Sooooo... ensure you have SDX enabled in the Ultimate menu.

It's always been the case for my tests as that is the only configuration supported.

 

I attached the PNG of HxD screen dumps of MBR and FAT32 sector 0, I truly hope you find something obviously wrong but I'm not holding my breath ... let me know either way.

 

 

 

Edited December 13, 2013 by phoenixdownita

[AtariGeezer]

The MBR looks to be blank. Did you format this first on your PC?

[phoenixdownita]

The MBR looks to be blank. Did you format this first on your PC?

Not exactly, the last 2 bytes at 1FE,1FF indicate it is an MBR and around 1C0 there's some info.

 

This card was prepared thru MyBIOS R2 and then formatted on Win8. I believe there's enough info in that MBR for for 1 partition, the real MBR info is really on the last 68/70 bytes, the rest is usable by "boot-code" but in this case there's nothing.

According to here http://en.wikipedia.org/wiki/Master_boot_record#Sector_layout it appears there is info for only 1 partition (which is true) with metadata in the 16 bytes from 1BEH to 1CCH, that 0BH at location 1C2H looks like a FAT32 partition ID, the next 3 sets of 16 bytes starting at 1CEH are 0 probably indicating the remaining possible 3 primary partitions are empty [not present], I am no expert on disk layout but the fact that it looks almost empty does not make it invalid per se.

 

Although you may be right nonetheless, as I said I am not exactly an expert in disk layout structures.

According to here http://home.teleport.com/~brainy/fat32.htm the partition should be at least marked as active in the first byte (location 1BEH), maybe that is what throws off U1MB, not sure.

Edited December 13, 2013 by phoenixdownita

[flashjazzcat]

I attached the PNG of HxD screen dumps of MBR and FAT32 sector 0, I truly hope you find something obviously wrong but I'm not holding my breath ... let me know either way.

Thanks for those! Quite an interesting MBR in the first screengrab. It is indeed a valid MBR partition table: type $0B is FAT32 with CHS addressing, which I guess is OK (and what U1MB used until it was corrected to type $0C, which is FAT32 LBA addressing - nevertheless the PBI will pick up type $0B as well). The CHS values (ironically) are missing from the partition entry, but again this won't cause an issue on the Atari side, since APT FDISK only adds the CHS values to the partition table (and aligns the FAT on cylinder boundaries) for legacy compatibility reasons. I have no idea how MyBIOS goes about aligning and creating partition entries, but I kind of wish you'd just try a factory fresh card, or at least something partitioned from scratch with FDISK 4 instead of being prepared with MyBIOS. It might be fine, but you're trying to get APT stuff to work with APT software, and bringing a third party partitioning utility into the fray just seems to be adding unwanted complication. I think you mentioned you'd already tried factory-fresh FAT formatted CF cards, though.

 

The PBI ROM doesn't care whether or not the active (or boot) flag is set on the partition entry in the MBR, BTW.

 

So - the PBI ROM should grab the partition entry at power-up, read the FAT32 boot sector, and store pointers to the FAT and Cluster area in readiness for the SIDE Loader issuing a mount image command. FAT boot sector should be fine, since Windows prepared it, and I've heard of no compatibility issues in that area.

[phoenixdownita]

Interesting details about $0B and $0C partition types.

I have a CF coming in a few days and that will not be touched at all by MyBIOS.

I will try it first full FAT32 only then I will use FDISK4 [assuming there's a standalone XEX version not requiring SDX to run], in alternative I should be able to use FDISK1 as present in the SIDE2 SDX4.46a.

 

Regarding already trying with FAT32 only that was all before Candle told that XEGS mode has to be off for PBI to even have a chance, same is true for FDISK1 prepared CF, at the time I thought XEGS mode didn't hamper PBI.

 

If it turns out it is the CF I will message sijmen so he may be able to fix the info he puts in MBR/FAT32 alignement so that U1MB/PBI can access it correctly.

I really hate to have the same software in 2 CF, although to be fair if I get ATR to work from U1MB then the "ATR" support from image/partition space within MyBIOS becomes unimportant.

Edited December 13, 2013 by phoenixdownita

[flashjazzcat]

I will try it first full FAT32 only then I will use FDISK4 [assuming there's a standalone XEX version not requiring SDX to run]

FDISK 4 does not require SDX. You can use it with any DOS you want. Likewise MATR.

 

...I should be able to use FDISK1 as present in the SIDE2 SDX4.46a.

Note the older FDISK versions will be deprecated once FDISK 4 final is released.

 

If it turns out it is the CF I will message sijmen so he may be able to fix the info he puts in MBR/FAT32 alignement so that U1MB/PBI can access it correctly.

Well, the MBR you posted should be perfectly usable, but I'd strongly recommend flattening the card in Windows or using FDISK just so we have all bases covered, and lest we end up looking back on a testing strategy which deftly managed to ensure at least one thing was always broken, while others were fixed.

Edited December 13, 2013 by flashjazzcat

[phoenixdownita]

Well, the MBR you posted should be perfectly usable, but I'd strongly recommend flattening the card in Windows or using FDISK just so we have all bases covered, and lest we end up looking back on a testing strategy which deftly managed to ensure at least one thing was always broken, while others were fixed.

Got my Transcend CF today and it "kind of work", but the plot f**king thickens.

 

When it arrived it was 1 big empty FAT32 partition ~3.8GB.

I simply copied on it games (from atarionline.pl) and flasher ATRs that I made.

Quite a few games worked [Zybex 1,2,3, Mario Bros(v1), MULE(v3)] and a few don't but probably if they have custom SIO I believe PBI can't really fix them.

 

I tried the flasher ATRs and all the ones generated by TheRomGenerator lock up on a blue screen with no messages, instead the ones generated by U1MBRomB seem to work [haven't let them start the flashing per se but all messages come up as expected and they detect the correct flash type].

So this is bizarre.

 

I decided to FDISK1 the Transcend CF from SIDE2 SDX with 512MB to APT, the rest to FAT32, formatted FAT32 in windows, retried the flasher ATRs, same results.

Then FDISK1 again but 3000MB to APT, the rest to FAT32, formatted FAT32 in windows, retried flasher ATRs, same results. I thought maybe FAT32 > 1GB could be the cause of the trouble.

 

During these tests I was using XEGS OS and I tried XEGS Mode jumper ON or OFF -> it made no difference .... what works works in both modes, what doesn't simply doesn't and it fails the same way.

I guess this means the XEGS OS has all the hooks for PBI mode.

Given that XEGS Mode jumper on U1MB made no difference here then obviously my old tests that involved SIDE2 SDX FDISK with the other CF (DaneElec) where not affected by it as it seems it doesn't matter.

I tried the above also with HiSpeedOS and StockOS and again no difference whatsoever.

 

Finally I decided to reflash my U1MB with an image with PBI0.3.4 and also it made no difference, as soon as I put back the other CF (DaneElec) then it went back to SelfTest.

So the same setup depending on the CF either works or goes to SelfTest .... somehow I don't think it's an hardware issues anymore.

 

One of the big difference on the 2 cards is their internal name, the one reported by FDISK when it finds the disk, the Transcend one albeit quite long has no space in it, the DaneElec ones instead does, it contains a space in the middle of the string .....

I believe this to be the cause of quite some of the issues I am experiencing.

In specific Transcend name="TS4GCF150", DaneElec name="SMI MODEL", this is the string reported by FDISK, as well as by the SIDE driver inside of SIDE2 SDX, I can't tell for sure if that is a space or something else but that is how it looks.

I'll let fjc ponder on it as he owns the PBI drivers and the whole APT toolkit shebang.

 

Assuming the space in the disk name for the DaneElec CF causes the trouble with mounting ATR from SIDEloader past restart, I am still left with the problem that TheRomGenerator ATRs get stuck. Not sure why.

 

For a little I guess I can consider U1MB not the culprit, the CF seems to be partially to blame although it probably is a SW issue.

 

So to summarize:

1) DaneElec card

space in internal name

no ATR boot from SIDE2 + U1MB "L"

bizarre behavior depending on PBI version (Basic vs SelfTest)

 

2) Transcend card

no space in internal name

OK with ATR boot from SIDE2 + U1MB "L"

TheRomGenerator flashing ATRs lock up

HiSpeedOS, StockOS, XEGS OS all behave the same

XEGS Mode jumper On or OFF makes no difference wrt ATR booting

 

I believe the few ATR games I tried that had issues are probably due to custom SIO and I'll try to understand their behavior separately.

Edited December 15, 2013 by phoenixdownita

[AtariGeezer]

I tried the flasher ATRs and all the ones generated by TheRomGenerator lock up on a blue screen with no messages, instead the ones generated by U1MBRomB seem to work [haven't let them start the flashing per se but all messages come up as expected and they detect the correct flash type].

So this is bizarre.

 

This is strange as they should be using the same flasher?

Can you post the ATR of U1MBRomB?

Edited December 15, 2013 by AtariGeezer

[phoenixdownita]

This is strange as they should be using the same flasher?

Can you post the ATR of U1MBRomB?

I don't think it's the flasher per se but the "DOS"/PBI exchange, anyway here they go.

Ultimate2.atr comes from lotharek website and has the issue (I can upload the one I generated but they behave the exact same, lock up), U1MFlash is instead generated by U1MBRomB and starts just fine.

The layout as seen by AspeQt is quite different among the two.

 

BTW, using MyIDE2 (mounting the flasher ATR in partition space etc...etc...) I was able to actually get the TheRomGenerator ATR flasher to start, but that is likely thru soft drivers not PBIs .... but this is highly speculative, I'm not sure how that works.

 

Also FDISK1 in SDX4.46a (SIDE2) creates FAT32 with type $0B, I guess $0C is more recent. I checked the MBR on the Transcend which has never been touched by MyBIOS .... eventually it will to see if MyBIOS "partitioning" scheme had any part on my issues but that is for another week .

U1MFlash.atr

Ultimate2.atr

Edited December 15, 2013 by phoenixdownita

[AtariGeezer]

Thanks

I'll pop in a SSTSF040 in my U1MB and do some tests...

[phoenixdownita]

Thanks

I'll pop in a SSTSF040 in my U1MB and do some tests...

As I said I managed to flash mine once from MyIDE2 so I don't know if the lock is related to the flasher, I used Build019 that one time.

[AtariGeezer]

I don't think it's the flasher per se but the "DOS"/PBI exchange, anyway here they go.

Ultimate2.atr comes from lotharek website and has the issue (I can upload the one I generated but they behave the exact same, lock up), U1MFlash is instead generated by U1MBRomB and starts just fine.

Okay, the one from Lotharek's website uses an older version of the flasher, which is why you are having problems with that ATR...

 

The latest version of The ROM Generator can be found here:

http://www.fiftyonefiftysystems.com/Atari/TheRomGenerator/Dwnld.html

 

EDIT: If you download the U1MB ROM from http://www.lotharek.pl/zasoby/produkty/67/pliki/Ultimate1MBv2.rom and use that with the The ROM Generator, you'll have an updated ATR

Edited December 15, 2013 by AtariGeezer

[vazquezrick]

We'll I have now bricked my Atari 800xl containing the Ultimate. Similar issues, the flasher froze after it erased the EPROM. I order an EPROM burner to fix this issue.

 

I was running the flasher from my Side2.

 

Bummer

[phoenixdownita]

Okay, the one from Lotharek's website uses an older version of the flasher, which is why you are having problems with that ATR...

 

The latest version of The ROM Generator can be found here:

http://www.fiftyonefiftysystems.com/Atari/TheRomGenerator/Dwnld.html

 

EDIT: If you download the U1MB ROM from http://www.lotharek.pl/zasoby/produkty/67/pliki/Ultimate1MBv2.rom and use that with the The ROM Generator, you'll have an updated ATR

Not so fast, the lock in my case happens even before any message is on screen. And I did already try the newer one to generate the following ATR that still locks.

I repeat it never even starts.

U1MBFlashSparta-R2-XEGS.atr

Edited December 15, 2013 by phoenixdownita

[phoenixdownita]

We'll I have now bricked my Atari 800xl containing the Ultimate. Similar issues, the flasher froze after it erased the EPROM. I order an EPROM burner to fix this issue.

 

I was running the flasher from my Side2.

 

Bummer

No it's a different issue, in your case you have a flasher that mismanaged the SST39SF040, in my case it never even starts. The ATR seems to boot then it locks with blue background, no erase, no text on screen, no nothing. I guess in a way it is better but given I have an EPROM burner anyway, bricking for me would be a step forward.

 

Your problem is documented here: http://atariage.com/forums/topic/218746-looking-for-someone-to-flash-u1mb/?do=findComment&comment=2880809

Edited December 15, 2013 by phoenixdownita

[AtariGeezer]

Not so fast, the lock in my case happens even before any message is on screen. And I did already try the newer one to generate the following ATR that still locks.

I repeat it never even starts.

Okay, I took a SSTSF040 out of my spare Incognito and programmed it on my willem with a U1MB ROM, popped it in my 800xl with U1MB and booted fine.

I made an ATR with the latest flasher U1MBFlashSparta.atr and it was erased and programmed without any errors.

Then I used your U1MBFlashSparta-R2-XEGS.atr and it too erased and programmed without any errors...

 

I copied the ATR's on a SIO2SD and used that as my source. Your hardware configuration might be the cause?

[phoenixdownita]

.... Your hardware configuration might be the cause?

Welcome to my misery, the fact is it is a stock NTSC XEGS, with only U1MB and SIDE2 nothing else.

The lock with TheRomGenerator ATRs happens when booting from SIDE2, this I my second CF and it changed completely the kind of issues.

When I manage to boot TheRomGenerator ATRs from MyIDE2 there are no issues, flashing works.

 

I believe the SW is a little to blame here (U1MBBIOS/PBI/SideLoader/both/something-else), and likely only some CFs are supported in the end.

My first CF got no ATR boot at all from U1MB + SIDE2, now with my second I got somewhere but in particular the TheRomGenerator ATRs show still some issues. I am not saying they cause it, just that they make it manifest.

 

Because TheRomGenerator ATRs locks I suspect there are other perfectly working ATRs that locks on my rig so I am trying to hone in on the cause.

Edited December 15, 2013 by phoenixdownita

[flashjazzcat]

I believe the SW is a little to blame here (U1MBBIOS/PBI/SideLoader/both/something-else), and likely only some CFs are supported in the end.

 

Unfortunately, owing to the ad-hoc testing strategy and the unrepeatability of your issue anywhere else (thus far), it's a little bold to point the finger at the software. I've asked that you prepare a CF card from scratch with FDISK; please do before speculating further. If a CF card proves troublesome, that's a hardware issue.

[phoenixdownita]

Unfortunately, owing to the ad-hoc testing strategy and the unrepeatability of your issue anywhere else (thus far), it's a little bold to point the finger at the software. I've asked that you prepare a CF card from scratch with FDISK; please do before speculating further. If a CF card proves troublesome, that's a hardware issue.

Apologies if I offended you, I was just putting in words my hypothesis, which obviously can be wrong.

I'm holding such belief for now because switching CF causes PBI0.3.4 to SelfTest, and that can happen according to your comments, I really don't know how it works, by forgetting to switch back the mathpack. I really don't see how a weird/"maybe bad" CF could change the way switching in/out the mathpack would work, I find it easier to believe instead the SW hit an unforeseen condition and it exits before remapping it in .... again this is my speculation which can be completely wrong.

 

If you prefer we can continue this investigation thru PM, I don't want to give the impression that PBI and/or APT toolchain is buggy or anything like that, I'm really only interested in figuring out where the issues are wrt my setup. It will not be the first time that HW/SW only supports certain flash device and that's also OK once it's known and understood.

 

Regarding CF completely FDISK driven, I did.

 

The Transcend 4GB was first used as it arrived with only FAT32 but then it got FDISKed with 512MB APT and the rest FAT32 used in a bunch of tests then FDISKed again with 3000MB APT and the rest FAT32, this second test batch because I thought maybe the size of the FAT32 was the culprit.

In all 3 cases (FAT32only, FDISKed 512APT, FDISKed 3000APT) the behavior wrt mounting ATR was always the exact same, and the relevant ATRs that lock up are the flasher from TheRomGenerator.

 

The extra tests I did after those was to play with the XEGS OS and the XEGS Mode jumper on U1MB to see the different behaviors and I discovered it made no difference at all [i was expecting no ATR support at all with XEGS mode jumper instead it behaved as if it didn't make a difference, also I did't know if the XEGS OS itself supports PBI and once more it seems it does].

Those extra tests were just for me, I reported the results as interesting. I have no issue to focus on one OS for now (the stock OS) and leave the XEGS jumper off, I actually already did and I am using the "Stock OS" as it is in the Lotharek site ATR image [i extracted the Rom thru AspeQt and flash it directly]

 

Finally once I got to the FDISKed 3000APT I also reflashed my U1MB with a Rom that has PBI0.3.4 on it and got the same exact consistent behavior wrt ATR booting on the Transcend CF.

It is at this point that I put back the "bad" DaneElec CF and experienced the SelfTest.

I do not know the code that deals with this switching/booting/mounting but you do, my question is how bad does a CF have to be the cause such behavior? Meaning, what part of the code can detect/misdetect the condition and trip on a bad CF.

 

The other part about the lockup of the TheRomGenerator ATRs on Transcend is also puzzling, but it may be due to other causes. It reaches the blue background screen so it looks like it is past "booting" although I've had them work (on totally different setting) via MyIDE2.

 

I deeply thank you for lending a helping hand, make no mistake I'm not trying to belittle anyone else's work, just a little frustrated that after going thru EPROM burner, CPLD programmer, 2 CF, there are still issues to get the combo to work when all pieces works instead as single entities.

If at all the second CF should help rule out 99.9% U1MB hardware as I managed to boot quite a few ATR games, unless of course those lockup are the symptoms of some yet undiscovered/misunderstood hardware issues.

 

Also please understand that the only way that I have to use ATRs is either thru SIDE2 or thru MyIDE2, I have no SIO devices available to me at all.

 

 

EDIT: done more testing. [stock OS, XEGS mode jumper OFF]

Wiped both cards, used DISKPART from windows to delete every and all partitions.

Used SIDE2 in SDX mode to FDISK both of them with 3000APT, created 1 65535 "disk" on each, named C: marked bootable.

Upon power cycle, SIDE2 SDX recongize there's a C: drive in both .... so far so good the SIDE driver is working as expected.

Now put SIDE2 in loader mode, then on U1MB activate SDX and SideHW on with button.

Power cycle, and let U1MB SDX take over.

DaneElec CF does NOT show a PBI line at the top during U1MB SDX boot, cannot get into C:

Transcend CF does show PBI line at the top (ver0.3), can get into C: and DIR. yppiii!!!!

[obviously "L" only works on Transcend]

 

So SIDE soft driver (as in SIDE2 SDX] seems to be just fine with any CF, hard driver [PBI?, not sure if it's this code] as in U1MB SDX not so much.

 

EDIT2: same setup but used MyBIOS R2 to partition the card, no APT partition at all.

"L" works fine on Transcend -> MyBIOS was not adding insult to the injury.

 

I then re-wiped my Transcend to be FDISK only, for the future.

Edited December 15, 2013 by phoenixdownita