Re: Commodore 64 Ultimate Cartridge project

On Mon, May 07, 2012 at 06:49:16PM +0200, Groepaz wrote:
> > I can understand you :) My only reason: interfacing with SPI bus is not so
> > fast if some "bit banging" is used, and I wanted decent performance mainly
> > because of the SPI based ethernet controller. However I am thinking on this
> > still, as maybe serial shift register of the CIA can help here to speed
> > things up a bit. In my idea uC is only needed to have some kind of fast
> > SPI/serial converter (and also to "cache" some data inside the uC's memory
> > still C64 is ready to process it, etc).
> > 
> > However as far as I can see, the goals are a "bit" different, you may not
> > need this at all.
> 
> i would strongly advice not to use the 6510 for bitbanging - since that is 
> dead slow. look at what speed the mmc64 can offer, it has a small spi 
> controller with 8mhz spi clock (so one byte can be transfered each c64 cycle), 

I am not sure I understand this. SPI bus transfers (in full duplex, but it
does not matter here, also I am not sure SD card would support read/write in 
same time) one bit within an SPI clock cycle, so 8MHz SPI clock means 1
Mbyte/sec, did you mean this way, that one byte for a C64 clock cycle? Just
because I am lost then: C64 is not able to read a byte _and_ store the
result within a single C64 clock cycle, even the shortest 6510 opcodes last
for 2 clock cycles. Or do you mean that there is some buffering on "the
small spi controller" and C64 can read it then slower? What kind of
controller is it, btw?

I am just asking this, since I want to do something similar: I have devices
(not even one, planned: SD card, the 28J60 ethernet controller, and maybe
some rtc chip with SPI connection) connected to the SPI bus, and I need to
connect to C64.  My idea (besides the slow bitbanging) is using an uC.  If I
maximize the size of the SPI "block" transfer, I can even read it into uC-s
memory, and allow C64 to read with non-constant speed etc, while uC can
read/write another data chunk from/to the SPI bus, etc.  However when I
think about this, I often feel, that it starts to "overgrow" my limited
experience on the topic, and I should use bitbanging even if it's really
slow :( Or using CIA's shift register, etc.

The other complicated solution would be disabling 6510 and allow uC to place
data into C64's memory, so basically do some kind of DMA (from the view
point of the C64 - I mean).  Then I can have more tight timing, not needed
to think about slower transfer by 6510 program, etc.

> and also uses a huge unrolled loop to read a sector from sd card. this is 
> quite ok speed, but already on the slowish side of things. with bitbanging it 
> would be at least 10 times slower, if not more - and unrolling loops would be 
> out of the question because codesize would explode.

I use bitbanging now on the PC parallel port to test my prototype SD card
software currently written in python :-) But of course it's another story.

       Message was sent through the cbm-hackers mailing list