Can AppleCommander write files to a specific track/sector?

[Mark Lemmert]

I am wondering if anybody knows if there is a way to specify the track and sector which AppleCommander writes files added via the AC command line interface?

My observation is that AC starts writing files added at track $3, sector $1, and always adds new files after the last file (with an empty sector in between). If possible I'd like to be able to specify the track and sector the file added will start at.


I've reviewed the command line guide on the AC website but haven't been able to discern a way to accomplish this. (http://applecommander.sourceforge.net/acguide.html)

Thanks much for any ideas!



Additional Information
--------------------------------

Example AC command line I'm using to write the files:

java -jar ac.jar -p my.program.dsk LOADER B 0x1F04 < LOADER.bin


Some context on the disk image I'm using, in case it's relevant

The disk image I'm using has I custom boot loader I wrote, which does not load DOS into memory except for RWTS. Upon completion, boot1 is customized to turn over control to my code.

I'm somewhat new to low level disk operations. My observation so far is that when running code like this without DOS loaded, I can make direct calls to RWTS to read/write to/from any tracks/sector on disk and essentially ignore the usual DOS methodology of how files are laid out on disk (from the book Beneath DOS I recall there is track reserved for the catalog and a sector skipped between the file data). To test this I literally did a write with RWTS to very track/sector and read it back again, verifying the data was the same.

For that reason, I'm fairly confident that if I can get AC to write a file to a specific track/sector, my code will be able to read it, even if I placed the file at a track/sector that DOS would not have for whatever reason.

If anybody has any ideas or sees any incorrect deductions/assumptions I've made, I really appreciate the feedback.

[Michael Pohoreski]

On Thursday, March 24, 2016 at 11:04:10 AM UTC-7, Mark Lemmert wrote:

> My observation is that AC starts writing files added at track $3, sector $1, and always adds new files after the last file (with an empty sector in between). If possible I'd like to be able to specify the track and sector the file added will start at.

I assuming you're talking about writing to a DOS 3.3 ? I don't know how AC works but I can give some info on DOS 3.3:

Normally, DOS 3.3 reserves the *entire* track $2 even though it never uses the last few sectors!! The first track with no data would naturally be Track $3, Sector $0 -- not sure why it is starting at sector $1. (DOS 3.3 is also dumb that you can never store data on track 0 but I digress.)

Does AC use the VTOC (Track $11, Sector $0) to determine what the first free sector is? Some of the modified DOSes (Pronto-DOS, IIRC) free up part of Track $2 for data.

[Michael Pohoreski]

On Thursday, March 24, 2016 at 11:04:10 AM UTC-7, Mark Lemmert wrote:

I know this probably won't help you today but I'll be writing a command line utility (pure C/C++ with no Java crap) to copy a file onto a virtual .DSK image in about month or so.

Right now I'm just writing a single file to the .DSK image starting at T0S0 and don't (yet) need the ability to place files at a specific Track/Sector location.

Normally this would be trivial to write (just start writing bytes at the correct offset) except you'll need to write in "pages" of 256 bytes in the correct DOS sector order.

You'll want to review "Beneath Apple DOS", Figure 3.24, "Comparison of Sector Skewing"

Physical Sector maps to DOS 3.3 Sector

A different approach has been used in DOS 3.3 in an attempt to maximize performance. The skewing is now done in software. The 16 physical sectors are numbered in ascending order (0, 1, 2, ... , 15) and are not physically skewed at all. A look-up table is used to translate a logical or soft sector number used by RWTS into the physical sector number found on the diskette. For example, if the logical sector number were a 2, this would be translated into the physical sector number 11 ($0B). Thus, RWTS treats physical sector 11 ($0B) as sector 2 for all intents and purposes. This presents no problem if RWTS is used for disk access, but would become a consideration if access were made without RWTS. DOS 3.3 uses what we refer to as a "2 descending" skew:

Physical
Sector DOS 3.3
0 0
1 7
2 E
3 6
4 D
5 5
6 C
7 4
8 B
9 3
A A
B 2
C 9
D 1
E 8
F F


NOTE: I am NOT talking about the skew used in the boot sequence:

* TABLE OF PHYSICAL BSECTR NUMBERS
* WHICH CORRESPOND TO THE LOGICAL
* BSECTRS 0-F ON TRACK ZERO...
BHERE2 EQU >*
TABLE EQU $800+BHERE2
DFB $00,13,11 ;00->00,01->13,02->11
DFB 09,07,05 ;03->09,04->07;05->05
DFB 03,01,14 ;06->03,07->01,08->14
DFB 12,10,08 ;09->12,10->10,11->08
DFB 06,04,02,15 ;12->6,13->04,14->02,15->

[David Schmidt]

On 3/24/2016 2:04 PM, Mark Lemmert wrote:
> I am wondering if anybody knows if there is a way to specify the
> track and sector which AppleCommander writes files added via the AC
> command line interface?

No, there's no capability to do that. The interface down to the
track/sector (or block, for ProDOS) level is buried deep in the code,
and is not surfaced to the user.

Recall that AC provides the same wrapper functions (i.e. writing a file)
to lots of different filesystems (Pascal, DOS, ProDOS, etc.) and each
has its own notion of file allocation, free pool management, and so on.
So while it's architecturally possible to add a specification for
allocation preference, there would have to be a way to translate that
preference into a form each filesystem could make sense of. And someone
would have to write it. ;-)

[Oliver Schmidt]

Hi Mark,

>The disk image I'm using has I custom boot loader I wrote, which does not l=
>oad DOS into memory except for RWTS. Upon completion, boot1 is customized t=

>o turn over control to my code.

I happend to do the very same back then.

>If anybody has any ideas or sees any incorrect deductions/assumptions I've =
>made, I really appreciate the feedback.=20

From my perspective it doesn't make sense to use AppleCommander in the
first place. The benefit of AppleCommander is that it knows about
Apple II file systems like DOS 3.3 and ProDOS 8.

However your disk image does _not_ use an Apple II file system but
rather loads files by direct access to the RWTS. So it's much more
appropriate for you to write a small C/C++ program that opens your
disk image as a plain file using the POSIX APIs open(), lseek(),
write() and close().

If your loader reads i.e track 3 sector 8 then you can put the 256
bytes of data to that place in the disk image with:

int dsk = open("myimage.dsk", O_WRONLY);
lseek(dsk, 3 * 256 * 16 + 8 * 256, SEEK_SET);
write(dsk, mybuffer, 256);
close(dsk);

Of course you can instead use any other language you like that allows
for random access to files. This includes script languages like Python
etc.

Regards,
Oliver

[Mark Lemmert]

On Thursday, March 24, 2016 at 1:57:20 PM UTC-5, Michael Pohoreski wrote:
> On Thursday, March 24, 2016 at 11:04:10 AM UTC-7, Mark Lemmert wrote:
>
> I know this probably won't help you today but I'll be writing a command line utility (pure C/C++ with no Java crap) to copy a file onto a virtual .DSK image in about month or so.
>
> Right now I'm just writing a single file to the .DSK image starting at T0S0 and don't (yet) need the ability to place files at a specific Track/Sector location.
>
> Normally this would be trivial to write (just start writing bytes at the correct offset) except you'll need to write in "pages" of 256 bytes in the correct DOS sector order.
>
> You'll want to review "Beneath Apple DOS", Figure 3.24, "Comparison of Sector Skewing"

Michael,

Thanks for your reply. The utility you described sounds like it may be very useful in my project. I look forward to seeing it!

If you need any help testing just let me know! (the timing is actually perfect, my post was an attempt to plan ahead, I won't need to tackle this challenge for another month or so)


I follow you in general on the difference between the physical sector and the DOS3.3 sector. Is this information needed to use your utility or information on what it's doing under the hood?


Thanks again.


Mark

[Mark Lemmert]

David,

Thanks for your reply. The reasons make sense to me. It's helpful just to know it's not possible so I can stop researching a dead end.


Mark

[Mark Lemmert]

On Friday, March 25, 2016 at 11:09:51 AM UTC-5, Oliver Schmidt wrote:
>it's much more
> appropriate for you to write a small C/C++ program that opens your
> disk image as a plain file using the POSIX APIs open(), lseek(),
> write() and close().
>
> If your loader reads i.e track 3 sector 8 then you can put the 256
> bytes of data to that place in the disk image with:
>
> int dsk = open("myimage.dsk", O_WRONLY);
> lseek(dsk, 3 * 256 * 16 + 8 * 256, SEEK_SET);
> write(dsk, mybuffer, 256);
> close(dsk);

Oliver,

Thanks for your reply.


This means sense. I'll admit that my using AppleCommander has been essentially a bandaid to my limited knowledge of modern programming languages. What you say makes a lot of sense. I can see how some C/C++ code could produce a better overall solution.

Thanks of the specific code example.



Mark

[Michael Pohoreski]

On Friday, March 25, 2016 at 11:11:12 AM UTC-7, Mark Lemmert wrote:
> Michael,
>
> Thanks for your reply. The utility you described sounds like it may be very useful in my project. I look forward to seeing it!

Hey Mark, glad to know that this actually might end up being useful for others.

> If you need any help testing just let me know! (the timing is actually perfect, my post was an attempt to plan ahead, I won't need to tackle this challenge for another month or so)

Don't worry -- I'll throw it up on GitHub and make an annoucement. :-)

> I follow you in general on the difference between the physical sector and the DOS3.3 sector. Is this information needed to use your utility or information on what it's doing under the hood?

I'll probably add a command line so you have *complete* control over the sector interleaving.

i.e. This is what I'm tentatively thinking:
-do Dos 3.3 Sector Order
-po ProDOS Sector Order
-skew Use custom interleaving

e.g.
bin2dsk foo.bin -t0 -s0 -skew "0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F" -o foo.dsk


I took a look at how AppleWin handles the sector skew. There are 3 arrays @ Line 62
https://github.com/AppleWin/AppleWin/blob/master/source/DiskImageHelper.cpp

// File: DiskImageHelper
/* DO logical order 0 1 2 3 4 5 6 7 8 9 A B C D E F */
/* physical order 0 D B 9 7 5 3 1 E C A 8 6 4 2 F */

/* PO logical order 0 E D C B A 9 8 7 6 5 4 3 2 1 F */
/* physical order 0 2 4 6 8 A C E 1 3 5 7 9 B D F */

BYTE CImageBase::ms_SectorNumber[NUM_SECTOR_ORDERS][0x10] =
{
{0x00,0x08,0x01,0x09,0x02,0x0A,0x03,0x0B, 0x04,0x0C,0x05,0x0D,0x06,0x0E,0x07,0x0F},
{0x00,0x07,0x0E,0x06,0x0D,0x05,0x0C,0x04, 0x0B,0x03,0x0A,0x02,0x09,0x01,0x08,0x0F},
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}
};

This mapping doesn't look too difficult. Just need to use the "inverse" for writing.

I still need to code up my own RWTS (or leech DOS3.3's, or Beautiful Boot's R(W)TS one) but after thinking about this ... this might happen sooner then later. :-)

> Thanks again.

Thank me once I got it written :-)