[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The Best IIgs HD Solution?
Hi,
> I am still gathering things for my IIgs on a limited budget...
> I was wondering, what is the most economical solution to add a hard
> drive to my ROM 3 gs? I already have IDE and SCSI drives around, just no
> IIgs interface or controller. I guess that is all I am really looking
> for unless an integrated card/HD would be less expensive. PLease help
> this enthusiastic, poor computer guy. BTW, I have moderately good
> soldering skills, so I may can build something from cheap parts. Any
> suggestion is welcome (dont make fun of me ;) ).
> -MrCarp
I certainly won't make fun of you !
If you want to go the DYI way, then point at http://s.guillard.free.fr,
where you will find a freeware IDE controller project I designed in the
beginning of this year, which should cost you no more than $10.
It runs everyday in my Apple IIe and IIgs.
Concerning the software, things are almost done and getting up pretty fast
(since I work on it almost every night). At the moment, I'm still at
prototype stage, but things working include :
- master / slave support
- low level routines : sector read / write
- device identification and initialization (only HDD is supported now, but
provision for CD, which is identified properly, is also in there)
- support for PC-structured hard disks, this is to say :
o PC partition structure (my software reads the PC's fdisk-made Master
boot record, and mounts the 1st partition if it is FAT16)
o FAT16 structure support (Boot Parameter Block, directory tree
navigation, cluster alchemy and mode)
o a set of directory tree functions
- full POSIX API on top of FAT16 : creat(), open(), read(), write(),
close(), fseek() etc.
You can have a 2 week old snapshot of both sources and test binary in
http://s.guillard.free.fr/csrc (the current status is more advanced and will
be made online this week).
This is structured in a multi layer operating environment (OSS) for the HDD
:
1st layer : low level routines - init device, read / write sectors
2nd layer : disk structure analysis - master boot record -> find the
partition table, boot parameter block -> find the FAT16 FS and its main
structures
3rd layer : FAT16 structure navigation - File Allocation Table itself,
cluster chain alloc / free, directories, etc.
4th layer : small and efficient user services - save / load / execute,
navigate in directory tree
5th layer : POSIX API (in a separate library) - standard unix like calls
(creat(), open(), read(), write(), lseek() etc.)
6th layer : standard unix like utilities (rm, mv, cat, cp, mkdir etc.)
Each layer runs on top of the previous, except 5th runs directly on top of
3rd.
The idea is to distribute the OSS code as :
a resident, ROMed module including 1st to 4th layers,
a developer library including 5th layer,
a set of executables including 6th layer
a patch for DOS3.3 and ProDOS to redirect their most used commands to the
HDD OS
Experiencing assembly coding with the prototype software has proved to be
very inefficient (even if it is the best path to small and fast code), so in
order to develop all this quickly, I decided to code all in C, then when
everything is running, convert at least layers 1 to 4 back to assembly.
But when all is validated (and I would appreciate user feedback and ideas),
I will remake things in assembly (easy, since the C compiler I use, CC65,
produces assembly files), hand optimize all and lower the RAM footprint as
possible.
Regards,
--
St�phane Guillard - stephane.guillard@steria.com