Bill Mensch and other 6502 talks at VCF West

[BigEd]

On Saturday VCF West put on a virtual conference, streamed live and now available as a recording.

Here are some 6502-related highlights. Many other interesting topics too. Individual talks here (may not include Q&A)

Here are cued-up links to the full session video:
6502 Assembly Language (Stephen A Edwards) at 2h10m
Genesis of the 6502 (Bill Mensch & Stephen Edwards) at 6h45m
Bil, Bill and Eric Talking Tech at 7h55m

[litwr]

The most surprising information for me has been given in the last part - there was no such thing as ROR bug!

[BigEd]

Oh! Do you have a timestamp please for that?

[John West]

The ROR bug starts at about 8:12:40

[BigEd]

Thanks! There's a tidier recut with a transcript, and I found the same point on that one (17m30):
https://youtu.be/sPaAnbkhgAE?t=1049

(I don't much like Bill's take on that - I'll stick to my existing understanding!)

Edit to clarify: I think Bill's saying it wasn't a bug, it was a specification error, and Chuck P wouldn't take kindly to being corrected, so he stayed quiet and implemented what he'd been told. But I'd say, at best it wasn't Bill's bug, if he was only following orders, but it's still a bug if it was (in some sense) supposed to work, and missing ROR off the initial documentation doesn't quite erase that, because it nearly worked and it was soon fixed.

[Dr Jefyll]

In the video Mensch seemingly attaches a lot of importance to a programming card which doesn't include ROR. And he mentioned Peddle signing off on a spec -- seemingly a key point, in Mensch's view. So, are we to suppose that the sign-off was based on a mere programming card (by which I presume he means a handy, pocket reference)? With all due respect to Mensch, that seems... odd.

Also odd that, as Ed pointed out, ROR almost worked.

-- Jeff

ps- FWIW, ROR certainly isn't missing from the MOS Programming Manual, written by Peddle, AIUI, and published Jan 1975. (I'm not saying this supports or refutes what Mensch said in the video.)

[litwr]

It is interesting, that some architectures missed rotations in both directions. For instance, the TMS9900 has only rotation to the right but doesn't have rotation to the left. It was opposite to the first 6502.

[barrym95838]

Add and Add with carry can be utilized as substitutes for shift left and rotate left, with a slight loss of efficiency if your operand doesn't allow direct register addressing.

[BillG]

barrym95838 wrote:

Add and Add with carry can be utilized as substitutes for shift left and rotate left, with a slight loss of efficiency if your operand doesn't allow direct register addressing.

The TMS9900 does not have shift or rotate with carry. It does not even have add with carry.

This is the original 6800 code I am attempting to paraphrase to other processors:

Code: Select all

 1050 B8 106F         [4] 01981          eora   RNDM+3    ; XOR A with random no.
 1053 48              [2] 01982          asla             ; Put bit 28.XOR.31 in
 1054 48              [2] 01983          asla             ;   carry by shifting left
 1055 79 106C         [6] 01984          rol    RNDM      ; Rotate all four bytes of
 1058 79 106D         [6] 01985          rol    RNDM+1    ;   the random no., rotating
 105B 79 106E         [6] 01986          rol    RNDM+2    ;   the carry into the LSB
 105E 79 106F         [6] 01987          rol    RNDM+3    ; The MSB is lost

For the 9900, this is what I currently have. I am just learning the instruction set; there are probably better ways to do it. For instance, the shift may be able to be done more than one byte at a time and keeping it all in registers on some processors. For now, I am just trying to translate an instruction at a time and get it working. I may try to optimize it later:

Code: Select all

 0224 D060 0311           00462         movb    @RNDM+7,R1      ; XOR A with random no.
 0228 2801                00463         xor     R1,R0
 022A 04C1                00464         clr     R1              ; Put bit 28.XOR.31 in
 022C 0A20                00465         sla     R0,2            ;   carry by shifting left
 022E 1702 (0234)         00466         jnc     RAND0
 0230 0201 0100           00467         li      R1,>100
 0234 D020 030B           00468 RAND0   movb    @RNDM+1,R0      ; Rotate all four bytes of
 0238 04C2                00469         clr     R2
 023A 0A10                00470         sla     R0,1
 023C 1702 (0242)         00471         jnc     RAND1
 023E 0202 0100           00472         li      R2,>100
 0242 B001                00473 RAND1   ab      R1,R0
 0244 D800 030B           00474         movb    R0,@RNDM+1
 0248 D020 030D           00475         movb    @RNDM+3,R0      ;   the random no., rotating
 024C 04C1                00476         clr     R1
 024E 0A10                00477         sla     R0,1
 0250 1702 (0256)         00478         jnc     RAND2
 0252 0201 0100           00479         li      R1,>100
 0256 B002                00480 RAND2   ab      R2,R0
 0258 D800 030D           00481         movb    R0,@RNDM+3
 025C D020 030F           00482         movb    @RNDM+5,R0      ;   the carry into the LSB
 0260 04C2                00483         clr     R2
 0262 0A10                00484         sla     R0,1
 0264 1702 (026A)         00485         jnc     RAND3
 0266 0202 0100           00486         li      R2,>100
 026A B001                00487 RAND3   ab      R1,R0
 026C D800 030F           00488         movb    R0,@RNDM+5
 0270 D020 0311           00489         movb    @RNDM+7,R0      ; The MSB is lost
 0274 0A10                00490         sla     R0,1
 0276 B002                00491         ab      R2,R0
 0278 D800 0311           00492         movb    R0,@RNDM+7

For comparison purposes, this is the code for other processors...

For the 6502:

Code: Select all

 15BB 4D 15DA         [4] 02152         eor     RNDM+3          ; XOR A with random no.
 15BE 0A              [2] 02153         asl     A               ; Put bit 28.XOR.31 in
 15BF 0A              [2] 02154         asl     A               ;   carry by shifting left
 15C0 2E 15D7         [6] 02155         rol     RNDM            ; Rotate all four bytes of
 15C3 2E 15D8         [6] 02156         rol     RNDM+1          ;   the random no., rotating
 15C6 2E 15D9         [6] 02157         rol     RNDM+2          ;   the carry into the LSB
 15C9 2E 15DA         [6] 02158         rol     RNDM+3          ; The MSB is lost

For the 8080:

Code: Select all

 1444 A9              [4] 02091         xra     C               ; XOR A with random no.
 1445 07              [4] 02092         rlc                     ; Put bit 28.XOR.31 in
 1446 07              [4] 02093         rlc                     ;   carry by shifting left
 1447 3A 1491        [13] 02094         lda     RNDM            ; Rotate all four bytes of
 144A 17              [4] 02095         ral
 144B 32 1491        [13] 02096         sta     RNDM
 144E 3A 1492        [13] 02097         lda     RNDM+1          ;   the random no., rotating
 1451 17              [4] 02098         ral
 1452 32 1492        [13] 02099         sta     RNDM+1
 1455 3A 1493        [13] 02100         lda     RNDM+2          ;   the carry into the LSB
 1458 17              [4] 02101         ral
 1459 32 1493        [13] 02102         sta     RNDM+2
 145C 3A 1494        [13] 02103         lda     RNDM+3          ; The MSB is lost
 145F 17              [4] 02104         ral
 1460 32 1494        [13] 02105         sta     RNDM+3

For the Atmel AVR:

Code: Select all

 0009EB 9000 0577     [2] 02114         lds     R0,RNDM+3       ; XOR A with random no.
 0009ED 2560          [1] 02115         eor     R22,R0
 0009EE 0F66          [1] 02116         lsl     R22             ; Put bit 28.XOR.31 in
 0009EF 0F66          [1] 02117         lsl     R22             ;   carry by shifting left
 0009F0 9160 0574     [2] 02118         lds     R22,RNDM        ; Rotate all four bytes of
 0009F2 1F66          [1] 02119         rol     R22
 0009F3 9360 0574     [2] 02120         sts     RNDM,R22
 0009F5 9160 0575     [2] 02121         lds     R22,RNDM+1      ;   the random no., rotating
 0009F7 1F66          [1] 02122         rol     R22
 0009F8 9360 0575     [2] 02123         sts     RNDM+1,R22
 0009FA 9160 0576     [2] 02124         lds     R22,RNDM+2      ;   the carry into the LSB
 0009FC 1F66          [1] 02125         rol     R22
 0009FD 9360 0576     [2] 02126         sts     RNDM+2,R22
 0009FF 9160 0577     [2] 02127         lds     R22,RNDM+3      ; The MSB is lost
 000A01 1F66          [1] 02128         rol     R22
 000A02 9360 0577     [2] 02129         sts     RNDM+3,R22

For the 68000:

Code: Select all

 00001748 B500                    01497         eor.b   D2,D0                   ; XOR A with random no.
 0000174A E500                    01498         asl.b   #2,D0                   ; Put bit 28.XOR.31 in
                                  01499                                         ;   carry by shifting left
 0000174C 1038 18D0               01500         move.b  RNDM,D0                 ; Rotate all four bytes of
 00001750 E310                    01501         roxl.b  #1,D0
 00001752 11C0 18D0               01502         move.b  D0,RNDM
 00001756 1038 18D1               01503         move.b  RNDM+1,D0               ;   the random no., rotating
 0000175A E310                    01504         roxl.b  #1,D0
 0000175C 11C0 18D1               01505         move.b  D0,RNDM+1
 00001760 1038 18D2               01506         move.b  RNDM+2,D0               ;   the carry into the LSB
 00001764 E310                    01507         roxl.b  #1,D0
 00001766 11C0 18D2               01508         move.b  D0,RNDM+2
 0000176A 1038 18D3               01509         move.b  RNDM+3,D0               ; The MSB is lost
 0000176E E310                    01510         roxl.b  #1,D0
 00001770 11C0 18D3               01511         move.b  D0,RNDM+3

[litwr]

BillG wrote:

The TMS9900 does not have shift or rotate with carry. It does not even have add with carry.

For the 9900, this is what I currently have. I am just learning the instruction set; there are probably better ways to do it. For instance, the shift may be able to be done more than one byte at a time and keeping it all in registers on some processors. For now, I am just trying to translate an instruction at a time and get it working. I may try to optimize it later:

Code: Select all

 0224 D060 0311           00462         movb    @RNDM+7,R1      ; XOR A with random no.
 0228 2801                00463         xor     R1,R0
 022A 04C1                00464         clr     R1              ; Put bit 28.XOR.31 in
 022C 0A20                00465         sla     R0,2            ;   carry by shifting left
 022E 1702 (0234)         00466         jnc     RAND0
 0230 0201 0100           00467         li      R1,>100
 0234 D020 030B           00468 RAND0   movb    @RNDM+1,R0      ; Rotate all four bytes of
 0238 04C2                00469         clr     R2
 023A 0A10                00470         sla     R0,1
 023C 1702 (0242)         00471         jnc     RAND1
 023E 0202 0100           00472         li      R2,>100
 0242 B001                00473 RAND1   ab      R1,R0
 0244 D800 030B           00474         movb    R0,@RNDM+1
 0248 D020 030D           00475         movb    @RNDM+3,R0      ;   the random no., rotating
 024C 04C1                00476         clr     R1
 024E 0A10                00477         sla     R0,1
 0250 1702 (0256)         00478         jnc     RAND2
 0252 0201 0100           00479         li      R1,>100
 0256 B002                00480 RAND2   ab      R2,R0
 0258 D800 030D           00481         movb    R0,@RNDM+3
 025C D020 030F           00482         movb    @RNDM+5,R0      ;   the carry into the LSB
 0260 04C2                00483         clr     R2
 0262 0A10                00484         sla     R0,1
 0264 1702 (026A)         00485         jnc     RAND3
 0266 0202 0100           00486         li      R2,>100
 026A B001                00487 RAND3   ab      R1,R0
 026C D800 030F           00488         movb    R0,@RNDM+5
 0270 D020 0311           00489         movb    @RNDM+7,R0      ; The MSB is lost
 0274 0A10                00490         sla     R0,1
 0276 B002                00491         ab      R2,R0
 0278 D800 0311           00492         movb    R0,@RNDM+7

IBM mainframes didn't also have operations with carry flag until the 2000s!
Thanks for this interesting code snippets. I have tried to make code for the TMS9900 a bit shorter.

Code: Select all

         xor     @RNDM+3,r0      ; XOR r0 with random no.
         clr     R1              ; Put bit 28.XOR.31 in
         sla     R0,2            ;   carry by shifting left
         jnc     RAND0
         inc     r1
RAND0    clr     r2
         a       @RNDM,@RNDM     ; rotate left
         jnc     RAND1
         inc     r2
RAND1    a       r1,@RNDM
         a       @RNDM+2,@RNDM+2
         a       r2,@RNDM+2       ; The MSB is lost

However I didn't test it. IMHO for the MIPS the snippet should be similar to this.
I have also typed code for the Z80.

Code: Select all

         ld a,(RNDM+3)
         xor c                    ; XOR c with random no.
         rla
         rla
         ld hl,RNDM
         rl (hl)
         inc hl
         rl (hl)
         inc hl
         rl (hl)
         inc hl
         rl (hl)                   ; The MSB is lost

BTW you missed RNDM+3 in your 8080 snippet beginning.
And, finally, my snippet for the 68000.

Code: Select all

         eor.b RNDM+3,d0           ; XOR c with random no.
         lsl.b #2,d0
         roxl RNDM
         roxl RNDM+2

It is odd but all 68k can't shift/rotate double words in memory.

[BillG]

litwr wrote:

Thanks for this interesting code snippets.

Thank you for the response. Quite a bit of thought and time obviously went into it.

litwr wrote:

I have tried to make code for the TMS9900 a bit shorter.

Code: Select all

         xor     @RNDM+3,r0      ; XOR r0 with random no.
         clr     R1              ; Put bit 28.XOR.31 in
         sla     R0,2            ;   carry by shifting left
         jnc     RAND0
         inc     r1
RAND0    clr     r2
         a       @RNDM,@RNDM     ; rotate left
         jnc     RAND1
         inc     r2
RAND1    a       r1,@RNDM
         a       @RNDM+2,@RNDM+2
         a       r2,@RNDM+2       ; The MSB is lost

My mistake was losing the context by including only a part of the code.

This is the full subroutine: it is the pseudo random number generator for the Space Voyage game on the 6800.

Code: Select all

 1045 F7 106B         [5] 01975 RANDOM   stab   BSAVE     ; Save the B accumulator
 1048 C6 08           [2] 01976          ldab   #8        ; Set counter
 104A B6 106F         [4] 01977 RPT      ldaa   RNDM+3    ; Get M.S. byte of random no.
 104D 48              [2] 01978          asla             ; Shift it left three
 104E 48              [2] 01979          asla             ;   times to get bit 28
 104F 48              [2] 01980          asla             ;   in line with bit 31
 1050 B8 106F         [4] 01981          eora   RNDM+3    ; XOR A with random no.
 1053 48              [2] 01982          asla             ; Put bit 28.XOR.31 in
 1054 48              [2] 01983          asla             ;   carry by shifting left
 1055 79 106C         [6] 01984          rol    RNDM      ; Rotate all four bytes of
 1058 79 106D         [6] 01985          rol    RNDM+1    ;   the random no., rotating
 105B 79 106E         [6] 01986          rol    RNDM+2    ;   the carry into the LSB
 105E 79 106F         [6] 01987          rol    RNDM+3    ; The MSB is lost
 1061 5A              [2] 01988          decb             ; Decrement the counter
 1062 26 E6 (104A)    [4] 01989          bne    RPT       ; If it's not 0, go repeat
 1064 F6 106B         [4] 01990          ldab   BSAVE     ; Restore the B accumulator
 1067 B6 106C         [4] 01991          ldaa   RNDM      ; Put random # in A
 106A 39              [5] 01992          rts              ; Return to calling program

For some reason, even though the 6800 is a big-endian, RNDM is stored in little-endian order. Ads in magazines indicate there was an 8080 version of Space Voyage but I have never found a copy of it anywhere. Perhaps this code originated on the little-endian 8080? The code can be rewritten to keep it in big-endian form, but that provides no advantage on the 6800.

Because of the endian mismatch, word-sized access to the two halves of RNDM by the 9900 will not work as is unless the order of the bytes is reversed. I did not do that, but it will be beneficial to cut the number of add with carry kludges from three down to one.

Code for the 9900 is deceptive. The "a @RNDM,@RNDM" instruction makes six 16-bit memory accesses: one to fetch the opcode, two to fetch the operand addresses as the processor is not aware they are the same, two to read the addends and one to write the sum. On the most common 9900 platform, the 99/4A, each 16-bit access suffers a four-cycle penalty as the memory circuitry makes two accesses to 8-bit memory.

litwr wrote:

I have also typed code for the Z80.

Code: Select all

 0100 3A 0126        [13] 00003          ld a,(RNDM+3)
 0103 A9              [4] 00004          xor c                    ; XOR c with random no.
 0104 17              [4] 00005          rla
 0105 17              [4] 00006          rla
 0106 21 0123        [10] 00007          ld hl,RNDM
 0109 CB16           [15] 00008          rl (hl)
 010B 23              [5] 00009          inc hl
 010C CB16           [15] 00010          rl (hl)
 010E 23              [5] 00011          inc hl
 010F CB16           [15] 00012          rl (hl)
 0111 23              [5] 00013          inc hl
 0112 CB16           [15] 00014          rl (hl)                 ; The MSB is lost

I did not make a version for the Z80.

I did not do any optimizing as I wrote the code, but the 8080 version can also be made better by using the M pseudo register access left over as an artifact from the 8008:

Code: Select all

 0116 21 0128        [10] 00019         lxi     H,RNDM
 0119 7E              [7] 00020         mov     A,M
 011A 17              [4] 00021         ral
 011B 77              [7] 00022         mov     M,A
 011C 23              [5] 00023         inx     H
 011D 7E              [7] 00024         mov     A,M
 011E 17              [4] 00025         ral
 011F 77              [7] 00026         mov     M,A
 0120 23              [5] 00027         inx     H
 0121 7E              [7] 00028         mov     A,M
 0122 17              [4] 00029         ral
 0123 77              [7] 00030         mov     M,A
 0124 23              [5] 00031         inx     H
 0125 7E              [7] 00032         mov     A,M
 0126 17              [4] 00033         ral
 0127 77              [7] 00034         mov     M,A

litwr wrote:

BTW you missed RNDM+3 in your 8080 snippet beginning.

This is the omitted part of the 8080 code; a copy of RNDM+3 is left in register C to do the xra:

Code: Select all

 143D 3A 1494        [13] 02086 RPT:    lda     RNDM+3          ; Get M.S. byte of random no.
 1440 4F              [5] 02087         mov     C,A
 1441 17              [4] 02088         ral                     ; Shift it left three
 1442 17              [4] 02089         ral                     ;   times to get bit 28
 1443 17              [4] 02090         ral                     ;   in line with bit 31
 1444 A9              [4] 02091         xra     C               ; XOR A with random no.
 1445 07              [4] 02092         rlc                     ; Put bit 28.XOR.31 in
 1446 07              [4] 02093         rlc                     ;   carry by shifting left

litwr wrote:

And, finally, my snippet for the 68000.

Code: Select all

         eor.b RNDM+3,d0           ; XOR c with random no.
         lsl.b #2,d0
         roxl RNDM
         roxl RNDM+2

It is odd but all 68k can't shift/rotate double words in memory.

As stated above for the 9900, the 68000 cannot shift sixteen bits at a time unless the endian of RNDM is reversed. Then, a single 32-bit shift with roxl.l can be done.

Again, I have done no optimization and will not until all versions give the exact same result as the original 6800 code.

[litwr]

BillG wrote:

Because of the endian mismatch, word-sized access to the two halves of RNDM by the 9900 will not work as is unless the order of the bytes is reversed.

Why didn't we reverse the bytes order? This doesn't change functionality of this pseudo random number generator.

BillG wrote:

Code for the 9900 is deceptive. The "a @RNDM,@RNDM" instruction makes six 16-bit memory accesses: one to fetch the opcode, two to fetch the operand addresses as the processor is not aware they are the same, two to read the addends and one to write the sum. On the most common 9900 platform, the 99/4A, each 16-bit access suffers a four-cycle penalty as the memory circuitry makes two accesses to 8-bit memory.

The Ti99/4A has 256 bytes of fast 16-bit RAM. Some ppl could expand their TI99-4a using 32 KB of fast 16-bit RAM.

BillG wrote:

I did not do any optimizing as I wrote the code, but the 8080 version can also be made better by using the M pseudo register access left over as an artifact from the 8008:

IMHO a version for the z80/8080 could be optimized more using 16-bit addition.

BillG wrote:

IThen, a single 32-bit shift with roxl.l can be done.

No, roxl.l works only for registers even on the 68020. Sometimes the 68k is very unorthogonal.

[BillG]

litwr wrote:

BillG wrote:

Because of the endian mismatch, word-sized access to the two halves of RNDM by the 9900 will not work as is unless the order of the bytes is reversed.

Why didn't we reverse the bytes order? This doesn't change functionality of this pseudo random number generator.

I did an instruction-by-instruction paraphrase of the original 6800 code and will not try to do any optimization until it was completely working and tested.

litwr wrote:

BillG wrote:

Code for the 9900 is deceptive. The "a @RNDM,@RNDM" instruction makes six 16-bit memory accesses: one to fetch the opcode, two to fetch the operand addresses as the processor is not aware they are the same, two to read the addends and one to write the sum. On the most common 9900 platform, the 99/4A, each 16-bit access suffers a four-cycle penalty as the memory circuitry makes two accesses to 8-bit memory.

The Ti99/4A has 256 bytes of fast 16-bit RAM. Some ppl could expand their TI99-4a using 32 KB of fast 16-bit RAM.

Much of those 256 bytes is used by system code. From what I have read, there is enough free space to safely allocate one workspace.

litwr wrote:

BillG wrote:

I did not do any optimizing as I wrote the code, but the 8080 version can also be made better by using the M pseudo register access left over as an artifact from the 8008:

IMHO a version for the z80/8080 could be optimized more using 16-bit addition.

After you posted a Z80 version, I threw this together to see whether use of the new 16-bit adc instruction of the Z80 is beneficial. The cost of fetching 16-bit addresses dominated the code:

Code: Select all

 0114 3A 012D        [13] 00017         ld      A,(RNDM+3)
 0117 A9              [4] 00018         xor     C
 0118 17              [4] 00019         rla
 0119 17              [4] 00020         rla
 011A 2A 012A        [16] 00021         ld      HL,(RNDM)
 011D ED6A           [15] 00022         adc     HL,HL
 011F 22 012A        [16] 00023         ld      (RNDM),HL
 0122 2A 012C        [16] 00024         ld      HL,(RNDM+2)
 0125 ED6A           [15] 00025         adc     HL,HL
 0127 22 012C        [16] 00026         ld      (RNDM+2),HL

litwr wrote:

BillG wrote:

IThen, a single 32-bit shift with roxl.l can be done.

No, roxl.l works only for registers even on the 68020. Sometimes the 68k is very unorthogonal.

Determining the time taken by 68000 instructions is complicated. Loading 32 bits into a register, shifting then storing it back may be competitive with two 16-bit in memory shifts.