_The Doctor__ Posted February 28, 2018 Share Posted February 28, 2018 which is kind of where you can see my understanding that trailing comments could be a problem and in the count... true or not that's how it appeared to me.... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 28, 2018 Share Posted February 28, 2018 I would imagine the problem with line length happens long before the parsing phase. If the CP asks the system for an EOL-terminated line of no more than 64 characters and it's > 64 characters long, a truncated record is the result. Quote Link to comment Share on other sites More sharing options...
fujidude Posted February 28, 2018 Share Posted February 28, 2018 The following batch file generates a "File not found" error, so I think we may conclude that white space ahead of the semicolon is disallowed: ; comment ; comment Page 115 of the manual says: Seems to work as per the description, although one could argue that the "skipped line" behaviour is inconsistent with the fact that comments may have leading space if placed after parsed commands. Not to mention the fact that actual parsed commands are allowed to have leading spaces, and in fact the manual and disk based code examples are rife with such examples. Since the parser has no problems doing that, it would seem that it could function very well to just look for anything valid (pre spacing or not), and then just ignore the rest once a ; is found. I guess that's how I was thinking it was intended to work but maybe not. I'm not complaining here. I'm put it forward because I thought DLT probably didn't intend for that behavior. If they did/do, then no harm either. I can easily work around by keeping semi-colons in the 1st column and just indenting the rest of the comments. Quote Link to comment Share on other sites More sharing options...
trub Posted March 1, 2018 Share Posted March 1, 2018 I agree that spaces before the semicolon should be ignored. In fact the same question applies to '-' starting a batch file or '#' for executing EXE programs (with X.COM). So we have to resolve this in the upcoming releases. 5 Quote Link to comment Share on other sites More sharing options...
fujidude Posted March 5, 2018 Share Posted March 5, 2018 (edited) I've discovered a possible bug in XLESS from the toolkit, SDX 4.49c. I noticed a lot of text based files I was trying to view with it would go bonkers. That is to say not display correctly, and even get caught in some kind of endless loop. I'll attach an .ATR with a couple of examples. Note, that the LESS program has no trouble properly displaying the same files. xlessbug.atr Edited March 5, 2018 by fujidude Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 10, 2018 Share Posted July 10, 2018 I have finally photographed the ghost that has been haunting me. SDX 4.49b No problem. I've never seen it. SDX 4.49c Pops up at random times. This is on a spinning drive, BTW. Not a CF-SSD. CONFIG.SYS: device sparta device sio /a device ultime device pclink device ramdisk set prompt=$L$P> Ideas? 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 10, 2018 Share Posted July 10, 2018 Have you run RWCRC on that disk with either version of SDX? The PBI driver is encountering transmission errors on the HDD which not even several retries can overcome. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted July 10, 2018 Share Posted July 10, 2018 yep that's the CF-MicroDrive (spinning disk) error that happens with C but not B.... B switches and reads the directory every time. C.... not so much..... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 10, 2018 Share Posted July 10, 2018 (edited) I gather that much, but since we've exhaustively covered the fact that DOS doesn't directly communicate with the drive, I'm trying to establish whether the device is actually reliable with 4.49b or just appears to be. Maybe sector transfers happen at slightly different intervals and this is enough to trigger issues that the retry logic in the PBI driver can't cope with. Intermittent device done errors are 100 PER CENT TYPICAL of flaky hard disks and Phi2 problems. Edited July 10, 2018 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted July 10, 2018 Share Posted July 10, 2018 (edited) well it's reliable enough that you can copy to and from partition to partition without messing up the files etc, and not that it matters....also from divisor 0 sio to the microdrive and back... no error reported and no error in the files themselves..... timing issues being what they are or can be, maybe a couple of CF I/II/+ spinning drives in the right hands would shed light on it... as you are aware many drives and interfaces aren't perfect, but are tolerated quite well.... a spin up delay might even be involved as these drive tend to spin up and fill the on board buffer... Edited July 10, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 10, 2018 Share Posted July 10, 2018 (edited) So RWCRC has not been run on the drive, I take it. These speculations are far too vague for anyone to have a hope of diagnosing the issue. What's required is a reproducible scenario. "It seems to work OK with 4.49b" isn't giving us much to go on when I don't have any means of replicating the issue here. Other thoughts: Does the same card work reliably with the Incognito XEX loader (which drives the disk somewhat more relentlessly than DOS)? Do mounted ATRs (on the HDD) work reliably, both when booted and when read and written by 4.49b and 4.49c? Edited July 10, 2018 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted July 10, 2018 Share Posted July 10, 2018 (edited) meh, deleted, going to pet the cat, and eat breakfast with the wife..... Edited July 10, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 10, 2018 Share Posted July 10, 2018 (edited) Fair enough... you can probably be spared my response as well. Kyle and I - as far as I was aware - are already dealing with this mystery via PM - so there's no need to pollute this topic with it. By all means send me one of the problem devices and I will be delighted to test it here. Edited July 10, 2018 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted July 10, 2018 Share Posted July 10, 2018 Just as an afterthought: since I'm updating the COLLEEN.SYS driver (for use with the Incognito HDD in 800 mode; the driver doesn't read the status register during sector transfers and therefore doesn't trigger 8-bit mode drop-outs), I just ran RWCRC on the MicroDrive Kyle sent me a couple of years ago (under SDX 4.49c) and it passed without errors. The driver has the same 128 frame timeout as the BIOS I sent Kyle last week, which he is presumably using for testing. 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 11, 2018 Share Posted July 11, 2018 Here's a pic of RWCRC ran 3 times on SDX 4.49b. Picture only shows 2, but I DID run it 3 times. SDX 4.49c post to follow. BTW, this drive is 100% APT, so I can't test the Loader. Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 11, 2018 Share Posted July 11, 2018 (edited) In the process of downloading a new, untouched copy of 4.49c, I filled up my drive, and look at the error number! Device Done, NOT Disk Full. 144 instead of 162. I then copied it successfully to the A: partition (which had plenty of free sectors) from the same PCLink drive as I tried before. 4.49c passed RWCRC twice with NO errors. This is getting interesting. Before anyone asks, the 1392 sectors at the very top of the pic are the dir. of another partition. There are about 600 free 256 byte sectors free on C:. The 256K SDX file is 1024 sectors long. I must use 256 byte sectors because BBS Express Pro only runs on disk based Sparta 3.x. Edit: I want to make it clear that THIS IS THE FIRST TIME I HAVE SEEN THAT ERROR in 4.49b. Edited July 11, 2018 by Kyle22 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted July 11, 2018 Share Posted July 11, 2018 (edited) now you broke it! see smiley face means joking... might be time to run some disk cleanup up utils as various tests and tools write to the disks and an fail different ways, might have some corrupt file/data/directory structures now... I wonder if the errors number has become a catch all for a couple different errors now.... Interesting to say the least... never seen the error with b.... pretty funky. I wonder what all the flashing and recopying and testing might be adding up to.....might be a good idea to verify the rom images and maybe re-flash? At this point I'm glad I put things back on my buddies computer and it's working, if I tooled around with it much more and got errors in b he'd be looking at me! I may have dodged a bullet! I hate to say it but with the direction this looks to be going... you might have to start over again. The only difference between his and yours is he has a standard processor and yours is an upgrade.... and his has the revision before yours for bios reminds me of when I rolled back to 4.47.... rock solid, reliable and tolerant for most things. I still keep a couple cartridges around just in case,,, It would be nice if each version would be revisited and bugs gone before starting the next re-write. Each major revision being about feature set and such improvements rather than bug fixes. That was sort of the norm for software at time.. minor revs were tweaks, fixes / major revs were visionary and broad in stroke... Edited July 11, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 11, 2018 Share Posted July 11, 2018 Calm down... This is no big deal. I have not seen any actual disk corruption at all. It was a surprise to see the 144 when the disk became full. Can this point to an error handler issue with SDX? How are the errors processed and displayed to the user? No errors at all seen with RWCRC. I have NOT even come close to wearing out the flash. SDX is DESIGNED to run on Rapidus and other 802/816 systems. This is the exact opposite of a shitty little game that was designed NOT to run on 'Upgrade' CPUs. This is NOT an issue with my 65C802. The BIOS is the latest and greatest. No issues whatsoever with that. Brilliant work! I will need to go back to 4.48 or even 4.47 to attempt to replicate the error and see if I get a 162 instead of a 144. Does PCL: work with 4.47? Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted July 11, 2018 Share Posted July 11, 2018 (edited) I can't remember specifically, but I think the driver loads, and then you must type out the PCL# : for everything.. it won't store or remember it... works just like CAR: does.... you know the whole DIR CAR:*.* deal.... in the later versions it retains such thing at the prompt... but earlier versions 4.47 etc. you have to type them out everytime other difference is you have a newer bios than his does.... not that it would matter... Edited July 11, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 11, 2018 Share Posted July 11, 2018 COPY PCLD:SDX449C.ROM is PERFECT Syntax. It worked FINE when copied to the A: drive. The point here is that WHEN THE DISK GOT FULL, IT THREW A 144 INSTEAD OF A 162. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted July 11, 2018 Share Posted July 11, 2018 you asked about 4.47 dude....I'm not talking about anything else... not your syntax on what you've done... but rather how it need be on 4.47 as you asked... 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 11, 2018 Share Posted July 11, 2018 I'll have to try 4.47 and see if a disk full throws a 144. Hopefully, it does NOT. Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted July 12, 2018 Share Posted July 12, 2018 (edited) I'll have to try 4.47 and see if a disk full throws a 144. Hopefully, it does NOT. Yeah, I know... Quoting myself again, but..... Look at the pic of 4.47 when the disk gets full. Here is SDX 4.47: SDX447.zip Please note that these are straight from the official site. If you want Jon's custom 4.47, please visit his site here: https://atari8.co.uk/firmware/ Edited July 12, 2018 by Kyle22 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted July 12, 2018 Share Posted July 12, 2018 ah, so it threw a disk full just like it should.... 2 Quote Link to comment Share on other sites More sharing options...
mr-atari Posted February 13, 2019 Share Posted February 13, 2019 http://atariage.com/forums/topic/287449-small-memory-footprint-dos/?p=4218339 Something for SDX 4.49 to support? Grtz, Sijmen. Quote Link to comment Share on other sites More sharing options...
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.