Jump to content

Lee Stewart

+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Everything posted by Lee Stewart

  1. Not DSRLNK (unless you tell it to), but the DSR it calls uses the >3xxx area in VRAM (not your SAMS window in CRAM) above the address contained in >8370—the TI Disk Controller definitely uses this area of VRAM. ...lee
  2. HarmlessLion Software ...lee
  3. Check the option in asm994a for copying to “TI Disk”. Asm994a will create a TIDISK image for you, which you can rename later or change to one you may have created before running the assembler. You can rename the image (MYDISK.TIDISK, say) to MYDISK.DSK because the formats are the same. You can always copy the file from the image to your Windows file system. ...lee
  4. Why such an old revision? Classic99 is now at v399.052. ...lee
  5. The XB loader cannot handle compressed-object-code files. ...lee
  6. If you want to change DSK2 in Classic99 to use the TI Controller, you will need to first insure you have a DSK image containing all the files you need. Then, on the Classic99 menu, choose “Disk”-->“DSK2”-->(top option) to open the necessary dialog box. Next, set the Disk Type to “TI Controller (DSK)” and Path to the appropriate DSK image. ...lee
  7. SAMS in fbForth 2.0 works pretty much the same as in TurboForth. The biggest difference is that low expansion RAM is mostly unavailable in fbForth—certainly, not enough for a 4-KiB page. It must use upper RAM for paging SAMS 4-KiB banks and how it does it is up to the user. I have not implemented TurboForth’s “SAMS Programming Library” in fbForth 2.0. It should be possible and I have thought about doing it. The one thing that has kept me back is that there is still a significant use of CPU RAM for the SAMS-defined words—it is not all in SAMS and the headers (as I recall) are larger to accommodate SAMS paging. I just don’t remember how much of each word is in CPU RAM—I should look at that again before I prove I don’t know what I’m talking about. ...lee
  8. Aha! So back to FigForth’s definition of tick. ...lee
  9. 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
  10. 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
  11. 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
  12. ???? 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
  13. I think Walid (@Vorticon) is about 70 miles northwest of you. ...lee
  14. 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
  15. Thank you, kindly. I wondered where you might have gone, but then I saw your signature. ...lee
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. They are not relocatable. Implementing relocatable code is a good bit more complicated. The only tags implemented are those associated with AORG.................9 DATA.................B BYTE.................B BSS..................B DEF..................6 <checksum>...........7—the checksum itself is ignored <end-of-file text>...: All other tagged words are ignored. ...lee
  23. That would be the quotient and the remainder. 🙂 ...lee
  • Create New...