Page 5 of 6
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Wed Jul 22, 2020 12:37 pm
by BillG
It feels to me that the most important variable is where RAM is to be found - presuming FLEX is to be loaded into RAM. And a part of that is whether RAM is contiguous. As to the rest of the address space, it doesn't matter too much whether it's ROM, I/O, empty, or an image of something else.
Perhaps you could list your targets and briefly tabulate their complement of RAM, in their various minimal, expanded, and maximal configurations?
Although you'll very likely not have Acorn's systems in your list, here's a sketch:
Yes, the location and availability of unused RAM is the primary determining factor.
The full picture is still incomplete as the use of zero page locations by various system components remains open to debate.
It is possible that multiple "standard" versions of FLEX can be built for any particular platform. For instance, it may be desirable by some to have $200 to $1FFF free for loading legacy software from tape.
Being on the other side of the pond, I am unlikely to have a real Acorn, especially if it requires a PAL monitor. Emulation provides a means to that platform, however.
---
The original target for the project was the Corsham 6502 CPU board for the SS-50 (SWTPC) bus. It has free RAM from $0 up to $DFFF; the monitor uses the upper 256 bytes for scratch memory. The original idea was that FLEX would load at the upper end of that RAM and set the MEMEND system variable to point just below the image. Now, the private portion of FLEX will use $200..$1FFF with the public part from $2000 and up.
---
From Dave at OSIweb,
On the C1P, the Monitor ROM is at the top 2K from F800-FFFF. This is also true for systems (C1/2/4/8) with the CEGMON boot ROM. The C2/4/8 Boot ROM occupies the top 3 pages, FD00-FFFF, and the Floppy port is at $FC00. The vido memory starts at $D000. Some serial ports, etc. might be at $C000, so the safest bet is to use the lower 48K of RAM (0000-BFFF). On disk systems that also have BASIC in ROM, BASIC occupies A000-BFFF, so those systems would be limited to 40K.
On A C1P system, the floppy is at $C000, and BASIC from A000-BFFF, so again, 40K available.
The private portion will use what it can from $200 to $1FFF with the rest at the upper end of free RAM.
The nature of the OSI disk hardware may require several track buffers.
---
A fully expanded KIM-1 offers free RAM in two blocks:
$0400..$13FF
$2000..$FFF7
The private portion will use what it can in the lower block with the remainder at the top of the main block.
---
floobydust is building a system with 32K of RAM and 32K of EEPROM. The part of the private portion which can reside in ROM will. The part which has to be in RAM will use the upper end of the $200 to $1FFF range.
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Fri Jul 24, 2020 9:58 pm
by BitWise
In a Second Processor, RAM runs up to F800.
I thought it was 64k of RAM but with the 2k boot ROM copied into F800 up and theoretically expendable (if you drive the tube directly)?
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Sat Jul 25, 2020 7:31 am
by BigEd
Yes, good point, you could get back a bit less than 2k: there would still be a little I/O in the address space, maybe that's as little as 16 bytes.
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Tue Jul 28, 2020 12:13 am
by floobydust
I just completed building an initial CF-Card/RTC adapter for my C02 Pocket SBC. This is what I plan to use to try FLEX with, once I write some code to make it go... details in the hardware section:
viewtopic.php?f=4&t=6223
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Thu Jul 30, 2020 11:30 pm
by BillG
The Poor Man's Linker experiment has gone well. The conversion of the run-time library to the new approach is done. In the foreseeable future, my Python library (currently 6502 only) will be converted in the same way; it really needs it.
The following program, the skeleton of a monitor or a debugger, compiles into a 6800 binary image a little under 2K bytes in size; it uses quite a bit but not all of the library code.
Code: Select all
10 PRINT '? ';
20 INPUT LINE A$
30 GOSUB 1000:REM Strip leading spaces from A$
40 B$=LEFT$(A$,1):A$=MID$(A$,2):GOSUB 1000:GOSUB 1100
50 IF B$ = 'D' THEN 10000
60 IF B$ = 'U' THEN 12000
90 IF B$ = 'Q' THEN END
95 PRINT 'Unrecognized command.':GOTO 10
1000 REM Strip leading spaces from A$
1010 IF ASC(' ') = ASC(A$) THEN A$=MID$(A$,2) ELSE RETURN
1020 GOTO 1010
1100 REM Convert B$ to upper case
1110 IF ASC('a') <= ASC(B$) AND ASC('z') >= ASC(B$) THEN B$=CHR$(ASC(B$)-32)
1120 RETURN
10000 REM DUMP
10001 print "DUMP ";a$:goto 10
12000 REM UNASSEMBLE
12001 print "UNASSEMBLE ";a$:goto 10
You may have noticed the ordering of "IF ASC(' ') = ASC(A$)" as a bit unusual. A single-pass compiler which generates code as it parses the source can do a better job if simple expressions which can be completely evaluated at compile time are on the left while things which must wait until run time are postponed as long as possible. The opposite "IF ASC(A$) = ASC(' ')" gets the first character from the string, puts it into a temporary variable, then does the comparison because without lookahead, the compiler does not know that a constant follows.
Since what I thought was source code for the FLEX BASIC interpreter turned out to be something else, SWTPC BASIC instead of TSC BASIC, I will be building a version of this compiler to generate 6502 code for TSC BASIC programs. I am just starting to reverse engineer the FLEX BASIC and Extended BASIC interpreters and thus cannot commit to doing anything with them at this time.
For comparison, here is some code from the two compilers...
The 6502 code generated by the compiler:
Code: Select all
00108 ; 120 C = A * (B + 1)
0B26 00109 L00120:
00110 ifdef __TRACE
00111 ldx #<120
00112 lda #>120
00113 jsr Trace
00114 endif
00115 ifdef __ATLIN
00116 ldx #<L00120
00117 stx ResLn_
00118 ldx #>L00120
00119 stx ResLn_+1
00120 endif
00121
0B26 18 [2] 00122 clc
0B27 AD 0F39 [4] 00123 lda B_
0B2A 69 01 [2] 00124 adc #<1
0B2C AA [2] 00125 tax
0B2D AD 0F3A [4] 00126 lda B_+1
0B30 69 00 [2] 00127 adc #>1
0B32 AC 0F37 [4] 00128 ldy A_
0B35 84 14 [3] 00129 sty Int0
0B37 AC 0F38 [4] 00130 ldy A_+1
0B3A 84 15 [3] 00131 sty Int0+1
0B3C 20 0D30 [6] 00132 jsr IMul
0B3F 8E 0F3B [4] 00133 stx C_
0B42 8D 0F3C [4] 00134 sta C_+1
The 6800 code generated by the compiler:
Code: Select all
00083 * 120 C = A * (B + 1)
0119 00084 L00120
00085 ifdef __TRACE
00086 ldx #120
00087 jsr Trace
00088 endif
00089 ifdef __ATLIN
00090 ldx #L00120
00091 stx ResLn_
00092 endif
00093
0119 C6 01 [2] 00094 ldab #1
011B 4F [2] 00095 clra
011C FB 0435 [4] 00096 addb B_+1
011F B9 0434 [4] 00097 adca B_
0122 FE 0432 [5] 00098 ldx A_
0125 BD 0297 [9] 00099 jsr IMul
0128 F7 0437 [5] 00100 stab C_+1
012B B7 0436 [5] 00101 staa C_
The 6502 multiply subroutine:
Code: Select all
. 00730 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
. 00731 ;
. 00732 ; IMul - Multiply integers
. 00733 ;
. 00734 ; Input:
. 00735 ; A:X = one number
. 00736 ; Int0 = the other number
. 00737 ;
. 00738 ; Output:
. 00739 ; A:X = the product
. 00740 ;
. 00741
.0D2C 00742 IMulB rmb 2 ; Operand
.0D2E 00743 IMulC rmb 1 ; Bits left
.0D2F 00744 IMulS rmb 1 ; Sign of the product
. 00745
.0D30 00746 IMul:
.0D30 A0 00 [2] 00747 ldy #0 ; Clear sign of product
.0D32 8C 0D2F [4] 00748 sty IMulS
. 00749
.0D35 C9 00 [2] 00750 cmp #0 ; Is first number negative?
.0D37 10 10 (0D49) [2/3] 00751 bpl IMul1 ; No
. 00752
.0D39 EE 0D2F [6] 00753 inc IMulS ; Update sign of product
. 00754
.0D3C 49 FF [2] 00755 eor #$FF ; Negate the number
.0D3E A8 [2] 00756 tay
.0D3F 8A [2] 00757 txa
.0D40 49 FF [2] 00758 eor #$FF
.0D42 18 [2] 00759 clc
.0D43 69 01 [2] 00760 adc #1
.0D45 AA [2] 00761 tax
.0D46 98 [2] 00762 tya
.0D47 69 00 [2] 00763 adc #0
. 00764
.0D49 00765 IMul1:
.0D49 8E 0D2C [4] 00766 stx IMulB ; Save the number
.0D4C 8D 0D2D [4] 00767 sta IMulB+1
. 00768
.0D4F A5 15 [3] 00769 lda Int0+1 ; Is the other number negative?
.0D51 10 10 (0D63) [2/3] 00770 bpl IMul2 ; No
. 00771
.0D53 EE 0D2F [6] 00772 inc IMulS ; Update sign of product
. 00773
.0D56 A9 00 [2] 00774 lda #0 ; Negate the other number
.0D58 38 [2] 00775 sec
.0D59 E5 14 [3] 00776 sbc Int0
.0D5B 85 14 [3] 00777 sta Int0
.0D5D A9 00 [2] 00778 lda #0
.0D5F E5 15 [3] 00779 sbc Int0+1
.0D61 85 15 [3] 00780 sta Int0+1
. 00781
.0D63 00782 IMul2:
.0D63 A9 10 [2] 00783 lda #16 ; 16 bits to multiply
.0D65 8D 0D2E [4] 00784 sta IMulC
. 00785
.0D68 A9 00 [2] 00786 lda #0 ; Clear product
.0D6A A8 [2] 00787 tay
. 00788
.0D6B 00789 IMul3:
.0D6B 4E 0D2D [6] 00790 lsr IMulB+1 ; Shift number right
.0D6E 6E 0D2C [6] 00791 ror IMulB
.0D71 90 09 (0D7C) [2/3] 00792 bcc IMul4 ; Skip add if low bit was clear
. 00793
.0D73 18 [2] 00794 clc ; Add number to product
.0D74 65 14 [3] 00795 adc Int0
.0D76 AA [2] 00796 tax
.0D77 98 [2] 00797 tya
.0D78 65 15 [3] 00798 adc Int0+1
.0D7A A8 [2] 00799 tay
.0D7B 8A [2] 00800 txa
. 00801
.0D7C 00802 IMul4:
.0D7C 06 14 [5] 00803 asl Int0 ; Shift the other number left
.0D7E 26 15 [5] 00804 rol Int0+1
. 00805
.0D80 CE 0D2E [6] 00806 dec IMulC ; One fewer bit to do
.0D83 D0 E6 (0D6B) [2/3] 00807 bne IMul3 ; More?
. 00808
.0D85 4E 0D2F [6] 00809 lsr IMulS ; Is product negative?
.0D88 90 0E (0D98) [2/3] 00810 bcc IMul5 ; No
. 00811
.0D8A 49 FF [2] 00812 eor #$FF ; Negate the product
.0D8C 18 [2] 00813 clc
.0D8D 69 01 [2] 00814 adc #1
.0D8F AA [2] 00815 tax
.0D90 98 [2] 00816 tya
.0D91 49 FF [2] 00817 eor #$FF
.0D93 69 00 [2] 00818 adc #0
. 00819
.0D95 4C 0D9A [3] 00820 jmp IMul6
. 00821
.0D98 00822 IMul5:
.0D98 AA [2] 00823 tax ; Product goes in A:X
.0D99 98 [2] 00824 tya
. 00825
.0D9A 00826 IMul6:
.0D9A 60 [6] 00827 rts
The 6800 multiply subroutine:
Code: Select all
. 00560 ******************************************************************************
. 00561 *
. 00562 * IMul - Multiply integers
. 00563 *
. 00564 * Input:
. 00565 * A:B = one number
. 00566 * X = the other number
. 00567 *
. 00568 * Output:
. 00569 * A:B = the product
. 00570 *
.0293 00571 IMulB rmb 2 ; Operand
.0295 00572 IMulC rmb 1 ; Bits left
.0296 00573 IMulS rmb 1 ; Sign of the product
. 00574
.0297 00575 IMul
.0297 7F 0296 [6] 00576 clr IMulS ; Clear sign of product
. 00577
.029A DF 02 [5] 00578 stx Int0 ; Save second number
. 00579
.029C 4D [2] 00580 tsta ; Is first number negative
.029D 2A 07 (02A6) [4] 00581 bpl IMul1 ; No
. 00582
.029F 7C 0296 [6] 00583 inc IMulS ; Update sign of product
. 00584
.02A2 40 [2] 00585 nega ; Negate the number
.02A3 50 [2] 00586 negb
.02A4 82 00 [2] 00587 sbca #0
. 00588
.02A6 00589 IMul1
.02A6 B7 0293 [5] 00590 staa IMulB ; Save the number
.02A9 F7 0294 [5] 00591 stab IMulB+1
. 00592
.02AC 96 02 [3] 00593 ldaa Int0 ; Is the other number negative?
.02AE 2A 0E (02BE) [4] 00594 bpl IMul2 ; No
. 00595
.02B0 7C 0296 [6] 00596 inc IMulS ; Update sign of product
. 00597
.02B3 73 0002 [6] 00598 com Int0 ; Negate the other number
.02B6 70 0003 [6] 00599 neg Int0+1
.02B9 25 03 (02BE) [4] 00600 bcs IMul2
.02BB 7A 0002 [6] 00601 dec Int0
. 00602
.02BE 00603 IMul2
.02BE 86 10 [2] 00604 ldaa #16 ; 16 bits to multiply
.02C0 B7 0295 [5] 00605 staa IMulC
. 00606
.02C3 4F [2] 00607 clra ; Clear product
.02C4 5F [2] 00608 clrb
. 00609
.02C5 00610 IMul3
.02C5 74 0293 [6] 00611 lsr IMulB ; Shift number right
.02C8 76 0294 [6] 00612 ror IMulB+1
.02CB 24 04 (02D1) [4] 00613 bcc IMul4 ; Skip add if low bit was clear
. 00614
.02CD DB 03 [3] 00615 addb Int0+1 ; Add number to product
.02CF 99 02 [3] 00616 adca Int0
. 00617
.02D1 00618 IMul4
.02D1 78 0003 [6] 00619 asl Int0+1 ; Shift the other number left
.02D4 79 0002 [6] 00620 rol Int0
. 00621
.02D7 7A 0295 [6] 00622 dec IMulC ; One fewer bit to do
.02DA 26 E9 (02C5) [4] 00623 bne IMul3 ; More?
. 00624
.02DC 74 0296 [6] 00625 lsr IMulS ; Is the product negative?
.02DF 24 04 (02E5) [4] 00626 bcc IMul5 ; No
. 00627
.02E1 40 [2] 00628 nega ; Negate the product
.02E2 50 [2] 00629 negb
.02E3 82 00 [2] 00630 sbca #0
. 00631
.02E5 00632 IMul5
.02E5 39 [5] 00633 rts
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Fri Jul 31, 2020 3:05 am
by barrym95838
I see several opportunities for improvement lurking in your code, but it might be better for us to keep our eyes on the big picture and save the fine-tuning for later.
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Fri Jul 31, 2020 7:47 am
by BillG
In the multiplication subroutines or the generated code? Changes to the latter may be easier made sooner than later.
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Fri Jul 31, 2020 8:25 am
by BillG
The only thing I see is the opportunity to change register usage in the inner loop and get rid of the two instructions at IMul5 plus the jmp around it in the 6502 multiply subroutine.
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Sun Aug 16, 2020 12:19 pm
by BillG
Reverse engineering of the TSC FLEX BASIC interpreters is not going well. I have real doubts about being able to build a compatible interpreter for the 6502 any time soon. Source code is available for the SWTPC interpreter, but it is not the same.
I was reminded of the Lucidata Pascal compiler. It generates an interpreted P-code instead of native machine code. The compiler is also provided in P-code form. What this means is that if a compatible interpreter can be implemented on the 6502, the compiler comes along for the ride. The interpreter is not very big, in fact, it is substantially smaller than BASIC. This is potentially going to be the next native language system to be available after the assembler.
Which brings up my toy Pascal compiler. I just did some work on the type system to allow single-byte variables, signed, unsigned and character. These are important for efficiency on an 8-bit system. The following is some code testing these features:
Code: Select all
00080 ; 00001 program Test;
00081 ; 00002
00082 ; 00003 var
00083 ; 00004 B : byte;
00084 ; 00005 B2 : byte;
00085 ; 00006 Ch : char;
00086 ; 00007 Ch2 : char;
00087 ; 00008 I : integer;
00088 ; 00009 S : shortint;
00089 ; 00010 S2 : shortint;
00090 ; 00011 W : word;
00091 ; 00012
00092 ; 00013 begin
00093 ; 00014 S := -1;
0B09 A9 FF [2] 00094 lda #-1
0B0B 8D 0F3C [4] 00095 sta S_
00096 ; 00015 I := S;
0B0E AE 0F3C [4] 00097 ldx S_
0B11 8A [2] 00098 txa
0B12 09 7F [2] 00099 ora #$7F
0B14 30 02 (0B18) [2/3] 00100 bmi 2f
0B16 A9 00 [2] 00101 lda #0
0B18 00102 2:
0B18 8E 0F3A [4] 00103 stx I_
0B1B 8D 0F3B [4] 00104 sta I_+1
00105 ; 00016 W := S;
0B1E AE 0F3C [4] 00106 ldx S_
0B21 8A [2] 00107 txa
0B22 09 7F [2] 00108 ora #$7F
0B24 30 02 (0B28) [2/3] 00109 bmi 2f
0B26 A9 00 [2] 00110 lda #0
0B28 00111 2:
0B28 8E 0F3D [4] 00112 stx W_
0B2B 8D 0F3E [4] 00113 sta W_+1
00114 ; 00017 writeln(I, ' ', W);
0B2E AE 0F3A [4] 00115 ldx I_
0B31 AD 0F3B [4] 00116 lda I_+1
0B34 20 0D86 [6] 00117 jsr WriteInteger
0B37 A9 20 [2] 00118 lda #32
0B39 20 0DBF [6] 00119 jsr PUTCHR
0B3C AE 0F3D [4] 00120 ldx W_
0B3F AD 0F3E [4] 00121 lda W_+1
0B42 20 0D8C [6] 00122 jsr WriteWord
0B45 20 0DCC [6] 00123 jsr PCRLF
00124 ; 00018
00125 ; 00019 B := S;
0B48 AD 0F3C [4] 00126 lda S_
0B4B 8D 0F39 [4] 00127 sta B_
00128 ; 00020 I := B;
0B4E AE 0F39 [4] 00129 ldx B_
0B51 A9 00 [2] 00130 lda #0
0B53 8E 0F3A [4] 00131 stx I_
0B56 8D 0F3B [4] 00132 sta I_+1
00133 ; 00021 W := B;
0B59 AE 0F39 [4] 00134 ldx B_
0B5C A9 00 [2] 00135 lda #0
0B5E 8E 0F3D [4] 00136 stx W_
0B61 8D 0F3E [4] 00137 sta W_+1
00138 ; 00022 writeln(I, ' ', W);
0B64 AE 0F3A [4] 00139 ldx I_
0B67 AD 0F3B [4] 00140 lda I_+1
0B6A 20 0D86 [6] 00141 jsr WriteInteger
0B6D A9 20 [2] 00142 lda #32
0B6F 20 0DBF [6] 00143 jsr PUTCHR
0B72 AE 0F3D [4] 00144 ldx W_
0B75 AD 0F3E [4] 00145 lda W_+1
0B78 20 0D8C [6] 00146 jsr WriteWord
0B7B 20 0DCC [6] 00147 jsr PCRLF
00148 ; 00023
00149 ; 00024 S := 20;
0B7E A9 14 [2] 00150 lda #20
0B80 8D 0F3C [4] 00151 sta S_
00152 ; 00025 S2 := S;
0B83 AD 0F3C [4] 00153 lda S_
0B86 8D 0F40 [4] 00154 sta S2_
00155 ; 00026 S2 := S2 + S;
0B89 18 [2] 00156 clc
0B8A AD 0F40 [4] 00157 lda S2_
0B8D 6D 0F3C [4] 00158 adc S_
0B90 8D 0F40 [4] 00159 sta S2_
00160 ; 00027 writeln(S, ' ', S2);
0B93 AD 0F3C [4] 00161 lda S_
0B96 20 0D30 [6] 00162 jsr WriteShortint
0B99 A9 20 [2] 00163 lda #32
0B9B 20 0DBF [6] 00164 jsr PUTCHR
0B9E AD 0F40 [4] 00165 lda S2_
0BA1 20 0D30 [6] 00166 jsr WriteShortint
0BA4 20 0DCC [6] 00167 jsr PCRLF
00168 ; 00028
00169 ; 00029 B := 20;
0BA7 A9 14 [2] 00170 lda #20
0BA9 8D 0F39 [4] 00171 sta B_
00172 ; 00030 B2 := B;
0BAC AD 0F39 [4] 00173 lda B_
0BAF 8D 0F38 [4] 00174 sta B2_
00175 ; 00031 B2 := B2 + B;
0BB2 18 [2] 00176 clc
0BB3 AD 0F38 [4] 00177 lda B2_
0BB6 6D 0F39 [4] 00178 adc B_
0BB9 8D 0F38 [4] 00179 sta B2_
00180 ; 00032 writeln(B, ' ', B2);
0BBC AD 0F39 [4] 00181 lda B_
0BBF 20 0D36 [6] 00182 jsr WriteByte
0BC2 A9 20 [2] 00183 lda #32
0BC4 20 0DBF [6] 00184 jsr PUTCHR
0BC7 AD 0F38 [4] 00185 lda B2_
0BCA 20 0D36 [6] 00186 jsr WriteByte
0BCD 20 0DCC [6] 00187 jsr PCRLF
00188 ; 00033
00189 ; 00034 I := 32;
0BD0 A2 20 [2] 00190 ldx #32
0BD2 A9 00 [2] 00191 lda #0
0BD4 8E 0F3A [4] 00192 stx I_
0BD7 8D 0F3B [4] 00193 sta I_+1
00194 ; 00035 writeln(chr(I + I));
0BDA 18 [2] 00195 clc
0BDB AD 0F3A [4] 00196 lda I_
0BDE 6D 0F3A [4] 00197 adc I_
0BE1 20 0DBF [6] 00198 jsr PUTCHR
0BE4 20 0DCC [6] 00199 jsr PCRLF
00200 ; 00036
00201 ; 00037 Ch := 'A';
0BE7 A9 41 [2] 00202 lda #65
0BE9 8D 0F41 [4] 00203 sta CH_
00204 ; 00038 Ch2 := Ch;
0BEC AD 0F41 [4] 00205 lda CH_
0BEF 8D 0F3F [4] 00206 sta CH2_
00207 ; 00039 writeln(Ch, chr(ord(Ch)+1))
0BF2 AD 0F41 [4] 00208 lda CH_
0BF5 20 0DBF [6] 00209 jsr PUTCHR
0BF8 18 [2] 00210 clc
0BF9 AD 0F41 [4] 00211 lda CH_
0BFC 69 01 [2] 00212 adc #1
0BFE 20 0DBF [6] 00213 jsr PUTCHR
0C01 20 0DCC [6] 00214 jsr PCRLF
00215 ; 00040 end.
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Sun Aug 16, 2020 5:08 pm
by barrym95838
In the multiplication subroutines or the generated code? Changes to the latter may be easier made sooner than later.
Sorry for not seeing this sooner. I would suggest checking out what the redoubtable Woz did over 43 years ago by going
here and searching for
MULPM. It's not a drop-in replacement for you, but it should give you an idea for the possibilities. Unless you're Bruce C. or Charlie H. (or me on a very lucky day) vintage Woz subroutines are hardly ever beatable for size, if that's what flips your switch.
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Sun Aug 16, 2020 5:40 pm
by BigEd
Amusing that Woz' assembler didn't have opcode $76 (ROR zp,X)
Code: Select all
FB60: 20 A4 FB 522 MULPM JSR MD1 ;ABS VAL OF AC AUX
FB63: A0 10 523 MUL LDY #$10 ;INDEX FOR 16 BITS
FB65: A5 50 524 MUL2 LDA ACL ;ACX * AUX + XTND
FB67: 4A 525 LSR ; TO AC, XTND
FB68: 90 0C 526 BCC MUL4 ;IF NO CARRY,
FB6A: 18 527 CLC ; NO PARTIAL PROD.
FB6B: A2 FE 528 LDX #$FE
FB6D: B5 54 529 MUL3 LDA XTNDL+2,X ;ADD MPLCND (AUX)
FB6F: 75 56 530 ADC AUXL+2,X ; TO PARTIAL PROD
FB71: 95 54 531 STA XTNDL+2,X ; (XTND)
FB73: E8 532 INX
FB74: D0 F7 533 BNE MUL3
FB76: A2 03 534 MUL4 LDX #$03
FB78: 76 535 MUL5 DFB $76
FB79: 50 536 DFB $50
FB7A: CA 537 DEX
FB7B: 10 FB 538 BPL MUL5
FB7D: 88 539 DEY
FB7E: D0 E5 540 BNE MUL2
FB80: 60 541 RTS
...
FBA4: A0 00 561 MD1 LDY #$00 ;ABS VAL OF AC, AUX
FBA6: 84 2F 562 STY SIGN ; WITH RESULT SIGN
FBA8: A2 54 563 LDX #AUXL ; IN LSB OF SIGN.
FBAA: 20 AF FB 564 JSR MD3
FBAD: A2 50 565 LDX #ACL
FBAF: B5 01 566 MD3 LDA LOC1,X ;X SPECIFIES AC OR AUX
FBB1: 10 0D 567 BPL MDRTS
FBB3: 38 568 SEC
FBB4: 98 569 TYA
FBB5: F5 00 570 SBC LOC0,X ;COMPL SPECIFIED REG
FBB7: 95 00 571 STA LOC0,X ; IF NEG.
FBB9: 98 572 TYA
FBBA: F5 01 573 SBC LOC1,X
FBBC: 95 01 574 STA LOC1,X
FBBE: E6 2F 575 INC SIGN
FBC0: 60 576 MDRTS RTS
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Sun Aug 16, 2020 6:43 pm
by BillG
I would suggest checking out what the redoubtable Woz did over 43 years ago by going
here and searching for
MULPM. It's not a drop-in replacement for you, but it should give you an idea for the possibilities. Unless you're Bruce C. or Charlie H. (or me on a very lucky day) vintage Woz subroutines are hardly ever beatable for size, if that's what flips your switch.
Thanks for that link. There is much information in that document though the formatting is painful to read.
For good and bad, I have seldom had to code for size and that is not one of my skills.
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Sun Aug 16, 2020 6:45 pm
by BillG
Amusing that Woz' assembler didn't have opcode $76 (ROR zp,X)
Could it be because the ROR instruction was defective on early versions of the processor?
https://en.wikipedia.org/wiki/MOS_Techn ... and_quirks
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Sun Aug 16, 2020 6:57 pm
by BigEd
Sounds likely!
Re: FLEX for the 6502 or building a compatible operating sys
Posted: Sun Aug 16, 2020 7:28 pm
by barrym95838
Amusing that Woz' assembler didn't have opcode $76 (ROR zp,X)
As you well know, this assembler was a notable step up from his
previous one. Woz was too busy churning out kilobyte after kilobyte of size-optimized code at that time, and wasn't going to let anything put a damper on his productivity.