SpartaDOS X 4.43 an the H: device

[walktari]

Hi there,

 

could anyone give me a hint why it seems to be impossible to access the H: device in Altirra and Atari800Win from the command line using SpartaDOS X 4.42 and 4.43? There's no problem with accessing the H: device in SDX from BASIC (SAVE "H:MYPROG.BAS").

 

Moreover BeWeDOS and RealDOS can access the H: device from command line, COPY MYPROG.BAS H:MYPROG.BAS works.

 

Thanks,

 

walktari

[flashjazzcat]

OK

 

The original authors of SDX wanted to support the referencing of drives by letters as well as numbers, and they also needed a device name for the cartridge, which is mapped out like a disk drive. If you want to reference drive 5 as "E:", the CIO naming conventions go out of the window.

 

However, they also understood that - outside of the command processor - people would still want to use CIO device names, and also access the new kernel devices from the CIO. Thus, they implemented a translation system. From applications (and BASIC), you can access drives and all the usual CIO devices in the normal way. However, in order to access the "new" devices - such as CAR: - you access it through the "D:" driver, i.e. "DCAR:". You can access any SDX kernel device name through the CIO by prefixing the device name with "D".

 

The SDX com processor, however, needs "E:", "K:", "H:" etc for drive numbers and will always interpret them as such. You cannot access CIO device names from the command prompt.

 

Emulator writers took the unfortunate but understandable decision to implement the "H:" device at the CIO rather than the SIO level. Thus you cannot access a device driver "H:" from the SDX command prompt.

 

If H: had been implemented at the SIO level (a rather more complex solution), you'd just mount the PC folder as disk 3 or whatever, and access it from SDX using "C:"

 

What I'm going to have a crack at is writing an SDX kernel driver whose functions are mapped onto wrapper routines which make calls to the H: driver through the CIO, and return data from H: in a packaged-up form which the kernel drivers expect to see. You'll then access H: from the command line via device "HDD:".

Edited April 19, 2011 by flashjazzcat

[drac030]

I'd say that the want to reference drives by letters is more a side effect than the purpose. But anyway, Sparta X is more a separate OS than just a DOS, it has own I/O kernel, own device drivers, own everything. If anyone ever wanted CP/M on the Atari, then Sparta X is much better than CP/M, it virtually has capabilities of MS-DOS. And it is connected to CIO just for backward compatibility, the ROM OS is used as BIOS for some of the devices (like CON: and PRN: ). Therefore the command processor does not use CIO, and thus you cannot use CIO devices directly at the command prompt.

 

The default device in Sparta X command processor is "DSK:". "Default" means that its identifier may be omitted, the user is only required to specify the unit (= drive number). The drive number may be specified as 1:, 2:, 3: ... or as A:, B:, C: ... Therefore if you type H: in the command processor, it interprets it as "DSKH:" or "DSK8:", i.e. drive 8.

 

fjc: I seriously ask you to abandon the "HDD:" as the device name, I am already fed up answering stupid questions about real hard disks, such as: "does it work as H: ?" asked by people who only used emulators and somehow came to an idea that "H:" = hard disk, and that that's the way Atari uses a hard disk. Despite that, "H:" does not stand for "hard disk", but for "host filesystem". Name it as you want, HFS: or whatever, just NOT "HDD:" please.

[flashjazzcat]

fjc: I seriously ask you to abandon the "HDD:" as the device name, I am already fed up answering stupid questions about real hard disks, such as: "does it work as H: ?" asked by people who only used emulators and somehow came to an idea that "H:" = hard disk, and that that's the way Atari uses a hard disk. Despite that, "H:" does not stand for "hard disk", but for "host filesystem". Name it as you want, HFS: or whatever, just NOT "HDD:" please.

OK - that's an understandable frustration. HFS: it is then.

[Roydea6]

fjc: I seriously ask you to abandon the "HDD:" as the device name, I am already fed up answering stupid questions about real hard disks, such as: "does it work as H: ?" asked by people who only used emulators and somehow came to an idea that "H:" = hard disk, and that that's the way Atari uses a hard disk. Despite that, "H:" does not stand for "hard disk", but for "host filesystem". Name it as you want, HFS: or whatever, just NOT "HDD:" please.

OK - that's an understandable frustration. HFS: it is then.

 

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.

 

Also instead of HFS: why not EMU: or would that interfer with the emupack files.., but if I didn't have to load the emupack files there shouldn't be any problem and my head wouldn't have to remember a different syntax.

[_The Doctor__]

Did DHFS: ever get created?

[flashjazzcat]

No, but congratulations on shattering your own already impressive record.

 

EDIT: The existence of the PCL: device and support for it in emulation has pretty much made the HFS: device redundant anyway, IMO.

 

 

Edited June 7, 2023 by flashjazzcat

[_The Doctor__]

H: has it's own unique method of converting long filenames and giving it an access method for SpartaDOS X use isn't a bad thing. I already use PCL: as PCLINK & RespeQT were always up and running for the most part. They both have their uses.

I suppose looking into aliasing or redirection in some way might be helpful. I didn't use emulation much if at all previously but there are times where I have to more-so these days.

Edited June 7, 2023 by _The Doctor__

[flashjazzcat]

Konrad has kindly published developer documentation covering kernel device drivers, so presumably someone who has a burning desire to implement HFS: will now do so.

[+Stephen]

10 minutes ago, flashjazzcat said:

Konrad has kindly published developer documentation covering kernel device drivers, so presumably someone who has a burning desire to implement HFS: will now do so.

Or we could check back in 2035.

[_The Doctor__]

59 minutes ago, Stephen said:

Or we could check back in 2035.

gotta make that 2029, it should take half as long to reach the next order of magnitude.