Jump to content

Lee Stewart

+AtariAge Subscriber
  • Posts

    5,802
  • Joined

  • Last visited

4 Followers

About Lee Stewart

Profile Information

  • Gender
    Male
  • Location
    Silver Run, Maryland

Recent Profile Visitors

21,053 profile views

Lee Stewart's Achievements

Quadrunner

Quadrunner (9/9)

4.8k

Reputation

  1. Stephen Shaw is @blackbox here. ...lee
  2. Surely you intended SRL R6,8 ...lee 😄
  3. Could be @lucien2, but check the first few posts of @Willsy opened with saying he had coded a TI Basic version, but I don’t know whether he ever posted it. ...lee
  4. In getbyte, if the MSB of R6 is ignored, this is not a problem, but, as far as I can tell, the MSB of R6 is indeterminate unless it has been cleared before invoking the procedure. ...lee
  5. This is what Thierry Nouspikel says: The controller card comprises a 8192 bytes (>2000) ROM that contains a power-up subroutine, four DSR for high-level file access and many subprograms for low- or mid- or high-level disk access. As usual with peripheral cards, that ROM appears at >4000-5FFF when CRU bit 0 is set to one for that card. Note that the controller's register map at >5FF0-5FFF, thus the last 16 bytes of the ROM cannot be accessed. You'll find a commented disassembly listing of the whole ROM on my download page (warning: it's written in an ugly programming style). ...lee
  6. See latest beta in this post. ...lee
  7. While working on my new DSRLNK, I had improved (I think) VRAM reads to use fewer instructions than I had used previously, so I thought I should review other ALC in the fbForth kernel for the same improvements. While doing so, I discovered a bug I had introduced into SPRGET while trying to fix a previous bug related to how a sprite’s y value is stored in the Sprite Attribute Table. The bugs and their ultimate fix are described in the excerpt from my fbForth 3.0 TODO list in the spoiler: Here is the latest beta with the fix: fbForth300_8_Ka.bin <<< Happy now, Bob (@atrax27407)? >>> ...lee
  8. I cleaned up the Miller-Warren-Stewart DSRLNK a bit (updated here and in Post #1): DSRLNK_fbForth02.a99 The code at the end of the DSRAGN section after “BL *GR9” seems a bit bloated, but I am not sure I can get it any smaller—now at 282 bytes. Next, we need to put it through its paces to see what errors shake out. ...lee
  9. I should add that the ALC I posted of the Miller-Warren-Stewart DSRLNK includes the Miller-Warren GPLLNK called by the MWS DSRLNK. ...lee
  10. The original Navarone “Widgit” had one: ...lee
  11. I now have an extensively modified version of the Miller-Warren DSRLNK that is almost the same as the Bagnaresi-Sullivan-Stewart DSRLNK in this thread. The only difference is that it cannot catch the Call Instance important to a second RS232 card because the relevant register is trashed before return. I handle that contingency by arbitrarily storing a 1 for the Call Instance upon a successful DSRLNK return, testing a subsequent failed direct call to a DSR/Subprogram by testing the stored Call Instance, making it 2 if it was 1, and running it again. If it fails the second try, the error return is taken. This should be OK because the direct call should never occur until after a successful initial call. As I mentioned in an earlier post, the advantages to the Miller-Warren DSRLNK are that it saves code by using the Console DSRLNK, and handles cassette tape and GROM DSRs that are not handled by other DSRLNKs. The only drawback I see is that it has grown in size. The original code was 120 bytes and, with the direct call routine and Call Instance handling, it has grown to 290 bytes. The good news is that it is still less than the 360 bytes of the Bagnaresi-Sullivan-Stewart version. Here, for your delectation, is the current incarnation: DSRLNK_fbForth.a99 <<====Superseded. Get the latest code in post #1. ...lee
  12. GPL workspace R13, R14, R15 are all important to have correct for routines that expect them, which includes pretty much all DSRs. R13 is the current GROM base—usually, >9800. R14 has the VDP timer tick in the MSB and various flags (per Thierry Nouspikel: >20 cassette operations, >10 cassette verify, >08 16K VDP mem >02 multicolor mode, >01 sound table in VDP mem) in the LSB. R15 should always be >8C02, the VDP write address. The standard DSRLNK routine does, indeed, have its own workspace, but, as noted by @InsaneMultitasker, it switches to the GPL workspace just before branching to a DSR. ...lee
  13. FYI, here is the TI RS232 DSR ROM disassembled and commented by Thierry Nouspikel and register numbers converted to R values by yours truly. Note the ISR at >A4092 – >A415C: RS232.a99 Also, see Thierry’s RS232 ISR discussion. ...lee
  14. This was actually corrected in the E/A Addendum. ...lee
  15. Though ALC macros can certainly be complicated, the simplest use, in my opinion, is shortcuts for often-used code. I use two macros for over 500 fbForth name fields of normal and immediate Forth words: Since I use the same code several times in the fbForth Floating Point Library for pushing and popping BL links to and from the return stack, the following macros are very convenient: ...lee
×
×
  • Create New...