flashjazzcat Posted June 11, 2018 Share Posted June 11, 2018 The loader runs a lot of tight NMIs down the height of the screen, so if the menu blows up, it's a bus issue or a hard CPU crash. Quote Link to comment Share on other sites More sharing options...
+mytek Posted June 11, 2018 Author Share Posted June 11, 2018 I also find it hard to believe that the issue is limited to the XEL Loader. Looks more like a CPU problem to me. I have a an NCR version CPU that I got from Dropcheck's first 1088XEL build that was problematic and caused a similar effect, which then went away when I swapped in a non-NCR CPU. Not saying that all NCR CPUs are a problem, but the one in Dropcheck's unit was. I don't know what CPUs you have in your 1088XELs, but if they are NCRs that might be what's causing the aberrations you are seeing. Quote Link to comment Share on other sites More sharing options...
john_q_atari Posted June 11, 2018 Share Posted June 11, 2018 I also find it hard to believe that the issue is limited to the XEL Loader. Looks more like a CPU problem to me. I have a an NCR version CPU that I got from Dropcheck's first 1088XEL build that was problematic and caused a similar effect, which then went away when I swapped in a non-NCR CPU. Not saying that all NCR CPUs are a problem, but the one in Dropcheck's unit was. I don't know what CPUs you have in your 1088XELs, but if they are NCRs that might be what's causing the abbreations you are seeing. This is the CPU I have in both machines: Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 11, 2018 Share Posted June 11, 2018 Synertek. I don't see any problem there. Blown up loaders are actually quite a useful indicator of issues, and in the past (on non-1088XEL systems), the problem has usually indicated some flaky ribbon cable or intermittent connection somewhere on the board. I'd be inclined to suspect the same thing here, regardless of the fact the same thing is happening on two boards. You could, for example, have the same manufacturing error on both systems. I can sometimes produce an identical symptom by hot-swapping certain SD cards on a CF/SD adapter. The effect is similar to pulling a cartridge out of a running machine: NMIs get out of sync, menu blows up, and the system crashes. Quote Link to comment Share on other sites More sharing options...
john_q_atari Posted June 11, 2018 Share Posted June 11, 2018 Synertek. I don't see any problem there. Blown up loaders are actually quite a useful indicator of issues, and in the past (on non-1088XEL systems), the problem has usually indicated some flaky ribbon cable or intermittent connection somewhere on the board. I'd be inclined to suspect the same thing here, regardless of the fact the same thing is happening on two boards. You could, for example, have the same manufacturing error on both systems. I can sometimes produce an identical symptom by hot-swapping certain SD cards on a CF/SD adapter. The effect is similar to pulling a cartridge out of a running machine: NMIs get out of sync, menu blows up, and the system crashes. I think I have a spare XEL-CF2 and single CF card adapter. If I solder the adapter directly into the XEL-CF2 board would that be a good trial to eliminate the ribbon cable as the cause? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 11, 2018 Share Posted June 11, 2018 I was really referring to the MMU/OS ROM ribbon cable of a standard U1MB machine as frequent causes of this kind of bother, but dodgy XEL-CF ribbon cables will give you all kinds of problems too. I don't want to send you on wild goose chases, though: I'm simply speculating based on prior experience. Certainly eliminating the easier stuff (cables, etc) first is a good approach. Quote Link to comment Share on other sites More sharing options...
john_q_atari Posted June 11, 2018 Share Posted June 11, 2018 I was really referring to the MMU/OS ROM ribbon cable of a standard U1MB machine as frequent causes of this kind of bother, but dodgy XEL-CF ribbon cables will give you all kinds of problems too. I don't want to send you on wild goose chases, though: I'm simply speculating based on prior experience. Certainly eliminating the easier stuff (cables, etc) first is a good approach. Well it's the only actual ribbon cable in the system, and if I have those parts they are spares, and I don't mind soldering, so I might try it just in case. Looking at the 1088XEL schematic, I would assume everything that touches D0...D7 on the CPU constitutes the bus in question. And the bus seems to touch just about everything... Other than checking pull-up resistor networks and touching all bus connections again with the soldering iron (I already visually double check every solder connection I make as I assemble the 1088XEL), I'm not sure what else to do from a hardware perspective. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 11, 2018 Share Posted June 11, 2018 Ribbon's as good a place as any to start, then, since the hardware perspective is the only one from which changes can be affected here. Quote Link to comment Share on other sites More sharing options...
john_q_atari Posted June 14, 2018 Share Posted June 14, 2018 (edited) I was really referring to the MMU/OS ROM ribbon cable of a standard U1MB machine as frequent causes of this kind of bother, but dodgy XEL-CF ribbon cables will give you all kinds of problems too. I don't want to send you on wild goose chases, though: I'm simply speculating based on prior experience. Certainly eliminating the easier stuff (cables, etc) first is a good approach. Well I'll be... I have 3 U1MBs and 2 1088xel motherboards. 2 of the 3 U1MBs in either of the 1088xel systems results in the XEL loader glitching when reading a CF card that I partitioned in Linux, the last U1MB doesn't glitch when reading that CF card. How I can have 2 bad U1MBs baffles me. Perhaps the first one I converted headers on I could see maybe I damaged it with heat, but 2? I thought I got pretty good at swapping headers by now, though not sure that is/was the cause... Any CF card partitioned with FDISK v4.5 glitches with the one "good" U1MB. What FDISK should I be using to partition my card? When I load FDISK v4.5 it always seems to wipe any partitions already on the card. Edited June 14, 2018 by john_q_atari Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 14, 2018 Share Posted June 14, 2018 You have a sufficiently diverse variety of "glitches" that I would absolutely suspect anything which got desoldered/soldered, including the IDC headers. The U1MB is an integral component of the 1088XEL so I would be surprised to see random compatibility issues. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 22, 2018 Share Posted June 22, 2018 (edited) Thanks to Marlin pressing me on these loader glitches, we finally figured out the reason: the high-speed OS. The patched OS is really unnecessary now that Hias' high-speed SIO driver is built into the PBI BIOS, but since Candle left the high-speed OS in the default OS slot, a lot of people end up running it anyway. Whether they inadvertently end up running it alongside the PBI implementation (which I imagine would cause wildly unpredictable results) I do not know, but simply running the latest XEX loader with the high-speed OS revealed a problem caused by the patched OS replacing the loader's VBI code with its own during SIO calls. This frequently resulted in the loader's internal DLI counter going out of sync (since the VBI is responsible for resetting it at the top of each frame), causing a crash. The PBI implementation of Hias' driver does not cause this problem, since it only subverts the currently running VBI if the currently active SIO operation requires it (i.e. a divisor 0 transfer). The loader performs no high-speed IO whatsoever (indeed, it only issues API calls to the PBI BIOS), so there was zero chance of problems there. Unfortunately the patched OS relies on certain decisions being made at compile time, and the version of the patched OS in circulation clearly runs its own minimal VBI handler during SIO calls. In any case, and despite the fact there's little or no need to ever use the high-speed patched OS with the loader, the fix was easy enough and will be part of the final firmware. Hopefully that puts an end to this mystery once and for all. Edited June 22, 2018 by flashjazzcat 7 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 23, 2018 Share Posted June 23, 2018 Spent a little more time investigating the aforementioned issue today (in between trying to get my flaky broadband router running) and the loader was even more culpable than I'd originally thought. The code which supposedly fired on the final DLI of the frame (and which I fixed to reset the counter) was actually redundant (I'd miscounted the number of NMIs) and never fired at all, resulting in the display still being jumpy during SIO calls when the High-Speed OS was running. All fixed now, but I reckon this bug has been active for a fairly long time now. The High-Speed OS runs its own minimal VBI during every SIO call, regardless of whether any high-speed serial IO actually occurs, and were it not for that fact, I doubt the bug would ever have showed itself. 5 Quote Link to comment Share on other sites More sharing options...
cbelcher Posted July 4, 2018 Share Posted July 4, 2018 First time trying this device - it's an SD to IDE adapter from AliExpress - and it seems to be working. I know people had some luck with the SD to CF adapter that then plugged into the CF to IDE carrier. This is one step simpler and I'm not sure anyone tried it yet (although electonically, it's probably very similar). So if you're allergic to CF it may be worth a go... 5 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 4, 2018 Share Posted July 4, 2018 First time trying this device - it's an SD to IDE adapter from AliExpress - and it seems to be working. Got a similar device here which didn't prove very reliable when I was writing the firmware, but the one you've bought has a different board layout and is probably more modern. Will pick one of these up some time and give it a go. 1 Quote Link to comment Share on other sites More sharing options...
+mytek Posted July 5, 2018 Author Share Posted July 5, 2018 I just wish they didn't have the SD slot so far back into the board. Makes it pretty difficult if not impossible to panel mount that and still have access. 1 Quote Link to comment Share on other sites More sharing options...
+MacRorie Posted July 5, 2018 Share Posted July 5, 2018 First time trying this device - it's an SD to IDE adapter from AliExpress - and it seems to be working. I know people had some luck with the SD to CF adapter that then plugged into the CF to IDE carrier. This is one step simpler and I'm not sure anyone tried it yet (although electonically, it's probably very similar). So if you're allergic to CF it may be worth a go... cbelcher, I hate seeing naked 1088XEL boards. Not that there is ANYTHING wrong with not having it in a case, but . . . I did a test print of a case. It's not perfect, and I need to run a lid for it, but since I am going to run another print to test out some changes, I would *gladly* send you this case for the cost of shipping. Just so you could protect that nice piece of machinery (and I could sleep more easily at night . Again, nothing against it or anything, but I saw this post and I have this thing . . . . Let me know. (The backplane is just to show the fit, it is one of the things I need to tweak. It works, but not to my satisfaction). 5 Quote Link to comment Share on other sites More sharing options...
rockdoc2010 Posted October 26, 2018 Share Posted October 26, 2018 cbelcher, I hate seeing naked 1088XEL boards. Not that there is ANYTHING wrong with not having it in a case, but . . . I did a test print of a case. It's not perfect, and I need to run a lid for it, but since I am going to run another print to test out some changes, I would *gladly* send you this case for the cost of shipping. Just so you could protect that nice piece of machinery (and I could sleep more easily at night . Again, nothing against it or anything, but I saw this post and I have this thing . . . . Let me know. (The backplane is just to show the fit, it is one of the things I need to tweak. It works, but not to my satisfaction). Wow you have a printed case! so you do that sort of thing on your offtime..hehehe is this tru? also can i use two dual cf adapters? I really like the pretty blue top lid but i already have the dual backplane, so.....are these units compatible like the multi IDE cables suggest? Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted December 10, 2018 Share Posted December 10, 2018 Can I access my FAT32 partitions in SDX? I've got it all working through the loader, is it possible to DIR FAT: or something like that like you can with CAR:? I worked my way through the extended firmware user guide today, the SDX one is a bit of a more substantial read for a quiet evening. Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted December 10, 2018 Share Posted December 10, 2018 Try FATFS.SYS. Read the manual here: http://sdx.atari8.info/sdx_files/4.48/SDX448_User_Guide.pdf Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 10, 2018 Share Posted December 10, 2018 No: FATFS.SYS does not yet support FAT32. Use FAT16. Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted December 10, 2018 Share Posted December 10, 2018 OK Thanks, I'll take that 'yet' as a promising sign and wait. I can get stuff onto my apt partitions from disks inserted in the SIO2PC. Thanks guys! Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted December 11, 2018 Share Posted December 11, 2018 Sorry, missed the '32' part. The Loader will read / write ATR images on the FAT32 partition. Save file to the mounted ATR, then use Altirra Disk Explorer to extract the file from the .ATR image. The same works in reverse as well. Quote Link to comment Share on other sites More sharing options...
Evidious Posted December 22, 2018 Share Posted December 22, 2018 I finally have my 1088XEL done but i am having trouble with the XEL-CF all i get is it saying "waiting for media" what am i doing wrong and what format is the cf card? special thanks to Mytek and MacRorie for helping me. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 22, 2018 Share Posted December 22, 2018 (edited) Sounds like the card isn't being recognised at all and the loader is stuck waiting for the device to come out of a reset state. Check connections and ribbon cable orientation. The card should be reset and recognised by the loader regardless of what's on it. Once you get over that problem, you can just format it FAT16 or 32, fill it with files and they should show up. Also be sure you have the correct firmware on the board. If you happened to flash the stock U1MB/SIDE firmware, the loader will look in vain for the IDE controller on a SIDE2 cartridge. Easy verification is 'XEL Loader' across the top of the loader's display. Edited December 22, 2018 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
+mytek Posted December 22, 2018 Author Share Posted December 22, 2018 Here's a diagram I did a while back that will help with insuring you have the ribbon cable connected correctly. This same diagram is linked to from my AtariBits website on the following page: /1088XEL/xel-cf-drive 4 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.