BillG
-
Content Count
62 -
Joined
Posts posted by BillG
-
-
You can PERFORM something THROUGH something else, so they are not like standard subroutines.
-
2
-
-
Not very big right now. The only things I have working is DISPLAY and PERFORM.
PERFORM is rather complicated if you know COBOL.
-
5 minutes ago, TheBF said:What language are your compilers for?
Python on the 6502
BASIC on the 6502, 6800 and AVR
Pascal on the 6502, 6800, 8080, AVR, 68000 (maybe 9900)
COBOL on the 6800 (started as a joke)
-
I guess my cover is blown, so...
I have been working on compilers for the 6502 and 680x among other processors. I just started to attempt code generation for the 9900.
It appears that adding a value from 1 to 6 to a variable can be optimized; likewise for subtracting a value from 1 to 6.
-
2
-
-
Please reference Chapter 4 of https://ia800307.us.archive.org/10/items/9900MicroprocessorSeriesFamilySystemsDesignDataBook/TexasInstruments9900MicroprocessorSeriesFamilySystemsDesign_text.pdf
Starting with page 4-89 and particularly pages 4-91, 4-92, 4-95 and 4-100
The following code sequence appears to take 29 machine cycles:
mov @Var,R0 ; 11 cycles ai R0,2 ; 7 cycles mov R0,@Var ; 11 cycles
While this only takes 9:
inct @Var ; 9 cycles
Am I correct? If so, there would appear to be plenty of opportunities for a compiler to optimize code like this.
-
1
-
-
4 hours ago, apersson850 said:So no, a native code Pascal compiler isn't what a TI 99/4A needs. For computers with larger memories, yes. But not for this little machine.
It's identifying some critical code and re-writing that in assembly that you can do for this machine.
It would depend upon whether you want to create a large program or a small and fast one.
-
1
-
-
Sure it does. Use array of char and ord() to "convert" to integer.
-
On 8/24/2020 at 6:06 AM, Vorticon said:The array tmpboard, while declared as [11..88] of integer
What kind of information are you keeping in that array? Namely, will bytes work rather than integers?
It may be more efficient for the compiler to generate access to bytes in the array by avoiding a left shift of the index to address integers.
-
3 hours ago, Vorticon said:I have a little puzzler I'd like perhaps some insight on. Can someone please tell me why the following code does not work
if turn>2 then begin if ((i-11) in validloc) and (tmpboard[i-11]=6) then cscore:=cscore+30; end;whereas if I reformat it as below the error goes away? Makes little sense to me as the inner begin/end pair should not be needed....
if turn>2 then begin if ((i-11) in validloc) then begin if (tmpboard[i-11]=6) then cscore:=cscore+30; end; end;As a background, the index of the tmpboard array has a range of 11 to 88 which is contained in the validloc set. So if i-11 goes out of range, then the second half of the if statement in the first code snippet should not get executed, and yet it does...
Unlike some languages like C, standard Pascal does not specify the order in which components of an expression are evaluated within an if statement.
By separating the two, you are forcing the skipping of the second subexpression when the first is not true. I cannot say why the result - whether 30 is added to cscore - is different depending on the order of evaluation. The problem usually manifests itself in protected access environments when the out-of-bounds array access faults - the 99/4 is not.
Borland Turbo Pascal allows choosing short-circuit evaluation in which the second part is skipped if the first determines the result.
-
1
-
-
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:
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.
-
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.
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 10You 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:
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:
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:
. 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:
. 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
-
The text editor code has been difficult; I can only stand to work on it a bit at a time.
The 6800 version keeps values in the X register for long stretches of code, sometimes across several subroutines. I am about to give up trying to keep it in 6502 registers even part of the time, but to declare RegX, a 2-byte variable in the zero page, and copy values into and out of it as the 6800 loads and stores X. Addresses already have to be stored in the zero page to access memory. It will not be as efficient, but the code will be somewhat clearer; this program really needs that.
So far, the following functionality is complete:
loading a file
saving a file
text buffer management
Print command
Insert command
Delete command
Renumber command
Overlay command
Find commandThe Copy command has been coded, but it does not work. When that is done, the Move command should be easy as it does a copy followed by a delete. I would guess we are somewhat past the halfway mark.
During breaks, I have been working on assemblers.
First, I added the SET directive to the 6800 ASMB. It is like EQU, but a label may be assigned a value more than once.
I have always liked the local labels in RELASMB, the 6809 relocatable assembler, and wished that ASMB implemented them.
Local labels work like this: a one or two digit number in the label field is considered to be a local label. It is referenced by stating the number followed by a "b" or "f" to designate whether to search for the nearest occurrence of the number before or following the current line. Note that it is not possible to find a local label on the current line. For example:
2 ; This is the target for "2b" 2 beq target ; The label for this line cannot be specified 2 ; This is the target for "2f"
Advantages of a local label include doing away with the need to come up with meaningful and unique names for short, trivial branches and a local label uses less memory than a regular symbol.
A web search for local label uncovered no prevalent standard, but a number with a "b" or "f" suffix is a very common form.
I will put a seemingly arbitrary limit on local labels: the number may not consist of only "0" and "1" digits. Why? ASMB 6800 accepts binary numbers in both the %xx and xxb forms. Something like "1b" is ambiguous.
I had been initially tempted to limit the reference of local labels to relative branch instructions to prevent people writing FORTRANish code, but RELASMB does not have that restriction. And it is convenient to be able to do something like the following:
ldx #2f ; Print error message jsr PSTRNG rts 2 fcc "Operand expected." fcb 4
I am currently implementing local labels in my 6502 cross assembler. Should that go well, the capability will be migrated to the 6800 and 6809 assemblers. Then I will implement it in ASMB 6800; ASMB 6502 will inherit that functionality.
-
1
-
-
The Z80 is performing an essential function - refreshing the DRAM...
-
This project is now two months old.
The FLEX file system (File Management System or FMS) is still lacking the code for writing random access files until I can come up with a good way to test it. I may go ahead and write the code but leave it disconnected to get an idea how big it is likely to be.
The FLEX user interface portion is feature complete except for background printing. Again, I may write the code to find out how large it will be. The error message reporting mechanism is complete.
There was little progress on the Utility Command Set this month. The SAVE utility has been written, but not thoroughly tested.
The 6800 assembler now runs on the 6502 as a cross assembler. To help test it, I have started implementing the text editor. It can currently create a text file and make some simple edits to it. The editor is definitely more difficult code than the assembler has been.
The current system memory map is:
$0000..$00FF - Zero page, locations at $12 and above are free for application programs to use
$0100..$017F - FLEX line buffer
$0180..$01FF - Stack
$0200..$033F - FLEX entry points, variables and printer driver
$0340..$047F - System File Control Block
$0480..$0AFF - FLEX Utility Command Space
$0B00..MEMEND - User memorySomewhere above that is about 6K of FLEX itself.
It is time to start trying to freeze the memory organization. I am considering making a somewhat radical change to move the public portions (entry points, variables, Utility Command Space) from $200 up to $2000. Why? Doing this will make it possible for a KIM-1 or clone with a expanded RAM and a serial port to run FLEX. The operating system itself can reside from $200 to $2000 on systems which allow that and at the top of user memory otherwise. Because the binary file format consists of a collection of separate chunks, pieces of the system can potentially be built to load into several disjoint places where memory is available.
Another decision is whether the system should reserve a part of the lower or upper end of the zero page.
The important part now is to determine where the public portions are located. This is where I need your input as to what your particular system requires and allows. It may not be possible to please everyone, but the main goal is to have one version of the utilities and application programs which work on all supported platforms.
-
I am now able to cross assemble most inherent 6800 instructions.
While 6800 binary files currently have no value on a 6502, this means that a large part of the fundamental infrastructure of the assembler is working.
Next up, evaluating expressions...
-
On 5/16/2020 at 4:33 PM, BillG said:On further examination, the 6800 version can be made substantially faster than the 6502 version by completely unrolling the loop but the code is almost twice as big. (The XSUB8 subroutine is also used elsewhere, so it cannot be eliminated in the process.) A small speed gain by a similar transformation of the 6502 version does not justify the massive increase in code size required.
I have to partially retract that statement. Somehow, I managed to forget that the 6800 only has one index register; the X register must to be ping ponged between I and J. Still, completely unrolling that loop makes the 6800 code about as fast as the 6502 version, but with much bigger code size. The result would look something like this:
0100 DE 00 [4] 00006 ldx I 00007 * 0102 E6 00 [5] 00008 ldab 0,X 0104 DE 02 [4] 00009 ldx J 0106 A6 00 [5] 00010 ldaa 0,X 0108 E7 00 [6] 00011 stab 0,X 010A DE 00 [4] 00012 ldx I 010C A7 00 [6] 00013 staa 0,X 00014 * 010E E6 01 [5] 00015 ldab 1,X 0110 DE 02 [4] 00016 ldx J 0112 A6 01 [5] 00017 ldaa 1,X 0114 E7 01 [6] 00018 stab 1,X 0116 DE 00 [4] 00019 ldx I 0118 A7 01 [6] 00020 staa 1,X etc.
There are two other service subroutines for the symbol table sorter.
CMPLBL compares two symbols, pointed to by the variables I and J. Note that the 6800 version uses a couple of temporary variables instead of modifying I and J, then fixing them after the loop is finished; this same approach would have made the exchange subroutine better. Completely unrolling the loop is again the fastest implementation.
The original 6800 code:
.154E DE 20 [4] 02922 CMPLBL LDX I .1550 DF 76 [5] 02923 STX XTEMP GET I INTO XTEMP .1552 DE 22 [4] 02924 LDX J .1554 DF 80 [5] 02925 STX XTEMP5 GET J INTO XTEMP5 .1556 C6 06 [2] 02926 LDAB #$06 SET COMPARE COUNT .1558 DE 76 [4] 02927 CMPLB1 LDX XTEMP .155A A6 00 [5] 02928 LDAA 0,X GET CHAR FROM I .155C 08 [4] 02929 INX .155D DF 76 [5] 02930 STX XTEMP .155F DE 80 [4] 02931 LDX XTEMP5 .1561 A1 00 [5] 02932 CMPA 0,X COMPARE WITH J CHAR .1563 26 06 (156B) [4] 02933 BNE CMPLB2 EXIT IF NOT EQUAL .1565 08 [4] 02934 INX .1566 DF 80 [5] 02935 STX XTEMP5 .1568 5A [2] 02936 DECB ELSE DECREMENT COUNT .1569 26 ED (1558) [4] 02937 BNE CMPLB1 LOOP UNTIL DONE .156B 39 [5] 02938 CMPLB2 RTS
The 6502 code:
.1981 04172 CMPLBL . 04173 ; LDX I . 04174 ; STX XTEMP ; GET I INTO XTEMP . 04175 ; LDX J . 04176 ; STX XTEMP5 ; GET J INTO XTEMP5 .1981 A0 00 [2] 04177 ldy #0 ; SET index .1983 04178 CMPLB1 ;LDX XTEMP .1983 B1 22 [5/6] 04179 lda (I),Y ; GET CHAR FROM I . 04180 ; INX . 04181 ; STX XTEMP . 04182 ; LDX XTEMP5 .1985 D1 24 [5/6] 04183 cmp (J),Y ; COMPARE WITH J CHAR .1987 D0 05 (198E) [2/3] 04184 bne CMPLB2 ; EXIT IF NOT EQUAL . 04185 ; INX . 04186 ; STX XTEMP5 . 04187 .1989 C8 [2] 04188 iny ; ELSE inCREMENT index .198A C0 06 [2] 04189 cpy #6 .198C D0 F5 (1983) [2/3] 04190 bne CMPLB1 ; LOOP UNTIL DONE . 04191 .198E 60 [6] 04192 CMPLB2 rts
PUSH pushes an address onto a software stack. This code is an even test which illustrates shortcomings in both processors. The 6800 does not provide easy access to the index register; this is corrected in the 6809. The 6502 does not provide an easy way to perform 16-bit arithmetic.
The original 6800 code:
.14B5 DF 80 [5] 02823 PUSH STX XTEMP5 PUT THE VALUE IN .14B7 DE 28 [4] 02824 LDX SRSP THE X REGISTER ONTO THE .14B9 96 80 [3] 02825 LDAA XTEMP5 SORT REQUEST STACK AND .14BB A7 00 [6] 02826 STAA 0,X UPDATE THE SORT REQUEST .14BD 08 [4] 02827 INX STACK POINTER .14BE 96 81 [3] 02828 LDAA XTEMP5+1 .14C0 A7 00 [6] 02829 STAA 0,X .14C2 08 [4] 02830 INX .14C3 DF 28 [5] 02831 STX SRSP .14C5 39 [5] 02832 RTS
The 6502 code:
.18AB 03977 PUSH . 03978 ; STX XTEMP5 ; PUT THE VALUE IN . 03979 ; LDX SRSP ; THE X REGISTER ONTO THE . 03980 ; LDAA XTEMP5 ; SORT REQUEST STACK AND . 03981 . 03982 ; Address in A:X .18AB A0 01 [2] 03983 ldy #1 .18AD 91 2A [6] 03984 sta (SRSP),Y ; UPDATE THE SORT REQUEST .18AF 88 [2] 03985 dey ; STACK POINTER .18B0 8A [2] 03986 txa .18B1 91 2A [6] 03987 sta (SRSP),Y . 03988 .18B3 18 [2] 03989 clc ; Update "stack pointer" .18B4 A5 2A [3] 03990 lda SRSP .18B6 69 02 [2] 03991 adc #2 .18B8 85 2A [3] 03992 sta SRSP .18BA A5 2B [3] 03993 lda SRSP+1 .18BC 69 00 [2] 03994 adc #0 .18BE 85 2B [3] 03995 sta SRSP+1 . 03996 .18C0 60 [6] 03997 rts
At this time, the symbol table sorter has been completely coded. Wish me luck as I begin to test it...
-
I have been known to say that programming a 6502 in assembly language is tedious compared with other processors. However, I just encountered an example in which the 6502 absolutely blows away the 6800.
One of my current projects is to convert the original 6800 FLEX assembler into a cross assembler running on the 6502.
Its symbol table is an array of eight byte entries: two bytes for the value and six for the symbol name. The symbol name is hashed to obtain an index into the array. In case of a collision, the name is rehashed up to a maximum of forty times to try other locations.
At the end of the assembly process, the table is packed and sorted, then the entries are printed in alphabetical order.
A subroutine swaps two entries addressed by the variables I and J, a task which the 6502 does with ease. It has just enough registers to avoid unnecessary memory accesses. I have observed in the past that the 6800 can be severely hampered by having only a single index register and that the 6502 addressing modes are particularly well suited for marching in lockstep through two parallel arrays.
The 6502 version of the subroutine consumes less than half the cycles while also being much smaller.
The 6502 code:
.1832 04047 XCHNG . 04048 ; LDX I .1832 A0 07 [2] 04049 ldy #8-1 ; SET COUNT and index . 04050 .1834 04051 XCHNG1 ;PSHB ; SAVE COUNT .1834 B1 22 [5/6] 04052 lda (I),Y ; GET CHAR FROM I .1836 AA [2] 04053 tax ; Stash I[Y] . 04054 ; STX I . 04055 ; LDX J .1837 B1 24 [5/6] 04056 lda (J),Y ; GET CHAR FROM J .1839 91 22 [6] 04057 sta (I),Y ; Replace in I . 04058 ; INX . 04059 ; STX J ; SET NEW J . 04060 ; LDX I .183B 8A [2] 04061 txa ; Recover I[Y] .183C 91 24 [6] 04062 sta (J),Y ; Replace in J . 04063 ; INX . 04064 . 04065 ; PULB ; RESTORE COUNT . 04066 .183E 88 [2] 04067 dey ; DECREMENT IT .183F 10 F3 (1834) [2/3] 04068 bpl XCHNG1 ; LOOP IF NOT -1TH BYTE . 04069 . 04070 ; BSR XSUB8 ; FIX I POINTER . 04071 ; STX I . 04072 ; LDX J . 04073 ; BSR XSUB8 ; FIX J POINTER . 04074 ; STX J . 04075 .1841 60 [6] 04076 rts
The original 6800 code:
.151F 09 [4] 02889 XSUB8 DEX DECREMENT X BY 8 .1520 09 [4] 02890 DEX .1521 09 [4] 02891 DEX .1522 09 [4] 02892 DEX .1523 09 [4] 02893 DEX .1524 09 [4] 02894 DEX .1525 09 [4] 02895 DEX .1526 09 [4] 02896 DEX .1527 39 [5] 02897 RTS . 02898 * .1528 DE 20 [4] 02899 XCHNG LDX I .152A C6 08 [2] 02900 LDAB #$08 SET COUNT .152C 37 [4] 02901 XCHNG1 PSHB SAVE COUNT .152D E6 00 [5] 02902 LDAB 0,X GET CHAR FROM I .152F DF 20 [5] 02903 STX I .1531 DE 22 [4] 02904 LDX J .1533 A6 00 [5] 02905 LDAA 0,X GET CHAR FROM J .1535 E7 00 [6] 02906 STAB 0,X REPLACE WITH I CHAR .1537 08 [4] 02907 INX .1538 DF 22 [5] 02908 STX J SET NEW J .153A DE 20 [4] 02909 LDX I .153C A7 00 [6] 02910 STAA 0,X REPLACE WITH J CHAR .153E 08 [4] 02911 INX .153F 33 [4] 02912 PULB RESTORE COUNT .1540 5A [2] 02913 DECB DECREMENT IT .1541 26 E9 (152C) [4] 02914 BNE XCHNG1 LOOP IF NOT 8TH BYTE .1543 8D DA (151F) [8] 02915 BSR XSUB8 FIX I POINTER .1545 DF 20 [5] 02916 STX I .1547 DE 22 [4] 02917 LDX J .1549 8D D4 (151F) [8] 02918 BSR XSUB8 FIX J POINTER .154B DF 22 [5] 02919 STX J .154D 39 [5] 02920 RTS
On further examination, the 6800 version can be made substantially faster than the 6502 version by completely unrolling the loop but the code is almost twice as big. (The XSUB8 subroutine is also used elsewhere, so it cannot be eliminated in the process.) A small speed gain by a similar transformation of the 6502 version does not justify the massive increase in code size required.
-
10 hours ago, BillG said:I am still investigating making the reformatting a selectable option.
A simple and elegant solution presented itself after I slept on it and came back to look at the problem from outside of the box: format each line of code, or not, in this case, as if the whole thing was a comment.
This is ideal for those of you on the spaces side of the Great Spaces versus TABs Debate. FLEX already provides automagic space compression on disk as sequences of two or more spaces (up to 255) are replaced with two bytes: a tag and a count. You may now make your code listings look exactly like you want.
Despite having this feature, many early FLEX programmers got into the unusual habit of separating fields in their assembly language programs with a single space and relying on the assembler to make listings legible.
Those on the TAB side were left out because the tag byte was, you guessed it, the hard TAB character. FLEX text files cannot contain hard TABs the way the tools were configured. Editors responded to the TAB key by inserting an appropriate number of spaces.
-
On 5/6/2020 at 9:00 PM, BillG said:* enhance the existing 6800 assembler to add features such as conditional assembly directives
I dove headlong into the assembler. Implementing conditional assembly does not initially appear to be very easy.
So to learn the code, I made a few changes to fix some things which have always bothered me about this assembler:
* The assembler does not allow placing a colon after a label. It now allows but does not require it.
* The assembler distinguishes between upper and lower case in symbols. That is now a selectable option.
* The assembler reformats the source code when it generates a listing. It originally printed "ldaa" as "lda a"; it now preserves both forms of the mnemonic as written. I am still investigating making the reformatting a selectable option.
-
This is a bit of a one month progress report.
The FLEX file system (File Management System or FMS) is feature complete except for the portions dealing with the creation, reading and writing of random access files. FLEX stores data on disk as a linked list of sectors. Reading or writing an arbitrary location in a file is not a simple arithmetic calculation; a naive implementation would have to read every sector of the file to follow the list until the needed sector is found. To solve this problem, creating a random file adds two special sectors which contain the addresses of the sectors in the file as they are allocated. Reading a byte from random location in a file requires first reading this sector map then the sector.
The FLEX user interface is feature complete except for enhanced error reporting and background printing. When a random file named ERRORS.SYS is present, its contents is used to present a meaningful error message instead of an error code number. This capability is dependent upon FMS random access file support. Background printing is an option which requires a source of periodic interrupts. I have not investigated this feature very much yet; there are hooks for it in various parts of the system.
The third leg of the FLEX system triad is the Utility Command Set, a collection of small programs on disk which provide a large majority of the user commands. The following commands have been implemented:
ASN
BUILD
CAT
DATE
DELETE
JUMP
LINK
LIST
RENAME
TTYSET
VERIFY
VERSIONleaving these yet to be implemented:
APPEND
COPY
EXEC
I
NEWDISK
O
P
PRINT
QCHECK
SAVE
XOUTThe bootstrap loaders work so the operating system can be loaded from a disk image.
The system total so far is about 9K bytes of machine code. That is an average of around 300 bytes per day. It may not seem like much, but remember that it is all written in assembly language.
The current memory map is:
$0000..$00FF - Zero page, locations at $12 and above are free for application programs to use
$0100..$017F - FLEX line buffer
$0180..$01FF - Stack
$0200..$033F - FLEX entry points, variables and printer driver
$0340..$047F - System File Control Block
$0480..$0AFF - FLEX Utility Command Space
$0B00..MEMEND - User memorySomewhere above that is about 6K of FLEX itself.
Unlike the 680x versions, the UCS area has been intentionally placed adjacent to free RAM so that a program needing maximum memory can easily use both.
The User's Guide is almost ready to publish; this is slightly modified from an original FLEX manual. The Programming Guide is about halfway done; it is a heavily modified version of an existing FLEX manual.
Finally, some preliminary work has been done on an editor and an assembler. The assembler subproject is actually comprised of four smaller projects:
* enhance the existing 6800 assembler to add features such as conditional assembly directives
* convert the 6800 assembler into a 6502 cross assembler running on the 6800
* convert the 6800 assembler into a 6800 cross assembler running on the 6502
* combine the three into a 6502 native assembler
-
I can now view a catalog of files on a disk, type out the contents of text files, delete and rename files.
Overall, I am very pleased with the progress of this project; it was started on April 6, less than a month ago.
Next up, testing all of the ways to write files. That should keep me busy over the weekend.
While working on file deletion, it became obvious that a very safe and reliable file undelete utility can be built. Should I decide to develop that, I'll do it first on the 6502, then migrate it back to the 6800 and 6809.
-
At long last, I am finally able to load and run a program from a binary file. A surprising amount of the file system had to be implemented in order to be able to do that. I am very thankful to be developing this using emulation. Using real hardware will have taken much, much longer.
It is often said that code on a 6502 tends to be faster but bigger.
The following subroutine in the FLEX file system copies an 8.3 file name to a temporary save area in a file control block.
The original 6809 code:
D540 BE D413 [6] 00177 MOVNAM LDX CURFCB MOVE FILE NAME TO TEMP D543 C6 0B [2] 00178 LDB #$0B D545 A6 04 [5] 00179 MOVNM1 LDA $04,X D547 A7 88 24 [5] 00180 STA $24,X D54A 30 01 [5] 00181 LEAX $01,X D54C 5A [2] 00182 DECB D54D 26 F6 (D545) [3] 00183 BNE MOVNM1 D54F 39 [5] 00184 RTS
The 6502 code:
.C57A 01901 MOVNAM .C57A 18 [2] 01902 clc ; Copy file name to temp .C57B A5 04 [3] 01903 lda FCBPtr .C57D 69 20 [3] 01904 adc #FCBWrk-FCBNam ; Offset to temp area .C57F 85 06 [3] 01905 sta FMSPtr .C581 A5 05 [3] 01906 lda FCBPtr+1 .C583 69 00 [2] 01907 adc #0 .C585 85 07 [3] 01908 sta FMSPtr+1 . 01909 .C587 A2 0B [2] 01910 ldx #8+3 .C589 A0 04 [2] 01911 ldy #FCBNam . 01912 .C58B B1 04 [5/6] 01913 MOVNM1 lda (FCBPtr),Y .C58D 91 06 [6] 01914 sta (FMSPtr),Y . 01915 .C58F C8 [2] 01916 iny .C590 CA [2] 01917 dex .C591 D0 F8 (C58B) [2/3] 01918 bne MOVNM1 . 01919 .C593 60 [6] 01920 rts
In this example, the 6502 code is 20 cycles faster, but 10 bytes bigger.
-
I discovered this several months ago:
https://www.corshamtech.com/ss-50-65...rd-experiment/
So I contacted Bob Applegate and told him that I have been working on a debugger for the 6502 and will convert it into a monitor.
We were talking about operating systems. Most of the popular ones on the 6502 are wrapped tightly around its host hardware. None of them were anything like a CP/M or MS-DOS which can be readily adapted to a new system.
I brought up the OSI DOS. He said that he had looked at it and thought it was “clunky.” I had to agree because the user had to manually allocate disk tracks.
There is DOS/65, a CP/M clone, but there is not much information available on how to adapt it and build a boot disk.
While working on adding support for his SD card “disk system” in my debugger/monitor, I had a thought. Why not build a clone of FLEX for the 6502?
I started working on it and have most of the command line interface of the DOS portion working and can boot it off of a virtual disk in my emulator. Next up are disk drivers then the file system.
This morning, I reached out to Dave , local Ohio Scientific expert and owner of http://www.osiweb.org/ , for his input. We have been having some interesting discussions.
More to come…-
4
-
-
No, standard Pascal does not allow a case statement with strings with the exception of single characters. Some dialects allow two or even four character string constants.
It is not on the 99, but Free Pascal does for arbitrary strings.
https://www.freepascal.org/docs-html/ref/refsu56.html
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Cycle counting question
in TI-99/4A Development
Posted
A complication: I was somehow under the impression that the 32K RAM card in the PEB was 16-bit memory, but it is 8-bit.
The TI documentation says three machine cycles for a memory access. Now I read about a 4-cycle penalty due to the 8-bit bottleneck. Four and not three. So is the total 7 cycles or is there an extra wait state on both bytes for a total of 8?
Cycle counting is further complicated by whether the Workspace is in fast or slow RAM.