phoenixdownita

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.

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.

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.

Wasn't implying 100%, just that the HW seems to be doing ok under those conditions. But I do understand your argument, 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? 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.

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.

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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]

I got ahold of the ROM that according to http://atarimax.com/flashcart/forum/viewtopic.php?f=17&p=7944#p7944 works fine on 2 Atari XEGS, one with Lotharek's U1MB and one with Candle's U1MB with related SIDE2 Also the poster above stated that both of the U1MBs are set in XEGS mode ON with no issue. The poster told me that on the Rom there is PBI 0.3.4, the message exchange was thru PMs so it is not on that thread, but I attach the ATR and extracted ROM for interested parties to dissect (the OSes are HiSpeed, MyBIOS RE, OSb, XEGS OS). Anyway I flashed it to my U1MB and as I already experimented with PBI 0.3.4 it goes to SelfTest , except with OSb in which case it goes into MemoPad (never used OSb so not sure if this is the equivalent catch all state). As I was at it, I re-flashed and swapped the EPROMs of my SIDE2 and U1MB (an AM29F040B in SIDE2 and the SST39SF040 on U1MB) thinking maybe a timing issue but it made absolutely no difference, everything works on its own right but together they go to Basic with default U1MB rom or Selftest with PBI 0.3.4. Because I was frustrated I re-flowed and re-soldered every chip and socket on the XEGS motherboard as well as the cartridge connector and quite a number of other components all around and vias too, just to rule out cold joints or the like and of course it made no difference . At this point it can be one pin/wire of the cables/IC adapters but that one pin/wire must only be used during PBI reboot because the rest works quite well, or U1MB is busted or maybe my CF is the cause of the mishaps. I have a CF coming in a couple of days (a 4B Transcend) to rule out that component too. The last hypothesis is that I have a bizarre motherboard version and the SW is having trouble doing the right thing with it. As always I'll keep everyone posted , I know by now it sounds more like a menace, sorry ROMXEGS.atr ult1mb-from-ROMXEGS.rom

No news on my issues, but it appears that someone has the same combo and it works for him: http://atarimax.com/flashcart/forum/viewtopic.php?f=17&p=7944#p7944 Maybe my U1MB is really busted and it's time to send it back .... lotharek is still assisting but considering Candle has no access to his computer it may be a while before something positive comes out of it.... what a drag.

Landed safely over here. It all works. I'm kind hesitant in opening it up to butcher it in order to attempt to support "fix page 6 instead of Pokey" to test other 128K games. It does look neat and well done and I like playing commando on its own right. Oh well, I guess i should have asked for a spare PCB only + Pokey so I could have gone down to business.

Just ordered a 4GB CF, just so I can make sure there's no other software stack dealing with the data. It'll have 1 single FAT32, I assume that is all that is needed, or should I bother trying to create an APT piece driven by SIDE2 stand alone SDX? I'll report once I retest. On a different note, do you have a timeline in mind to release the whole nine yards of APT tools + PBI drivers? It'd be great if new SDX roms/PBI roms are available for SIDE/SIDE2/U1MB/MyIDE/... to incorporate all your hard work.

Hi there, still me with the XEGS issues. Today I took the PBI drivers from here http://www.atari8.co.uk/apt/ultimate1mb/Ultimate_1MB_PBI_BIOS_0.3.4.zip and flashed them on my U1MB, on top of a stock U1MBv2 rom. Now when i select an ATR from SideLoader ("L") with Enter instead of going to Basic it goes to SelfTest . If instead I press space it very quickly mark it as D1 then when I press Enter it goes to Basic , with whatever was stock PBI on U1MB instead pressing Space would take a little bit before marking as D1 ... and with or without marking it landed me in Basic when I pressed Enter. As Candle mentioned I cannot use XEGS mode to mount ATR in SIDE2, so I took out the jumper and I am testing normal mode only, and even no extra RAM and stock always starting U1MBv2 rom from lotharek site, then repeated test by replacing PBI roms thru theRomGenerator with 0.3.4 from the link and experienced the change in behavior reported] BTW, I can't seem to find anyone with an XEGS + U1MB + SIDE2 to confirm/refute if the ensemble works for ATR mounting ("L").

About my last post, obviously impossible mission is not in the list as it needs (S)RAM in that Pokey address space instead of page 6, but the rest is still possible and there's quite a few other 78SG with no (S)RAM to fill the blanks with

Hi santosp, haven't yet received my cart but I got thinking. I would probably replace the 27c020 with a 27c040 (the only difference is to cut your 27c020 PGM trace as that is A18 on 27c040) and use a second switch to select among 4 128K banks rather than the 2 available now. Now regarding making other 128K games beside commando work on your PCB I was reading http://www.atarihq.com/danb/7800cart/7800%20bankswithcing%20guide.txt and it appears that a way to swap Pokey with bank6 at $4000-$7fff (or maybe floating in same cases) is all that is needed to have the rest of the games marked as 78SG (SG=supergame) and without extra RAM to work. [in the doc 78S9 is for games that have an extra 16K of ROM mapped right there so 144K] I believe hardcoding bank6 and forget of the floating cases instead of Pokey would do the trick (you mentioned you had issue with Ikari warriors and I believe it is due to the lack of Bank6 mapped where Pokey is on Commando),. The 4 banks of a 27c040 would allow to put Commando + either 3 of Basketbrawl, Fatal Run, Ikari, fixed Impossible Mission, Midnight Mutants, Ninja Golf, Xenophobe, haven't decide what I care for the most but they all are kind of expensive on their own right A 27c080 is also a possibility as it only moves VPP [pin1] out of your way and uses it is as A19 [so a triple switch would work here with A17/A18/A19, pin30/31/1 respectively]. With a triple switch and a 27c080 and assuming we can swap Pokey for all but Commando (a selector can be made to default Pokey if triple Switch is OFF-OFF-OFF for example -> so Commando would have to be in first 128K), then we get 8 games to be available and that is plenty [actually I could fit my whole selection in there]. So my question is how hard would it be to find a way to switch a "fix" bank 6 on the $4000-$7fff with the Pokey [maybe this could be its own switch], I am afraid that the fact that Pokey just maps 16 addresses over the whole space made you design the PCB so it may be quite hard to retrofit the remaining decoding logic. I understand this could be the beginning of a multicard, but it seems what you did is so close that what would be needed to complete it almost begs to be done .