Jump to content

Lee Stewart

+AtariAge Subscriber
  • Content Count

    4,132
  • Joined

  • Last visited

Community Reputation

1,917 Excellent

About Lee Stewart

  • Rank
    River Patroller

Profile Information

  • Gender
    Male
  • Location
    Silver Run, Maryland

Recent Profile Visitors

17,469 profile views
  1. I did not think the Hilton would allow that many people in a room. ...lee
  2. Yes, except that the font would then be limited to 32 characters (ASCII 96..127), which would need manipulation similar to TI Basic’s offset to display whatever ASCII subset you desired. It might be possible to manipulate the Pattern Descriptor Table (PDT) to get more characters (at the expense of the already limited number of sprite patterns) if you placed the SPLIT3 text window at the bottom of the display. It still might require manipulation of the PDT. One problem is that the PDT must be on a 2-KiB boundary. If FILES were changed to 1, that would free up 518 bytes more above the Sprite Pattern Descriptor Table (SPDT) for a total of 123 character patterns starting at the bitmap-mode SPDT. I just do not remember whether the PDT can be moved to an arbitrary 2-KiB boundary or must be in the position analogous to its display position as is the case with SPLIT and SPLIT2 modes. ...lee
  3. Absolutely. You just need to remember the coordinate limits for the bitmap part of the display: GRAPHICS2 (bitmap) mode has a pixel resolution of 256x192 (columnsxrows). columns—0..255 rows—0..191 SPLIT mode removes the bottom third of the display from bitmap mode, making the upper (bitmap mode) display 256x128. columns—0..255 rows—0..127 SPLIT2 mode removes the top sixth of the display from bitmap mode, making the lower (bitmap mode) display 256x160. columns—0..255 rows—32..191 ...lee
  4. Drawing the Cartesian axes and plotting curves in bitmap mode is trivial in fbForth 2.0. Labeling the axes, however, is not. The problem is that the programmer must essentially plot the letters and numbers because fonts do not work in bitmap mode as they do in most of the other display modes. The problem is the reverse in graphics mode (the mode used by TI Basic and all XBs). In that mode, letters and numbers are easy, but plotting can only be done by manipulating character codes, which quickly limits fonts due to consuming characters during the plot. BTW, the “out of ink” problem in TI Logo is due to this consumption of character patterns for plotting in graphics mode. That said, I will have an example plot in the near future for which I may try to use the font scheme of TI Forth’s 64-column editor. ...lee
  5. Here it is with a couple of fonts from an old WordPerfect installation: Top font is “Microgramma Medium Extended” and bottom font is “Square 721 Extended”. Here they both are in bold: ...lee
  6. TurboForth has SAMS support, as well. In fact, that is the source of what I ported to fbForth. @Willsy(Mark Wills) developed a library for easily using SAMS to extend the TurboForth dictionary without needing to know the details of SAMS paging with >MAP , etc. It is detailed in his article, “SAMS Programming Library for TurboForth V1.2.1:1”. I intend to port it to fbForth one of these days. ...lee
  7. I agree—with one possible addition, viz., a second “Listing of Important Threads”, or some such, that lists links to important(?) threads (with cryptic, one-line descriptions) in a table-of-contents sort of way. ...lee
  8. Not to put too fine a point on it, but I get 108 bytes when I assemble Thierry’s code, which includes its local workspace. ...lee
  9. You may have already read this, but GPL Interface Specifications for the 99/4 Disk Peripheral is my go-to document for all things related to the details of the TI disk DSR, especially for levels 1 and 2 access. ...lee
  10. You may be right, but from my quick look (probably too quick) it looked as though it uses XOR as only one operation, it starts with a specific 16-bit value (A006h, I think) that gets periodically incremented during processing. It also performs a circular right shift (5 bits, I think) as part of the process. I did not look at much more of the logic. The beginning key could be changed, but that would likely require re-assembly—I do not think it is a runtime option. I should look at it again to make sure the increment was to the key and not the program walking through the file. ...lee
  11. Is this possibly a version of John A. Johnson’s program of the same name that encrypts/decrypts Geneve MDOS programs? If so, that ALC source is available on WHTech. ...lee
  12. Not true! Interpreters go back to, at least, 1952 and the first LISP interpreter was implemented in 1958! ...lee
  13. Yeah, I made only minor changes to the original code from the 64-column editor of TI Forth. I should have made more where the stack number for UNTIL was concerned. That is a little less than satisfactory, indeed. The only real difference is the last word ( PCH ), which restores the character under the cursor before exiting RKEY . This was necessary because there is no text-mode analog to the sprite cursor in the bitmap mode of the 64-column editor. Here is the original RKEY from the 64-column editor by Leslie O’Hagan: Leslie O’Hagan wrote this editor about a week after Leon Tietz wrote the 40-column editor, which, by the way, had no repeats. It simply used the TI Forth KEY routine from the TI Forth system-support routines (includes cursor blink) that the outer (text) interpreter uses. I had often thought of changing KEY to act like RKEY to get the key repeat, but ran out of steam or patience—I forget which. ...lee
  14. FYI, here is the Forth code I converted to the ALC of post #408: ...lee
  15. The only weirdness I am aware of in radix-100 math on the TI-99/4A is how zero and negative numbers are handled: If the first word (2 bytes) is 0000h, the entire radix-100 number is treated as zero, regardless of the values in the remaining 3 words. That is, 0000h 6363h 0035h 1234h is considered to have the same value as 0000h 0000h 0000h 0000h. Negative radix-100 numbers have only the first word negated. Any calculations deal with this contingency before performing the actual calculation, which is done with the absolute values of the numbers. The sign of the result is adjusted to accommodate the signs of the calculation arguments. ...lee
×
×
  • Create New...