Hi! (happy to see you again here ;-) ) Some words regarding your new interface plans... > 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 ????) Yes, indeed. Once I discussed this one with a friend (Credo/Success) and guess it's possible but quite hard. I mean, if the program should deal with better emulation than the current ones (...pure serial (logical) implementation shouldn't be too hard, I saw that working in some progs). The real problem is to present some 'slow but compatible ;-)' type of an 1541 emulation for 1541 dependent software. It would need a lot of Intel specific tricks and a very good optimized 6502 interpreter to keep sync to realtime; one good point in the emulation could be to present cycle exact timing _just_in_i/o_times (anytime a program does i/o in the drive); that way the internal timer in the PC would or could still be suitable (else, not; because of inappropriate resolution) for timing. > 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. > 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. Seem to remember to some similar ideas from Frank. Also quite convergent to one of my earlier ideas on how to read and write disks in a PC 5.25 drive. The similarity is: both of your new idea and mine needs a continuous bit-stream to read and write. Well of course there are differences. Since the PC is quite slow and uncertain for reading such streams that comes off from a floppy head, I thought it would be the easiest to build a small TTL panel for sampling the bit-read signal into a static RAM (emitting the stream directly from the RAM in the opposite case). I guess not much stuff is needed; a clock generator, some counters, a serial shift-register and so on (all other lines could be still controlled by the original PC floppy controller). The read stream can be processed by an appropriate software (streams to be written could be also prepared by software). (Maybe the same ideas were invented in the German Catweasel controller; this is able to handle any floppy formats with PC drives). Now the similarities: maybe, your interface will need to present more or less the same speed data stream (with a lot of differences of course). So if the LPT seems to be inappropriate for such a task, maybe a similar sampling based board could do. Also a lot of similarities in the software: your server program will have to deal with image-data converting to floppy format streams. Frank should know more on the actual possibilities of the LPT; AFAIK he has done a lot of appropriate experiments with that port. L. - 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.