Re: Hardware musings

["Justin England" <justin@rapidcity.net>]

"mdj" <mdj.mdj@gmail.com> wrote in message 
1160964413.018840.34150@f16g2000cwb.googlegroups.com">news:1160964413.018840.34150@f16g2000cwb.googlegroups.com...
>
> Mark McDougall wrote:
>
>> Having said that, I don't believe in this case that it is a fault with 
>> USB
>> itself. My guess is either crappy windows scheduling, or crappy windows
>> programming of the USB host controller.
>
> Yeah - this is a big part of the problem. Most OS's don't have
> sufficient RTOS-like capabilities to guarantee that kind of precision.
> It'd be madness to design something which uses the now Universal Serial
> Bus, and have highly specific OS requirements.

My idea would be that the USB connection would only be used for data 
transfer.  The PIC would be programmed to handle all of the disk control.

Disk image created from PC (CiderPress?) - sent down the USB port with a 
command to tell the PIC to write the image - PIC receives image and stores 
in a RAM buffer of sorts - checksum the image - write to disk.

I had never really though about using it to read disk to create images since 
my A2 can do that just fine, and since my //gs is networked, it is easy to 
store in a network location that my PC can then read.

>
>> Someone mentioned that the 'magic box' that was required would actually 
>> *be*
>> an Apple II - and for protected disks this may well be the case. But it's
>> not actually a bad idea! It's fast getting to the stage where a 6502 can 
>> be
>> implemented in a CPLD (probably can now?) and without the graphics and 
>> I/O
>> there's not much more to an Apple than a CPU and some ROM & RAM. I'm yet 
>> to
>> think this thru myself but I'm wondering if that really could be the way 
>> to
>> go here? Interesting....
>
> The big question is, are there CPLD's out there with sufficient
> capacity, yet still in a form factor that's compatible with hobbyist
> level electronics work?
>
> The nice thing about those PICs is they ship in a 28pin DIP that's easy
> to breadboard with, and operating at 48Mhz gives sufficient grunt to
> simulate a lot of simple hardware.
>

I haven't looked in some time, but I would have to imagine that one could 
find a PIC with sufficient ROM (for the code), RAM (buffer for images) and 
speed to have timing resolution down to what is needed to control the 
Disk ][ drive.

I wouldn't even think about trying to control the Disk ][ from a windows 
app... to many software layers that you would need to go through in order to 
directly talk to a USB device to get the required timing need to read/write 
to a disk ][.  Again, this is what led me to think about using a PIC to do 
the actual drive control.

As for using a CPLD or FPGA, I am a programmer, therefore I would consider 
using something like a PIC.  Although, any programmable microcontroller with 
sufficient speed would do the job.  All of the control of the drive would 
then be programmed, and therefore would be easier for me to do.  Others may 
be more familiar with using CPLDs and would be easier for them to control 
the drive using "logic".

Justin