phoenixdownita Posted December 15, 2013 Author Share Posted December 15, 2013 (edited) .... I copied the ATR's on a SIO2SD and used that as my source. Your hardware configuration might be the cause? Ever tried with a SIDE/SIDE2? Is it possible that the "DOS" that you embed into the ATR flashers forces SIO hence it won't work out in PBI mode? [big speculation on my part but it's an hypothesis] EDIT: Even when I use MyIDE2 to run the flasher ATR I have trouble. With U1MB SDX off it all starts fine then obviously the flasher code say "waiting for SDX card ...." and stops there as expected, if I turn SDX on on U1MB then the ATR boots off of MyIDE2 but it gets stuck without writing anything on screen, I need to press reset and this time it goes thru and I can see the flasher.com starting and doing its thing, so not sure if IDE based devices may have issues as opposed to SIO based devices. Edited December 15, 2013 by phoenixdownita Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 15, 2013 Share Posted December 15, 2013 (edited) 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. No offense taken! I have no objection to assisting you out here on the forums rather than via PM if that's what you prefer. Indeed, it may be useful to others if we ever get to the bottom of the issue. What's not useful to others (or to us) is to start drawing conclusions as if the root cause of the issue is being narrowed down, when in fact it appears to me that you nor I (nor anyone else who has spoken up) have any real idea what the problem is. It often happens, of course, that people get frustrated when things don't work and they want to blame the hardware or the software. I've done it myself; sometimes I was right, but sometimes I was wrong, and it transpired I'd been making some repeated user/installer error. As for the boot to Basic / Self-test thing: well, I really thought for a moment that I'd managed to replicate the issue in emulation there while setting up Altirra in Wine on Linux Mint 16. No way, no how would the emulated U1MB machine boot an ATR, but it was possible to read and write to them. Well, it turned out I'd forgotten to check "SIO Override detection" in Altirra's disk settings, so the Atari wasn't even attempting a PBI boot. I really thought I'd discovered some (admittedly completely perplexing) software issue there, but it was the kind of user error I describe above. Regarding CF completely FDISK driven, I did. Good. 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. Well, now we get to the bottom of it. These CF cards are "block" devices, so providing the controller can reliably read sectors (and react to IDE busy states, etc), it will basically work. By a "bad" CF card, we usually mean something which causes timing issues which result in transmission errors, and once reliable communication between the Atari and the media has been lost, well - naturally not much will work reliably. So, how "bad" does it have to be? Not very would be the answer, since if a dropped byte and a double read occur at the hardware level when the PBI ROM is reading a sector, there's no programmatical method of determining what data is invalid (unless we apply our own checksums to sectors, but fortunately the days of software error correction in hard disk drivers seems to be at an end, otherwise we'd still be enjoying 25KB per second transfer rates). In short, the drivers tend to assume that the controller is at least communicating reliably with the device. Repeated transmission errors (which I must say are unusual with modern controllers) would result in a non-booting ATR if when the Atari was booted for the first time (with the CF card in place, and before running the SIDE Loader), the PBI ROM was unable to identify the FAT on the card. It would then fail to register the first FAT partition in the RAM-based partition table. However, it would also report an error to the SIDE loader when the latter attempted to mount the disk image. I deeply thank you for lending a helping hand, make no mistake I'm not trying to belittle anyone else's work... No problem - and my pleasure. I don't mean to seem like I'm overreacting. It's just I'm as frustrated as you are, in a way, and it's essential that we are utterly pragmatic in diagnosing the issues at hand. Of course there's always a "fear" that software will be to blame (after all, it's possible), and drivers like these are especially critical things. I hate to think of some lurking issue that we can't nail down however hard we try. Edited December 15, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 15, 2013 Author Share Posted December 15, 2013 (edited) ... Of course there's always a "fear" that software will be to blame (after all, it's possible), and drivers like these are especially critical things. I hate to think of some lurking issue that we can't nail down however hard we try. What do you make of the fact that when both cards are prepared with FDISK1 in SIDE2 they are working from SIDE2 SDX exactly as expected via the SIDE drivers, both can create drives inside the APT, both upon reboot get recognized and the C: volume automounted. But as soon as I switch SIDE2 in loader mode and activate SDX from U1MB (SIDE HW on with button) then the DaneElec does not show the PBI startup/boot text line and obviuosly doesn't work, but the Transcend is just fine and shows the PBI text at startup and recognizes the CF as well as the created C: drive. [no SideLoader in the picture at all here, just letting U1MB boot in SDX and have SIDE2 pose as the PBI device] My point being what's so different between the SIDE soft driver and the PBI driver once it comes to recognize the CF and read the partitions and APT out of it. After all in the 2 cases the HW involved [sIDE2 + CF] is the exact same, so I would think if that part of the HW chain is at fault even the SIDE2 driver will have trouble at one point or another when dealing with the CF. Edited December 15, 2013 by phoenixdownita Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 15, 2013 Share Posted December 15, 2013 (edited) What do you make of the fact that when both cards are prepared with FDISK1 in SIDE2 they are working from SIDE2 SDX exactly as expected via the SIDE drivers, both can create drives inside the APT, both upon reboot get recognized and the C: volume automounted. But as soon as I switch SIDE2 in loader mode and activate SDX from U1MB (SIDE HW on with button) then the DaneElec does not show the PBI startup/boot text line and obviuosly doesn't work, but the Transcend is just fine and shows the PBI text at startup and recognizes the CF as well as the created C: drive. [no SideLoader in the picture at all here, just letting U1MB boot in SDX and have SIDE2 pose as the PBI device] My point being what's so different between the SIDE soft driver and the PBI driver once it comes to recognize the CF and read the partitions and APT out of it. After all in the 2 cases the HW involved [sIDE2 + CF] is the exact same, so I would think if that part of the HW chain is at fault even the SIDE2 driver will have trouble at one point or another when dealing with the CF. Well, I've taken that PBI notice out of the latest (unreleased) ROMs since it's probably more trouble than it's worth. Don't rely on its appearing or otherwise to tell you whether the card works or not. Test it. Same goes with the soft driver's boot message: it might appear, but can you actually use the reported partitions for anything useful? Have you run stability tests on them? Have you tried RWCRC when you find yourself confronted with an apparently working partition? So can you therefore assert that the SIDE2's soft-driver is 100 per cent error free, when compared to the PBI ROM? Regarding the differences between the SIDE soft-driver ad the PBI: we can't just assume that software is going to behave identically when you're introducing and taking away banked ROM space (by enabling/disabling the PBI), and even booting DOS from a different physical source. If things are marginal with the DaneElec in the first place, altering the hardware environment might just tip things over the edge sufficiently that transfers fail altogether. The fact that two drivers which recognize the same partitioning scheme act differently with the same media when you introduce banked ROM under the floating point package and RAM under the hardware registers doesn't point to driver issues to me... the inconsistency would seem to point to hardware. If your Transcend works and the DaneElec is causing trouble, put that DaneElec to one side for a moment, and at least remove one element of haphazzardness from the testing. Edited December 15, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 16, 2013 Author Share Posted December 16, 2013 (edited) ... can you therefore assert that the SIDE2's soft-driver is 100 per cent error free, when compared to the PBI ROM?Wasn't implying 100%, just that the HW seems to be doing ok under those conditions. But I do understand your argument, Regarding the differences between the SIDE soft-driver ad the PBI: we can't just assume that software is going to behave identically when you're introducing and taking away banked ROM space ........ ....... when you introduce banked ROM under the floating point package and RAM under the hardware registers doesn't point to driver issues to me... the inconsistency would seem to point to hardware. I was really just asking what are the differences, and there's a lot more than I expected. BTW in PBI mode, who kicks the PBI rom to recognize the CF? Is the U1MB bios that does the first reckon or does it just let the PBI take over the whole task? If your Transcend works and the DaneElec is causing trouble, put that DaneElec to one side for a moment, and at least remove one element of haphazzardness from the testing.I understand this point, I guess I really would like to find the root cause even if it turns out to be a timing issue or a non conforming CIS, but for now I'll set it aside. I was able this afternoon to go over quite a few ATRs [50 or so] and most worked without a hitch. A few don't quite work but that can be due to custom SIO. I am then left for now with the puzzling TheRomGenerator lockup during the boot process, not sure what's going on there. On a totally different note the fact that my XEGS is NTSC is not helping either, I've had quite a few instances of "flashing/glitching" games where the screen seems to "bounce" once in a while (like each second or less) making them unplayable, in your opinion can it be due to NTSC/PAL differences? ... a few of those games have Polish writings. Anyway I will wait for your release of the improved APT toolchain which I presume will include upgraded SDX images for U1MB and SIDE. Thanks for listening to my rants. Edited December 16, 2013 by phoenixdownita Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted December 16, 2013 Share Posted December 16, 2013 I am then left for now with the puzzling TheRomGenerator lockup during the boot process, not sure what's going on there. I really don't see how that's possible as the ATR that's created is a validated SpartaDOS image and the flasher is the latest created by Trub that I verified last night to work just fine... 1 Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 16, 2013 Author Share Posted December 16, 2013 I really don't see how that's possible as the ATR that's created is a validated SpartaDOS image and the flasher is the latest created by Trub that I verified last night to work just fine... I don't understand why it would lock, I only know that it does (on my setup). This is my first CF that actually boots ATRs at all, so it may be still something with the CF (again) or with U1MB or with SIDE2 or with the XEGS ... still too many variables, I can still use the other flasher (or go hardware with the EPROM burner) so I'm not going to sweat this one out, just pointed out something that should work but behaves odd. I'm not saying that what TheRomGenerator does is inherently wrong/buggy, just stating what happens to me. Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted December 16, 2013 Share Posted December 16, 2013 Didn't Ultimate have a problem flashing the rom if the Side cartridge was still plugged into the cartridge slot..at one time I bricked my SIDE cartridge and had to re flash it because the flashing program could not tell which rom to flash since they're both the same chip.. Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted December 16, 2013 Share Posted December 16, 2013 Didn't Ultimate have a problem flashing the rom if the Side cartridge was still plugged into the cartridge slot..at one time I bricked my SIDE cartridge and had to re flash it because the flashing program could not tell which rom to flash since they're both the same chip.. Yep, same happened to me 2 years ago. U1MB Flasher was updaed shortly after that... Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted December 16, 2013 Share Posted December 16, 2013 I don't understand why it would lock, I only know that it does (on my setup). This is my first CF that actually boots ATRs at all, so it may be still something with the CF (again) or with U1MB or with SIDE2 or with the XEGS ... still too many variables, I can still use the other flasher (or go hardware with the EPROM burner) so I'm not going to sweat this one out, just pointed out something that should work but behaves odd. I'm not saying that what TheRomGenerator does is inherently wrong/buggy, just stating what happens to me. Yep, it's definitely weird The only difference between mine and Rays is that he uses SDX boot sectors and mine creates a bootable SpartaDOS 3.3 ATR... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 16, 2013 Share Posted December 16, 2013 (edited) Well I'm afraid that my intuition suggests that all the lock-ups and intermittent faults point to basically unstable hardware. Every time I've worked on a machine which behaved like this, there was a dry solder joint or a timing issue which required a replacement CPU or similar. Edited December 16, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 16, 2013 Author Share Posted December 16, 2013 Well, if that is indeed the case I guess it's all headed for obliteration. I can probably re-sell U1MB, SIDE2 and MyIDE2 losing likely 20% which for all the fun I had with them is not so bad, they kept me busy across a few week-ends. The XEGS instead can hit the recycle pile of the local electronic shop. Problem solved. Amen. 1 Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 22, 2013 Author Share Posted December 22, 2013 (edited) Yep, it's definitely weird The only difference between mine and Rays is that he uses SDX boot sectors and mine creates a bootable SpartaDOS 3.3 ATR... A happier chapter to the saga. As I stated many times before the TheRomGen ATRs lock up on me on a blue background a few sec in (loading the ATR via U1MB Setup menu then "L" thru SIDE2), but I just discovered that after the lockup if I bring up the U1MB setup menu (HELP + RESET) then quit (press Q) without doing anything else at all I can see the U1MB SDX starting its merry way and then automagically boot the flasher, no lockup this time. I guess the selected ATR info (from U1MB "L") survives in RAM at the HELP + RESET followed by Q, and SDX can recover it and boot into it just fine, not sure, just reporting. In a way it makes me happy as I have one method to use TheRomGen ATRs to flash to my heart content. On other topic I went thru quite a few ATRs (say 100 or so) and the vast majority boots without any issue whatsoever, I found out the hard way that Eidolon 128K requires CompyShop mode for U1MB extra mem.... is there a list of extra mem games and what "mode" they support? Also found out that many games I tested with "gfx screen bounces" were due to being PAL so simply misbehaving on NTSC, quite a pity as some looks interesting but the screen bounce makes them borderline unplayable. Edited December 22, 2013 by phoenixdownita 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 23, 2013 Share Posted December 23, 2013 So ATRs suddenly work? What changed there? Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 23, 2013 Author Share Posted December 23, 2013 So ATRs suddenly work? What changed there? ATRs on a Transcend CF over SIDE2 were fine already, my issues were with the previous CF I was attempting to use (a DaneElec CF), with the exclusion of TheRomGen flasher ATRs. Those ATRs "PBI booted" on Transcend CF but locked up before any message on screen at a blue background, not sure if they were supposed to be run on real SIO only. Anyway the change has obviously been a different CF to get ATR recognized at PBI time. Limited to the TheRomGen flasher ATRs only I've noticed the combination reported above. Namely let them lockup, press HELP+RESET then at the U1MB setup screen simply press Q to quit. Wait a little, at this point U1MB SDX takes over and somehow it boots the flasher ATRs which this times around doesn't lock. [During the tests I had SDX on, SIDE HW on with button, PBI 1, XEGS stock OS from slot 4 and XEGS mode jumper on, none of these settings was touched or changed during the experiments] Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 23, 2013 Share Posted December 23, 2013 Right. Well it was never clear to me from your descriptions that you had any ATR on any CF card working. This is exactly the kind of chaotic troubleshooting I was talking about. So neither hardware nor software were to blame... Sigh. Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 23, 2013 Author Share Posted December 23, 2013 (edited) I don't mean to rub you the wrong way but I still believe there's some secondary SW incompat. The fact that the DaneElec card wouldn't work well under "PBI boot" only may be a symptom. Granted it is possible that the DaneElec card itself could be a little out of standard as well so I won't push this any further, we're talking about 8US$ shipping included and I can use it just fine with MyIDE2 and any non "PBI boot" related "work" .... sorry meant to say "play". The only issue left that escapes my understanding are the TheRomGen flashing ATRs locking up. Maybe they were meant to be booted from SIO, not sure, but as far as I am concerned it's the last not well understood issue. Also why would it work upon HELP+RESET followed by Q is beyond my knowledge. Be as it may I already mailed both Lotharek and Candle that I don't hold the U1MB/SIDE2 HW responsible for my woes ... which really means I won't be returning them any time soon. I am looking forward to your new releases, after all if I get it right you are "the guy" we owe to to get PBI support at all on these devices, so "hats off" to that for sure. Edited December 23, 2013 by phoenixdownita Quote Link to comment Share on other sites More sharing options...
candle Posted December 23, 2013 Share Posted December 23, 2013 side loader disables sdx whereas atr made by theromgenerator reuqires its presence simplest option is to add possibility for side loader to leave sdx enabled, which would ruin 95% bootable atr images if made default behaviour Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 23, 2013 Share Posted December 23, 2013 (edited) I don't mean to rub you the wrong way but I still believe there's some secondary SW incompat. The fact that the DaneElec card wouldn't work well under "PBI boot" only may be a symptom. Granted it is possible that the DaneElec card itself could be a little out of standard as well so I won't push this any further, we're talking about 8US$ shipping included and I can use it just fine with MyIDE2 and any non "PBI boot" related "work" .... sorry meant to say "play". Well, yeah it seems that SIDE doesn't like the cheap DaneElec card. This is just one of those isolated quirks, and it's why you try a couple of different CF card brands if you're having issues (and it seems you did, and experienced success with another, which I somehow failed to deduce). There's no software incompatibility to "believe" in: these drivers all work the same way, in as much as they drive the IDE controller according to the ATA specs. If hardware quirks create issues, it's not the software's fault. Sure, we can try to compensate for missed/double reads in software, but that's a hit and miss solution anyway unless you want to go the whole hog and have checksums, etc, which cripple the transfer speeds. The software assumes the hardware works. It's as simple as that. The software cannot be "incompatible" with a Compact Flash card which operates as an ATA device. What I was worried about was some kind of logic bug in the ATR booting, and this caused me to scuttle away and do a lot of double-checking and testing. Fortunately I was working on APT stuff at the time anyway, so doing some extra testing is probably no bad thing, I suppose. Be as it may I already mailed both Lotharek and Candle that I don't hold the U1MB/SIDE2 HW responsible for my woes ... That's the bit I almost missed. Fortunately I spotted the latest post, and can now stop wondering if PBI mounting is broken in the drivers as well. Edited December 23, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 23, 2013 Author Share Posted December 23, 2013 (edited) side loader disables sdx whereas atr made by theromgenerator reuqires its presence simplest option is to add possibility for side loader to leave sdx enabled, which would ruin 95% bootable atr images if made default behaviour So to make it clear the theromgenerator ATRs cannot currently boot from U1MB+SIDE2 because they require SDX to be still on while SideLoader turns it off for compatibility with pretty much everything else? And they never worked directly unless booted from a SIO or after being in SDX already? I like that this mystery is now not a mystery anymore. I'm really looking forward to a flashing solution for U1MB that works with the combo U1MB+SIDE2 only. In any case we should document that for now TheRomGen flashers do require SIO. Somehow I cannot believe I am the only one that stumbled on this problem, am I the only one flashing from SIDE2? Edited December 23, 2013 by phoenixdownita Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 23, 2013 Author Share Posted December 23, 2013 (edited) Yep, it's definitely weird The only difference between mine and Rays is that he uses SDX boot sectors and mine creates a bootable SpartaDOS 3.3 ATR... Candle just gave an explanation http://atariage.com/forums/topic/218960-u1mb-side2-on-xegs-issues/page-3?do=findComment&comment=2891241, maybe it could be worthy to have the TheRomGen generate ATRs with boot sectors as an option for people like me that only have access to a SIDE2 device. I don't know how much work that would be or how hard, but at least we now know what could be needed, and also why they don't quite work for the time being. Edited December 23, 2013 by phoenixdownita Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted December 23, 2013 Share Posted December 23, 2013 I don't know much. The ATR created by TheRomGenerator does in fact have "Boot Sectors" + SpartaDOS 3.3 in case someone tries to load the ATR without having SDX enabled... The current flasher requires SDX to be enabled in order for the flasher to work, which is the way it's been for the last couple of years... You're still making assumptions as to what should or shouldn't be, so until you fully understand the inner workings of what's going on, stop blaming software... 1 Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted December 23, 2013 Share Posted December 23, 2013 Well, I was able to flash my U1MB from the FAT32 partition on my SIDE cart It works when the ATR created by TheRomGenerator is selected as "D2:" from the Side Loader, but not D1. Will investigate after sleep time... Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 24, 2013 Author Share Posted December 24, 2013 How do you do that? If I select a random ATR (marked D1) then the flasher (marked D2) then deselect D1, and try to launch D2 I get a "D1 not mounted" error at the bottom of the screen of SIDEloader. Do you keep an "empty" ATR as selected D1? Also when you say it doesn't work as D1, what happens in your case? Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted December 24, 2013 Share Posted December 24, 2013 Scratch that, as it seems to have worked 1 out of 3 times upon further testing. No reset was used... Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.