Jump to content
IGNORED

SpartaDOS X 4.48


drac030

Recommended Posts

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.

Link to comment
Share on other sites

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.

  • Like 5
Link to comment
Share on other sites

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 by fujidude
Link to comment
Share on other sites

  • 4 months later...

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?

post-13040-0-32702100-1531181509_thumb.jpg

 

  • Like 1
Link to comment
Share on other sites

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 by flashjazzcat
Link to comment
Share on other sites

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 by _The Doctor__
Link to comment
Share on other sites

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 by flashjazzcat
Link to comment
Share on other sites

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 by flashjazzcat
  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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. :(

 

post-13040-0-11873500-1531274170_thumb.jpg

 

Edit: I want to make it clear that THIS IS THE FIRST TIME I HAVE SEEN THAT ERROR in 4.49b.

Edited by Kyle22
Link to comment
Share on other sites

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 by _The Doctor__
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by _The Doctor__
Link to comment
Share on other sites

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.

 

post-13040-0-70550300-1531355393_thumb.jpg

 

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 by Kyle22
  • Like 1
Link to comment
Share on other sites

  • 7 months later...

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...