Jump to content

Lee Stewart

+AtariAge Subscriber
  • Content Count

    5,085
  • Joined

  • Last visited

Community Reputation

3,265 Excellent

3 Followers

About Lee Stewart

  • Rank
    Quadrunner

Profile Information

  • Gender
    Male
  • Location
    Silver Run, Maryland

Recent Profile Visitors

19,462 profile views
  1. This relates to the Pattern Definition Table areas loaded by GPLLNK routines >16, >18 and >4A located in GROM 0. This is information from several sources (Heiner Martin, E/A Manual and Thierry’s site). >16 (“Standard Character Set”—Characters used on title screen) Copies 512 pattern bytes for ASCII 32 ( ) – 95 (_). These characters use all 8 dot rows so there is no inter-row space. >18 (“Small Capital Character Set”—Characters used in both Graphics and Text modes) Copies 512 pattern bytes for ASCII 32 ( ) – 95 (_). The first dot row of each character is >00, which provides the inter-line space. >4A (“Lower Case Character Set”, actually, very small caps—Characters used in both Graphics and Text modes) Copies 248 pattern bytes for ASCII 96 (`) – ASCII 126 (~). The first dot row of each character is >00, which provides the inter-line space. For XB: Routine >18 (or >16, if you insist) should find >0400 in FAC. >0400 is the start of the pattern for <space>. Routine >4A should find >0600 in FAC. >0600 is the start of the pattern for <back tick>, i.e., (`). The Sprite Attribute Table starts at >0300. Store >D0 at >0300 to disable all sprites. ...lee
  2. HEX \ 3 DIGIT BCD to int convertor. Limited to 999 : F>INT ( addr len -- addr len n) OVER [email protected] ( -- mantissa) CASE 0 OF 0 ENDOF 40 OF OVER 1+ [email protected] ENDOF 41 OF OVER 1+ [email protected] 64 * >R OVER 2+ [email protected] R> + ENDOF ( default) -1 \ bad # indicator ENDCASE ; DECIMAL Not to put too fine a point on it, but the floating point numbers are BCC (Binary Coded Centimal—radix 100) rather than BCD (Binary Coded Decimal—radix 10), which limits F>INT to 9999 rather than 999. There is also a bug in the default case. The bad # indicator (-1) needs to be swapped with the leftover byte so that ENDCASE does not consume the indicator: HEX \ 4 DIGIT BCC to int convertor. Limited to 9999 : F>INT ( addr len -- addr len n) OVER [email protected] ( -- mantissa) CASE 0 OF 0 ENDOF 40 OF OVER 1+ [email protected] ENDOF 41 OF OVER 1+ [email protected] 64 * >R OVER 2+ [email protected] R> + ENDOF ( default) -1 \ bad # indicator SWAP \ get byte for ENDCASE where it belongs ENDCASE ; DECIMAL ...lee
  3. Sorry. That still makes absolutely no sense as the reason for any disk corruption. Something else is going on in his scenario. CALL UNMOUNT(3) does exactly the same thing as CALL MOUNT(3,3). And the only disk writing is to the area in the CF reserved for associating a volume with a drive slot. Both commands write to the same, physical place, not to a volume. ...lee
  4. ???? Not sure how that could possibly matter. All that CALL UNMOUNT(<drive#>) does is to change the volume# to the default volume# for that drive—same volume# as drive#, the way it was shipped. It does not result in an empty drive as happens when you physically remove a diskette from a drive on real iron. There is always a volume mounted in each of the 3 drive emulations. ...lee
  5. I think Walid (@Vorticon) is about 70 miles northwest of you. ...lee
  6. As long as you leave the E/A utilities alone in low expansion RAM, It should take a minimal amount of ALC to write a simple memory image loader. You should also be able to write an ALC routine that would use GPLLNK to execute the E/A cartridge’s “5 RUN PROGRAM FILE” program loader at a place after the file entry (supplied by your code). You can do (1) with your own DSRLNK. However, though you could use your own GPLLNK to jump into the E/A GROM, you have no choice but to leave E/A’s DSRLNK at >22B2, with its WP at >209A, because the E/A program image loader code calls it. ...lee
  7. Thank you, kindly. I wondered where you might have gone, but then I saw your signature. ...lee
  8. TI Forth, fbForth, TurboForth (not sure about Camel99 Forth) all use ‘$’ extensively. It is used primarily in the code field of CODEd words to point to the parameter field (where the executable code for the word usually starts). Here is an fbForth example from the code field through the rest of the definition of MOVE : *** MOVE *** ( src dst cnt --- ) * Code Field MOVE DATA $+2 <---Code Field word points to Parameter Field (next instruction) * Parameter Field MOV *SP+,R1 pop cnt to R1 MOV *SP+,R2 pop dst to R2 MOV *SP+,R3 pop src to R3 MOV R1,R1 cnt = 0? JEQ MOVE2 exit if so MOVE1 MOV *R3+,*R2+ copy next cell DEC R1 dec counter JNE MOVE1 copy another cell if not done MOVE2 B *NEXT back to inner interpreter ...lee
  9. No. It is quite the other way around. This is self-modifying code that replaces the placeholder, >AAAA, with the contents of WORKSV at execution time. ...lee
  10. I hate to bring this up because it has little to do with your excellent work on this project (and you may have answered this before ISTR), but isn’t OVER better than 2DUP DROP ...lee
  11. The attached ALC from Thierry Nouspikel’s disassembly of the Editor/Assembler utilities may aid in our effort: EditorAssemblerLoMemUtilities_Nouspikel.a99 I changed all register references from numbers to ‘R’ notation. Hopefully, I got them all without screwing up non-register numbers. The loader starts at A23BA. The tag jump table is near the end at A2662. You probably guessed correctly that the labels are the actual addresses of the assembled code with a prefix of ‘A’. ...lee
  12. You should not need to anticipate these references. Simply include them as EQUates and, if they are used, they will appear tagged with ‘6’ at the end of the tagged object file and will be created by your loader’s code. ...lee
  13. Your loader would need to be able to understand all instructions with address references—possible, but complicated, with branch statements and statements that use symbolic address references, but I do not think possible with other uses of address labels. The only reason relocatable object code can be managed (and fairly easily, at that) is that the assembler marks all relocatable addresses in the tagged object code with segment addresses and offsets in a linked chain for each unique, relocatable address reference. The loader merely needs to walk each of those chains backwards to replace the segment+offset with the relocated addresses. For REF, prior loading of tagged object code containing the relevant DEF labels (per @Willsy’s loader) would provide the necessary variable definitions with the relevant addresses. Regarding using DEF and REF the way I implied in my earliest post on this topic, DEF would need to define the relevant word to contain the address of the DEFed label rather than the data at that address. I suppose you could flag the loader to manage DEFs as EXECUTE objects (CFAs per @Willsy’s loader) or direct branches (BL, BLWP) that would return where they left. @Willsy’s use of CFAs is probably wisest because it makes the code part of Forth. The only down side to this is that you must have the original ALC, which must be modified to have DEFed labels contain the address of the executable code rather than its own address and the return changed to B *NEXT to get back to the Forth environment. I am sure I have oversimplified (misconstrued?) some of the above, but it could be a fun project. At the very least, these musings provide something of a springboard for going forward, ...lee
×
×
  • Create New...