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

Hi, to all,

as there is already burst patch for c64 (one wire hack),

to get 1571 and 1581 tu use burst on c64 (also kernel roms exist to 
support that)

perhaps it is time to mod 1541 drive to talk faster ? :)

Regards,

Zoran


On 3/30/22 17:46, Jim Brain wrote:
> 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
>
>