A2Aviator

Nothing comes to mind when I think about it.. but I'm wondering if
there's something out there that will copy a volume to a specified
location, to a folder named the same as the source volume, and then
eject it. .. and automatically do it again when the next disk is
inserted.

The pretense is, after making images of floppies, to be able to copy
the contents of the floppies to a server as well. Since I have an
autoloader this can be done un-attended. The imaging is taken care of,
with ImageMaker, (Sheppyware)

ict@ccess

A2Aviator wrote:
> Nothing comes to mind when I think about it.. but I'm wondering if
> there's something out there that will copy a volume to a specified
> location, to a folder named the same as the source volume, and then
> eject it. .. and automatically do it again when the next disk is
> inserted.
>
> The pretense is, after making images of floppies, to be able to copy
> the contents of the floppies to a server as well. Since I have an
> autoloader this can be done un-attended. The imaging is taken care of,
> with ImageMaker, (Sheppyware)


There are two programs in the Nibble magazines called "copyall" and
"directory copy" that copies complete directories and volumes. It
would not take much to write a short applesoft program to eject the
disk and and create a folder with the same name as the new inserted
disk. Then just call the copy routine to transfer the files over.

Rob

A2Aviator

Hmmm... Nibble. Never thought of that ..

The only thing.. Applesoft - ProDOS 8 .. what about possible
resources.

Obviously not an issue for P8 stuff, which is my first aim anyway.

Makes me wonder though, if there's a macro type thing that does mouse
control for GS/OS, that I may have missed over the years. The only
thing I can think of is the El Macro CDA.

As for ejecting from Applesoft, seems I recall doing that in the past,
that'll be a PEEK into the past.

Toinet

It is not clear to me if you want to 1/ create a disk image of your
floppy and put it into a folder OR 2/ copy the files of the floppy
into a folder?

The advantage of 1 is that you can copy any kind of floppies (ProDOS,
DOS, etc.). On the contrary with 2, you are limited to ProDOS.

antoine

ict@ccess

A2Aviator wrote:
> Hmmm... Nibble. Never thought of that ..
>
> The only thing.. Applesoft - ProDOS 8 .. what about possible
> resources.
>
> Obviously not an issue for P8 stuff, which is my first aim anyway.
>
> Makes me wonder though, if there's a macro type thing that does mouse
> control for GS/OS, that I may have missed over the years. The only
> thing I can think of is the El Macro CDA.
>
> As for ejecting from Applesoft, seems I recall doing that in the past,
> that'll be a PEEK into the past.


Totally forgot about resource forks since currently all my programming
has been under P8. I am studying the program called "Unforkit" to see
how it converts the DATA and RSRC forks into separate folders. But my
ultimate goal is to rewrite Prodos 8 to recognize an 8 GB CFFA drive
as one complete drive. So, slight changes also need to be made to the
volume boot blocks and directory which I have already done. Once I
made the changes to Prodos 8 to read and write to the drive, I was
looking into a way to copy extended files from all the regular disks
onto the 8 GB drive. Then I would have needed some help in writing a
driver for GSOS to recognize the drive.

It doesn't seem that big of a feat to me. The greatest downtime is to
study the P8 code. So if anyone has a source listing of Prodos 8
V2.0.3 would help speed up the transition tremendously. Then,
obviously I would release the new version of P8 and extended file copy
program into the public domain.

I have already written a driver for Dreher's CFFA card to recognize an
8 GB drive, as, 256 separate drives of 32 MB each. But I would like
Prodos 8 to recognize it as one complete 8 GB drive.


Rob

A2Aviator

On Sep 4, 12:35*am, Toinet <antoine.vig...@laposte.net> wrote:
> It is not clear to me if you want to 1/ create a disk image of your
> floppy and put it into a folder OR 2/ copy the files of the floppy
> into a folder?

I want both.

'1' is taken care of for the most part, right now.
'2' is what I'm exploring options for.

I want to archive the disks as a whole, and prior to image support
directly on the IIgs, the way I was doing it was using Shrinkit to
archive the disk, as that was the only other universally accepted and
understood way of dealing with disk images. The emulator had it's own
way, and the real hardware had it's own way.

Using Shrink II on a Mac, one could then extract the Shrinkit disk
image and it would create a DC42 image of the extraction so you then
have an emulator compatible image.

Then I wish to bring the files onto a server as well, to make an
archive thats accessible at the file/folder level. So that files can
be browsed using an emulator or platinum hardware without having to
mount a crapton of disk images, drag, unmount, etc.

Toinet

On 4 sep, 11:57, "ict@ccess" <gids...@sasktel.net> wrote:
>
> Totally forgot about resource forks since currently all my programming
> has been under P8. *I am studying the program called "Unforkit" to see
> how it converts the DATA and RSRC forks into separate folders. *But my
> ultimate goal is to rewrite Prodos 8 to recognize an 8 GB CFFA drive
> as one complete drive. *So, slight changes also need to be made to the
> volume boot blocks and directory which I have already done. *Once I
> made the changes to Prodos 8 to read and write to the drive, I was
> looking into a way to copy extended files from all the regular disks
> onto the 8 GB drive. *Then I would have needed some help in writing a
> driver for GSOS to recognize the drive.

Aargh, a 32 bit ProDOS-8!

>
> It doesn't seem that big of a feat to me. *The greatest downtime is to
> study the P8 code. *So if anyone has a source listing of Prodos 8
> V2.0.3 would help speed up the transition tremendously. *Then,
> obviously I would release the new version of P8 and extended file copy
> program into the public domain.

That sounds dangerous to me but the idea is great, I've always wanted
a ProDOS 8 support for bigger drives but that will prevent us from
accessing such drives from GS/OS and other platforms.

Instead of rewriting ProDOS 8, why don't you add a disk driver to
support bigger drives? That support may be limited to the physical
access not to the handling of a file system thus reducing the
interest, I don't remember exactly what that does but I really believe
the changes will kill compatibility. I'd rather write a GS/OS FST
instead of breaking what P8 does well.

Correct me if I'm wrong, I may have missed some ideas.

>
> I have already written a driver for Dreher's CFFA card to recognize an
> 8 GB drive, as, 256 separate drives of 32 MB each. *But I would like
> Prodos 8 to recognize it as one complete 8 GB drive.
>

What did you do? Disassembly, addition of new device information and
re-assembly?

> Rob

antoine

ict@ccess

> > Totally forgot about resource forks since currently all my programming
> > has been under P8. *I am studying the program called "Unforkit" to see
> > how it converts the DATA and RSRC forks into separate folders. *But my
> > ultimate goal is to rewrite Prodos 8 to recognize an 8 GB CFFA drive
> > as one complete drive. *So, slight changes also need to be made to the
> > volume boot blocks and directory which I have already done. *Once I
> > made the changes to Prodos 8 to read and write to the drive, I was
> > looking into a way to copy extended files from all the regular disks
> > onto the 8 GB drive. *Then I would have needed some help in writing a
> > driver for GSOS to recognize the drive.
>
> Aargh, a 32 bit ProDOS-8!

Actually it would be only a 24 bit Prodos 8. Although the CFFA card
can access up to 128 GB, that would seem way overkill for such small
file sizes of most apple II files. And 2x 8 GB drives would be
supported for a total of 16 GB is probably still larger than ever
would be needed to store every program ever written for any Apple II.
>
> >
> > It doesn't seem that big of a feat to me. *The greatest downtime is to
> > study the P8 code. *So if anyone has a source listing of Prodos 8
> > V2.0.3 would help speed up the transition tremendously. *Then,
> > obviously I would release the new version of P8 and extended file copy
> > program into the public domain.
>
> That sounds dangerous to me but the idea is great, I've always wanted
> a ProDOS 8 support for bigger drives but that will prevent us from
> accessing such drives from GS/OS and other platforms.

Not at all. Only 4 bytes need to be added and 2 bytes changed in the
volume and directory headers. The forward and backward links, the
file start block, and the hard drive size. And the number of files
per directory block and bytes per entry would need to be adjusted.
>
> Instead of rewriting ProDOS 8, why don't you add a disk driver to
> support bigger drives? That support may be limited to the physical
> access not to the handling of a file system thus reducing the
> interest, I don't remember exactly what that does but I really believe
> the changes will kill compatibility. I'd rather write a GS/OS FST
> instead of breaking what P8 does well.
>
Due to the way the Volume header is laid out, the maximum size of a
drive will always be 32 MB. I have already written a driver to access
up to 256 drives of 32 MB each. All that is needed is to use the
(V)olume command as in CATALOG,V255 would catalog drive #255. By
using the V parameter, all 256 drives can be accessed as if it were
drive #1.

> Correct me if I'm wrong, I may have missed some ideas.
>
> >
> > I have already written a driver for Dreher's CFFA card to recognize an
> > 8 GB drive, as, 256 separate drives of 32 MB each. *But I would like
> > Prodos 8 to recognize it as one complete 8 GB drive.
> >
>
> What did you do? Disassembly, addition of new device information and
> re-assembly?
>

I just wrote a driver that bypassed the protocols, calculated the high
order bit in a 24 bit number, and accessed the read/write block
routines already in the slot ROM. By adding 4 bytes to the volume and
directory headers and changing 2 more, access can be made to the
entire 8 GB contiguously without having boot blocks and volume header
at the beginning of each 32 MB interval.

This driver only works on dreher's CFFA card version 2.0. Check it
out here

http://dreher.net/phpBB/viewtopic.ph...55aacf405c78eb

and here is the updated short driver routine.

The bytes that get changed to your slot number are:
$4001 - $0n, 4012 - $0n, 4024 - $n0 and 402A - $Cn where n is the slot
# your card is in.

4000:A9 05 0A A8 A9 10 99 10 BF C8 A9 40 99 10 BF 60
40108 A0 05 AD 68 BE F0 30 D9 F8 05 B0 2B AA CA 8A
4020:99 F8 04 A2 50 2C FF CF 2C 00 C5 20 DE CB A5 42
40300 07 A0 FF A2 FF A9 00 60 C9 02 D0 02 38 89 18
4040:20 20 CB B0 02 A9 00 60 A9 02 60 00 00 00 00 00

rich12345

On Sep 3, 10:22*pm, A2Aviator <a2avia...@gmail.com> wrote:
> Makes me wonder though, if there's a macro type thing that does mouse
> control for GS/OS, that I may have missed over the years. The only
> thing I can think of is the El Macro CDA.

There is one "macro type thing" that does mouse control for GS/OS,
I cannot remember the name, but it comes with source code, wherever
it is.

Toinet

On 5 sep, 20:29, rich12345 <aiiad...@gmail.com> wrote:
> On Sep 3, 10:22*pm, A2Aviator <a2avia...@gmail.com> wrote:
>
> > Makes me wonder though, if there's a macro type thing that does mouse
> > control for GS/OS, that I may have missed over the years. The only
> > thing I can think of is the El Macro CDA.
>
> There is one "macro type thing" that does mouse control for GS/OS,
> I cannot remember the name, but it comes with source code, wherever
> it is.

It is included in the ROM with FakeMouse,
antoine