Dear All,

I have just opened a new project on Brutal Deluxe's website. This
project is dedicated to the AppleDisk5.25 GS/OS driver provided by
Apple.

I would like it to support new features so that other File System
Translators could be used (there are two orphans close to me ;-)

Please visit http://www.brutal-deluxe.fr/projects/appledisk5.25/index.html
or access to it via our home page located at http://www.brutal-deluxe.fr/

Your comments, emails and warnings are welcome,

Antoine Vignau
Brutal Deluxe Software

"Toinet" <antoine.vignau@laposte.net> wrote in message news:6d76252c-20d0-4200-8667-a9d0cf7593a5@v5g2000prm.googlegroups.com...
> Dear All,
> 
> I have just opened a new project on Brutal Deluxe's website. This
> project is dedicated to the AppleDisk5.25 GS/OS driver provided by
> Apple.
> 
> I would like it to support new features so that other File System
> Translators could be used (there are two orphans close to me ;-)
> 
> Please visit http://www.brutal-deluxe.fr/projects/appledisk5.25/index.html
> or access to it via our home page located at http://www.brutal-deluxe.fr/
> 
> Your comments, emails and warnings are welcome,
> 
> Antoine Vignau
> Brutal Deluxe Software 

This link works.  ;-) 

http://www.brutal-deluxe.fr/projects/appledisk525/index.html 

Bill Garber from GS-Electronics
http://www.garberstreet.com

"If you wish to forget anything on the 
spot, make a note that this thing is to 
be remembered."  (Edgar Allen Poe) 

Toinet wrote:
> Dear All,
> 
> I have just opened a new project on Brutal Deluxe's website. This
> project is dedicated to the AppleDisk5.25 GS/OS driver provided by
> Apple.
> 
> I would like it to support new features so that other File System
> Translators could be used (there are two orphans close to me ;-)

Great project!  Since day one with GSOS I've wanted an FST for Apple CP/M 
format.  I don't think Apple ever released a shred of information on the API 
for FSTs, so it's likely to be a lot of disassembly.

I'm rooting for you.

Steve

"Toinet" <antoine.vignau@laposte.net> wrote in message 
news:6d76252c-20d0-4200-8667-a9d0cf7593a5@v5g2000prm.googlegroups.com...
>I would like it to support new features so that other File System 
>Translators could be used

Mr. T.

C'est si bon!

I am inspired. Now I have another reason to aquire a GS. This simplifies the 
13 sector problem and I knew the experts would come forth... I was wondering 
how I would get that 13 sector disk image back onto a disk.

Bill

On 15 nov, 00:21, Steven Hirsch <snhir...@gmail.com> wrote:
> Great project! =A0Since day one with GSOS I've wanted an FST for Apple CP=
/M
> format. =A0I don't think Apple ever released a shred of information on th=
e API
> for FSTs, so it's likely to be a lot of disassembly.
>
> I'm rooting for you.
>
> Steve

I would rather say that we can now create FSTs (see our RDOS FST) but
I will focus on the CP/P disks which I have never had between my hands
but I know where they are on Asimov.

Nevertheless, those disks are 140 KB long, 35 tracks of 16 sectors,
just like our Pro/DOS disks but were these disks copyable with
Locksmith? Were the disk drives connected to the CP/M card or do the
Apple II disk controller card?

Any other info on the "physical" disk format interest me. The
A2.CPM.ref.txt found on asimov is a good starting point.

Thank you,

antoine

On Nov 16, 8:10=A0am, Toinet <antoine.vig...@laposte.net> wrote:

> Nevertheless, those disks are 140 KB long, 35 tracks of 16 sectors,
> just like our Pro/DOS disks but were these disks copyable with
> Locksmith? Were the disk drives connected to the CP/M card or do the
> Apple II disk controller card?

> Any other info on the "physical" disk format interest me. The
> A2.CPM.ref.txt found on asimov is a good starting point.

You boot up normally as usual, via the Apple II disk controller card,
and then loading the OS, finds the CP/M and then starts running the OS
on that add-on card.

You can copy the software with most disk copy software on the Apple II
side.

On Nov 15, 3:35=A0pm, wyeo <willie...@gmail.com> wrote:
>
> You boot up normally as usual, via the Apple II disk controller card,
> and then loading the OS, finds the CP/M and then starts running the OS
> on that add-on card.
>
> You can copy the software with most disk copy software on the Apple II
> side.

Diskmaker8 works for me when recreating Apple CP/M disks.

The 5.25" drives were connected to the standard controller. It's been a 
while but as far as I know CP/M disks used a standard 16-sector low-level 
format, meaning they could be copied by any utility that copied an entire 
disk image. Obviously the contents of the sectors would be unintelligible to 
any DOS, Pascal or ProDOS file-based utility (that didn't have specific 
support for CP/M disks).

The only low-level difference I'm aware of is that the sector interleave was 
unique to CP/M disks.

Physical: 0 1 2 3 4 5 6 7 8 9 A B C D E F
DOS:      0 D B 9 7 5 3 1 E C A 8 6 4 2 F
Pascal:   0 2 4 6 8 A C E 1 3 5 7 9 B D F
CP/M:     0 3 6 9 C F 2 5 8 B E 1 4 7 A D

ProDOS uses the same interleave as Pascal.
CP/M disks used a 1K allocation unit, so information is stored in four 
"consecutive" sectors, for example: 0 3 6 9.
-- 
Peter Watson
-- Write to MS-DOS disks on the Apple IIgs?
-- Impossible!  ;-)


"Toinet" <antoine.vignau@laposte.net> wrote in message 
news:75f76ad7-8489-4311-958c-0288c96d84af@z28g2000prd.googlegroups.com...
On 15 nov, 00:21, Steven Hirsch <snhir...@gmail.com> wrote:
> Great project! Since day one with GSOS I've wanted an FST for Apple CP/M
> format. I don't think Apple ever released a shred of information on the 
> API
> for FSTs, so it's likely to be a lot of disassembly.

I would rather say that we can now create FSTs (see our RDOS FST) but
I will focus on the CP/P disks which I have never had between my hands
but I know where they are on Asimov.

Nevertheless, those disks are 140 KB long, 35 tracks of 16 sectors,
just like our Pro/DOS disks but were these disks copyable with
Locksmith? Were the disk drives connected to the CP/M card or do the
Apple II disk controller card?

Any other info on the "physical" disk format interest me. The
A2.CPM.ref.txt found on asimov is a good starting point.

Thank you,

antoine 

Toinet wrote:

> I would rather say that we can now create FSTs (see our RDOS FST) but
> I will focus on the CP/P disks which I have never had between my hands
> but I know where they are on Asimov.
> 
> Nevertheless, those disks are 140 KB long, 35 tracks of 16 sectors,
> just like our Pro/DOS disks

Physically, they are 140 KB GCR encoded diskettes and can be sector-copied by 
any 16-sector capable Apple 2 series machine.

My interest is in seeing the _file_system_ accessible through the FST. 
Specifically, to catalog CP/M diskettes and copy files to and from them. 
Support for one of the recognized time & datestamp extensions would be an 
added extra.

The CP/M directory format is well documented and can probably be turned up 
with a little Googling.

mojoehand wrote:
> On Nov 15, 3:35 pm, wyeo <willie...@gmail.com> wrote:
>> You boot up normally as usual, via the Apple II disk controller card,
>> and then loading the OS, finds the CP/M and then starts running the OS
>> on that add-on card.
>>
>> You can copy the software with most disk copy software on the Apple II
>> side.
> 
> Diskmaker8 works for me when recreating Apple CP/M disks.

I have any number of ways to image / re-create CP/M diskettes.  My motivation 
is to have the file system directly accessible from GSOS.  Read-only would be 
a good start, but R/W would be more useful.

On Nov 16, 12:10 am, Toinet <antoine.vig...@laposte.net> wrote:

> Were the disk drives connected to the CP/M card or do the
> Apple II disk controller card?

The regular Disk ][ handles the CP/M diskettes. 6502 boots off the
diskette the usual way, at certain point transfers control to Z80,
then serves disk I/O requests when necessary. I guess the stock RWTS
could've been used.

> Any other info on the "physical" disk format interest me. The
> A2.CPM.ref.txt found on asimov is a good starting point.

As the others pointed out, nothing different from the 16 sector format
except for the interleave.

Thank you All,

The following address summarizes all the necessary information, I
believe. Can you please validate that it is correct? http://www.dcast.vbox.co.uk/cpm.html

I like the usage of the eighth bit on the three extension letters!

My understanding is:
- standard GCR encoded disk
- 35 tracks / 16 sectors with a specific interleave
- a block is a set of 4 sectors
- a block is 1024 bytes long
- block number 0 starts on track 3, sector 0
- blocks 80 to 8F are reserved for cp/m (tracks 0 to 2)
- two blocks reserved for the directory (blocks 0 and 1)
- a deleted file entry holds $E5 at offset 0
- there are no load address nor file length
- file length can be determined by the number of blocks)

If I understand correctly, the rc byte (offset +F) holds the number of
128-byte records in a file. I would have thought it held the number of
1024-byte blocks. Am I wrong?

As the AppleDisk5.25 driver works with 256 and 512-byte blocks, that
requires some changes... More ProDOS than DOS 3.3 or RDOS.

Can someone create a cp/m disk which contains only one big file (the
biggest that can be created) ? I would like to validate the value of a
file entry at offset +C. That value is 1 when the file is bigger than
16 blocks but which value is this if the file is bigger than 32 or 48
blocks?

Thank you in advance.

antoine

nb. email address can be found on brutal-deluxe.fr

Toinet wrote:
> Thank you All,
> 
> The following address summarizes all the necessary information, I
> believe. Can you please validate that it is correct? http://www.dcast.vbox.co.uk/cpm.html
> 
> I like the usage of the eighth bit on the three extension letters!
> 
> My understanding is:
> - standard GCR encoded disk
> - 35 tracks / 16 sectors with a specific interleave

Yes

> - a block is a set of 4 sectors
> - a block is 1024 bytes long

It depends, although this sounds correct for Apple CP/M

> - block number 0 starts on track 3, sector 0
> - blocks 80 to 8F are reserved for cp/m (tracks 0 to 2)

For the majority of cases, yes.  Some of the Microsoft Softcard CP/M systems 
recognize a so-called "data disk" mode that wraps around from track 34 to use 
0, 1 and 2 as additional data storage.  There is some trickery involving a 
fake directory entry to flag this situation, but I don't remember all the details.

> - two blocks reserved for the directory (blocks 0 and 1)

Correct, but specific for the Apple implementation

> - a deleted file entry holds $E5 at offset 0
> - there are no load address nor file length

Load address or other handling (batch file invocation) is implicit, based 
(usually) on the type of the file as determined by the extension.

> - file length can be determined by the number of blocks)

All true as far as I know.  Files are always modulo 128 in size.  Text files 
are terminated with ^Z to indicate the actual end of data, but the sector is 
padded with junk as required to even out the size.

> If I understand correctly, the rc byte (offset +F) holds the number of
> 128-byte records in a file. I would have thought it held the number of
> 1024-byte blocks. Am I wrong?

I don't remember this level of detail any more, but here is a good, concise 
explanation of the CP/M directory and disk structure:

http://manpages.ubuntu.com/manpages/feisty/man5/cpm.html

Steve

Toinet wrote:
> Thank you All,
> 
> The following address summarizes all the necessary information, I
> believe. Can you please validate that it is correct? http://www.dcast.vbox.co.uk/cpm.html
> 
> I like the usage of the eighth bit on the three extension letters!

For extensions like ZSDOS and CP/M 3.x, it's all of the letters.

Here's even more valuable information:

http://www.seasip.demon.co.uk/Cpm/formats.html

I guess Apple never released a CP/M FST for two (different) reasons:

- Microsoft
- the AppleDisk5.25 deals with blocks of 512 bytes only (even for DOS
3.3) and CP/M with 1KB blocks at a minimum.

Other reasons may exist...

antoine

Toinet wrote:
> I guess Apple never released a CP/M FST for two (different) reasons:
> 
> - Microsoft

Microsoft has no proprietary stake in CP/M.  At the time, it was owned by 
Digital Research (later Caldera).

> - the AppleDisk5.25 deals with blocks of 512 bytes only (even for DOS
> 3.3) and CP/M with 1KB blocks at a minimum.

???  Why is this a problem?  It's just the way it is.  CP/M BIOS 
implementations used deblocking to translate between physical sectors and CP/M 
records (128 byte blocks).

On Nov 17, 9:47=A0am, Steven Hirsch <snhir...@gmail.com> wrote:

> > - the AppleDisk5.25 deals with blocks of 512 bytes only (even for DOS
> > 3.3) and CP/M with 1KB blocks at a minimum.
>
> ??? =A0Why is this a problem? =A0It's just the way it is. =A0CP/M BIOS
> implementations used deblocking to translate between physical sectors and=
 CP/M
> records (128 byte blocks).

It shouldn't be at all. I have several CP/M volumes on 800kb 3.5"
media. Those should also be readable with the FST.

Matt

In comp.sys.apple2 Toinet <antoine.vignau@laposte.net> wrote:
> My understanding is:
> - standard GCR encoded disk
> - 35 tracks / 16 sectors with a specific interleave
> - a block is a set of 4 sectors
> - a block is 1024 bytes long
> - block number 0 starts on track 3, sector 0
> - blocks 80 to 8F are reserved for cp/m (tracks 0 to 2)
> - two blocks reserved for the directory (blocks 0 and 1)
> - a deleted file entry holds $E5 at offset 0
> - there are no load address nor file length
> - file length can be determined by the number of blocks)
> 
> If I understand correctly, the rc byte (offset +F) holds the number of
> 128-byte records in a file. I would have thought it held the number of
> 1024-byte blocks. Am I wrong?

Source code for the CP/M disk reader in CiderPress:

  http://ciderpress.cvs.sourceforge.net/viewvc/ciderpress/CiderPress/diskimg/CPM.cpp?revision=1.1.1.1&view=markup

We discovered that, on some Microsoft Softcard, disks, blocks 80-8f can be
used to hold data.

-- 
Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/

Andy McFadden wrote:
> In comp.sys.apple2 Toinet <antoine.vignau@laposte.net> wrote:
>> My understanding is:
>> - standard GCR encoded disk
>> - 35 tracks / 16 sectors with a specific interleave
>> - a block is a set of 4 sectors
>> - a block is 1024 bytes long
>> - block number 0 starts on track 3, sector 0
>> - blocks 80 to 8F are reserved for cp/m (tracks 0 to 2)
>> - two blocks reserved for the directory (blocks 0 and 1)
>> - a deleted file entry holds $E5 at offset 0
>> - there are no load address nor file length
>> - file length can be determined by the number of blocks)
>>
>> If I understand correctly, the rc byte (offset +F) holds the number of
>> 128-byte records in a file. I would have thought it held the number of
>> 1024-byte blocks. Am I wrong?
> 
> Source code for the CP/M disk reader in CiderPress:
> 
>   http://ciderpress.cvs.sourceforge.net/viewvc/ciderpress/CiderPress/diskimg/CPM.cpp?revision=1.1.1.1&view=markup
> 
> We discovered that, on some Microsoft Softcard, disks, blocks 80-8f can be
> used to hold data.

Yup, the BIOS automagically wraps those around to tracks 0,1 and 2.  Microsoft 
refers to this as a "data only" diskette.  There are options to the system 
utilities for creating the format.

I don't remember all the details, but I think disks with system tracks create 
a dummy file to make those overflow sectors look like they're being used by a 
file (to prevent the OS from being scribbled over).

Hi All,

Today's (first) update... http://www.brutal-deluxe.fr/projects/appledisk525/index.html

Thank you,

Antoine Vignau
Brutal Deluxe Software

Toinet wrote:
> Hi All,
> 
> Today's (first) update... http://www.brutal-deluxe.fr/projects/appledisk525/index.html

Is there a way to download a binary or (better yet) source?

Way to go on the CP/M FST!!  If you can get it to recognize Z-System style 
datestamps, I will be forever in your debt.  If it is able to _write_ to CP/M 
diskettes, you are el-Supremo hacker!

Steve

Hi Toinet,

>Thank you All,
>
>The following address summarizes all the necessary information, I
>believe.

Not that important for your project but maybe nevertheless worth
mentioning is that it is the other way round possible to read/write
DOS 3.3 / ProDOS 8 / any 16 sector disk from Apple CP/M using these
BIOS calls:
http://www.seasip.demon.co.uk/Cpm/bios.html

I know because I created once a Turbo Pascal (thus running on CP/M)
program that read Wordstar files (on ordinary file level), which had a
proprietary extention to contain file names of graphic files. The
program would print the WordStar file and replace the embedded
filenames with the actual graphics. The graphics were loaded directly
from ProDOS 8 disks (actually only from the root directory) using BIOS
calls to access the ProDOS 8 disk on sector level.

This allowed me to combine the (from me perspective) best text editor
and best graphics editor to create documents. You just defined the
grachics area in the text as reactangular with '-'s and '!'s. This you
could have graphics and text side by side, small graphics for icons...

Sorry for wandering from the subject, Oliver

"Oliver Schmidt" <ol.sc@web.de> wrote in message 
news:gg8ih0$t1o$1@online.de...
>Not that important for your project but maybe nevertheless worth mentioning 
>is that it is the other way round possible to read/write DOS 3.3 / ProDOS 8 
>/ any 16 sector disk from Apple CP/M using these BIOS calls:

http://www.seasip.demon.co.uk/Cpm/bios.html

Thanks for this.

>The graphics were loaded directly from ProDOS 8 disks (actually only from 
>the root directory) using BIOS calls to access the ProDOS 8 disk on sector 
>level.

And also for this.

>You just defined the grachics area in the text as reactangular with '-'s 
>and '!'s. This you could have graphics and text side by side, small 
>graphics for icons...

So you could also have read Minipix from ProDOS and DOS 3.3 disks and used 
them in your documents like an early Wordstar Mail Merge or like Ventura 
Publisher 1 files used-to work in MS-DOS . That is very cool!

!---------------------!
!                     !
!                     !
!                     !
!---------------------!

Some file name in the middle I suppose. Your inspiration is appreciated. 
More graphics in ProDOS. Better paint programs. No need to convert disks.

>Sorry for wandering from the subject, Oliver

Not me. It's all interesting.

Bill

On Nov 14, 1:59=A0pm, Toinet <antoine.vig...@laposte.net> wrote:
> Dear All,
>
> I have just opened a new project on Brutal Deluxe's website. This
> project is dedicated to the AppleDisk5.25 GS/OS driver provided by
> Apple.
>
> I would like it to support new features so that other File System
> Translators could be used (there are two orphans close to me ;-)
>
> Please visithttp://www.brutal-deluxe.fr/projects/appledisk5.25/index.html
> or access to it via our home page located athttp://www.brutal-deluxe.fr/
>
> Your comments, emails and warnings are welcome,
>
> Antoine Vignau
> Brutal Deluxe Software


http://6502.org/homebuilt

http://www.z80.eu/dos65.html

Richard's DOS/65 - Richard Leary has written DOS/65, an interesting
operating system with file system compatibility to CP/M-80 (and other
similarities).

Latest update on the AppleDisk5.25 driver project:

http://www.brutal-deluxe.fr/projects/appledisk525/index.html

Our beloved GS/OS driver now handles 13 sectors disks: it can read,
write and format them. The associated DOS 3.2 FST is working well and
is under a heavy testing phase. I wonder whether I keep write/format
capabilities to it, I don't think so. Generating empty DOS 3.2 disks
is somewhat useless...

The driver reads 5.25 CP/M disks. The next step is to finalize the CP/
M FST which is buggy (oh! under development)

Antoine Vignau
Brutal Deluxe Software

Toinet wrote:
> Latest update on the AppleDisk5.25 driver project:
> 
> http://www.brutal-deluxe.fr/projects/appledisk525/index.html
> 
> Our beloved GS/OS driver now handles 13 sectors disks: it can read,
> write and format them. The associated DOS 3.2 FST is working well and
> is under a heavy testing phase. I wonder whether I keep write/format
> capabilities to it, I don't think so. Generating empty DOS 3.2 disks
> is somewhat useless...
> 
> The driver reads 5.25 CP/M disks. The next step is to finalize the CP/
> M FST which is buggy (oh! under development)

You the man!  Looking forward to this being completed and available.  What a 
great Christmas present that would be :-).

Steve

"Toinet" <antoine.vignau@laposte.net> wrote in message 
news:0fb89c7b-646e-4f2b-9711-9c1f10e561a0@s9g2000prg.googlegroups.com...
>Our beloved GS/OS driver now handles 13 sectors disks: it can read, write 
>and format them.

We are blessed!

>The associated DOS 3.2 FST is working well and is under a heavy testing 
>phase. I wonder whether I keep write/format capabilities to it, I don't 
>think so.

Tony,

I would be dissapointed if you removed write/format capabilities for 13 
sector disks.  If it is working then why not leave it in?

>Generating empty DOS 3.2 disks is somewhat useless...

Peut-�tre. Many of the things we do with old computers are of little use to 
others.

Creating DOS 3.2 data disks would be of use if one had a DOS 3.2 program 
that needed data. Then write/format would be useful.

>The driver reads 5.25 CP/M disks. The next step is to finalize the CP/M FST 
>which is buggy (oh! under development)

Bravo! Please put write/format capabilities into this too if you can.

Bill

PS - see message below earlier in this thread.

"Bill Buckels" <bbuckels@mts.net> wrote in message 
news:JSpTk.1555$ya5.494@newsfe19.iad...
>Mr. T.

>C'est si bon!

>I am inspired. Now I have another reason to aquire a GS. This simplifies 
>the 13 sector problem and I knew the experts would come forth... I was 
>wondering how I would get that 13 sector disk image back onto a disk.

On 17 d=E9c, 14:31, "Bill Buckels" <bbuck...@mts.net> wrote:
> "Toinet" <antoine.vig...@laposte.net> wrote in message
>
> news:0fb89c7b-646e-4f2b-9711-9c1f10e561a0@s9g2000prg.googlegroups.com...
>
> >Our beloved GS/OS driver now handles 13 sectors disks: it can read, writ=
e
> >and format them.
>
> We are blessed!
>
> >The associated DOS 3.2 FST is working well and is under a heavy testing
> >phase. I wonder whether I keep write/format capabilities to it, I don't
> >think so.
>
> Tony,
>
> I would be dissapointed if you removed write/format capabilities for 13
> sector disks. =A0If it is working then why not leave it in?
>

Adding write/format capabilities means three things:
- let disk image programs generate 13-sec disks, that's fine. But I
think none handle 13-sec .NIB or .DSK images
- add write capability to a FST. Pretty difficult.
- add format capability to a FST. Quite easy.

> >Generating empty DOS 3.2 disks is somewhat useless...
>
> Peut-=EAtre. Many of the things we do with old computers are of little us=
e to
> others.
>
> Creating DOS 3.2 data disks would be of use if one had a DOS 3.2 program
> that needed data. Then write/format would be useful.
>
> >The driver reads 5.25 CP/M disks. The next step is to finalize the CP/M =
FST
> >which is buggy (oh! under development)
>
> Bravo! Please put write/format capabilities into this too if you can.
>

write capability is already included. Format will be added to FST.

I will add format capabilities to the DOS 3.3 FST as well.

> Bill
>
> PS - see message below earlier in this thread.
>
> "Bill Buckels" <bbuck...@mts.net> wrote in message
>
> news:JSpTk.1555$ya5.494@newsfe19.iad...
>
> >Mr. T.
> >C'est si bon!
> >I am inspired. Now I have another reason to aquire a GS. This simplifies
> >the 13 sector problem and I knew the experts would come forth... I was
> >wondering how I would get that 13 sector disk image back onto a disk.

antoine

"Toinet" <antoine.vignau@laposte.net> wrote in message 
news:5e07dd06-5b96-4b46-9aa5-11c0ef2dedc2@40g2000prx.googlegroups.com...
> write capability is already included. Format will be added to FST.
>
> I will add format capabilities to the DOS 3.3 FST as well.

I think the important thing is that format capability allows full disk 
copying. At least you can make disk backups!
-- 
Peter Watson
-- Write to MS-DOS disks on the Apple IIgs?
-- Impossible!  ;-)

Happy New Year 2009,

There are been some interesting updates on the Brutal Deluxe
Software's website thanks to David Craig:

- The SOS 1.3 source code
- The ProDOS 1.7 source code
- The DOS 3.3 revision C source code
- Apple III documentation
- IWM documentation

And some minor updates to the GS/OS AppleDisk 5.25 driver:
- The DOS 3.3 FST now supports formatting
- The DOS 3.2 FST works well
- The driver has had some changes to support RDOS 3.2 disks
- The driver now has 13-sectors read/write/format routines
- The 13-sectors format routine can format the first track only, hum,
it is a bug, not a feature ;-)

Antoine

On Sun, 11 Jan 2009, Toinet wrote:

> Happy New Year 2009,
>
> There are been some interesting updates on the Brutal Deluxe
> Software's website thanks to David Craig:
>
> - The SOS 1.3 source code
> - The ProDOS 1.7 source code
> - The DOS 3.3 revision C source code

Hm.  I should try to port some of this stuff to CA65.

-uso.

On Jan 12, 6:21=A0am, Toinet <antoine.vig...@laposte.net> wrote:
> Happy New Year 2009,
>
> There are been some interesting updates on the Brutal Deluxe
> Software's website thanks to David Craig:
>
> - The SOS 1.3 source code
> - The ProDOS 1.7 source code
> - The DOS 3.3 revision C source code
> - Apple III documentation
> - IWM documentation
>
> And some minor updates to the GS/OS AppleDisk 5.25 driver:
> - The DOS 3.3 FST now supports formatting
> - The DOS 3.2 FST works well
> - The driver has had some changes to support RDOS 3.2 disks
> - The driver now has 13-sectors read/write/format routines
> - The 13-sectors format routine can format the first track only, hum,
> it is a bug, not a feature ;-)
>
> Antoine

The apple /// items, source code have been up at The Apple ///
Resource for over a year now.

http://apple3.applearchives.com

On Sun, 11 Jan 2009, bill.martens@gmail.com wrote:

> The apple /// items, source code have been up at The Apple ///
> Resource for over a year now.
>
> http://apple3.applearchives.com

The links on the source code page are circular.

-uso.

On Jan 12, 11:35=A0am, lyricalnanoha
<lyricalnan...@usotsuki.hoshinet.org> wrote:
> On Sun, 11 Jan 2009, bill.mart...@gmail.com wrote:
> > The apple /// items, source code have been up at The Apple ///
> > Resource for over a year now.
>
> >http://apple3.applearchives.com
>
> The links on the source code page are circular.
>
> -uso.

uso, they are fixed...thanks for the heads up there.  Looks like the
last time they got published, the files were moved before hand so they
didnt get re-published.  LOL.

On Jan 11, 10:23=A0pm, "bill.mart...@gmail.com" <bill.mart...@gmail.com>
wrote:
> On Jan 12, 11:35=A0am, lyricalnanoha
>
> <lyricalnan...@usotsuki.hoshinet.org> wrote:
> > On Sun, 11 Jan 2009, bill.mart...@gmail.com wrote:
> > > The apple /// items, source code have been up at The Apple ///
> > > Resource for over a year now.
>
> > >http://apple3.applearchives.com
>
> > The links on the source code page are circular.
>
> > -uso.
>
> uso, they are fixed...thanks for the heads up there. =A0Looks like the
> last time they got published, the files were moved before hand so they
> didnt get re-published. =A0LOL.
While you're in a fixin' mood... could you look into the software
links?  The disk images all seem to be circular as well.

On Jan 12, 3:01=A0pm, schmidtd <schmi...@my-deja.com> wrote:
> On Jan 11, 10:23=A0pm, "bill.mart...@gmail.com" <bill.mart...@gmail.com>
> wrote:
>
> > On Jan 12, 11:35=A0am, lyricalnanoha
>
> > <lyricalnan...@usotsuki.hoshinet.org> wrote:
> > > On Sun, 11 Jan 2009, bill.mart...@gmail.com wrote:
> > > > The apple /// items, source code have been up at The Apple ///
> > > > Resource for over a year now.
>
> > > >http://apple3.applearchives.com
>
> > > The links on the source code page are circular.
>
> > > -uso.
>
> > uso, they are fixed...thanks for the heads up there. =A0Looks like the
> > last time they got published, the files were moved before hand so they
> > didnt get re-published. =A0LOL.
>
> While you're in a fixin' mood... could you look into the software
> links? =A0The disk images all seem to be circular as well.

hmmm...maybe its the same issue? thanks David.

And now, for something almost identical to my previous post on the
subject: an update to the AppleDisk5.25 driver project on
http://www.brutal-deluxe.fr/

Regards,

antoine

Toinet wrote:
> And now, for something almost identical to my previous post on the
> subject: an update to the AppleDisk5.25 driver project on
> http://www.brutal-deluxe.fr/

Nothing like public embarrassment to get me moving :-).  I still owe you the 
800k CP/M image.  Just be aware that it will be specific to AE CP/AM and the 
Applicard.  There are at least two other CP/M implementations that use 3.5" 
diskettes (Cirtech and ALS) and I don't have any confidence that their disk 
layout is at all similar.

Will try to get to it later in the week or next weekend.  I'd do it sooner, 
but I discovered that the CardZ180 driver doesn't recognize my Apple Superdisk 
  controller :-(.  Have to pull the machine apart and put a standard Disk 3.5 
controller back in.

Steve

I have one new idea on an Apple 2 peripheral, but it
involves a lot more software than hardware, so I want
to hear from the driver experts.

A while ago I saw a very interesting project:
http://avr.15.forumer.com/a/fat-floppy-drive-interface-avr-asm_post1006.html

The original project page is not there any more, but I have a copy.
Almost no hardware - just an ATMEGA8 uC, like the one I used in PD8
and a few resistors. Everything else is the firmware inside the uC
and it reads and writes *high density* MFM floppies.
It should not be hard at all to add a bit of firmware to read/write
Apple compatible floppies, both 5.25" and 3.5" - it is very easy to
implement the Woz Machine on a 16 MHz AVR.

It is also a fact that 3.5" disk controllers are relatively rare and
expensive. So a very simple board from the hardware perspective can
be an interface to the "industry standard" 5.25" or 3.5" drives and
read/write both MFM and GRC. Given the right drivers that is. Even 
emulate the Disk ][ interface for 140K disks just like PD8.

Anybody interested so far?

-Alex.

On Feb 3, 9:29=A0am, Alex Freed <alex_n...@mirrow.com> wrote:
> Anybody interested so far?

Hmm, no replies yet from "driver experts" so one from me:

Are you talking about reading actual Apple II disks, a la FDI etc, or
just reading and writing to modern HD media via an emulation of 5.25 &
3.5 GCR formats?

Either way, very interested.

Cheers,
Nick.

sicklittlemonkey wrote:
> 
> Are you talking about reading actual Apple II disks, a la FDI etc, or
> just reading and writing to modern HD media via an emulation of 5.25 &
> 3.5 GCR formats?

After posting I remembered that the Apple 3.5" disks were "special".
AFAIK they use variable speed to using a PC drive to read/write Apple
3.5" disks is at least difficult.

My main idea is that if an old PC type 5.25" drive is used it would be
possible to:

1. read/write standard 140K disks. Not very useful as Apple Disk ][ 
drives are plentiful, at least in this part of the world.

2. read/write 1.2MB HD disks or connect a 3.5" drive for 1.44MB disks.
Convenient for data exchange with a PC.

3. read/write 800K ProDOS volumes on HD media. Not compatible with Apple 
3.5" media.

4. Read absolute pulse timing of a (protected) track like EDD board.

Not sure if this list is attractive enough.



-Alex.

On Feb 3, 1:44=A0pm, Alex Freed <alex_n...@mirrow.com> wrote:
> After posting I remembered that the Apple 3.5" disks were "special".
> AFAIK they use variable speed to using a PC drive to read/write Apple
> 3.5" disks is at least difficult.

Yes, of course. Well, let's not say impossible. ;-)

> 1. read/write standard 140K disks. Not very useful as Apple Disk ][
> drives are plentiful, at least in this part of the world.
>
> 2. read/write 1.2MB HD disks or connect a 3.5" drive for 1.44MB disks.
> Convenient for data exchange with a PC.
>
> 3. read/write 800K ProDOS volumes on HD media. Not compatible with Apple
> 3.5" media.
>
> 4. Read absolute pulse timing of a (protected) track like EDD board.

1 and 4 are enough for me to be interested.

That is, one card that can read and write 5.25 Apple disks and also
possibly capture to FDI or similar format. The other features are
welcome bonuses considering that outside the US old Apple drives and
media are not so common.

Cheers,
Nick.

Alex Freed wrote:
> sicklittlemonkey wrote:
>>
>> Are you talking about reading actual Apple II disks, a la FDI etc, or
>> just reading and writing to modern HD media via an emulation of 5.25 &
>> 3.5 GCR formats?
> 
> After posting I remembered that the Apple 3.5" disks were "special".
> AFAIK they use variable speed to using a PC drive to read/write Apple
> 3.5" disks is at least difficult.

Wouldn't it be possible to cleverly emulate the variable speed zones in 
software by playing with the data rate?  (For some value of cleverness at any 
rate).

Steve

"Steven Hirsch" <snhirsch@gmail.com> wrote in message 
news:YdKdnWEBU6Dx5RXUnZ2dnUVZ_h2WnZ2d@giganews.com...
> Alex Freed wrote:
>> sicklittlemonkey wrote:
>>>
>>> Are you talking about reading actual Apple II disks, a la FDI etc, or
>>> just reading and writing to modern HD media via an emulation of 5.25 &
>>> 3.5 GCR formats?
>>
>> After posting I remembered that the Apple 3.5" disks were "special".
>> AFAIK they use variable speed to using a PC drive to read/write Apple
>> 3.5" disks is at least difficult.
>
> Wouldn't it be possible to cleverly emulate the variable speed zones in 
> software by playing with the data rate?  (For some value of cleverness at 
> any rate).
>
> Steve

Yes, Disk2FDI manages to read Apple 3.5" disks in PC type (single speed) 
3.5" drives.

Charlie

On 3 f=E9v, 01:29, Alex Freed <alex_n...@mirrow.com> wrote:
>
> Anybody interested so far?
>
> -Alex.

Alex and al.,

The idea is interesting just like all other Apple II hardware
projects, mainly because I do not understand a bit of them.

From my user's point of view, I have to admit that I am not interested
in seeing another floppy controller, nor Z80 card nor any other cards
similar to the thousands of Apple II cards out there.

Nowadays, I believe people use and work with their Apple II through an
emulator and will continue unless a real Apple II facilitates
exchanges with todays' platforms (wifi, usb, bluetooth) or enhances
its current limitations (enhanced video board, enhanced sound boards).
That is why I believe the lattest useful Apple II cards are the
Ethernet ones.

But hardware is only one part of the subject and the most useful/
feature complete card in the universe offers limited interest if it
has no drivers nor developers supporting it: see the Second Sight
video board: it offered powerful features and great video enhancements
and no support... then it died.

Still, from my user's point of view, I would like the following:
- Apple II emulators remove their "standard" limitations by offering
enhancements (e.g. Apple IIgs emulators link other softswitches to get
enhanced video resolutions, or ease file exchanges between the host
computer and the emulated Apple II)
- Hardware gurus build Wifi, USB or Bluetooth boards. I would be
delighted to help for the driver's part (even though my knowledge on
the matter is "short")

I am an Apple IIgs developer (hum) and I would like to see IIgs
emulators evolve like AppleWin does. It offers emulation enhancements
by handling expansion cards, which is really convenient.

Last but not least, what I *really* would like is that Apple releases
the complete Apple II source code (especially the IIgs one ;-) in some
sort of GPL. That would ease a developer's access to our platform,
which is, according to me, the weakness of our platform, especially on
the IIgs.

I cannot count the number of hours for the disassembly of the IIgs
toolsets in ROM, understanding QuickDraw II's internals has been a
huge work, the work on the FSTs has been even heavier and some parts
still remain unclear. Having the official Apple source codes would be
useful to all of us.

I might be wrong, I enjoy doing my sort-of useless work, that changes
my mind from my interesting real job but if we keep on creating the
same hardware parts not bypassing our beloved platform's limits, then
we shall lose interest in the software part.

I will support HW creators by buying their cards, I will develop for
them if it expands our communicability with other platforms or offers
great enhancements compared to the original platform.

That is my 2 euros ;-)

Antoine

Toinet wrote:
> 
> From my user's point of view, I have to admit that I am not interested
> in seeing another floppy controller, nor Z80 card nor any other cards
> similar to the thousands of Apple II cards out there.

I guess there are different schools of though on this issue. Personally
I prefer making hardware to writing programs and I'm trying to make 
things that are useful (at least to me).
In my mind you don't need to use say wifi to make communications between
old and new computers easier if a wire works just fine. What I do see as 
a limitation is the 140K floppy. It's not big enough for comfort and the 
media is getting hard to find.
I do own a GS, but I bought it on e-bay a few years ago and didn't have 
one when they were new. That's why to me a ][+ or //e is a "real" Apple
and I'm trying to enhance those platforms.

> 
> Nowadays, I believe people use and work with their Apple II through an
> emulator and will continue unless a real Apple II facilitates
> exchanges with todays' platforms (wifi, usb, bluetooth) or enhances
> its current limitations (enhanced video board, enhanced sound boards).
> That is why I believe the lattest useful Apple II cards are the
> Ethernet ones.

Some people do like emulators and others do not. To me it has to be a 
dedicated box even if there is a single FPGA inside.

> 
> But hardware is only one part of the subject and the most useful/
> feature complete card in the universe offers limited interest if it
> has no drivers nor developers supporting it: see the Second Sight
> video board: it offered powerful features and great video enhancements
> and no support... then it died.

That's exactly why I want to hear from the potential software developers
before doing anything.

-Alex.

Steven Hirsch wrote:
>>
>> After posting I remembered that the Apple 3.5" disks were "special".
>> AFAIK they use variable speed to using a PC drive to read/write Apple
>> 3.5" disks is at least difficult.
> 
> Wouldn't it be possible to cleverly emulate the variable speed zones in 
> software by playing with the data rate?  

I thought about it - that's why I said "at least difficult" rather than
impossible. In fact reading may not be too hard, but writing is a 
different story.
Since the device requires almost no hardware and all the programming is 
done on the AVR side, it is easy to experiment. I mean the prototype 
doesn't even need to be connected to an Apple - just a serial channel to 
a PC or a Linux box.

-Alex.

Toinet wrote:
> On 3 f�v, 01:29, Alex Freed <alex_n...@mirrow.com> wrote:
>> Anybody interested so far?
>>
>> -Alex.
> 
> Alex and al.,
> 
> The idea is interesting just like all other Apple II hardware
> projects, mainly because I do not understand a bit of them.
> 
> From my user's point of view, I have to admit that I am not interested
> in seeing another floppy controller, nor Z80 card nor any other cards
> similar to the thousands of Apple II cards out there.

Of course, what Alex has proposed would be an "ultra" floppy
controller, capable of handling GCR and MFM on modern drives
of any size.

Considering that the AppleDisk 3.5 Controller (Superdisk Controller)
is so hard to come by, this would be a real benefit to many.

> Nowadays, I believe people use and work with their Apple II through an
> emulator and will continue unless a real Apple II facilitates
> exchanges with todays' platforms (wifi, usb, bluetooth) or enhances
> its current limitations (enhanced video board, enhanced sound boards).
> That is why I believe the lattest useful Apple II cards are the
> Ethernet ones.

I guess I don't see the value in "facilitating exchanges" when it is
already so easy with 1) a 115kbps serial link, 2) Ethernet, 3) CFFA +
CiderPress, and 4) Superdisk and sneakernet.

Since I can walk 128MB (a CF card) between machines in less than a
minute, that's about 2MB/second effective transfer rate!

The real interoperability issue isn't data transfer, but data
*exchange*, meaning that formats, headers, coding, etc., is handled
to make the data transfer useful.  In the PC world, CiderPress does
a virtuoso job of that--good enough that I never feel any inconvenience
in moving code, data, images, etc., between the Apple world and the
modern world.  (And as I've mentioned before, I have no desire to
hamper my access to the modern world by doing it *through* an Apple II.)

> But hardware is only one part of the subject and the most useful/
> feature complete card in the universe offers limited interest if it
> has no drivers nor developers supporting it: see the Second Sight
> video board: it offered powerful features and great video enhancements
> and no support... then it died.

You are absolutely right--hardware is useless without software, and
it is the lack of a compelling software story that discourages most
hardware extensions (many of them quite appropriately ;-).

> Still, from my user's point of view, I would like the following:
> - Apple II emulators remove their "standard" limitations by offering
> enhancements (e.g. Apple IIgs emulators link other softswitches to get
> enhanced video resolutions, or ease file exchanges between the host
> computer and the emulated Apple II)

There you lose me.  Adding architectural extensions to an emulator is
equivalent to adding architectural extensions to the hardware.  Unless
there is robust development to support it, the value goes unused.

This is quite different from building extensions to map existing,
well-supported features to modern hardware--like allowing ProDOS to
use a CF card as a multi-volume hard disk, or allowing hi-res graphics
to be faithfully displayed on a modern VGA display.

This latter type of extension is instantly usable by the entire
community with the panoply of Apple II software, while the former
type is usable only by a few to run only a few special apps.

> - Hardware gurus build Wifi, USB or Bluetooth boards. I would be
> delighted to help for the driver's part (even though my knowledge on
> the matter is "short")
> 
> I am an Apple IIgs developer (hum) and I would like to see IIgs
> emulators evolve like AppleWin does. It offers emulation enhancements
> by handling expansion cards, which is really convenient.
>
> Last but not least, what I *really* would like is that Apple releases
> the complete Apple II source code (especially the IIgs one ;-) in some
> sort of GPL. That would ease a developer's access to our platform,
> which is, according to me, the weakness of our platform, especially on
> the IIgs.

I don't expect this to happen--ever.

> I cannot count the number of hours for the disassembly of the IIgs
> toolsets in ROM, understanding QuickDraw II's internals has been a
> huge work, the work on the FSTs has been even heavier and some parts
> still remain unclear. Having the official Apple source codes would be
> useful to all of us.

I certainly would, but I expect any better understanding of this code
to continue to be the result of valiant efforts like your own.

> I might be wrong, I enjoy doing my sort-of useless work, that changes
> my mind from my interesting real job but if we keep on creating the
> same hardware parts not bypassing our beloved platform's limits, then
> we shall lose interest in the software part.

I disagree.  It is precisely the static architecture of the platform
that makes it interesting to provide new capabilities through software!

If I have a great idea for the Apple II that only requires a 240MHz
processor, a 64K-color megapixel display, and 32MB of RAM, I suggest
that it's not actually an idea for an Apple II.  ;-)

Maybe this is a difference between IIgs users and //e (and earlier)
users--more IIgs users want to be riding the Moore's "Law" wave, and
more //e users are content to program the machine that Woz designed.

If so, then perhaps it is at least partially due to the IIgs GUI, and
all the MacWindows associations it implies.

Just as you find it appealing to relax using a IIgs after a day's work,
I find it relaxing to use the command line text interface of the //e
after a lot of GUI-based computing.  ;-)

-michael

******** Note new website URL ********

NadaNet and AppleCrate II for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Charlie wrote:
> "Steven Hirsch" <snhirsch@gmail.com> wrote in message 
> news:YdKdnWEBU6Dx5RXUnZ2dnUVZ_h2WnZ2d@giganews.com...
>> Alex Freed wrote:
>>> sicklittlemonkey wrote:
>>>> Are you talking about reading actual Apple II disks, a la FDI etc, or
>>>> just reading and writing to modern HD media via an emulation of 5.25 &
>>>> 3.5 GCR formats?
>>> After posting I remembered that the Apple 3.5" disks were "special".
>>> AFAIK they use variable speed to using a PC drive to read/write Apple
>>> 3.5" disks is at least difficult.
>> Wouldn't it be possible to cleverly emulate the variable speed zones in 
>> software by playing with the data rate?  (For some value of cleverness at 
>> any rate).
>>
>> Steve
> 
> Yes, Disk2FDI manages to read Apple 3.5" disks in PC type (single speed) 
> 3.5" drives.

I didn't realize that disk2fdi worked with 3.5" drives!  Another example is 
the Copy II Plus option board.  Unless I'm confusing it with something else, 
it was able to read and duplicate 800K Mac diskettes (same low-level format, I 
think).

"Steven Hirsch" <snhirsch@gmail.com> wrote in message 
news:1p6dnXqfLPZZdhXUnZ2dnUVZ_jOdnZ2d@giganews.com...
> Charlie wrote:
>> "Steven Hirsch" <snhirsch@gmail.com> wrote in message 
>> news:YdKdnWEBU6Dx5RXUnZ2dnUVZ_h2WnZ2d@giganews.com...
>>> Alex Freed wrote:
>>>> sicklittlemonkey wrote:
>>>>> Are you talking about reading actual Apple II disks, a la FDI etc, or
>>>>> just reading and writing to modern HD media via an emulation of 5.25 &
>>>>> 3.5 GCR formats?
>>>> After posting I remembered that the Apple 3.5" disks were "special".
>>>> AFAIK they use variable speed to using a PC drive to read/write Apple
>>>> 3.5" disks is at least difficult.
>>> Wouldn't it be possible to cleverly emulate the variable speed zones in 
>>> software by playing with the data rate?  (For some value of cleverness 
>>> at any rate).
>>>
>>> Steve
>>
>> Yes, Disk2FDI manages to read Apple 3.5" disks in PC type (single speed) 
>> 3.5" drives.
>
> I didn't realize that disk2fdi worked with 3.5" drives!

It also supports 3" drives (whatever they are) and 8" drives.  I've found 
when reading 3.5" Apple II disks there is an occasional disk that won't read 
in either the upper tracks or the lower tracks.  Using a different 3.5" PC 
drive usually cures the problem.

> Another example is the Copy II Plus option board.  Unless I'm confusing it 
> with something else, it was able to read and duplicate 800K Mac diskettes 
> (same low-level format, I think).

I'm not familiar with the Copy II Plus board but another interesting card is 
the PC Transporter.  It can read/write an Apple II 3.5" drive in either GCR 
with the variable speed (800K) or PC MFM with single speed (720K).  In this 
case though, I don't believe the speed is done in software.  If I remember 
correctly the PC Transporter somehow keeps the speed from varying in the 
drive.

Charlie

 

Charlie wrote:
> "Steven Hirsch" <snhirsch@gmail.com> wrote in message 
> news:1p6dnXqfLPZZdhXUnZ2dnUVZ_jOdnZ2d@giganews.com...
>> Charlie wrote:
>>> "Steven Hirsch" <snhirsch@gmail.com> wrote in message 
>>> news:YdKdnWEBU6Dx5RXUnZ2dnUVZ_h2WnZ2d@giganews.com...
>>>> Alex Freed wrote:
>>>>> sicklittlemonkey wrote:
>>>>>> Are you talking about reading actual Apple II disks, a la FDI etc, or
>>>>>> just reading and writing to modern HD media via an emulation of 5.25 &
>>>>>> 3.5 GCR formats?
>>>>> After posting I remembered that the Apple 3.5" disks were "special".
>>>>> AFAIK they use variable speed to using a PC drive to read/write Apple
>>>>> 3.5" disks is at least difficult.
>>>> Wouldn't it be possible to cleverly emulate the variable speed zones in 
>>>> software by playing with the data rate?  (For some value of cleverness 
>>>> at any rate).
>>>>
>>>> Steve
>>> Yes, Disk2FDI manages to read Apple 3.5" disks in PC type (single speed) 
>>> 3.5" drives.
>> I didn't realize that disk2fdi worked with 3.5" drives!
> 
> It also supports 3" drives (whatever they are) and 8" drives.  I've found 
> when reading 3.5" Apple II disks there is an occasional disk that won't read 
> in either the upper tracks or the lower tracks.  Using a different 3.5" PC 
> drive usually cures the problem.
> 
>> Another example is the Copy II Plus option board.  Unless I'm confusing it 
>> with something else, it was able to read and duplicate 800K Mac diskettes 
>> (same low-level format, I think).
> 
> I'm not familiar with the Copy II Plus board but another interesting card is 
> the PC Transporter.  It can read/write an Apple II 3.5" drive in either GCR 
> with the variable speed (800K) or PC MFM with single speed (720K).  In this 
> case though, I don't believe the speed is done in software.  If I remember 
> correctly the PC Transporter somehow keeps the speed from varying in the 
> drive.

PC drives are not even capable of the "zone" speed changes that Apple
3.5" drives do.  To read or write an Apple GCR 3.5" disk with a PC drive
requires changing the bit clock rate.

-michael

******** Note new website URL ********

NadaNet and AppleCrate II for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Charlie wrote:

> I'm not familiar with the Copy II Plus board but another interesting card is 
> the PC Transporter.  It can read/write an Apple II 3.5" drive in either GCR 
> with the variable speed (800K) or PC MFM with single speed (720K).  In this 
> case though, I don't believe the speed is done in software.  If I remember 
> correctly the PC Transporter somehow keeps the speed from varying in the 
> drive.


The PCT uses a real Apple drive to do 800K 3.5" diskettes AFAIK.  Haven't had 
mine setup for years, so I may be in error here.

"Michael J. Mahon" <mjmahon@aol.com> wrote in message 
news:DsmdnTGdt9BUfxTUnZ2dnUVZ_qninZ2d@giganews.com...
> Charlie wrote:
>> "Steven Hirsch" <snhirsch@gmail.com> wrote in message 
>> news:1p6dnXqfLPZZdhXUnZ2dnUVZ_jOdnZ2d@giganews.com...
>>> Charlie wrote:
>>>> "Steven Hirsch" <snhirsch@gmail.com> wrote in message 
>>>> news:YdKdnWEBU6Dx5RXUnZ2dnUVZ_h2WnZ2d@giganews.com...
>>>>> Alex Freed wrote:
>>>>>> sicklittlemonkey wrote:
>>>>>>> Are you talking about reading actual Apple II disks, a la FDI etc, 
>>>>>>> or
>>>>>>> just reading and writing to modern HD media via an emulation of 5.25 
>>>>>>> &
>>>>>>> 3.5 GCR formats?
>>>>>> After posting I remembered that the Apple 3.5" disks were "special".
>>>>>> AFAIK they use variable speed to using a PC drive to read/write Apple
>>>>>> 3.5" disks is at least difficult.
>>>>> Wouldn't it be possible to cleverly emulate the variable speed zones 
>>>>> in software by playing with the data rate?  (For some value of 
>>>>> cleverness at any rate).
>>>>>
>>>>> Steve
>>>> Yes, Disk2FDI manages to read Apple 3.5" disks in PC type (single 
>>>> speed) 3.5" drives.
>>> I didn't realize that disk2fdi worked with 3.5" drives!
>>
>> It also supports 3" drives (whatever they are) and 8" drives.  I've found 
>> when reading 3.5" Apple II disks there is an occasional disk that won't 
>> read in either the upper tracks or the lower tracks.  Using a different 
>> 3.5" PC drive usually cures the problem.
>>
>>> Another example is the Copy II Plus option board.  Unless I'm confusing 
>>> it with something else, it was able to read and duplicate 800K Mac 
>>> diskettes (same low-level format, I think).
>>
>> I'm not familiar with the Copy II Plus board but another interesting card 
>> is the PC Transporter.  It can read/write an Apple II 3.5" drive in 
>> either GCR with the variable speed (800K) or PC MFM with single speed 
>> (720K).  In this case though, I don't believe the speed is done in 
>> software.  If I remember correctly the PC Transporter somehow keeps the 
>> speed from varying in the drive.
>
> PC drives are not even capable of the "zone" speed changes that Apple
> 3.5" drives do.  To read or write an Apple GCR 3.5" disk with a PC drive
> requires changing the bit clock rate.

Yes, I understand that Disk2FDI does this (for reading anyway).

What I was trying to say was that the PC Transporter does the reverse.  It 
reads and writes to 800K 3.5" Apple drives using a single speed when doing 
MFM 720K so that the disks can be used in a PC.  I've never seen any 
documentation on how that is done.  I originally assumed (before owning a 
PCT) that an Apple drive automatically adjusted its rotational speed when 
the head moved to different track zones, but I'm pretty sure that when I 
formatted a MS-DOS disk I couldn't hear the speed changing (I don't have my 
PC Transporter set up in my Apple II any more so I can't double check 
myself).

So:

PC drive = single speed for all tracks.
Apple 3.5" drive = multiple speeds in zones *or* single speed for all 
tracks.

I probably shouldn't have brought up the PC Transporter in this thread 
because it confuses the issue.  Its just that nothing I've ever read from 
Apple gives any indication that the rotational speed of the drive can be 
controlled from outside the drive.

Charlie

"Steven Hirsch" <snhirsch@gmail.com> wrote in message 
news:fu2dnU05iqHEthfUnZ2dnUVZ_vSdnZ2d@giganews.com...
> Charlie wrote:
>
>> I'm not familiar with the Copy II Plus board but another interesting card 
>> is the PC Transporter.  It can read/write an Apple II 3.5" drive in 
>> either GCR with the variable speed (800K) or PC MFM with single speed 
>> (720K).  In this case though, I don't believe the speed is done in 
>> software.  If I remember correctly the PC Transporter somehow keeps the 
>> speed from varying in the drive.
>
>
> The PCT uses a real Apple drive to do 800K 3.5" diskettes AFAIK.

Yes, you are correct.  I shouldn't have brought up the PC Transporter.  I 
was just referring to it as a curiosity because I believe it manages to do 
multi-speed and single speed (hardware rotational speed not software 
read/write speed) on an Apple drive.

Sorry for the confusion,

Charlie

Charlie wrote:
> "Steven Hirsch" <snhirsch@gmail.com> wrote in message 
> news:fu2dnU05iqHEthfUnZ2dnUVZ_vSdnZ2d@giganews.com...
>> Charlie wrote:
>>
>>> I'm not familiar with the Copy II Plus board but another interesting card 
>>> is the PC Transporter.  It can read/write an Apple II 3.5" drive in 
>>> either GCR with the variable speed (800K) or PC MFM with single speed 
>>> (720K).  In this case though, I don't believe the speed is done in 
>>> software.  If I remember correctly the PC Transporter somehow keeps the 
>>> speed from varying in the drive.
>>
>> The PCT uses a real Apple drive to do 800K 3.5" diskettes AFAIK.
> 
> Yes, you are correct.  I shouldn't have brought up the PC Transporter.  I 
> was just referring to it as a curiosity because I believe it manages to do 
> multi-speed and single speed (hardware rotational speed not software 
> read/write speed) on an Apple drive.

I'm sceptical that the PCT is doing anything special at all.  I'm of the 
impression that the variable speed magic is simply built into the drive itself 
Unless I'm confusing this with the Unidisk 3.5 (original) the drive presents 
itself as a sequence of blocks and completely hides the fact that tracks and 
sectors are involved.

On Feb 5, 11:56=A0am, "Charlie" <charlieD...@verEYEzon.net> wrote:
>=A0Its just that nothing I've ever read from
> Apple gives any indication that the rotational speed of the drive can be
> controlled from outside the drive.

The original 400KB Mac 3.5" drives had their speed controlled by the
Macintosh. AFAIK, the 800KB drives ignore the speed signal on pin 10
of the 19 pin connector. On the Apple IIc and IIgs this pin is used as
the Write Protect signal.

See http://support.apple.com/kb/TA48050?viewlocale=3Den_US for pinout
and signal descriptions.

"David Wilson" <mcs6502@gmail.com> wrote in message 
news:78e4f06d-aae1-46d7-a777-08e542bc16b5@v18g2000pro.googlegroups.com...
On Feb 5, 11:56 am, "Charlie" <charlieD...@verEYEzon.net> wrote:
> Its just that nothing I've ever read from
> Apple gives any indication that the rotational speed of the drive can be
> controlled from outside the drive.

>------------------------------------------
The original 400KB Mac 3.5" drives had their speed controlled by the
Macintosh. AFAIK, the 800KB drives ignore the speed signal on pin 10
of the 19 pin connector. On the Apple IIc and IIgs this pin is used as
the Write Protect signal.

See http://support.apple.com/kb/TA48050?viewlocale=en_US for pinout
and signal descriptions.
>------------------------------------------

That's interesting.  I never thought to check Mac info.  It's also a little 
confusing (at least to me :-)  How can the same pin be used for two 
different functions depending on which computer is used?  Can't the Mac 
detect a write protected disk?

Charlie

 

"Steven Hirsch" <snhirsch@gmail.com> wrote in message 
news:2OadnZ7TefVfQxfUnZ2dnUVZ_s7inZ2d@giganews.com...
> Charlie wrote:
>> "Steven Hirsch" <snhirsch@gmail.com> wrote in message 
>> news:fu2dnU05iqHEthfUnZ2dnUVZ_vSdnZ2d@giganews.com...
>>> Charlie wrote:
>>>
>>>> I'm not familiar with the Copy II Plus board but another interesting 
>>>> card is the PC Transporter.  It can read/write an Apple II 3.5" drive 
>>>> in either GCR with the variable speed (800K) or PC MFM with single 
>>>> speed (720K).  In this case though, I don't believe the speed is done 
>>>> in software.  If I remember correctly the PC Transporter somehow keeps 
>>>> the speed from varying in the drive.
>>>
>>> The PCT uses a real Apple drive to do 800K 3.5" diskettes AFAIK.
>>
>> Yes, you are correct.  I shouldn't have brought up the PC Transporter.  I 
>> was just referring to it as a curiosity because I believe it manages to 
>> do multi-speed and single speed (hardware rotational speed not software 
>> read/write speed) on an Apple drive.
>
> I'm sceptical that the PCT is doing anything special at all.  I'm of the 
> impression that the variable speed magic is simply built into the drive 
> itself

Well I won't argue the point since I don't have the PCT running at the 
moment.  Maybe someone else with a PCT can confirm/shoot me down.

> Unless I'm confusing this with the Unidisk 3.5 (original) the drive 
> presents itself as a sequence of blocks and completely hides the fact that 
> tracks and sectors are involved.

I believe you are referring to the Unidisk 3.5 drive which has it's own 
processor built in (a so-called smart drive).  An Apple 3.5" drive has none 
of that fancy stuff.

Charlie

David Wilson wrote:
> On Feb 5, 11:56 am, "Charlie" <charlieD...@verEYEzon.net> wrote:
>>  Its just that nothing I've ever read from
>> Apple gives any indication that the rotational speed of the drive can be
>> controlled from outside the drive.
> 
> The original 400KB Mac 3.5" drives had their speed controlled by the
> Macintosh. AFAIK, the 800KB drives ignore the speed signal on pin 10
> of the 19 pin connector. On the Apple IIc and IIgs this pin is used as
> the Write Protect signal.
> 
> See http://support.apple.com/kb/TA48050?viewlocale=en_US for pinout
> and signal descriptions.

So only a special AE 800KB floppy could have its zone speed changes
overridden by software or the disk controller...

-michael

******** Note new website URL ********

NadaNet and AppleCrate II for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

On Feb 2, 4:29=A0pm, Alex Freed <alex_n...@mirrow.com> wrote:
> I have one new idea on an Apple 2 peripheral, but it
> involves a lot more software than hardware, so I want
> to hear from the driver experts.
>
> A while ago I saw a very interesting project:http://avr.15.forumer.com/a/=
fat-floppy-drive-interface-avr-asm_post10...
>
> The original project page is not there any more, but I have a copy.
> Almost no hardware - just an ATMEGA8 uC, like the one I used in PD8
> and a few resistors. Everything else is the firmware inside the uC
> and it reads and writes *high density* MFM floppies.
> It should not be hard at all to add a bit of firmware to read/write
> Apple compatible floppies, both 5.25" and 3.5" - it is very easy to
> implement the Woz Machine on a 16 MHz AVR.
>
> It is also a fact that 3.5" disk controllers are relatively rare and
> expensive. So a very simple board from the hardware perspective

an AVR seems to be much simpler than:

http://ultimateapple2.com/images/A2DiskController.jpg

aiiadict@gmail.com wrote:
>>
>> A while ago I saw a very interesting project:http://avr.15.forumer.com/a/fat-floppy-drive-interface-avr-asm_post10...
> 
> an AVR seems to be much simpler than:
> 
> http://ultimateapple2.com/images/A2DiskController.jpg

See the thread I started on Poor-man's catweasel for another approach.