Hello. g.baltissen@hccnet.nl wrote: > 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. This version overdrives the C64 CPU. Rather than rewrite the original KERNAL, you'll need to patch the original and add lot of new code (IDE programming and making a new file system). Probably you would need also some extra RAM buffer and IDE interfacing HW. Chezh guys made it and available now. > 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 ????) Right you need a little KERNAL patch on C= side and more sophisticated SW on PC. BTW the speed is amazing. I never seen much faster (maybe REU or RAMLink with good driver). I made some sort of testing and programming. The HW (cable) is extremely simle (one little chip). > 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. I'm just working on it. The half o'work is done. I plan also collect the sources on funet and make also another better listing with cross-ref. table. >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 Great idea. That could be *very* compatible but sometimes slow emulation. Some sort of IDE programming and new sub-OS also necessary. Don't mention the HW. Although this idea is much better than connecting IDE to C64. Imagine, you can simply insert disk into IDE + 1541 and copy it to/from HD without of interacting C64 memory. > 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. Not the same. Less programming because you needn't create a new sub-OS for IDE. You can use DOS, Linux or any free OS. You need some kind of disk image converter into raw GCR data. You can also use good'n'compatible parallel speeders between C64 and 1541. > 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. Maybe some RAM buffer (8K) would help a lot. Most of speeders at least wait for SYNC mark, but then ignores Byte Ready flag and reads data well syncronized with CPU. I think about connecting SRAM to LPT port. > 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. Why make 2 interfaces (for PC and 1541) when one also enough? > 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. I don't see why this necessary. You simply make list of disk you using, the switch between them with switch. Switch can be connected into 1541 VIA port or to PC LPT port. > 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. Or use a switch like on CMD drives. > 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. That is not so bad. But some prediction would speed up things. > 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. As I wrote the buffer would help lot. Richard Atkinson wrote: >1. Have the 1541 ROMs been disassembled and fully documented yet? Just working on commented version(s). >3. For the 1541 code experts: approximately how much hardware-specific >code would have to be changed? If you want emulate only one disk then nothing (if HW is enough compatible). But some new commands (like MD, CD, etc) would be also good so little additional programming necessary. Probably no extra ROM, but patch enuff. Frank - 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.