On Fri, Jul 18, 2014 at 04:25:17PM +0200, Gerrit Heitsch wrote: > On 07/18/2014 05:33 AM, Jim Brain wrote: > >lda #0 > >sta $82 > >loop2: ldx #00 > >loop: lda $100,x > >sta $80 > >lda #$ff > >sta $82 > >lda #$00 > >sta $82 > >inx > >bne loop > >inc $08 > >lda $08 > >cmp #$10 > >bne loop2 > >loop3: beq loop3 > The code could be optimized further, not that it's necessary for this > purpose, but it just jumped out at me when looking at your code and I > noticed you didn't use the Y register. Simply add > > LDY #$10 > > at the beginning and then instead of > > LDA $08 > CMP #$10 > > use > > CPY $08 > > And also start reading at $0800 and not $0100. Or you read from f800..ffff and you don't need any compare ;-) > >And, I was able to dump out the entire 2kB of ROM. I also found out > >that it looks like the system requires 4 cycles after RESET goes high to > >start > > Probably has something to do with loading the RESET vector and getting > things set up internally before putting the program counter onto the > address bus for the first command fetch. Does any 6502 datasheet show a > clock by clock diagram for what happens once RESET goes high? It's the same as any other BRK, except the stack writes are turned into reads. Seven cycles total; first three are accessing the stack, next two are accessing the reset vector, last two are fetching the next instruction. Depending on how you count and on how your phases are aligned etc. you'll need to add some cycles at the start, e.g. for fetching the 2nd opcode byte. There is also a cycle or so delay from taking the reset pin high to the BRK being forced. And the 6500 perhaps adds extra delay from its special reset circuitry, who knows. But I doubt it. So sim it on visual6502 and find out ;-) It looks like the four cycles are exactly what it takes to get to the vector reads. Segher Message was sent through the cbm-hackers mailing listReceived on 2014-07-18 23:00:03
Archive generated by hypermail 2.2.0.