SpartaDOS X MyIDE Driver

[drac030]

On TF 2005 you could also check where it got stuck. And no, it is not "a real 800", not even almost. A real 800 doesn't have the RAM under the OS.

[HiassofT]

Hi!

 

On TF 2005 you could also check where it got stuck.

I tried to fire up the Freezer but the system is completely locked up, even pressing system reset to generate an NMI doesn't help. Only reset helps.

 

But, if you like, I could send you a complete memory dump, maybe we can see something from the stack data.

 

And no, it is not "a real 800", not even almost. A real 800 doesn't have the RAM under the OS.

It is - almost :-) When using the old OS from the Freezer there's no way to get to the RAM under the OS. The only thing you could do that is not possible on the 400/800 is configure portb to output again and then map the selftest from the XL OS to $5000.

 

BTW: In most cases just using an old OS in an XL is good enough for a quick test as portb is configured to input (i.e. OS enabled, basic&selftest disabled due to the pull-ups) and writing some values to portb has no effect (unless you reconfigure portb to output).

 

so long,

 

Hias

[drac030]

I could send you a complete memory dump, maybe we can see something from the stack data.

 

Yes, please do. But I also would prefer you to use a regular SDX-beta, not the MyIDE-ones. Not that I doubt in flashjazzcat's programming skills (quite contrary, actually), but the MyIDE driver is an additional factor which may make anayzing the dump more difficult.

 

In most cases just using an old OS in an XL is good enough for a quick test as portb is configured to input

Yes, you are right, I didn't think about it. So I agree, "almost" an 800. Pity I still can't test that.

Edited December 2, 2010 by drac030

[HiassofT]

Hi drac!

 

Yes, please do. But I also would prefer you to use a regular SDX-beta, not the MyIDE-ones. Not that I doubt in flashjazzcat's programming skills (quite contrary, actually), but the MyIDE driver is an additional factor which may make anayzing the dump more difficult.

Could you please send (or point) me to an official RC image? Currently I only have the ones from flashjazzcat.

 

Just had another idea, I tried the SDX443RC_SDX128.ROM with the atari800 emulator ("atari800 -nopatchall -b -cart SDX443RC_SDX128.ROM") and it also locks up. According to the stack trace the problem (or one of the problems) seems to be the "JSR $E486 / PHENTV" call which is only available in the XL/XE OS.

 

> stack
01EC: DB EB  EBD9: JSR ED10
01EE: D0 F0  F0CE: JSR E459
01F0: ED EF  EFEB: JSR F095
01F2: AA 3F  3FA8: JSR E486
01F4: EE 04  04EC: JSR 3FA0
01F6: A2 A2  A2A0: JSR A2F8
01F8: 41 72  723F: JSR A240
01FA: E2 70  70E0: JSR 7135
01FC: DB F2  F2D9: JSR F37E
01FE: FE F1  F1FC: JSR F2CF

 

so long,

 

Hias

[drac030]

("atari800 -nopatchall -b -cart SDX443RC_SDX128.ROM") and it also locks up. According to the stack trace the problem (or one of the problems) seems to be the "JSR $E486 / PHENTV" call which is only available in the XL/XE OS.

 

I tried the "atari800 -nopatchall -b -cart SDX443RC2_SDX128.ROM" (with a800 2.1.0) and it worked. Despite that, JSR $E486 is not used by the kernel nor by the programs SDX loads using the default CONFIG.SYS. Some utilities on CAR: however, use the call. These are:

 

CON64.SYS

QUICKED.SYS

Z.SYS

 

None of them is loaded by default, so I have no idea, what's happening there. But sure, I can remove the call from two of them (con64.sys won't run on a 400/800 anyway, because it needs an XE-compatible RAM expansion).

[HiassofT]

I tried the "atari800 -nopatchall -b -cart SDX443RC2_SDX128.ROM" (with a800 2.1.0) and it worked. Despite that, JSR $E486 is not used by the kernel nor by the programs SDX loads using the default CONFIG.SYS. Some utilities on CAR: however, use the call. These are:

 

CON64.SYS

QUICKED.SYS

Z.SYS

Then it must be something with the RC ROM image I got from flashjazzcat. If I start it with the XL OS I can see a "Quick Ed installed" message.

 

Then I did another test with 4.43RC on my Turbo Freezer, using a custom config.sys (only device sparta, sio, ataridos, jiffy, ramdisk, myide).

 

Now SDX booted fine, but I got a "Config error: DEVICE MYIDE" (with the XL OS, extended RAM disabled, the MyIDE driver 0.9a loaded fine, using the same config.sys).

 

@flashjazzcat: could you have a look at this?

 

BTW: "ed" doesn't work with the old OS, I only get those "Atari hearts" (chr$(0)) when I press a key.

 

I guess, if the few problems are solved, chances aren't too bad that it should also work on the 400/800 :-)

 

so long,

 

Hias

[drac030]

Could you please send (or point) me to an official RC image?

 

Anyone who wants to receive beta-builds of SDX, should PM (either me or trub) with e-mail address. This address will get added to the distribution list. Beta builds are sent via e-mail as attachments containing raw *.ROM images and flashing *.ATR files.

 

BTW: "ed" doesn't work with the old OS

 

Yes, it does not. It has been fixed in CVS just a month ago.

Edited December 2, 2010 by drac030

[+bf2k+]

SDX 4.42 started fine, but the last 4.43rc I got from flashjazzcat locked up after the "RTIME-8" line.

 

so long,

 

Hias

 

Same thing here. However the SDX 4.4x documentation indicates that there is "some" compatibility - I don't know what that means but both my MyIDE + Flash running 4.43rc and my AtariMax Flash1Mb 4.43 both lock up just like yours.

[walter_J64bit]

Has anyone tried this driver in BEWE-DOS?

[BillC]

I tried the "atari800 -nopatchall -b -cart SDX443RC2_SDX128.ROM" (with a800 2.1.0) and it worked. Despite that, JSR $E486 is not used by the kernel nor by the programs SDX loads using the default CONFIG.SYS. Some utilities on CAR: however, use the call. These are:

 

CON64.SYS

QUICKED.SYS

Z.SYS

Then it must be something with the RC ROM image I got from flashjazzcat. If I start it with the XL OS I can see a "Quick Ed installed" message.

 

Then I did another test with 4.43RC on my Turbo Freezer, using a custom config.sys (only device sparta, sio, ataridos, jiffy, ramdisk, myide).

 

Now SDX booted fine, but I got a "Config error: DEVICE MYIDE" (with the XL OS, extended RAM disabled, the MyIDE driver 0.9a loaded fine, using the same config.sys).

 

@flashjazzcat: could you have a look at this?

 

BTW: "ed" doesn't work with the old OS, I only get those "Atari hearts" (chr$(0)) when I press a key.

 

I guess, if the few problems are solved, chances aren't too bad that it should also work on the 400/800 :-)

 

so long,

 

Hias

I hope the incompatibilities are resolvable because, as I already mentioned, this looks to be an excellent storage solution for the 400/800 systems. I will purchase at least one once it is available, whether is is 400/800 compatible or not.

 

If not I seem to at least have raised an awareness of keeping SpartaDOS X and its utilities 400/800 compatible.

 

Bill

[flashjazzcat]

According to the stack trace the problem (or one of the problems) seems to be the "JSR $E486 / PHENTV" call which is only available in the XL/XE OS.

I forget which other program used this vector (SI2.EXE?) apart from the list Drac gave. The vector is also missing from the official MyIDE OS, and I had to put the routine back to avoid several incompatibilities.

 

I tried the "atari800 -nopatchall -b -cart SDX443RC2_SDX128.ROM" (with a800 2.1.0) and it worked. Despite that, JSR $E486 is not used by the kernel nor by the programs SDX loads using the default CONFIG.SYS. Some utilities on CAR: however, use the call. These are:

 

CON64.SYS

QUICKED.SYS

Z.SYS

Then it must be something with the RC ROM image I got from flashjazzcat. If I start it with the XL OS I can see a "Quick Ed installed" message.

 

Then I did another test with 4.43RC on my Turbo Freezer, using a custom config.sys (only device sparta, sio, ataridos, jiffy, ramdisk, myide).

 

Now SDX booted fine, but I got a "Config error: DEVICE MYIDE" (with the XL OS, extended RAM disabled, the MyIDE driver 0.9a loaded fine, using the same config.sys).

 

@flashjazzcat: could you have a look at this?

One condition which will cause "Config error" is simply for the target file to be missing. I can't envisage many other conditions whereby the driver would be found, attempt to install, and abort without printing some kind of message.

 

Has anyone tried this driver in BEWE-DOS?

It would be a futile exercise. The internal workings of the two systems are entirely incompatible, and in any case, Bewe-DOS must be booted from disk.

[HiassofT]

According to the stack trace the problem (or one of the problems) seems to be the "JSR $E486 / PHENTV" call which is only available in the XL/XE OS.

I forget which other program used this vector (SI2.EXE?) apart from the list Drac gave. The vector is also missing from the official MyIDE OS, and I had to put the routine back to avoid several incompatibilities.

I guess it would be good to search for all occurences of these calls so that the final SDX will work fine on all computers. After all, this is just a convenience function and if it's used by many SDX programs a replacement could be included in the SDX ROM.

 

One condition which will cause "Config error" is simply for the target file to be missing. I can't envisage many other conditions whereby the driver would be found, attempt to install, and abort without printing some kind of message.

Very strange... MYIDE.SYS is present on CAR:, just like ATARIDOS.SYS, SPARTA.SYS, ...

 

BTW: Could you please send me the latest MYIDE.SYS file so I can also do tests with other SDX versions?

 

Oh, and another (maybe stupid, I'm a SDX noob) question: How can I copy files from CAR:? I tried "COPY CAR:MYIDE.SYS A:" but just got a "161 Too many open channels". I thought CAR: is supposed to work like Dx:

 

so long,

 

Hias

[flashjazzcat]

According to the stack trace the problem (or one of the problems) seems to be the "JSR $E486 / PHENTV" call which is only available in the XL/XE OS.

I forget which other program used this vector (SI2.EXE?) apart from the list Drac gave. The vector is also missing from the official MyIDE OS, and I had to put the routine back to avoid several incompatibilities.

I guess it would be good to search for all occurences of these calls so that the final SDX will work fine on all computers. After all, this is just a convenience function and if it's used by many SDX programs a replacement could be included in the SDX ROM.

It is indeed a very small convenience function. Of course, in some cases, even saving the couple of dozen or so bytes it would take to write the code "longhand" in the application is useful. However, I think the benefits of eradicating it outweigh the drawbacks.

 

One condition which will cause "Config error" is simply for the target file to be missing. I can't envisage many other conditions whereby the driver would be found, attempt to install, and abort without printing some kind of message.

Very strange... MYIDE.SYS is present on CAR:, just like ATARIDOS.SYS, SPARTA.SYS, ...

 

BTW: Could you please send me the latest MYIDE.SYS file so I can also do tests with other SDX versions?

 

Oh, and another (maybe stupid, I'm a SDX noob) question: How can I copy files from CAR:? I tried "COPY CAR:MYIDE.SYS A:" but just got a "161 Too many open channels". I thought CAR: is supposed to work like Dx:

I think the latest version of the driver is on the last CAR: image I sent you. In any case, I have a couple of changes to make today and I'll send you that one. In the meantime, you can copy the driver from CAR: with:

 

TYPE CAR:MYIDE.SYS >>A:MYIDE.SYS

 

This simply redirects the console output to a file. You can only open one channel at a time on the CAR: device, and COPY requires two.

[drac030]

I forget which other program used this vector (SI2.EXE?) apart from the list Drac gave.

 

The VBXE driver. Are there any pre-XL VBXE installs?

 

In any case, I don't think anyone can seriously think of using SDX on a 48k machine, the MEMLO is too high to run just about everything outside CAR:

[HiassofT]

Oh, and another (maybe stupid, I'm a SDX noob) question: How can I copy files from CAR:? I tried "COPY CAR:MYIDE.SYS A:" but just got a "161 Too many open channels". I thought CAR: is supposed to work like Dx:

I think the latest version of the driver is on the last CAR: image I sent you. In any case, I have a couple of changes to make today and I'll send you that one. In the meantime, you can copy the driver from CAR: with:

 

TYPE CAR:MYIDE.SYS >>A:MYIDE.SYS

Thanks, the double ">" did the trick! I was trying "TYPE CAR:MYIDE.SYS >A:MYIDE.SYS" before which didn't quite do what I was expecting :-)

 

so long,

 

Hias

[flashjazzcat]

I think the driver is finished, bar the shouting. I realize I'm late releasing the latest update, but nothing important has changed anyway. The next one I issue to the testers will be "1.1RC".

 

 

 

[+Stephen]

I think the driver is finished, bar the shouting. I realize I'm late releasing the latest update, but nothing important has changed anyway. The next one I issue to the testers will be "1.1RC".

Not sure if you've done any new releases since I accidentally deleted the damn thread

[Roydea6]

I think the driver is finished, bar the shouting. I realize I'm late releasing the latest update, but nothing important has changed anyway. The next one I issue to the testers will be "1.1RC".

Not sure if you've done any new releases since I accidentally deleted the damn thread

 

Thread is still there you just opt'ed out, by pressing delete. ASK fjc to add you back to conversation.

[flashjazzcat]

I can't add him back in, because there are still 12 participants and the maximum is supposed to be 10 (hence the "Invite" option is not visible). I think Stephen asked an admin to get him back on, but nothing's happened.

Edited December 14, 2010 by flashjazzcat

[flashjazzcat]

I'm working on a driver update right now (got a bit side-tracked with the IDEa for a while), and the most important change is to FDISK, which will now write the partition table in 8-bit PIO mode if the drive is capable. This is to allow the setting of the FAT MBR signature bytes (at $1FE-1FF) so that Windows won't keep trying to format the drive when you use it with MyIDETool. The sector still appears as a 256 byte sector (i.e. with all the MSBs unused), but with the last byte of the sector set to $AA (and the penultimate byte set to $55).

 

As well as that, I'm going to write a simple stability test program to remove some of the guesswork from finding a working hardware setup.

[flashjazzcat]

Working on a diagnostic/benchmark utilitity, and the results for raw 512bps reads (that's not using DOS or even the LSIO vector, but the low-level BIOS routines of the driver):

 

(Reading 2048 contiguous sectors, i.e. 1MB of data)

 

DMA on:

 

12.26 secs = 85.5KB/s

 

DMA off:

 

9.1 secs = 115.2KB/s

 

These results are pretty much in line with the very top end of HDD performance on the Atari 8-bit, so are more or less what I expected. I suppose the only application which could take advantage of this kind of performance would be some kind of partition backup/cloning utility.

[flashjazzcat]

Quite surprised by how closely matched the low-level read/write speeds are:

 

 

(two runs seen here: first with DMA on, then with DMA off via a batch file). This is also a good indicator of how fantastically efficient the SDX FMS is (raw sector reads being less than 15% faster than reading a file).

 

Stability test part of diagnostic program has been tested with one of the non-working CF cards I own. It consistently reports write errors, which I guess are the primary problem with MyIDE equipment. My "good" CF cards pass the test every time. I haven't yet tested the program on an unstabilized machine, but I think this is a program well worth running before you start building partitions on CF cards or HDDs.

 

The stability test writes a sector of random bytes and then reads it back a number of times, closely monitoring the error pattern (verifying the data against a copy of the original sector in RAM). Inconsistent errors cause the program to report read errors, while bad bytes in consistent locations cause the program to deduce write instability.

 

I'll release this lot to the beta testers in a day or two.

 

...Thanks Jon.

 

No problem Jon.

Edited December 15, 2010 by flashjazzcat

[twh/f2]

I think it's very useful to have a stability testing tool. in my beta tests it turned out that from my 4 Ataris only one had the required stability. I still did not fully understand what exactly is wrong with my other Ataris. For now however I booked it under the "mexican cpu issue" . hopefully there will be some nice beginner-level hardware-mod documentations in future, so that everybody can enjoy the fantastic MyIDE+SDX hardware-software chain.

 

grüße,

\twh

[+bf2k+]

 

I'll release this lot to the beta testers in a day or two.

 

 

Great - I have a flaky CF card that I can't wait to test it with.

[+Stephen]

Quite surprised by how closely matched the low-level read/write speeds are:

 

 

(two runs seen here: first with DMA on, then with DMA off via a batch file). This is also a good indicator of how fantastically efficient the SDX FMS is (raw sector reads being less than 15% faster than reading a file).

 

Stability test part of diagnostic program has been tested with one of the non-working CF cards I own. It consistently reports write errors, which I guess are the primary problem with MyIDE equipment. My "good" CF cards pass the test every time. I haven't yet tested the program on an unstabilized machine, but I think this is a program well worth running before you start building partitions on CF cards or HDDs.

 

The stability test writes a sector of random bytes and then reads it back a number of times, closely monitoring the error pattern (verifying the data against a copy of the original sector in RAM). Inconsistent errors cause the program to report read errors, while bad bytes in consistent locations cause the program to deduce write instability.

 

I'll release this lot to the beta testers in a day or two.

 

...Thanks Jon.

 

No problem Jon.

Awesome - I have a working 130XE and a non-working 130XE to test with. Might even find the time to try scoping the Phi2 signal on both.