Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.apple2.programmer > #5339 > unrolled thread
| Started by | James Davis <JPD.Enterprises@outlook.com> |
|---|---|
| First post | 2019-12-26 01:20 -0800 |
| Last post | 2020-02-28 01:26 -0700 |
| Articles | 14 — 8 participants |
Back to article view | Back to comp.sys.apple2.programmer
Applesoft's CASE Statement (Fully Anotated) James Davis <JPD.Enterprises@outlook.com> - 2019-12-26 01:20 -0800
Applesoft's CASE Statement (Fully Anotated) gids.rs@sasktel.net - 2019-12-26 10:15 -0800
Applesoft's CASE Statement (Fully Anotated) gids.rs@sasktel.net - 2019-12-28 12:41 -0800
Re: Applesoft's CASE Statement (Fully Anotated) James Davis <JPD.Enterprises@outlook.com> - 2019-12-29 16:03 -0800
Re: Applesoft's CASE Statement (Fully Anotated) gids.rs@sasktel.net - 2019-12-29 20:39 -0800
Re: Applesoft's CASE Statement (Fully Anotated) James Davis <JPD.Enterprises@outlook.com> - 2019-12-31 00:43 -0800
Re: Applesoft's CASE Statement (Fully Anotated) Michael Pohoreski <michael.pohoreski@gmail.com> - 2020-02-18 14:11 -0800
Re: Applesoft's CASE Statement (Fully Anotated) James Davis <JPD.Enterprises@outlook.com> - 2020-02-22 13:36 -0800
Re: Applesoft's CASE Statement (Fully Anotated) Michael J. Mahon <mjmahon@aol.com> - 2020-02-23 13:18 -0600
Re: Applesoft's CASE Statement (Fully Anotated) Steve Nickolas <usotsuki@buric.co> - 2020-02-24 11:49 -0500
Re: Applesoft's CASE Statement (Fully Anotated) Andy McFadden <thefadden@gmail.com> - 2020-02-25 08:58 -0800
Re: Applesoft's CASE Statement (Fully Anotated) Antoine Vignau <antoine.vignau@laposte.net> - 2020-02-25 12:19 -0800
Re: Applesoft's CASE Statement (Fully Anotated) James Davis <JPD.Enterprises@outlook.com> - 2020-02-26 22:57 -0800
Re: Applesoft's CASE Statement (Fully Anotated) awanderin <awanderin@gmail.com> - 2020-02-28 01:26 -0700
| From | James Davis <JPD.Enterprises@outlook.com> |
|---|---|
| Date | 2019-12-26 01:20 -0800 |
| Subject | Applesoft's CASE Statement (Fully Anotated) |
| Message-ID | <cc95f37b-7666-496b-b3e0-0f5465278462@googlegroups.com> |
Applesoft's CASE Statement (Fully Anotated by James Davis):
. . .
; ------------------------------------------------------------------------------
D981: 4C C9 DE SYNERR2 JMP SYNERROR ;(LpFrg Entry Point) Throw "?Syntax" Error
; ------------------------------------------------------------------------------
. . .
********************************************************************************
* ON (GOTO/GOSUB) Statement: Deferred Only; This is Applesoft's CASE Statement *
* Parameters: ON aexpr GOTO linenum {[, linenum]} *
* or: ON aexpr GOSUB linenum {[, linenum]} *
********************************************************************************
D9EC: 20 F8 E6 ONGOTO JSR GETBYT ;Get Number from FAC+4
D9EF: 48 PHA ;Push it onto Stack
D9F0: C9 B0 CMP #TOK_GOSUB ;Is it a GOSUB token?
D9F2: F0 04 BEQ ONGOCASE ;YES, Done checking tokens
D9F4: C9 AB ONGOTOK CMP #TOK_GOTO ;NO; Is it a GOTO token?
D9F6: D0 89 BNE SYNERR2 ;NO; Throw "?Syntax" Error
D9F8: C6 A1 ONGOCASE DEC FAC+4 ;YES; Counted to right Case Line # yet?
D9FA: D0 04 BNE ONGOFIND ;NO; Keep looking
D9FC: 68 PLA ;YES; Retrieve GOTO/GOSUB Code from Stack
D9FD: 4C 2A D8 JMP EXECSTMNT1 ;And Execute it
; ;Find correct Case Line #
DA00: 20 B1 00 ONGOFIND JSR CHRGET ;Get Next Char/Token from Program Line
DA03: 20 0C DA JSR LINGET ;Convert ASC # to HEX # in LINNUM
DA06: C9 2C CMP #',' ;Is Character a comma?
DA08: F0 EE BEQ ONGOCASE ;YES; Loop until Case found
DA0A: 68 PLA ;Not found, so ignore ON...GOTO/GOSUB
DA0B: 60 BAS_RTS09 RTS ;Return to Caller
********************************************************************************
* Convert ASC Number to HEX Number in LINNUM: *
********************************************************************************
* Enter with: Carry Set to just reset LINNUM to $0000; *
* Carry Clear to Convert ASCII Digits to BIN/HEX Number in LINNUM; *
* & First Digit of ASCII Number in A-Reg & TXTPTR pointing to next *
* (e.g., CHR just GOT by CHRGET). *
********************************************************************************
DA0C: A2 00 LINGET LDX #$00 ;Prepare to Clear Line Number
DA0E: 86 50 STX LINNUM ;Reset Line Number, Low
DA10: 86 51 STX LINNUM+1 ;Reset Line Number, High
DA12: B0 F7 ASCHEX BCS BAS_RTS09 ;Exit Loop if Not a Digit; Return to Caller
; ;(NXTDGT JSR CHRGET below does the carry)
; ;Else; Subtract w/o Carry:
DA14: E9 2F SBC #'/' ;(#s after it) Convert Digit to Binary/Hex
DA16: 85 0D STA CHARAC ;Save Binary/Hex Digit
; ;Check Range:
DA18: A5 51 LDA LINNUM+1 ;Get Line Number, High
DA1A: 85 5E STA INDEX ;Save Line Number, High; (for Multiplying)
DA1C: C9 19 CMP #$19 ;Line # too large (>63999)?
; ;[(64,000=$FA00)/10]=[(6400=$1900)]
; ------------------------------------------------------------------------------
; Why is LINNUM already divided by 10? Because, with each iteration, we are
; reading the most significant digit of a decimal line number (characters from
; left to right); which then gets multiplied by 10 before adding the next deci-
; mal digit to its value (all the while, converting ASC/decimal to BIN/hex).
; ------------------------------------------------------------------------------
DA1E: B0 D4 BCS ONGOTOK ;(BGE) YES, Indirectly throw a Syntax Error
; ==============================================================================
; I could not reproduce the problem said to exist here, so I deduced why!--JPD:
; ==============================================================================
; This branches when LINNUM+1 (Line Number, High) gets up to $19. It never goes
; past $19, so it can never reach $AB [which would cause catastrophe (below)];
; hense, this is not "<<< DANGEROUS CODE >>>" as said in the past! Except, ...
; ------------------------------------------------------------------------------
; Supposedly, if (A)=$AB on the line above, ONGOTOK will compare equal and cause
; a catastrophic jump to [some location that does not make sense was given here]
; (for GOTO), or to other locations for other calls to LINGET. You can see this
; if you first put BRK in [the location that does not make sense], then type
; GOTO 43776. Any value in the range: 43776~44031 ($AB00~$ABFF) will cause the
; problem. [Logically, this seems correct, but it doesn't happen! ON (1)
; GOSUB/GOTO 43776 works fine as long as line 43776 exists in the program.]
; ------------------------------------------------------------------------------
; ... It will happen if you accidentally type a line number (in your list of
; line numbers) that is in the Range times 10: (437760~440310)=($6AE00~$6B7F6)]
; which are illegal line numbers > 63999. [Who does that? Shakey Fingers!]
; ------------------------------------------------------------------------------
; NEW
; 5 REM ONGO.TEST
; 10 TT = 1: ON 1 GOSUB 43750 : REM BELOW RANGE
; 20 TT = 2: ON 1 GOTO 43760 : REM BELOW RANGE
; 30 TT = 3: ON 1 GOSUB 44040 : REM ABOVE RANGE
; 40 TT = 4: ON 1 GOTO 44050 : REM ABOVE RANGE
; 50 TT = 5: ON 1 GOSUB 44000 : REM INSIDE RANGE
; 60 TT = 6: ON 1 GOTO 44010 : REM INSIDE RANGE
; 63 TT = 7: ON 1 GOSUB 440600 : REM ILLEGAL LINE NO. INSIDE 10*RANGE
; 66 TT = 8: ON 1 GOTO 440700 : REM ILLEGAL LINE NO. INSIDE 10*RANGE
; 70 PRINT "PASSED ALL TESTS"
; 99 STOP
; 43750 PRINT "(";TT;") 1ST TEST ON GOSUB" : GET A$: RETURN
; 43760 PRINT "(";TT;") 1ST TEST ON GOTO" : GET A$: GOTO 30
; 44000 PRINT "(";TT;") 3RD TEST ON GOSUB" : GET A$: RETURN
; 44010 PRINT "(";TT;") 3RD TEST ON GOTO" : GET A$: GOTO 63
; 44040 PRINT "(";TT;") 2ND TEST ON GOSUB" : GET A$: RETURN
; 44050 PRINT "(";TT;") 2ND TEST ON GOTO" : GET A$: GOTO 50
; 44060 PRINT "(";TT;") 4TH TEST ON GOSUB" : GET A$: RETURN
; 44070 PRINT "(";TT;") 4TH TEST ON GOTO" : GET A$: GOTO 70
; ==============================================================================
; ;Multiply by Ten:
DA20: A5 50 LDA LINNUM ;Get Line Number, Low
DA22: 0A ASL A ;Double Temp Line Number, Low [2x]
DA23: 26 5E ROL INDEX ;Double & Add Carry to Temp Line Num, High
DA25: 0A ASL A ;Double Temp Line Number, Low [4x]
DA26: 26 5E ROL INDEX ;Double & Add Carry to Temp Line Num, High
DA28: 65 50 ADC LINNUM ;Add Result back into Real Line Number, Low
DA2A: 85 50 STA LINNUM ;Set Real Line Number, Low [4x+1x=5x]
DA2C: A5 5E LDA INDEX ;Get Temp Line Number, High [4x]
DA2E: 65 51 ADC LINNUM+1 ;Add it to Real Line Number, High
DA30: 85 51 STA LINNUM+1 ;Set Real Line Number, High [4x+1x=5x]
DA32: 06 50 ASL LINNUM ;Double Real Line Number, Low [2(5x)=10x]
DA34: 26 51 ROL LINNUM+1 ;Double & Add Carry to Real Line Num, High
DA36: A5 50 LDA LINNUM ;Get Line Number, Low
DA38: 65 0D ADC CHARAC ;Add Digit (saved above)
DA3A: 85 50 STA LINNUM ;Set Line Number, Low
DA3C: 90 02 BCC NXTDGT ;If no Carry, Skip High Byte
DA3E: E6 51 INC LINNUM+1 ;Else, Add Carry (1) to Line Number, High
; ; (INC = 3 cycles vs. ADC = 5 cycles)
DA40: 20 B1 00 NXTDGT JSR CHRGET ;Get Next Char/Token
DA43: 4C 12 DA JMP ASCHEX ;Convert Next Char/Token; (Exit if Not #)
********************************************************************************
. . .
[toc] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2019-12-26 10:15 -0800 |
| Message-ID | <9ac78016-399e-4c5b-99de-9bfdcc99467a@googlegroups.com> |
| In reply to | #5339 |
Here is a routine that allows the full 65535 line #’s and is 10 bytes shorter LINGET EQU * LDX #0 STX $50 STX $51 BCS FINI LOOP EOR #$30 TAX LDY $51 LDA $50 ASL ROL $51 ASL ROL $51 BCS ILQTY ADC $50 STA $50 TYA ADC $51 STA $51 BCS ILQTY ASL $50 ROL $51 BCS ILQTY TXA ADC $50 STA $50 BCC GETCHAR INC $51 BEQ ILQTY GETCHAR JSR $00B1. ; CHARGET BCC LOOP FINI RTS ILQTY JMP $E199 It can be tested from the applesoft prompt with this 3F6: point ampersand to following statements JSR $00B7 JSR LINGET LDA $51 LDX $50 JMP $F941 At the applesoft prompt type & (any number) As you can see, the routine no longer hinders lines above 63999
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2019-12-28 12:41 -0800 |
| Message-ID | <2a8cd062-2358-4d75-bb8b-12f8696fcb91@googlegroups.com> |
| In reply to | #5340 |
A slightly faster version Note: if Y-reg needs to be preserved, it can be replaced with LDA $51 - PHA and TYA to PLA at the cost of 1 extra byte LINGET EQU * LDX #0 STX $50 STX $51 BCS FINI LOOP EOR #$30 TAX LDY $51 LDA $50 ASL ROL $51 ASL ROL $51 BCS ILQTY ADC $50 STA $50 TYA ADC $51 STA $51 BCS ILQTY ASL $50 ROL $51 BCS ILQTY TXA ADC $50 STA $50 BCS SETHI GETCHAR JSR $00B1. ; CHARGET BCC LOOP FINI RTS SETHI INC $51 BNE GETCHAR ILQTY JMP $E199
[toc] | [prev] | [next] | [standalone]
| From | James Davis <JPD.Enterprises@outlook.com> |
|---|---|
| Date | 2019-12-29 16:03 -0800 |
| Message-ID | <330316af-36c2-4615-8c43-5f3aed16a242@googlegroups.com> |
| In reply to | #5347 |
On Thursday, December 26, 2019 at 10:15:05 AM UTC-8, gid...@sasktel.net wrote: > Here is a routine that allows the full 65535 line #’s and is 10 bytes shorter > > LINGET EQU * > LDX #0 > STX $50 > STX $51 > BCS FINI > > LOOP EOR #$30 > TAX > > LDY $51 > LDA $50 > ASL > ROL $51 > > ASL > ROL $51 > BCS ILQTY > > ADC $50 > STA $50 > TYA > ADC $51 > STA $51 > BCS ILQTY > > ASL $50 > ROL $51 > BCS ILQTY > > TXA > ADC $50 > STA $50 > BCC GETCHAR > INC $51 > BEQ ILQTY > > GETCHAR JSR $00B1. ; CHARGET > BCC LOOP > FINI RTS > > ILQTY JMP $E199 > > > It can be tested from the applesoft prompt with this > > 3F6: point ampersand to following statements > > JSR $00B7 > JSR LINGET > LDA $51 > LDX $50 > JMP $F941 > > > At the applesoft prompt type > > & (any number) > > As you can see, the routine no longer hinders lines above 63999 On Saturday, December 28, 2019 at 12:41:29 PM UTC-8, gid...@sasktel.net wrote: > A slightly faster version > Note: if Y-reg needs to be preserved, it can be replaced with LDA $51 - PHA and TYA to PLA at the cost of 1 extra byte > > LINGET EQU * > LDX #0 > STX $50 > STX $51 > BCS FINI > > LOOP EOR #$30 > TAX > > LDY $51 > LDA $50 > ASL > ROL $51 > > ASL > ROL $51 > BCS ILQTY > > ADC $50 > STA $50 > TYA > ADC $51 > STA $51 > BCS ILQTY > > ASL $50 > ROL $51 > BCS ILQTY > > TXA > ADC $50 > STA $50 > BCS SETHI > > GETCHAR JSR $00B1. ; CHARGET > BCC LOOP > > FINI RTS > > SETHI INC $51 > BNE GETCHAR > > ILQTY JMP $E199 Could you do a Code Dump of your assembly here? Then I could put it in a file for 6502bench SourceGen, to better examine it. Is this yours originally or did you get it from a newer Apple II ROM image? Maybe the AppleWin Team could use this in their Apple II ROM releases to improve Applesoft!?
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2019-12-29 20:39 -0800 |
| Message-ID | <b7f9124a-29b1-43a8-a0d7-ccf411487538@googlegroups.com> |
| In reply to | #5348 |
It would be quicker to enter the lines into the mini-assembler. Currently only have internet access thru my cel phone.
[toc] | [prev] | [next] | [standalone]
| From | James Davis <JPD.Enterprises@outlook.com> |
|---|---|
| Date | 2019-12-31 00:43 -0800 |
| Message-ID | <bb7a282c-977c-4ff0-ba0e-f85002d02508@googlegroups.com> |
| In reply to | #5349 |
On Sunday, December 29, 2019 at 8:39:24 PM UTC-8, gid...@sasktel.net wrote: > It would be quicker to enter the lines into the mini-assembler. > > Currently only have internet access thru my cel phone. Good Idea. I did not think of that. Thanks, James Davis
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2020-02-18 14:11 -0800 |
| Message-ID | <f997f2fc-a2f4-453f-80b6-b12dd14cd2c1@googlegroups.com> |
| In reply to | #5348 |
Sadly, fixing Applesoft bugs is beyond the intent of AppleWin due to numerous reasons: * We can't move entry points around * We can't fix in bugs in Applesoft as we don't have time to track down issues caused by this mod/patch * It would be non-standard and this would break software that uses that (standardized) behavior and just causes us more "support" issues that could be spent on other things. * Where do we draw the line? Do we get rid of all the unused code in F8 ROM? i.e. Casette port? * Which Apple 2 models do we support? * For serious programs no one uses Applesoft due to its horrible speed. For the record I _do_ want to have a 65C02 version of Applesoft with the bugs fixed and that is smaller -- but _that_ personal project is still years off. i.e. Imagine the size Applesoft could be if say someone like qkumba ever decided to optimize it!? :-) It makes me giddy removing all the unused / badly written code in Applesoft someday and see how many bytes we can reclaim! I guess that would be an epic "code golf". :-) My hope is to do that after my main game disassembly projects are done. If we ever decided to support this it would be an optional ROM plugin as the out-of-the-box experience needs to be authentic (bugs and all.) So no, not yet. :-)
[toc] | [prev] | [next] | [standalone]
| From | James Davis <JPD.Enterprises@outlook.com> |
|---|---|
| Date | 2020-02-22 13:36 -0800 |
| Message-ID | <8f29961f-bddf-45c1-89ce-6ef60c401492@googlegroups.com> |
| In reply to | #5408 |
On Tuesday, February 18, 2020 at 2:11:52 PM UTC-8, Michael Pohoreski wrote: > Sadly, fixing Applesoft bugs is beyond the intent of AppleWin due to numerous reasons: > > * We can't move entry points around > * We can't fix in bugs in Applesoft as we don't have time to track down issues caused by this mod/patch > * It would be non-standard and this would break software that uses that (standardized) behavior and just causes us more "support" issues that could be spent on other things. > * Where do we draw the line? Do we get rid of all the unused code in F8 ROM? i.e. Casette port? > * Which Apple 2 models do we support? > * For serious programs no one uses Applesoft due to its horrible speed. > > For the record I _do_ want to have a 65C02 version of Applesoft with the bugs fixed and that is smaller -- but _that_ personal project is still years off. > > i.e. Imagine the size Applesoft could be if say someone like qkumba ever decided to optimize it!? :-) It makes me giddy removing all the unused / badly written code in Applesoft someday and see how many bytes we can reclaim! I guess that would be an epic "code golf". :-) > > My hope is to do that after my main game disassembly projects are done. If we ever decided to support this it would be an optional ROM plugin as the out-of-the-box experience needs to be authentic (bugs and all.) > > So no, not yet. :-) Michael, I am working on a fully/verbosely annotated 6502 SourceGen Disassembly of the Apple II Plus complete ROM space image. I am about half way through it now. When I am done with it, I will upload it to Asimov for all to download as desired. It may help you (in your quest) [and others, and any future newbies (who I am doing it for)] acquire a better understanding of the way the 5.25" floppy disk drive Bootstrap loader (in the ROM image twice) [Documented mostly by Andy McFadden], Applesoft BASIC, and the (hybrid version in the ROM image) Autostart Monitor all work. James Davis
[toc] | [prev] | [next] | [standalone]
| From | Michael J. Mahon <mjmahon@aol.com> |
|---|---|
| Date | 2020-02-23 13:18 -0600 |
| Message-ID | <LrKdnXJf6eK9Tc_DnZ2dnUU7-QfNnZ2d@giganews.com> |
| In reply to | #5412 |
James Davis <JPD.Enterprises@outlook.com> wrote: > On Tuesday, February 18, 2020 at 2:11:52 PM UTC-8, Michael Pohoreski wrote: >> Sadly, fixing Applesoft bugs is beyond the intent of AppleWin due to numerous reasons: >> >> * We can't move entry points around >> * We can't fix in bugs in Applesoft as we don't have time to track down >> issues caused by this mod/patch >> * It would be non-standard and this would break software that uses that >> (standardized) behavior and just causes us more "support" issues that >> could be spent on other things. >> * Where do we draw the line? Do we get rid of all the unused code in F8 >> ROM? i.e. Casette port? >> * Which Apple 2 models do we support? >> * For serious programs no one uses Applesoft due to its horrible speed. >> >> For the record I _do_ want to have a 65C02 version of Applesoft with the >> bugs fixed and that is smaller -- but _that_ personal project is still years off. >> >> i.e. Imagine the size Applesoft could be if say someone like qkumba ever >> decided to optimize it!? :-) It makes me giddy removing all the unused / >> badly written code in Applesoft someday and see how many bytes we can >> reclaim! I guess that would be an epic "code golf". :-) >> >> My hope is to do that after my main game disassembly projects are done. >> If we ever decided to support this it would be an optional ROM plugin as >> the out-of-the-box experience needs to be authentic (bugs and all.) >> >> So no, not yet. :-) > > Michael, > > I am working on a fully/verbosely annotated 6502 SourceGen Disassembly of > the Apple II Plus complete ROM space image. I am about half way through > it now. When I am done with it, I will upload it to Asimov for all to download as desired. > > It may help you (in your quest) [and others, and any future newbies (who > I am doing it for)] acquire a better understanding of the way the 5.25" > floppy disk drive Bootstrap loader (in the ROM image twice) [Documented > mostly by Andy McFadden], Applesoft BASIC, and the (hybrid version in the > ROM image) Autostart Monitor all work. > > James Davis > I’ve always found the Sourcerer disassembly of Applesoft helpful. And Bob Sander-Cederlof’s disassembly is also excellent, and documents some bugs as well! -- -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
[toc] | [prev] | [next] | [standalone]
| From | Steve Nickolas <usotsuki@buric.co> |
|---|---|
| Date | 2020-02-24 11:49 -0500 |
| Message-ID | <alpine.BSF.2.02.2002241146150.61767@frieza.hoshinet.org> |
| In reply to | #5413 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 23 Feb 2020, Michael J. Mahon wrote: > I’ve always found the Sourcerer disassembly of Applesoft helpful. And Bob > Sander-Cederlof’s disassembly is also excellent, and documents some bugs as > well! The sources I reference - which roll in CA65 - are Sander-Cederlof's disassembly of FPBASIC, plus the original ][ ROM code, with changes to the ][+ firmware disassembled by me (and sometimes using different labels; for example, the official label APPLEII is called BANNER in my listing). http://3.buric.co/patmon.a65.txt http://3.buric.co/patmon.lst.txt -uso.
[toc] | [prev] | [next] | [standalone]
| From | Andy McFadden <thefadden@gmail.com> |
|---|---|
| Date | 2020-02-25 08:58 -0800 |
| Message-ID | <159eb86c-9d2b-4726-a78c-2473553bf656@googlegroups.com> |
| In reply to | #5414 |
On Monday, February 24, 2020 at 8:49:27 AM UTC-8, Steve Nickolas wrote: > The sources I reference - which roll in CA65 - are Sander-Cederlof's > disassembly of FPBASIC, plus the original ][ ROM code, with changes to the > ][+ firmware disassembled by me (and sometimes using different labels; for > example, the official label APPLEII is called BANNER in my listing). The SourceGen versions of Applesoft and the F8 ROMs (https://6502disassembly.com/) do a pretty good job of demonstrating the advantages and limitations of the format. On the one hand it's fully cross-referenced and you can generate code for multiple assemblers. On the other hand there are many instances where the Applesoft code uses an operand that is the result of a formula involving multiple labels or a math operator other than addition, and SourceGen doesn't yet have a way to represent that. (My Applesoft listing is also based on the S-C disassembly. The F8 ROM listings are straight out of the reference manual, so the commentary on the original ROM is much more detailed than the autostart version.)
[toc] | [prev] | [next] | [standalone]
| From | Antoine Vignau <antoine.vignau@laposte.net> |
|---|---|
| Date | 2020-02-25 12:19 -0800 |
| Message-ID | <79e6fe14-2c76-4ec2-b3e0-0ecf6819eab2@googlegroups.com> |
| In reply to | #5415 |
What is missing in the original Applesoft II source code? av
[toc] | [prev] | [next] | [standalone]
| From | James Davis <JPD.Enterprises@outlook.com> |
|---|---|
| Date | 2020-02-26 22:57 -0800 |
| Message-ID | <169797d4-6091-4dd3-a0e9-797bc5979ff9@googlegroups.com> |
| In reply to | #5413 |
On Sunday, February 23, 2020 at 11:19:01 AM UTC-8, mjm...@aol.com wrote: > James Davis wrote: > > On Tuesday, February 18, 2020 at 2:11:52 PM UTC-8, Michael Pohoreski wrote: > >> Sadly, fixing Applesoft bugs is beyond the intent of AppleWin due to numerous reasons: > >> > >> * We can't move entry points around > >> * We can't fix in bugs in Applesoft as we don't have time to track down > >> issues caused by this mod/patch > >> * It would be non-standard and this would break software that uses that > >> (standardized) behavior and just causes us more "support" issues that > >> could be spent on other things. > >> * Where do we draw the line? Do we get rid of all the unused code in F8 > >> ROM? i.e. Casette port? > >> * Which Apple 2 models do we support? > >> * For serious programs no one uses Applesoft due to its horrible speed. > >> > >> For the record I _do_ want to have a 65C02 version of Applesoft with the > >> bugs fixed and that is smaller -- but _that_ personal project is still years off. > >> > >> i.e. Imagine the size Applesoft could be if say someone like qkumba ever > >> decided to optimize it!? :-) It makes me giddy removing all the unused / > >> badly written code in Applesoft someday and see how many bytes we can > >> reclaim! I guess that would be an epic "code golf". :-) > >> > >> My hope is to do that after my main game disassembly projects are done. > >> If we ever decided to support this it would be an optional ROM plugin as > >> the out-of-the-box experience needs to be authentic (bugs and all.) > >> > >> So no, not yet. :-) > > > > Michael, > > > > I am working on a fully/verbosely annotated 6502 SourceGen Disassembly of > > the Apple II Plus complete ROM space image. I am about half way through > > it now. When I am done with it, I will upload it to Asimov for all to download as desired. > > > > It may help you (in your quest) [and others, and any future newbies (who > > I am doing it for)] acquire a better understanding of the way the 5.25" > > floppy disk drive Bootstrap loader (in the ROM image twice) [Documented > > mostly by Andy McFadden], Applesoft BASIC, and the (hybrid version in the > > ROM image) Autostart Monitor all work. > > > > James Davis > > > > I’ve always found the Sourcerer disassembly of Applesoft helpful. And Bob > Sander-Cederlof’s disassembly is also excellent, and documents some bugs as > well! > > -- > -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com Do you have a download site address for the "Sourcerer disassembly of Applesoft" you mentioned? I am using several different disassemblies as reference material for my document. But mostly BS-C's from Andy McFadden's website and one from Apple/Microsoft dated 1984 & 1990, divided into Parts A, B, C, & D.
[toc] | [prev] | [next] | [standalone]
| From | awanderin <awanderin@gmail.com> |
|---|---|
| Date | 2020-02-28 01:26 -0700 |
| Message-ID | <yublfon15je.fsf@gmail.com> |
| In reply to | #5418 |
James Davis <JPD.Enterprises@outlook.com> writes: > On Sunday, February 23, 2020 at 11:19:01 AM UTC-8, mjm...@aol.com wrote: >> James Davis wrote: [...] > > Do you have a download site address for the "Sourcerer disassembly of > Applesoft" you mentioned? > > I am using several different disassemblies as reference material for > my document. But mostly BS-C's from Andy McFadden's website and one > from Apple/Microsoft dated 1984 & 1990, divided into Parts A, B, C, & > D. It's in the 8-bit Merlin assembler package--all versions from Dos 3.3 and onwards. ftp.apple.asimov.net/pub/apple_II/images/programming/assembler/merlin/ should get to a number of disk images with the listing on it. You will have to run the image in an emulator, because the actual formatted listing is not there on the disk. Probably to bypass copyright issues, Glen Bredon wrote some code to merge his labels and comments with the object code on your Apple II to create the disassembly. Or at least that is how I remember things. I haven't actually done the process since the 1980s. -- -- Jerry awanderin at gmail dot com
[toc] | [prev] | [standalone]
Back to top | Article view | comp.sys.apple2.programmer
csiph-web