flashjazzcat Posted August 31, 2013 Share Posted August 31, 2013 My guess is that at very high baud rates the SDX SIO driver is skipping interrupts, therefore skipping timer tickovers and fooling RWTEST into thinking less time has elapsed than actually has. Quote Link to comment Share on other sites More sharing options...
atari8warez Posted August 31, 2013 Share Posted August 31, 2013 My guess is that at very high baud rates the SDX SIO driver is skipping interrupts, therefore skipping timer tickovers and fooling RWTEST into thinking less time has elapsed than actually has. You may be right, as I don't see this behavior occur when I switch my U1MB to High-Speed OS mode and use SIO /A in my CONFIG.SYS, only when native SDX HS routines are used. Quote Link to comment Share on other sites More sharing options...
drac030 Posted September 1, 2013 Share Posted September 1, 2013 It is a known issue with ICD SIO drivers, that they disable interrupts for POKEY indexes below 4 or so. It is awaiting a fix. In meantime, you may use IDE+ serial routines which do not have this problem. Quote Link to comment Share on other sites More sharing options...
atari8warez Posted September 3, 2013 Share Posted September 3, 2013 Ok, thanks Quote Link to comment Share on other sites More sharing options...
+Larry Posted February 9, 2014 Share Posted February 9, 2014 I am preparing an SDX format CF card (HD) for my new SIDE2 cart. I prepared the card using the APT software on the SIDE SDX 4.46 CAR:. There is nothing wrong with the Sandisk card. If I take that card and insert it into the IDE+2 (also with SDX 4.46, this SDX can't read the disk. See the two pics -- same card prepared from the SIDE2 as read correctly on the SIDE2 but the directory is "jibberish" on the IDE+2. I thought that media from one device (using APT) was supposed to be readable on other devices? I have always used my sector copier "SECTRBAK.COM" to sector copy files from an APE backup image to/from hard drive -- IDE+2, MIO, Black Box, MYIDE. Nothing fancy, but works well. 256 byte sectors, written in Action!. Works with KMK's original FDISK2 partitions, but can't read and/or write to D1: from the APT-prepared partition. I can use the SIDE2 cart and its SDX to copy files to this partition, but I'd sure like to be able to sector copy these backups to the card. Any thoughts appreciated! -Larry Quote Link to comment Share on other sites More sharing options...
drac030 Posted February 10, 2014 Share Posted February 10, 2014 Ahm, that, strictly speaking, does not belong to SDX division, rather there is an issue with APT drivers. First, make sure that you have used the latest FDISK from FJC. I do not know if he has released it officially yet, but there are betas of FDISK4 either on his website or there in the corresponding thread. I would recommend using one of these, possibly the very latest one. Second, make sure that your IDE+ has the very latest BIOS (v.1.3) flashed into its PBI ROM. Version 1.2 is outdated and not fully compatible with latest amendments to the APT specs fjc has proposed and implemented in FDISK4. If both criteria are met, I am afraid, that I will need to take a look at the card's dumpfile... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 10, 2014 Share Posted February 10, 2014 (edited) I wonder if the SIDE driver on the cart is so old that it uses an incompatible DD interleave? I know Konrad and I synchronised on this eventually, but Lotharek is evidently selling the SIDE carts with v.1.0 drivers on them. Try something more recent from my website, or wait a day or two and download the brand new stuff. I'll send new ROMs to Lotharek as well. Edited February 10, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+Ripdubski Posted February 10, 2014 Share Posted February 10, 2014 Nice work! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 12, 2014 Share Posted February 12, 2014 I know Konrad and I synchronised on this eventually... May have spoken too soon there. IDE Plus appears to use two entirely different mappings for 128 byte logical sectors (which exist as boot sectors in DD partitions), depending on whether they are boot sectors in DD partitions or data sectors in SD partitions. Quote Link to comment Share on other sites More sharing options...
+Larry Posted February 12, 2014 Share Posted February 12, 2014 Hi Jon- Thanks for looking into this! One other thing that might be of note is that the SIDE2 SDX 4.46a cannot sector copy from a regular DD MyDos image. My HD backup program uses $E459 and does correctly read all sectors under cartridge SDX and IDE+2 SDX (using FDISK2). I don't know if that is meaningful or not, but I thought that I might be able to work-around the issue by using a regular MyDos backup. SIDE2 SDX does fine with "small DD images" but large HD images don't seem to work. -Larry Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 12, 2014 Share Posted February 12, 2014 Any program which copies sectors via a call to the OS SIO vector won't work with the soft-driver, which makes sense if you think about it, since the soft-driver works by patching into the SDX SIO table. Quote Link to comment Share on other sites More sharing options...
+Larry Posted February 12, 2014 Share Posted February 12, 2014 Is there another vector that will work? That would seem to be a significant limitation. An after-thought: that also means that any program that makes an SIO vector call will not work? -Larry Quote Link to comment Share on other sites More sharing options...
lemiel Posted February 12, 2014 Share Posted February 12, 2014 (edited) From manual - if I understand Jon correctly - http://sdx.atari8.info/sdx_files/4.20/sdx-4.20-manual.pdf This data table is referred to as COMTAB and is pointed to by the OS variable DOSVEC at memory location 10 ($0A). LSIO COMTAB-10 This is a pointer to the SpartaDOS high speed SIO routine. You can use the address contained here instead of $E459, the OS SIOV, to perform high speed sector I/O with your programs. Edited February 12, 2014 by lemiel 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 13, 2014 Share Posted February 13, 2014 (edited) Is there another vector that will work? That would seem to be a significant limitation. An after-thought: that also means that any program that makes an SIO vector call will not work? I don't quite know what you expect from these drivers. The only way to intercept calls to the OS SIOV is to hack the OS ROM or have a proper PBI device (and you can achieve the latter by pairing your SIDE with an Ultimate 1MB). The fact SDX runs from a cart and has its own SIO vector offers a unique opportunity to install a hard disk driver from ROM. This is why the driver was written, and why the SIDE cart was designed for it. A better solution to the sector copying issue would be to simply use a sector copier which calls LSIO. SDX is bundled with one, called HDSC. Edited February 13, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+Larry Posted February 13, 2014 Share Posted February 13, 2014 Hi Jon- Thanks to you and lemiel for the additional information. It's not a matter of what I expect from the drivers. I clearly did not understand this soft driver issue. Thanks to this episode and your explanation, I do now. But to me, it's a big issue that so many existing programs would potentially break. Thank goodness that pairing it with the Ultimate provides an excellent solution. And no problem patching the sector copier. -Larry Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 13, 2014 Share Posted February 13, 2014 (edited) No problem Larry. But to me, it's a big issue that so many existing programs would potentially break. Thank goodness that pairing it with the Ultimate provides an excellent solution. And no problem patching the sector copier. I can't really agree that a lot of programs will break, although I suppose it depends how much of the software you want to use with a hard disk performs IO by calling the SIO directly. Sector copiers and sector editors are two applications I can think of which access the disk directly via SIO, and we have examples (HDSC and EDDY) which work via LSIO, and therefore with the soft-drivers. All productivity applications should access the hard disk via the DOS filesystem, and again, these will work nicely with the soft-drivers. When the soft-drivers were all I had (used with a MyIDE cartridge at the time), with EDDY and HDSC, there was really no everyday operation I could not conveniently undertake. Of course, what you can't do using the soft-drivers is boot stuff from the hard disk and use a DOS other than SpartaDOS X. Certainly the Ultimate/SIDE solution is more capable and versatile, but with either solution, once you've booted SDX, operation is almost identical until you want to boot something else. Edited February 13, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 9, 2014 Share Posted March 9, 2014 http://www.atarimax.com/warpos/documentation/ Could you burn it to a 32 in one OS board and make it work that way? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 8, 2014 Share Posted April 8, 2014 Just noticed something interesting: SDX's copyright notice appears to reflect the date when the ROM was last edited with the SDX Image tool. Is this intentional? Seems slightly counter-intuitive, although I can kind of see the thinking behind it, if it's the case. Quote Link to comment Share on other sites More sharing options...
trub Posted April 11, 2014 Author Share Posted April 11, 2014 The date displayed by SDX upon startup (or VER command) reflects the time when CAR: directory was created. This allows to recognize (up to some extent) if the ROM file is "DLT original" or if it is modified by a user Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 1, 2014 Share Posted May 1, 2014 (edited) Does SDX keep a bank of extended RAM mapped in as the base bank when using OSRAM and with the RAMdisk driver installed? Ultimate 1MB upgrade, set to 1MB, v. 4.46, CONFIG.SYS: USE OSRAM DEVICE SPARTA OSRAM ... DEVICE RAMDISK At startup from the SDX prompt, PORTB reads $E1, which indicates one of the extended banks is mapped in at $4000-$7FFF, and indeed there is the boot sector of the RAMdisk sitting at $4000. Now, I run my application (without "X", in this case), and then check the state of PORTB after the program has loaded. Again, it is $E1, and the boot sector of the RAMdisk (or what is left of it) can still be seen in front of the program code in the banking window. If I then exit the application and attempt to get a directory of the RAMdisk, its root directory is scrambled. Since the application has not yet made any changes to the extended banks it detected, this would suggest that SDX loaded the application directly over the boot sector of the RAMdisk, situated in bank $E1. This issue has the fairly serious compound effect of making the application think that $E1 is the main bank (if the default value of PORTB is simply assumed to be the main bank). If $FF is written to PORTB after the application loads, it of course maps out the application code which DOS loaded into bank $E1, causing the application to immediately crash. The workaround is to not install the RAMdisk driver when using OSRAM. This appears to make DOS use the main bank as the default. If DOS is running in extended RAM, the problem does not appear to exist (as far as I can tell). Edited May 1, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 3, 2014 Share Posted May 3, 2014 This sounds like something that I have found and fixed about two months ago. To be sure I need to know what the rest of the CONFIG.SYS looks like. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 3, 2014 Share Posted May 3, 2014 (edited) This sounds like something that I have found and fixed about two months ago. To be sure I need to know what the rest of the CONFIG.SYS looks like. CONFIG.SYS as follows (slightly amended stock version, basically): USE OSRAM DEVICE SPARTA OSRAM DEVICE SIO DEVICE ATARIDOS DEVICE INDUS 4 DEVICE RTIME8 DEVICE JIFFY DEVICE RAMDISK Suppressing RAMdisk installation appears to fix the issue, as does USE BANKED, IIRC. Edited May 3, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
drac030 Posted July 12, 2014 Share Posted July 12, 2014 @fjc: sorry for my late answer, I forgot to reply. This was a problem with the old (until 4.46 inclusive) memory management code. It has been fixed since a year or something. @all: I have found a bug in CAR:UNERASE.COM. Until a new version goes out, please use the CLX program (from the Toolkit) after doing an unerase, to verify if the disk information is okay. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 12, 2014 Share Posted July 12, 2014 @fjc: sorry for my late answer, I forgot to reply. This was a problem with the old (until 4.46 inclusive) memory management code. It has been fixed since a year or something. No problem. Quote Link to comment Share on other sites More sharing options...
+Larry Posted January 1, 2015 Share Posted January 1, 2015 Hi- This is not really bug, I guess, but rather an incompatibility. SDX 4.46 appears to not properly read APE's PC mirror (used to read/write Atari files to/from the Windows PC). APE's PC Mirror is single density and a default 65535 sectors. I found this issue when trying to use UFLASH to update my Ultimate. The problem does not appear using AspeQt's folder options, so there is an easy work-around. -Larry 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.