SpartaDOS X 4.43

[mr-atari]

Thanks for the reply(s).

 

about: ATARIMAX 1Mb cartridge.

 

I did use the latest version .

The plain cartridge as downloaded gives a error: "No binairy file"

Typing SIO.SYS /C gift "error in CHDIR" and it loops for ever.

 

Can I ask (perhaps a stupid) other question?

The build-in format uses stack-area, I use it too in my apps, garbaging up the screen.

The format-function still works tough.

 

Is there a file version of FORMAT.COM too?

 

Later,

Sijmen.

Edited April 13, 2011 by mr-atari

[drac030]

The plain cartridge as downloaded gives a error: "No binairy file"

Typing SIO.SYS /C gift "error in CHDIR" and it loops for ever.

 

This works here:

 

 

The build-in format uses stack-area, I use it too in my apps, garbaging up the screen.

The format-function still works tough.

 

Is there a file version of FORMAT.COM too?

 

There is no FORMAT.COM. The internal format must use the stack area because it is also supposed to work when invoked from within a program (not only when invoked from the COMMAND.COM). t normally creates no conflicts, because SIO or PBI devices do not touch the stack. Anyway, it is only the FORMAT display which occupies that memory, this is why it still works, despite looking screwed.

[flashjazzcat]

Obvious question: Drac030, are you using the "latest" MyIDE BIOS in the pic? In any case - I know what I'm putting my money on as the cause of the problem.

[drac030]

I hardly believe that the OS could screw the communication with the CAR: device (which is internal to SDX). From the symptoms, I would rather suspect a corrupt *.ROM image or a hardware problem.

 

PS. the *.ROM image for 1 Mb Maxflash on our site is OK, I just checked.

Edited April 13, 2011 by drac030

[flashjazzcat]

I hardly believe that the OS could screw the communication with the CAR: device (which is internal to SDX).

Don't forget the OS is new and improved.

[+Stephen]

Obvious question: Drac030, are you using the "latest" MyIDE BIOS in the pic? In any case - I know what I'm putting my money on as the cause of the problem.

Couldn't be a hardware issue with the MyIDE

[mr-atari]

Ok, I need to do some digging here and let you know later.

 

I'm indeed testing on the beta-version of the MyIDE-BIOS and the Spartados X 4.43rc works fine.

So until now, I didn't check further, I will do.

 

Later,

Sijmen.

 

[edit]

I checked on my stock 800xl, atarimax 1mb cartridge, file downloaded here:

http://sdx.atari8.info/index.php?show=en_download

 

Unfortunately I get the same errors with SIO.SYS /A or /C

See screenshot

 

What do I wrong?

[edit]

Edited April 14, 2011 by mr-atari

[flashjazzcat]

Why the sudden interest in SDX compatibility, Sijmen? Is it because it supports 512 byte sectors and produces good looking RWTEST results? You have always recommended MyDOS in the past.

[mr-atari]

Why the sudden interest in SDX compatibility, Sijmen? Is it because it supports 512 byte sectors and produces good looking RWTEST results? You have always recommended MyDOS in the past.

 

Just for the fun of it :-)

I guess people forget this.

 

B.T.W.

MyDOS was the only dos that worked on the atarimax_IDE cartridge with the BIOS stored in OSRAM.

Spartados works on the internal IDE and since Steve sells these too, there is some demand for it.

 

Talk to you later.

[flashjazzcat]

Why the sudden interest in SDX compatibility, Sijmen? Is it because it supports 512 byte sectors and produces good looking RWTEST results? You have always recommended MyDOS in the past.

 

Just for the fun of it :-)

I guess people forget this.

 

B.T.W.

MyDOS was the only dos that worked on the atarimax_IDE cartridge with the BIOS stored in OSRAM.

Spartados works on the internal IDE and since Steve sells these too, there is some demand for it.

 

Talk to you later.

Well, I've taken all my driver content off your forum - so go for it.

[drac030]

Unfortunately I get the same errors with SIO.SYS /A or /C

(...)

What do I wrong?

 

Nothing. We managed to reproduce the behaviour. The SIO is apparently cursed in this release: one of the modules, SIO5.OVL, is not compiled correctly due to a bug in MADS 1.9.0. Hence the "not binary file" message you get.

 

This module is only loaded for SIO.SYS /A when using OSRAM mode for both DOS code *and* buffers (default for <= 128k RAM). This is why it worked for me, because my Atari has 320k RAM.

 

I have already regenerated the offending OVL using a newer version of MADS, but you'll have to wait until evening for website update.

[drac030]

"Service pack" ready. At the same time the final version of the manual got available as well. Have fun.

[+Larry]

A "Service Pack" -- I love it!!!

-Larry

 

"Service pack" ready. At the same time the final version of the manual got available as well. Have fun.

[phaeron]

I was also seeing the same problem with SIO /A, and I can verify that SP1 fixes the problem for me.

[mr-atari]

Thanks for the update, I'll check it out Sunday!

 

I want to point out that I'm posting here as requested on your site, because I've found issues with SDX.

 

That I'm also working on a BIOS that supports MyIDE is not relative here.

 

Just to set things 'straigh'.

 

Later,

Sijmen.

[mr-atari]

There is no FORMAT.COM. The internal format must use the stack area because it is also supposed to work when invoked from within a program (not only when invoked from the COMMAND.COM). t normally creates no conflicts, because SIO or PBI devices do not touch the stack. Anyway, it is only the FORMAT display which occupies that memory, this is why it still works, despite looking screwed.

 

Ok, I figured something out like that.

In fact I do the same in some apps

Can I check a byte in ram to see if format is running?

So I can program a work-around.

 

Thanks,

Sijmen.

 

P.S.

SIO.SYS works as it should. Thanks for the fix!

[drac030]

There is no such flag in the memory, unfortunately. Checking the stack area for the display data does not help, because the formatter does not clean it up after itself. There is no method of checking that which does not involve hacks.

[drac030]

People who want to use SDX with an emulator: there were complaints that SDX does not allow to access "H:" device (or any CIO device, in fact) from the command prompt. It is true, it doesn't. And because Sparta X has its very own kernel and set of devices, it is rather hard to integrate "H:" with the system. And we do not support emulators directly. However, I know that flashjazzcat is currently working on a device driver that could allow full access, I hope that he'll complete it really soon.

 

For now, there is a provisional (and primitive, I admit, but working) solution, just download the "emupack", unpack it and follow the instructions in the TXT file: http://sdx.atari8.info/index.php?show=en_addons Tested on A800Win and Altirra 1.5, seems to work.

[phaeron]

I noticed that the toolkit disk has a driver called PCLINK.SYS that appears to expose a full SDX device. Do you think it would be possible to expose a more capable H: device through this method? I would be interested in doing this if I could find details on the SIO protocol for it. I think this would allow for better H: support without requiring hooks in the SDX core or otherwise doing emulator-specific work.

[flashjazzcat]

I believe the intention was to employ PCLINK to allow highly flexible emulator support. However, this would naturally require support on the emulator side, which would be highly desirable. What I aim to cook up should work on all emulators which support H: via their existing implementation... however, just how it will pan out remains to be seen. I hope Drac030 will publish details of the PCLINK protocols so you can have a crack at supporting it.

 

@Drac030: Thanks for the emupack: this should save many minutes in a typical day, and will ease driver development.

[trub]

PCLINK protocol is implemented in sio2bsd, the sources are available at Drac030's site: http://drac030.krap....-inne-pliki.php

Official specification of the protocol is here: http://atariki.krap....dex.php/DOS2DOS (Polish-speakers only )

[drac030]

phaeron: yes, I believe that implementing PCLink protocol in an emulator would be highly desirable at least for SDX users. I am also open for remarks.

[Roydea6]

People who want to use SDX with an emulator: there were complaints that SDX does not allow to access "H:" device (or any CIO device, in fact) from the command prompt. It is true, it doesn't. And because Sparta X has its very own kernel and set of devices, it is rather hard to integrate "H:" with the system. And we do not support emulators directly. However, I know that flashjazzcat is currently working on a device driver that could allow full access, I hope that he'll complete it really soon.

 

For now, there is a provisional (and primitive, I admit, but working) solution, just download the "emupack", unpack it and follow the instructions in the TXT file: http://sdx.atari8.in...?show=en_addons Tested on A800Win and Altirra 1.5, seems to work.

 

Atirra has now been upgraded version Altirra-1.9-test34 has the capability to load the SDX443_intsdx128.ROM but the emupack doesn't work with this rom I had to start using the SDX443_Altirra_Atari800Win.car file. I haven't tested with the new Atari800 2.2.0 Emulator.

[drac030]

Emupack is not hardware specific, so there is no reason why it should work with one build and not with the other. In Altirra 1.5 it anyway worked with the Maxflash 1Mb. Apart from that, could you be a little bit more specific? What does mean "doesn't work"?

[phaeron]

EDIR EMU: is working for me in latest test version of Altirra for both the intSDX128 and MaxFlash ROM images.

 

Possible issue: it doesn't seem to work if PCLINK.SYS is also loaded. This happens in both Altirra and Atari800WinPLus 4.0.

 

Thanks for the PCLink info -- I'm attempting an implementation, although at the moment I have some ACK timing issues to work out that seem to be related to the SDX high speed SIO driver. Also, in sio2bsd, there are some error handling cases that look a bit odd to me: a couple of places set an error code on an unexpected command, but return an ACK instead of a NAK.