Jump to content
IGNORED

SpartaDOS X 4.48


drac030

Recommended Posts

It seems that I have to write a test program for that. To check, at which stage the error exactly occurs. But still, if the behaviour depends on whether a disk is in the ATR8000 or not, this must cause a difference in the behaviour of the ATR8000 itself. The DOS on Atari does not really control the operation of the peripherals, they are "intelligent" devices, they are sent commands and they respond or not, you see.

Edited by drac030
  • Like 1
Link to comment
Share on other sites

I learned two new things.

 

- a disk in either drive at boot time allows the ATR8000 to register new disks in either drive.

 

- When I get the "Device does not respond" error if I type COLD any disk in a drive gets registered. No restarting of the ATR8000 necessary.

 

-SteveS

Edited by a8isa1
Link to comment
Share on other sites

I finally installed one of Steve Tucker's composition images consisting language carts, MyDOS (stacking not simulated), other stuff. I am able to boot the ATR8000 without a disk and have MyDOS register and access disks in either drive.

I don't know if this proves anything. MyDOS was never designed to be cartridge based.

A few days ago I used sio2bsd as an SIO logger. It doesn't record the data only the events and the SIO commands. Perhaps it will be helpful to diagnose what's going on with SDX and the ATR8000.

Here's what I did.

I booted the ATR8000 without any disk. I then inserted two good disks and attempted to read their respective directories, "DIR A:", "DIR B:". Next leaving a disk in drive 1 I type "COLD". After the 800XL rebooted I typed "DIR A:JUNK.JNK". That file doesn't exist on the disk. I just needed to know that D1: (A:) responds.

I manually edited the log file to change the EOL to Windows CR/LF and inserted a note indicating when "COLD" had been typed.

 

Typing COLD once in SDX to "wake up" the ATR8000 isn't a very big deal.

 

 

atr8000_SIO_log.zip

Link to comment
Share on other sites

man man | less will go into endless loop if drive 1 is un-available... you get error 138 until reset or reboot.

swap in another drive to the DA: slot such as my #8: ramdisk or DO: ramdisk in as D1: or put a real drive on #1 then it works just fine....

if drive 1 is write protected you get the 144 error followed by 170 followed by 138 followed by lock up or various other error only way out is a reset....

the same behavior exists for man man | more etc.

but.....

using direct method such as

less car:man.man and it's all good works just fine!

more car:man.man and again it works just fine....

 

If you are at D1:

type

$MANPATH

all by itself and it will switch to DCAR1: and you can launch files and do dir commands etc while remaining inside CAR:

of course if you use ? or /? on the prompt you will get the X help as you would expect while in a car device

Edited by _The Doctor__
Link to comment
Share on other sites

man man | less will go into endless loop if drive 1 is un-available... you get error 138 until reset or reboot.

You use a pseudopipeline ("|") and this requires some space to create a temporary file. If you have not set the environment correctly (see the manual, chapter "Configuring your system" -> Environment variables), then the CP will atttempt to create the temp file on the current drive/dir. If the current drive/dir is not writable, the effect will be probably as you depict.

Link to comment
Share on other sites

I did not remember the issue in the past and hadn't tested everything like I used to so the behavior may have happened a number of versions/revisions back.... I don't mind that cp drops to dcar1: on $manpath attempt.. I like that I can stay in the car: rather than typing it all out for each request, in fact I prefer that as I test and mess about like I used to...I come and go with projects and as such I appear to be easily forgotten.. :)

 

We have become accustomed to tossing in the cartridge and going about our work and not having drives on till we save or load something... we almost always have the mio and other ramdisks on, populated, and assigned as our last drives....

 

I will go thru the process remake the the configs and save it in the user area....

Link to comment
Share on other sites

I finally installed one of Steve Tucker's composition images consisting language carts, MyDOS (stacking not simulated), other stuff. I am able to boot the ATR8000 without a disk and have MyDOS register and access disks in either drive.

 

I don't know if this proves anything. MyDOS was never designed to be cartridge based.

 

A few days ago I used sio2bsd as an SIO logger. It doesn't record the data only the events and the SIO commands. Perhaps it will be helpful to diagnose what's going on with SDX and the ATR8000.

 

Here's what I did.

 

I booted the ATR8000 without any disk. I then inserted two good disks and attempted to read their respective directories, "DIR A:", "DIR B:". Next leaving a disk in drive 1 I type "COLD". After the 800XL rebooted I typed "DIR A:JUNK.JNK". That file doesn't exist on the disk. I just needed to know that D1: (A:) responds.

 

I manually edited the log file to change the EOL to Windows CR/LF and inserted a note indicating when "COLD" had been typed.

 

Typing COLD once in SDX to "wake up" the ATR8000 isn't a very big deal.

 

 

It seems to me that any SDX command that talks to the SIO should do the same as COLD command .... Like DF - SIOSET - CHKDSK D1 /X

Edited by rdea6
Link to comment
Share on other sites

It seems to me that any SDX command that talks to the SIO should do the same as COLD command .... Like DF - SIOSET - CHKDSK D1 /X

Thanks. It was worth a try.

 

Unfortunately, just like DIR A:, CHKDSK A: spins the drive and generates error, "138 Device does not respond"

 

SIOSET doesn't generate an error. It also doesn't list a TYPE for unit 1.

 

SIOSET 1 NORMAL sets the type but doesn't spin the drive. I'm not sure if it's supposed to do so.

 

None of the above operations wake up the ATR8000.

Link to comment
Share on other sites

I've been able to get the ATR8000 3.02 firmware working partially in emulation and think I've been able to replicate this issue. The problem is that, for some reason, the firmware will sometimes ignore Read PERCOM Block ($4E) commands outright without even sending an ACK or NAK for the command, if it hasn't read the geometry for the disk. This causes SpartaDOS X to retry and then time out on the $4E command before it gets to the sector read. The source code to the firmware is available and confirms the problem:

;	... PERCOM 'N' COMMAND PROCESSOR ...
;
GETPARAMS:
	CALL	DRVINDEX	;POINT IY TO DRIVE'S DATA AREA
	RET	C		;EXIT IF NOT A DRIVE IN OUR BOX

	CALL	HASPARMS
	RET	Z		;EXIT IF DISK PARAMS NOT KNOWN

	CALL	SENDACK		;SEND 'ACK' FOR COMMAND FRAME

The second conditional return is the one that's aborting the command. A sector read/write command is apparently necessary for geometry detection to work.

  • Like 4
Link to comment
Share on other sites

Thanks, phaeron. So it turns out to be what I suspected, a problem with the ATR-8000 firmware.

 

It can probably be worked around by relying on the STATUS command information on the density when the READ PERCOM returns an error. It may be a bit difficult to accomplish, because the STATUS and READ PERCOM commands are sent by different SDX layers (STATUS by the FMS, READ PERCOM by the underlying BLOCK_IO). It may mean that it is a time to sort it out and get rid of the ICD idea of inquiring the SIO status at the FMS level.

  • Like 3
Link to comment
Share on other sites

My understanding was he turned on the atr8000 without a disk then was unable to see disk that was inserted after until Atari cold start in sdx

With MyDOS etc. no disk at start with atr8000 and was able to access disk inserted afterwards with Atari not requiring cold start....

 

if that is the case my thoughts seemed reasonable.... by the time this is all said and done I think I am going to have everything hooked up all at once again... mio black box atr8000 myide a mess of floppy and hard drives......this room is going to be an even bigger mess! should never have taken anything down..... I inevitably have to find it and put it all back together again anyway.... :)

  • Like 2
Link to comment
Share on other sites

Oy, this firmware is a mess.

 

Sending a Write PERCOM Block command seems to be enough to initialize the drive entries so that the Read PERCOM Block command isn't ignored. However, the ATR8000 doesn't seem to have active disk change detection, so the result of the Read PERCOM Block command that SDX issues can still be bogus; neither the PERCOM block nor the status density bits will be updated properly until a Read Sector command is issued, when the drive actually issues Read Address commands to query the disk. This means that if the sector size changes, SDX will try to do I/O with the wrong sector size and either get errors or time out, and only the next access will work. This drive is wonky enough that it would probably warrant a special INDUS.SYS-like driver rather than warping the standard drive access code to try to make this work.

  • Like 3
Link to comment
Share on other sites

From what I understand it would not help when there is no floppy disk inserted. Or?

Just to be clear. If I boot the Atari without a disk in the drive there is nothing I can do to the ATR8000 to enable SDX to read a disk. Neither a RESET or cold start (of the ATR8000) with a disk in the drive will let SDX read a disk.

 

The only thing that works is put a disk in a drive and type COLD. I don't have to do anything to the ATR8000.

 

Considering I'm likely the only Atarian in the world using an ATR8000 as his primary floppy drive and also using SDX (but less than 10% of the time) it is probably not worth anyone's time to pursue changing the ATR8000's firmware or changing SDX.

 

I am satisfied that if I forget to insert a disk I can just type COLD.

 

On the other hand, if anyone would like to fix the ATR8000's firmware (and even enhance it with ultraspeed) I certainly would not complain. :D

Edited by a8isa1
  • Like 1
Link to comment
Share on other sites

We have UltraSpeed for the Indus, which also uses a Z80 for SIO bitbanging. The code should be very similar.

I can't think it would be too difficult to modify it to give a much needed speed up to the ATR.

The ATR8000 has more things to do. It does printing with spooling, RS232 (also bit-banging), and supports 4 drives. It also has the BIOS for CP/M, though it can't run CP/M and serve the Atari at the same time.

Link to comment
Share on other sites

The ATR8000 has more things to do. It does printing with spooling, RS232 (also bit-banging), and supports 4 drives. It also has the BIOS for CP/M, though it can't run CP/M and serve the Atari at the same time.

Yes, I know it has more things to do than disk drives, but there may (I haven't investigated yet) be some free space in the ROM, or we could install a larger (EP)ROM in it.

 

Is it possible for the computer to upload code to the ATR as it does with the Indus? I don't think so, but another possibility is to add the upload command to the ROM (it may use less space), and then send the code to the ATR in RAM.

 

The ATR has lots of RAM, so something should be possible, I would think.

 

I wish I still had my ATR.

  • Like 2
Link to comment
Share on other sites

Yes, I know it has more things to do than disk drives, but there may (I haven't investigated yet) be some free space in the ROM, or we could install a larger (EP)ROM in it.

 

Is it possible for the computer to upload code to the ATR as it does with the Indus? I don't think so, but another possibility is to add the upload command to the ROM (it may use less space), and then send the code to the ATR in RAM.

 

The ATR has lots of RAM, so something should be possible, I would think.

 

I wish I still had my ATR.

yes it's possible to upload code to RAM.

 

I don't remember the person's nick but there was that great project to make the ATR8000 generate a CP/M system disk, this being initiated from the Atari side of things not from within CP/M.

Edited by a8isa1
  • Like 2
Link to comment
Share on other sites

all of that is true... no reason all options could not be explored....

 

 

SPARTA TEAM!

 

SpartaDos 4.49b has so many positive changes that I love but it is annoying me now.... it's clearing the screen on returning from commands, for example from 64 and 80 column displays, certain games and software blam where'd it go?.... it's really bad I have no idea why the change was made to make it clear screens but it busts things up I am not used to having this happen... this is really bad behavior.... reading a screen or directory and boom it dissapears.... title screen comes up and boom blue flash and it's gone.... this clear screen thing is a BAD idea..... please put it back to the way it was...... so many great improvements, more stable, more accurate and then face palm one step to far and messes up big time with screen clearing... it's calling gr.0 for no reason.... terrible.... if something exits badly and it scrambles the screen hitting reset usually solves it.... if it scrambles more than that we have bigger problems, a better behaviour would be to look at the mode on entry and restore it on exit....

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

I've been running 4.49b for some months and have not noticed intrusive screen clearing. I think any changes made there were quite subtle and intended only to ensure the correct display mode is active once the command processor appears (for instance, in the case of a program neglecting to return to graphics 0 from a bitmapped display prior to jumping through $0A). I can type "BASIC" at the CP, however, and then immediately type "DOS" again and be right back at the CP without any screen clearing.

 

Are there any specific software titles or scenarios you can suggest to replicate the issue?

  • Like 2
Link to comment
Share on other sites

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