Re: Patching in a CBM disk drive connection in a C64 case.

From: Claudio Sánchez - Tokafondo <tokafondo_at_gmail.com>
Date: Wed, 30 Mar 2022 19:21:44 +0100
Message-ID: <6f2df105-07f4-0a4d-5080-0ac46ce344d8_at_gmail.com>
El 30/03/2022 a las 16:46, Jim Brain escribió:
> On 3/30/2022 6:11 AM, Claudio Sánchez - Tokafondo wrote:
>>
>> Thanks. What about taking the serial protocol out?
>>
>> I mean:
>>
>> AFAIK, all data transfers in the serial bus are I/O based: the computer CPU writes or read data into a specific memory address so the CIA makes its job of sending it to, or receiving it from the drive, isn't it?
>>
>> And the CBM drive CPU does the same: read or write data in its companion CIA memory location for the same reason.
>>
>> So why not to get rid of the CIAs and make both CPUs to access the same memory location inside the computer, via DMA?
> 
> I think there's a misconception on how IEC serial works that is making this thread longer than it needs to be.
> 
> In the PET line (IEEE) and the prototype VIC-20, the design lent itself to the idea you pose above.  In the PET line, for example, one could remove the 75160/161 or equivalent circuitry and replace it with a CPLD or something that grabbed the bytes sent to the 8 bit registers and skipped the whole IEEE protocol.
> 
> Of course, IEEE is parallel, so you're not buying much at that point, but stay with me.
> 
> When the VIC was designed, the idea was to continue to byte transfer, but use the built-in shift register int eh 6522 VIA to serialize the data over the wire.  Prototype KERNAL did just that.
> 
> But, as elsewhere noted in this list, VIA has a shift register bug, and silicon changes would be too late to hit VIC-20 ship date.
> 
> So, the byte transfer idea was scrapped and the CPU took over chopping up the byte into bits and sending or receiving it on both sides (VIC and peripherals)
> 
> The 64 started life as VIC++, and the idea was the share preipherals. 6526 fixed the shift register issue, but compatibility won the day.  64 also uses bit stores (and slowed them down more to deal with VIC-II cycle stealing).
> 
> So.
> 
> To accomplish what you note above, you need to rewrite the KERNAL and DOS to store/read the data in bytes, not bits (with the requisite software clock generation).
> 
> But:
> 
> At that point, as Michal notes, you've tossed compatibility out, as most speeders and related code will assume the CIA/VIA IO registers are being used to transfer by bit, not by byte.
> 
> Jim
> 
> 
Thanks for all that explanation. I really appreciate it.

What about keeping standard KERNAL routines along with new ones that would use that DMA transfer mode?

If compatibility is a must, then that could be a way.

I understand the necessity of having old software running in new formats, but at some point the CBM machines would be able to get advantage of faster speeds and bigger capacities even breaking compatibility.
Received on 2022-03-30 21:00:03

Archive generated by hypermail 2.3.0.