Having many a time pondered the same issues and having seen the wonderful work that's been done on the emulator seen, I came to the following conclusions: 1) emulation of the 1541 and other CBM peripherals in software is quite possible 2) the X1541 link is by far the most popular, easiest, holds the highest probability for implementation without people "frying" their existing hardware 3) the hardware, electronics, or PC platform needs to be cheap enough and not require its own monitor and keyboard, else one might as well buy a CMD device! There have been two nobel attempts at such emulation of the protocol (VC1541 and SERVER64), though neither has attempted to support complete direct access and CPU emulation. I've compiled a specification for such an enhanced emulator and much of the Direct Access support is feasible, but some level of imcompatibility will always exist without the exact hardware or GCR enoded disk images. Being a realist I believe any HDD project would be "compatible" rather than a replacement, just like a 1581 works like a 1541, but not quite - etc. If anyone is interested in the specification I've prepared, I can post it. Regards, Nick > -----Original Message----- > From: g.baltissen@hccnet.nl [SMTP:g.baltissen@hccnet.nl] > Sent: Saturday, 4 September 1999 3:30 > To: cbm-hackers@dot.tcm.hut.fi > Subject: New idea HD for C= > > Hallo allemaal, > > Here is another idea for attaching an "harddisk" to your C=. But to > refresh > your mind I give you a history of older idea's: > > Connecting an IDE to your C= thru an interface > You need to rewrite the original Kernal. The problem is that a lot > of > PRGs (like GEOS) bypass the Kernal but by doing so they cannot see > the > HD. > > Connecting a PC to the C= thru a X1541-cable or an IEEE-equivalent. > In this case it all depends on how well the SW can emulate one of > original C= drives. But AFAIK there isn't one available yet. > (Frank ????) > > Connecting an IDE-drive to a 1541 > The idea is to addapt the above interface so it can be used by the > 6502 > in an 1541-drive. Then you have to change the Kernal. Problems: 1) > there is no listing INCLUDING comments etc. available. 2) Even if > you > have the listing, it is very tough material to understand. 3) what > about PRGs who directly address the 6522 used for the transferring > the > data from/to the floppy > > Connecting a PC thru the printerport to the 1541 > The basic of this idea is to get rid of the floppy and some IC's, > mainly the array 3255272-01, and use the above mentioned 6522 as > communication port with the PC. > Advantage: Less soldering then the above idea. Problems: the same. > > > Now my latest idea. The essence is the same as the above idea: get rid of > the > drive and some electronics. Then connect a PC to the 6522 thru an > interface. > The idea is to let the PC behave like the original floppy and electronics. > So > if the PC sees the 6522 giving signals for the original steppingmotor, it > adjusts the SW-pointer which tells the program which track the 'drive' is > using. > > I do not know what kind of interface to use. I'm thinking of using a > printer- > port but I/O-operations of an Intel-machine need a lot of time: 0.5 uSec. > Another option is to rebuild an old LPT-card so it is addressed by a > memory- > read/write. Then things can be speed up to 8 MHz or more. > > There are two ways of changing "floppys": > 1) We give a command to the PC which on its turn searches for the new > "floppy" and then manipulates the "Write-protect"-input so the 1541 > thinks the floppy has changed. Needs an extra keyboard and monitor > for > the PC. > 2) We have to change the Kernal of the drive. We at least need to add a > command so we are able to change a "floppy". PC works stand-alone. > > I also have some thoughts about how deal with the data. The moment a real > floppy is formatted, a stream of bytes is send to the ports of the 6522 at > certain intervals. Writing to a floppy is first searching the sector by > reading the contents of the correct track and then writing the data. IMHO > the > only thing we have to do is read/write the data at the same interval. The > only difference with a real system will be that the start of reading a > real > floppy will be random somewhere in the track and I always will start at > the > first sector. > The only difficulty will be determing the interval, the rest seems just to > be > reading/writing a stream of bytes: We even do not have to know what kind > of > information they represent. > > I would like to know your opinion, comments etc. about this idea. Thanks. > > Groetjes, Ruud > > PS: Is it "a 1541" or "an 1541" ? :) > > ------------------------------------------------------------------------------------------------ PLEASE TAKE NOTE: The contents of this email (including any attachments) may be privileged and confidential. Any unauthorised use of the contents is expressly prohibited. If you have received this email in error, please advise us immediately (you can contact us by telephone on +61 8 9441 2311 by reverse charge) and then permanently delete this email together with any attachments. We appreciate your cooperation. Whilst Orbital endeavours to take reasonable care to ensure that this email and any attachments are free from viruses or other defects, Orbital does not represent or warrant that such are free from computer viruses or other defects. (C) 1999: Orbital Engine Company (Australia) Pty Ltd and its affiliates - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.