92 replies to this topic

[phaeron]

v0.4 works much better. Not only does Ilusia load fine now, but this also fixes a problem I just hit where v0.3 was giving 255 System Errors in a 128K configuration. Thanks!

By the way, the ARC command apparently doesn't handle general SDX device paths and won't extract from PCL:. It thinks it's A: instead.

[atarimac]

spookt, on Sat Apr 23, 2011 8:10 AM, said:

Yeah, I guess we know about the carts but the OP was specifically asking about emulators.

Flashjazzcat was right BTW Atari800MacX does support pass through carts amongst its many other great features.

The Atari800 emulator's latest release should have the dual cartridge feature also. I checked my Atari800MacX dual cart code in there about a year or so ago, and I think the team just did an updated release.

Speaking of releases, this week was my last week of school for this semester, so if work allows, I should get around to releasing a Atari800MacX bug fix/maintenance release in the next week or two.

Mark

[drac030]

phaeron, on Sat Apr 30, 2011 1:01 AM, said:

By the way, the ARC command apparently doesn't handle general SDX device paths and won't extract from PCL:. It thinks it's A: instead.

Exactly. It is one of the things on the todo list.

[atx4us]

atarimac, on Sat Apr 30, 2011 12:43 PM, said:

spookt, on Sat Apr 23, 2011 8:10 AM, said:

Yeah, I guess we know about the carts but the OP was specifically asking about emulators.

Flashjazzcat was right BTW Atari800MacX does support pass through carts amongst its many other great features.

The Atari800 emulator's latest release should have the dual cartridge feature also. I checked my Atari800MacX dual cart code in there about a year or so ago, and I think the team just did an updated release.

Speaking of releases, this week was my last week of school for this semester, so if work allows, I should get around to releasing a Atari800MacX bug fix/maintenance release in the next week or two.

Mark

Mark,

Thanks for letting us know about the dual cartridge support for Atari800 2.2.1.

First, attach the "SDX443_intsdx128.car" cartridge image. Then, the "Insert SDX Piggyack Cartridge" will appear in the "Cartridge Management" menu. Choose this option to insert your piggy back cartridge. Nice!

Hayden

Edited by atx4us, Mon May 2, 2011 5:07 AM.

[HiassofT]

Hi!

I just ran into an issue with the SDX formatter (format.com):

If I send a percom block with a "floppy configuration" (i.e. one which has tracks/heads/sectors set, not a "hdd config" with just a single track), the format configuration (tracks/density) won't update to the percom block. If a "hdd config" is received, the number of sectors and density is displayed correctly and I can build a directory (formatting is unavailable then, of course).

No big issue for standard "floppies" with <= 1440 sectors, I can just manually set these values.

But it doesn't work for larger "floppies", for example 2880 QD sectors (80 tracks, 2 sides, 18 sectors of 512 bytes) or 5760 DD sectors (80 tracks, 2 sides, 36 sectors) as format.com won't let me choose more than 1440 sectors. If I build a directory it will create a VTOC with max. 1440 sectors - the remaining space is unavailable.

Could you maybe change this so that format.com respects the values in the percom block and allows building a directory with tracks*sides*sectors total sectors? Even better: also allow formatting these drives (including drives with a "hdd config"), I support this in AtariSIO and it will blank-out the whole image (sometimes nice for testing stuff).

so long,

Hias

[drac030]

HiassofT, on Thu May 5, 2011 4:03 AM, said:

But it doesn't work for larger "floppies", for example 2880 QD sectors (80 tracks, 2 sides, 18 sectors of 512 bytes) or 5760 DD sectors (80 tracks, 2 sides, 36 sectors) as format.com won't let me choose more than 1440 sectors. If I build a directory it will create a VTOC with max. 1440 sectors - the remaining space is unavailable.

Yes, the formatter has such a limitation. That's the way ICD wrote it.

Quote

Could you maybe change this so that format.com respects the values in the percom block and allows building a directory with tracks*sides*sectors total sectors?

Yes, I am planning to make the formatter do that and other things as well, so that it would become more flexible. This just requires time.

Quote

Even better: also allow formatting these drives (including drives with a "hdd config"), I support this in AtariSIO and it will blank-out the whole image (sometimes nice for testing stuff).

I don't think it is a good idea to even support the format command for such images, I even had to block this in SIO2BSD, as I once ended up with accidentally wiped out ATR image, when an "!" command intended for a real floppy drive was by my mistake also received by SIO2BSD. For real hard drives, physical formatting has no point either, and if you want to wipe the disk's content, a dedicated program is a much safer solution.

Edited by drac030, Sat May 7, 2011 2:12 PM.

[flashjazzcat]

The ARCLOCK.SYS driver in 4.43 isn't working properly for me. I had no troubles with an older driver (which I've now mislaid but hopefully will be able to find again), but every time the machine cold-starts, the driver resets the clock. I had to add the /F switch in CONFIG.SYS, otherwise I just kept getting "No ARC Clock". It's easy to miss the "clock reset" message, too, and one tends not to notice that the clock isn't set until one has inadvertently created a lot of files will nonsense dates.

It's rather frustrating, since Trub went to great lengths to get this driver to work properly. I even tested the betas, and I don't recall having any problems, although I do believe he made some change before the final version.

[HiassofT]

drac030, on Sat May 7, 2011 2:11 PM, said:

Quote

Could you maybe change this so that format.com respects the values in the percom block and allows building a directory with tracks*sides*sectors total sectors?

Yes, I am planning to make the formatter do that and other things as well, so that it would become more flexible. This just requires time.

Thanks a lot!

Quote

Quote

Even better: also allow formatting these drives (including drives with a "hdd config"), I support this in AtariSIO and it will blank-out the whole image (sometimes nice for testing stuff).

I don't think it is a good idea to even support the format command for such images, I even had to block this in SIO2BSD, as I once ended up with accidentally wiped out ATR image, when an "!" command intended for a real floppy drive was by my mistake also received by SIO2BSD. For real hard drives, physical formatting has no point either, and if you want to wipe the disk's content, a dedicated program is a much safer solution.

I never had the problem of a "mistakingly" received command frame with AtariSIO. As for real hard drives, well, wiping out 16MB would take quite some time and might not be too practicable with a maximum timeout of ~255 seconds. As for AtariSIO: everything's stored in RAM, so it's just a "delete[]" followed by a "new". Even if you accidentally wiped a drive you can still choose to not write back the data to your harddrive. And you have the big benefit that you can work with the drives just like real floppy drive - use DOS/Percom Block to configure it to 90k/130k/180k/16MB whatever, issue a format command and you have freshly allocated drive of your desired size

so long,

Hias

[kurtm]

HiassofT, on Mon May 9, 2011 5:03 AM, said:

I never had the problem of a "mistakingly" received command frame with AtariSIO. As for real hard drives, well, wiping out 16MB would take quite some time and might not be too practicable with a maximum timeout of ~255 seconds. As for AtariSIO: everything's stored in RAM, so it's just a "delete[]" followed by a "new". Even if you accidentally wiped a drive you can still choose to not write back the data to your harddrive. And you have the big benefit that you can work with the drives just like real floppy drive - use DOS/Percom Block to configure it to 90k/130k/180k/16MB whatever, issue a format command and you have freshly allocated drive of your desired size

so long,

Hias

This may be what Hias is saying, but here goes:

What if the emulation devices did take a percom block and when you format, it just creates a new image of the spec? It would probably have to pick a new name itself (or we could have an exotic SIO command that sets the name). But that way, they won't blow away an image by mistake, but you also have a way to create new images from the atari itself.

Thoughts?

--Kurt

[drac030]

HiassofT, on Mon May 9, 2011 5:03 AM, said:

I never had the problem of a "mistakingly" received command frame with AtariSIO.

Never so far, that is

Quote

As for AtariSIO: everything's stored in RAM, so it's just a "delete[]" followed by a "new". Even if you accidentally wiped a drive you can still choose to not write back the data to your harddrive.

For SIO emulators I still think that it is much safer to do that with some manual control, i.e. choosing options on the SIO emulator user panel/screen whatever. If you can block flushing the image contents to the disk, then you must be also able to wipe the image you select similar way.

Quote

And you have the big benefit that you can work with the drives just like real floppy drive - use DOS/Percom Block to configure it to 90k/130k/180k/16MB whatever, issue a format command and you have freshly allocated drive of your desired size

Not exactly. The SDX disk formatter allows to configure floppies (either real or emulated) and format them to a variety of formats. I agree that the variety is, maybe, not varied enough and the flexibility of the formatter's menu is to be enhanced (and it will be enhanced in some future), but at the other hand it allows you to format disks to 90/130/180/250/360/500/720/1000/1440k, which is a set of formats sufficient for most needs, isn't it.

There is however one exception, the disks which identify itself as "hard disks" (trk == 1) cannot be formatted. And I think it is reasonable, because:

1) real floppies do not return such PERCOM blocks

2) real hard drives do not need such formatting (partition wiping and resizing is done by dedicated software)

So the only real purpose of this change would be emulator support, and that's what we don't do. Despite that I think that it is actually good thing, if the device is able to tell the DOS in advance (i.e. before a format command is sent over the bus) that it does not wish to be formatted.

[HiassofT]

Hi!

drac030, on Mon May 9, 2011 2:52 PM, said:

Quote

And you have the big benefit that you can work with the drives just like real floppy drive - use DOS/Percom Block to configure it to 90k/130k/180k/16MB whatever, issue a format command and you have freshly allocated drive of your desired size

Not exactly. The SDX disk formatter allows to configure floppies (either real or emulated) and format them to a variety of formats. I agree that the variety is, maybe, not varied enough and the flexibility of the formatter's menu is to be enhanced (and it will be enhanced in some future), but at the other hand it allows you to format disks to 90/130/180/250/360/500/720/1000/1440k, which is a set of formats sufficient for most needs, isn't it.

There is however one exception, the disks which identify itself as "hard disks" (trk == 1) cannot be formatted. And I think it is reasonable, because:

1) real floppies do not return such PERCOM blocks

2) real hard drives do not need such formatting (partition wiping and resizing is done by dedicated software)

So the only real purpose of this change would be emulator support, and that's what we don't do. Despite that I think that it is actually good thing, if the device is able to tell the DOS in advance (i.e. before a format command is sent over the bus) that it does not wish to be formatted.

I have no problem with it, just wanted to suggest something which MyDos supports for ages and what I think to be a really nice feature.

so long,

Hias

[HiassofT]

Hi!

drac030, on Mon May 9, 2011 2:52 PM, said:

Quote

And you have the big benefit that you can work with the drives just like real floppy drive - use DOS/Percom Block to configure it to 90k/130k/180k/16MB whatever, issue a format command and you have freshly allocated drive of your desired size

Not exactly. The SDX disk formatter allows to configure floppies (either real or emulated) and format them to a variety of formats. I agree that the variety is, maybe, not varied enough and the flexibility of the formatter's menu is to be enhanced (and it will be enhanced in some future), but at the other hand it allows you to format disks to 90/130/180/250/360/500/720/1000/1440k, which is a set of formats sufficient for most needs, isn't it.

There is however one exception, the disks which identify itself as "hard disks" (trk == 1) cannot be formatted. And I think it is reasonable, because:

1) real floppies do not return such PERCOM blocks

2) real hard drives do not need such formatting (partition wiping and resizing is done by dedicated software)

So the only real purpose of this change would be emulator support, and that's what we don't do. Despite that I think that it is actually good thing, if the device is able to tell the DOS in advance (i.e. before a format command is sent over the bus) that it does not wish to be formatted.

I have no problem with it, just wanted to suggest something which MyDos supports for ages and what I think to be a really nice feature.

so long,

Hias

[drac030]

HiassofT, on Mon May 9, 2011 3:10 PM, said:

I have no problem with it, just wanted to suggest something which MyDos supports for ages and what I think to be a really nice feature.

I know that MyDOS' behaviour (sending PERCOM block to "high-capacity" drives, apparently in order to resize them) and I consider it useless. So we don't agree in this point.

[HiassofT]

drac030, on Mon May 9, 2011 3:25 PM, said:

I know that MyDOS' behaviour (sending PERCOM block to "high-capacity" drives, apparently in order to resize them) and I consider it useless. So we don't agree in this point.

OK, I'm fine with that!

so long,

Hias

[Keatah]

With the original website for SpartaDOS X 4.43, where can I get this nowadays? I'm looking to use it with Altirra 1.9.

All searches seem to return outdated links, which is what frakking google seems best at nowadays. Either that, or non-relevant links.

Edited by Keatah, Mon May 23, 2011 6:54 PM.

[rdea6]

Try post #1 of this Thread...

[Keatah]

rdea6, on Mon May 23, 2011 7:04 PM, said:

Try post #1 of this Thread...

Tried that, -- http://sdx.atari8.info/ -- 1st thing I did. Seems to be down or not accessible by my IP, never ever had that issue though. Is that page working for you? Because if so, then it is an ip provider problem and I can mess with a proxy then.

--update-- seems a proxy says it's dead too.

Edited by Keatah, Mon May 23, 2011 7:14 PM.

[spookt]

There's another thread floating around about this but I threw the zip file of 443 images which I grabbed at the weekend up to my web space:

http://www.sixtimesn...X443_images.zip

I can put the manual up there too if anyone needs it. Not sure if I have the latest extentions disk but I can look.

Hopefully the official site will be back soon.