Jump to content

Lee Stewart

+AtariAge Subscriber
  • Content Count

    5,093
  • Joined

  • Last visited

Community Reputation

3,280 Excellent

3 Followers

About Lee Stewart

  • Rank
    Quadrunner

Profile Information

  • Gender
    Male
  • Location
    Silver Run, Maryland

Recent Profile Visitors

19,533 profile views
  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
×
×
  • Create New...