I recently started a small project just for fun. I had some clone nes controllers lying around and tried to adapt them to c64. It was a bit trivial and got it working. I chose the path that I didn't need to disassemble and solder on to the pads of the controller instead I read the data from the controller serially with a microcontroller, atmega328 that is. Having done that, I thought that loading stuff from joystick port would be somewhat useless but a fun thing to do. Since joy port doesn't present any loading or memory interface. There should be a loader of some sort on the C64 side. The smallest assembly routine I've created which is then get poked into the memory is this so far : DELAY_1MS = $EEB3 JOY2 = $DC00 ;XXXFRLDU ;-----||| ;-----||*--- Up - Indicates if there is ongoing transfer ;-----|*------ Down - Transferred bit ;-----*--------- Left - Flags end of transmission (1=continue, 0=stop) *=$030C NEXTBITS - ;Low byte of JOY2 (DC00) also used to initialize X register to 0 by SYS command LDA JOY2 ;State of up button flags the transfer ;1=Not pressed,no transfer; 0=Pressed, transfer started LSR BCS - ;Shifting the least significant bit into carry we get ;transferred bit (Down not pressed = 1, Down pressed = 0) LSR ;We put the transferred bit into the respective byte ROL PRGLOAD, X ;Next bit transfer for next byte, incrementing X INX ;Shift redundant stop bit into Carry ;1 means go on ;0 means stop transmission.. no need to use another register LSR ;To prevent badlines interfering with the synchronization, ;we wait >40 cycles... an existing rom routine preserves the ;X register and takes approx. 1ms. Luckily, it doesn't touch carry. ;It destroys A register but we already shifted the redundant bit into carry JSR DELAY_1MS ;Use Left button press decide ending/continuing transfer BCS NEXTBITS ; Aligning the second stage loader at the end of initial loader, hence we save 3 bytes ; getting rid of jumping... ; This area is actually used by kernal vectors but it's easy to restore them later from rom. PRGLOAD This assembly program which is 17 bytes then get poked into memory by this basic program, 1 poke56334,0:fori=0to16:reada:poke780+i,a:next:sys780 2 data 173,0,220,74,176,250,74,62,29,3,232,74,32,179,238,176,239 Well, the question is... is there any basic / kernal exploit that I can use to make it shorter? Can you think of any? By the way, this routine is only used to transfer a second stage loader which is 256 bytes and it only takes 1-2 seconds to load that part. Second stage loader can possibly load at speeds of at least 15/20K per second... (Employing both joy ports would double that throughput) Here is a small demo of it loading the 256 bytes second stage loader using above routine, https://www.youtube.com/watch?v=uCOyWWKs2yMReceived on 2019-01-16 01:00:03
Archive generated by hypermail 2.2.0.