My 6502 Disassembly Project

[Bill]

(Bonus: Why would we want to write a timer but then disable the interrupt?

In a non-interrupt driven system when the CPU wants the elapsed time between events? The clock can be polled this way if it is read by accessing register 4 (read and disable interrupt.)

And why would we ever want to read from register C to read the timer and enable the interrupt, besides in the odd case you care about it counting down from 255 after it just counted down from your number?)

According to page 2-56 of the Rockwell datasheet, the loaded count is decremented at the divided clock rate until it hits 0, then it decrements at an undivided clock rate; the interrupt is generated when it hits $FF. I guess so that the code can determine the latency in actual clock cycles.

[urbite]

Agree that the game save RAM is at 1800h. I had this in my spreadsheet but overlooked it when creating the memory map wiki page. Here’s the clip from my spreadsheet.

[Bill]

Agree that the game save RAM is at 1800h. I had this in my spreadsheet but overlooked it when creating the memory map wiki page. Here’s the clip from my spreadsheet.

The ram is 1024 bit, so it is 256x4.

[urbite]

Fixed in above post and wiki

[Bill]

Check out the Wiki article for L346E. There are some places where $1800 + X is referred to; the subroutine called by this code seems to store stuff in $1800+X, $183B+X, and $1876+X. I can’t recall nor imagine what things would need to be stored 3 times, but what’s interesting is it seems to switch to BCD mode, perhaps so as to store something directly convertible to two base-10 digits.

I cannot say about the storing in three places part, but the routine looks to me like it is incrementing a BCD number. It increments the one’s digit in BCD mode. If the result is $10, it must have incremented a 9 to a 10, or $10 in BCD. Storing the $10 to 4-bit RAM automagically removes the “tens” digit, storing just the 0. By decrementing X and repeating, it goes on to increment the ten’s digit and so on until there is no more carry.

BTW, you have the comment on the bcc L3485 instruction backward. http://www.6502.org/tutorials/compare_beyond.html

The sense of the carry flag after subtraction on the 6502 is backward compared to most other processors.

[Bill]

The three places mystery deepens:

.3494 9D 1800		  02901	L3494:      sta L1800,X
.3497 69 01		  02902	            adc #$01
.3499 9D 183B		  02903	            sta L183B,X
.349C 69 01		  02904	            adc #$01
.349E 9D 1876		  02905	            sta L1876,X
.34A1 60		  02906	            rts

Each one is one larger than the other…

[urbite]

Paul, since you modified your disassembler control file, please check it into the BitBucket so I can take advantage of the latest symbols.

I uploaded the ud6502 (urbite disassembler for 6502) disassembler control file and resulting assembly listing file generated using the latest control file. In addition to defining symbols, ud6502 allows both line and block comments to be defined. The idea is that the control file is iteratively refined until the resulting disassembly morphs into a fully readable source with comments and directives that can then be reassembled. With that said, I’m not 100% certain that my 6502 source format is correct.

This 1990 vintage project was never completely finished, so the control file syntax is a bit rough and the output format is non-standard. In spite of that it is quite useful as an iterative tool. The labels in the control file have the following characteristics.

• Any label that is not defined in the control file (automatically generated) has a trailing underscore
• Automatically generated labels are prefixed with a single letter specifying the type of access (absolute, relative, zero page, subroutine, etc). This gives some insight into how the particular location is referenced.
• Labels defined in the control file currently need to have an access type definition that matches code usage or they won’t be found - the same label must be defined for each type of access. As a result, duplicate labels will be included in the listing once for each definition. A good example of this is the RESET_ENT label, which is accessed as absolute data in the reset vector location but as an absolute jump address in the code. This needs to be fixed.

I will add some usage info to the beginning of control file when I get a chance. This has always been used only by me, so the instructions were in my head or the source code.

ud6502 is written in C and I had to make some mods so it would compile to run under Win 7. In doing so I was reminded how ugly the code is. Rewriting it will be my first real python project. I’ll upload the executable if you think it will be a useful for this project. But you’d disown me if I released the hacky ugliness that is 26 year old C code

[urbite]

The disassembly listing I checked in has some labels and detailed comments added to the part of the initialization code that checks for stuck slam, ball roll, and plumb bob switches, and the presence of the game PROM at

Also added is a detailed description of the delay routine - would someone please check my timing loop calculations and confirm the 656ms delay value.

[Bill]

Also added is a detailed description of the delay routine - would someone please check my timing loop calculations and confirm the 656ms delay value.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Delay for 656 milliseconds
;
; 1st order delay calculation (assume branch always taken)
; # clocks = 587018 = 255*(7+255*9)+2+6
; Clock frequency = 3.579545/4 = 894.88625 KHz
; Delay time (sec) = 1/f(MHz) * # clocks / 10^6
; = 4/3.579545 * 587018 / 10^6
; = 0.655969 seconds

each branch is taken 254 times at 3 cycles each, then it falls through on the 255th time on the way out of the loop for 2 cycles. You are nowhere near the page boundary, so you never get the added cycle penalty for crossing that. So the answer is:

; # clocks = 586762 = 255*(7+255*9 - 1) - 1+2+6
; Clock frequency = 3.579545/4 = 894.88625 KHz
; Delay time (sec) = 1/f(MHz) * # clocks / 10^6
; = 4/3.579545 * 586762 / 10^6
; = 0.655683 seconds

Confirmed.

[Bill]

I would like to point out that the authors of the code seem to have a fetish for using an upper case letter ‘O’ instead of a ‘0’ for the digit zero. That is why we have strange subroutines like L34C0.

Also, we have a hexadecimal conversion table at $22ED.

[mrcity]

Hmm, haven’t noticed the 0 vs O issue. However, I built out some more pages over the weekend including some details on the RIOT U5 timer interrupt events. Looks like it is doing something with the display as you go through L2807 & especially L283D. I wasn’t able to deduce much of the context because I’m not sure when the U5 timer interrupt is actually being paid attention to.

[Bill]

You guys might find this interesting… https://calendar.dallasmakerspace.org/events/view/647

[denzuko]

Count me in! Anyone else apart of the VCC want to join?

[Bill]

OK, I finally completed the port of my cross assembler to Win32.

I modified the Gold wings source on Bitbucket to make it generate the same binary.

Is there a web interface to upload a binary file or will I have to do the Clone and Git dance?

[mrcity]

Cool. I’m not sure how much the Web interface & browser will handle non-printable characters and such, but since copying & pasting 0x08 (backspace) might have unintended results, it’s probably best to go with the clone & git dance. That’ll make your life easier anyhow in the long run, as Git Shell is a nice utility to have around in Windows-land.

[Bill]

I uploaded the executable for the assembler and disassembler (future simulator/debugger) along with the resulting files from the assembly.

Do we want to transfer the comments from the wiki to the source files?

[mrcity]

It would probably be helpful, and especially so once we’re through commenting all of it. For now, the wiki should be our first and foremost attention because there you can essentially use the browser to step through the code. My eyes tend to glaze over when I’m having to jump around in a really long text file that’s not terribly distinctive over the course of the contents. Plus the wiki gives you context as to who jumps to/calls what line of code and where you can go from there.

[Bill]

Bill, you might be interested to know that in a lot of cases, new stuff to display on the VFD quickly “slides” in from the right to give it a fast scrolling effect. I haven’t paid close enough attention to see if it blanks the screen before sliding in new text, or if the original text stays put for the new text to slide over. I’d imagine it blanks the original text in order to further enhance the visual stimulus.

Simulation verifies that the subroutine at L31A2 is doing this. It shifts a text string from right to left.

[mrcity]

Well, this just got real: my machine is back up & running! I got a new MPU board for it with all-new RIOT chips, and had to redo one of the wires in the wiring harness. It even fixed the issue where it would freeze somewhere in test mode. Now if we make any changes to the ROM code as a result of our explorations, it’ll be really easy to test.

Bill, looks like I’ve got a lot of catching up to do with the notes you’ve left on the project Wiki!

[Raymond]

You should look into the NeoLoch Inquistor with the PIA/RIOT chip blade. It will test 6520/6521 PIA, 6820/6821/6822 PIA, and the 6532 RIOT chips.