Re: Hardware musings

["Greg Andrzejewski" <pressyourluck85@yahoo.com>]

"Justin England" <justin@rapidcity.net> wrote in message 
LsSdnSjPt8iedbLYnZ2dnUVZ_smdnZ2d@rapidnet.com">news:LsSdnSjPt8iedbLYnZ2dnUVZ_smdnZ2d@rapidnet.com...
> Hello all...  I have been an off and on reader of this newsgroup and the 
> A2 "hobby" in general for the last 10 years or so.  I moved several years 
> back and haven't yet got around to setting up my A2 collection, but that 
> will change soon.  Mind you, my first Apple was a //c that I purchased 
> sometime in the late 80's while in high school, but used apples for 
> several years in school before buying one.
>
> After spending some time over the last few weeks scanning / reading the 
> posts from the last few years, it seems that there are several topics that 
> keep coming up that are of interest to me.
>
> First topic, //c storage.  I would love to have the ability to attach a 
> mass storage device to my //c in order to have access to my large 
> collection of files / programs that I had collected during my //c days. 
> BUT, what I would prefer to have is access to an AppleTalk server.  Before 
> anybody goes off and says that AppleTalk was never fully implemented on 
> the //c, I am aware of that.
>
> Some background, my current (still unpacked) set up includes a //e with a 
> workstation card, a ROM 3 //gs with a HS SCSI card (amongst other 
> goodies), my original //c, and various other //[c,c+,e,gs]'s.  When I had 
> my systems last set up, the capable //'s were networked via AppleTalk 
> using netatalk on my FreeBSD sever (with a Mac to do the localtalk - 
> ethernet bridge.)  I started a project of copying all of my A2 files / 
> progs to the BSD server so both my //e and //gs could access them without 
> having to use a sneaker net (and for backup purposes.)  Therefore, that is 
> why I would prefer to have AppleTalk in my //c so that I could have access 
> to my network "share" on my BSD server.
>
> A light technical overview of the project:  I did a quick scan in the last 
> couple of days of the AppleTalk ROM listings in my //c Tech Ref book.  It 
> appears at first glance that Apple set up the AT code in the //c to simply 
> look like a smart port device.  Therefore, I would have to assume that 
> ProDOS would have seen it as nothing more than another smartport.  Since 
> the //c already has a smartport, why couldn't a device be built that 
> connected to the smartport and talk to an AppleTalk network (via localtalk 
> or even ethernet.)  My idea would be (mind you, I have forgotten most of 
> what I ever knew about A2 hardware) to have something like a PIC that 
> would receive the signals / commands from the smart port, and translate 
> them to AT and send them down the localtalk wire.  There would also have 
> to be some form of a CHOOSER that could talk to the PIC and could even 
> store usernames, passwords and "shares" in NVRAM. A simple ATINIT could be 
> written to map the "shares" to ProDOS volumes.
>

Appletalk on a IIc would be cool, but I don't think it would be worth the 
time. Putting all that work into implementing a dead protocol doesn't make 
sense to me. Especially since, if you have the expertise/ability to pull 
such a project off, there are probably more worthwhile projects for you to 
work on (IIc ethernet maybe?)

> Second topic, disk transfer from a Windoze PC to A2 disks.  Since there is 
> no way to directly connect a disk ][ drive to a PC (unlike other 8 bit 
> computer's disk drives), why couldn't a "magic" box be built that would 
> connect a disk ][ to a USB port.  It should be fairly easy to find a USB 
> to TTL device that could talk to a PIC, and the PIC could directly manage 
> the drive.  On the PC side, it shouldn't need to look like nothing more 
> than a USB to serial device, therefore a simple protocol could be 
> developed that the PIC code could interpret and perform the necessary 
> functions. Considering the amazing CiderPress program, it should be easy 
> for Andy to implement a way of sending data down the USB port that 
> includes the protocol handshake and a raw disk image (in a predefined 
> format.)  Again, I have forgotten most of what I knew about A2 hardware, 
> but I can't imagine it being horribly difficult to "emulate" a disk ][ 
> controller with a PIC considering it should have to ability to do the 
> timing critical functions.
>

This idea has been kicking around in my head for a little while, too. I 
suggest you download a copy of "Understanding the Apple II" (search the 
group for links) as there is a chapter that describes the disk ][ operation 
in detail. I know this topic has come up before, so you may want to dig 
around the archives for old threads. IIRC, even though the disk ][ card is 
just a state machine, Apple II disk access is so timing dependent that for 
the amount of logic it would take to duplicate it on a PIC or FPGA you might 
as well put the whole computer on it.

Smartport devices might be easier, but I don't believe there is a whole lot 
of documentation on the protocol.

-Greg

> The ideas behind this are that it would make "boot strapping" a //[c,e,gs] 
> much easier if you have no boot disks, and, more importantly,  it would be 
> much easier / faster / convenient to use CiderPress on my PC to create 
> real disks from the images d/l'ed from the internet (as opposed to using 
> A2 utilities.)
>
> Any thoughts on if these projects are feasible or an I missing some key 
> elements of A2 hardware that would make them too difficult to build.  Now 
> I am mainly a programmer, and only have limited experience doing hardware 
> design.  Granted, I recently returned to school (part-time) after a 15 
> year hiatus, and instead of going for a Comp Sci degree, I decided upon a 
> Comp Engineering degree.  So maybe I could consider one of these ideas as 
> a school project.
>
> Just my hardware musings from the last few weeks,
>
> Justin
>
>
>
>
>