+Lee Stewart Posted October 2, 2012 Author Share Posted October 2, 2012 ... Lee, would you mind stress-testing the following Math words: */ UM* /MOD */MOD UM/MOD ... Mark Same for */MOD . It works! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 2, 2012 Author Share Posted October 2, 2012 ... Lee, would you mind stress-testing the following Math words: */ UM* /MOD */MOD UM/MOD ... Mark And /MOD works as it should! ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 2, 2012 Author Share Posted October 2, 2012 ... Lee, would you mind stress-testing the following Math words: */ UM* /MOD */MOD UM/MOD ... Mark UM* and UM/MOD are working correctly as far as I can tell. All look good from here! :thumbsup: :thumbsup: ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 3, 2012 Share Posted October 3, 2012 Phew! That's good news! I have to say, it's looking like this new build (with both stacks reversed) is working pretty solid. I haven't checked the file io code yet (general file handling) but block handling and editing is working fine. I'm considering adding a facility to allow the block buffers to be in VDP *or* CPU RAM. That way we can implement a bit-map library much more easily. I'm still mentally fermenting/percolating the changes that would be required. That's how I tend to work. I just sit on it for a week or so, letting it sink in before I attack the keyboard. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 4, 2012 Author Share Posted October 4, 2012 Floating Point Math Library--- If we stay with the MDOS calling scheme, the following mechanism should work: * REF FPMLIB entry point for floating point math library (FPML) FPLWS EQU >83A0 FPML workspace FPLLNK DATA FPLWS,FPMLIB new workspace and branchpoint * * set up registers with input parameters (R0-R5) * R0 = FPML subroutine # * R1 = pointer to result * R2 = parameter #1 * R3 = parameter #2 * R4 = parameter #3 * R5 = parameter #4 * BLWP @FPLLNK * * error returned in R0 and result at address passed to FPML in R1 * If we decide to use the old 4A way of doing business, the I/O parameters would be as described in the Editor/Assembler Manual, using FAC, ARG and other scratchpad-RAM addresses. And, the call would be done in the familiar way: * BLWP @FPLLNK DATA * At this point, as I said earlier, I'm torn. ...lee I am having a little difficulty figuring out exactly how to implement and test the FP library. My initial attempt was going to rely on the fewest changes to the FP library to get it off the ground. Alas, the register-passing method will not work using the TF registers because the first 6 registers are not all available: R3-R6 are used by TF. I will either need to LWPI to an intermediate workspace to set up R0-R5 for FP input parameters or add the TF workspace to my save/restore routine. As it is, it looks like I need to save and restore 834Ah-836Fh (38 bytes) and 83A0h-83BFh (32 bytes) for each call to the FP library. What's another 32 bytes? ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 5, 2012 Share Posted October 5, 2012 My initial attempt was going to rely on the fewest changes to the FP library to get it off the ground. Alas, the register-passing method will not work using the TF registers because the first 6 registers are not all available: R3-R6 are used by TF. I will either need to LWPI to an intermediate workspace to set up R0-R5 for FP input parameters or add the TF workspace to my save/restore routine. As it is, it looks like I need to save and restore 834Ah-836Fh (38 bytes) and 83A0h-83BFh (32 bytes) for each call to the FP library. What's another 32 bytes? ...lee Nah! As of today's build of TF (ahem!) it is now possible to change TF's workspace on the fly while it's running! You need the following routine, or your own equivalent: asm: tfws ( addr --) *sp+ r1 mov, \ get new ws address r1 $A00A @@ mov, \ load into ws restore vector (for KEY) r1 r2 mov, \ copy addr r2 6 ai, \ point to r3 in target ws r3 r2 *+ mov, \ copy program counter r4 r2 *+ mov, \ data stack pointer r5 r2 *+ mov, \ copy return stack pointer r2 12 ai, \ point to r12 in target ws r12 r2 *+ mov, \ copy NEXT pointer r0 $02E0 li, \ LWPI op-code r2 $045C li, \ NEXT op-code r0 b, \ execute the code in this workspace ;asm The above code copies the program counter and stack pointers to the new workspace, then it actually writes a small program in the *current* workspace and branches to it to execute the LWPI instruction. If this sounds complicated, it's because it's not possible to set the workspace from a register - it's an immediate instruction. So it writes: LWPI <addr> B *R12 CPU ram location >A00A is vector (it was previously marked as spare, so I re-assigned it) that must hold a copy of the workspace. This address will not change in the future. It is required because KEY changes the workspace to GPLWS (>83E0) to do a console keyboard scan, and KEY needs to know what to restore the workspace to after it's done. A similar machination to the above code had to be inserted into KEY to allow the workspace to be restored by means of a LWPI instruction. Anyway, the long and the short of it is, you can just move TF's workspace to somewhere else. Yeah it'll run a little slower, but I don't think you'll notice quite frankly! Note: This just moves the *workspace* (so you can use >8300 to >831F). The other code is still in PAD. Anyway, it's there if you think it'll come in handy. It was an easy enough hack, er, modification so I snuck it in there. Latest ROMs (for classic99) attached. TF-V1.2-05-Oct-2012.zip 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 5, 2012 Author Share Posted October 5, 2012 Nah! As of today's build of TF (ahem!) it is now possible to change TF's workspace on the fly while it's running! ... Note: This just moves the *workspace* (so you can use >8300 to >831F). The other code is still in PAD. Anyway, it's there if you think it'll come in handy. It was an easy enough hack, er, modification so I snuck it in there. ... Thanks, Mark! I probably won't get back to this until Sunday or Monday. Getting ready to celebrate my 69th tomorrow with about 100 family and friends! I have my priorities! ...lee Quote Link to comment Share on other sites More sharing options...
Rod Van Orden Posted October 5, 2012 Share Posted October 5, 2012 Mark: I tried out TF-V1.2-05-Oct-2012 with Classic99, Ti994w and Win994a. It worked great for Classic-99. However, in trying out the ROMS with Ti994w and Win994a, I found that WORDS is missing. WORDS does work perfectly with Classic-99. Are you tweeking the ROMS for the other emulators / simulators? (I would find that to be unlikely)..... For Ti994w and Win994a I dropped to TF-V1.2-15-Sep-2012 where things run well. Am I missing something here? Rod Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 5, 2012 Share Posted October 5, 2012 No there's only one build. Words should be missing from all of them so you've gone wrong somewhere! Words should reappear when (if) I get vocabulary support added. One it two other things to look at first! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 8, 2012 Author Share Posted October 8, 2012 @Willsy... Because TF uses 834Ch-835Bh for ISR-related stuff, do I need to disable interrupts before I save and then use that space for FP stuff? ...lee Quote Link to comment Share on other sites More sharing options...
Rod Van Orden Posted October 8, 2012 Share Posted October 8, 2012 Mark and Lee: I was busy during the past couple of weeks, first with jury duty, then with the IACP conference here in San Diego. I guess Detroit may be looking for a new Police Chief, huh? I agree with Lee that the five math words mentioned check out. They look good. Go for it. I have attached a file of some testing for UM* (others will follow). You can put this file under one of your disk files within either Classic-99 or Ti994w. I have internally documented what I did. By the way, Lee, I hope you had a good birthday celebration this past weekend. Happy Birthday! Rod Math Word Testing for UM-Times.zip Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 8, 2012 Author Share Posted October 8, 2012 Mark and Lee: I was busy during the past couple of weeks, first with jury duty, then with the IACP conference here in San Diego. I guess Detroit may be looking for a new Police Chief, huh? I agree with Lee that the five math words mentioned check out. They look good. Go for it. I have attached a file of some testing for UM* (others will follow). You can put this file under one of your disk files within either Classic-99 or Ti994w. I have internally documented what I did. By the way, Lee, I hope you had a good birthday celebration this past weekend. Happy Birthday! Rod Thanks, I had a grand time on Saturday! I am not sure what to do with your file, however. It seems to be a TF block file with non-text header information at the top that gets listed to the screen when I type 1 LIST. I am trying to use it as a FIAD file in directory, DSK1, under Classic99. Maybe I'm doing something wrong. ...lee Quote Link to comment Share on other sites More sharing options...
Rod Van Orden Posted October 8, 2012 Share Posted October 8, 2012 Lee: No. I'm the one who did something wrong...... The TI names and the PC names of the files are in conflict. I messed up. But I fixed all that, and the attachment should provide what you will need....... Rod Math Word Testing.zip Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 9, 2012 Share Posted October 9, 2012 @Willsy... Because TF uses 834Ch-835Bh for ISR-related stuff, do I need to disable interrupts before I save and then use that space for FP stuff? ...lee No. Interrupts will be off (LIMI 0) before a CODE word runs. Quote Link to comment Share on other sites More sharing options...
Rod Van Orden Posted October 9, 2012 Share Posted October 9, 2012 OK, folks. I found out where I was going wrong with Classic99 and the build TF V1.2 R-5-Oct12. Those pesky file directories are all different from one emulator to the next. Everything now is loading up just fine under Classic99, Ti994w and Win994a. There is no words definition in this build. I have verified that a zillion times. However, I'll load in a words definition from Lee around block 55 of his BLOCKS file. Except, I will be using the code as described in Post #74 here.It seems the word TERMINAL? has been removed from this build, as well.And that's fine. TERMINAL? is not in the Forth-83 Standard. Of course "pause" is borrowed from TI-FORTH (or from Lee's version). And that will make the boat float. Happy camper. Has anyone else noticed anything out of the ordinary with the new build? If not, Mark, I think you are getting really close to a V1.2 release. Mark: QUESTION. Is it possible for you to include a CD with your book? It would contain all the setups of the four big emulator / simulator environments, and basically be ready to go. All the user has to do is load up on their PC or laptop, and its TurboForthing forever....... I guess with all the different software involved you would have to get mutual cooperation and permissions from the other authors..... Especially if you want to use some of those TI ROMS...... Rod Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 10, 2012 Share Posted October 10, 2012 Yeah, terminal got the boot! BREAK? is still there. I removed TERMINAL? because it's hopelessly trivial to implement: : TERMINAL ( -- flag) KEY? 2 = ; More ROM space for me. Yes, V1.2 is looking pretty solid. There's more changes I need to make though. Lee observed an anomaly with referencing to CLOAD/LOAD and I need to look at that. That may require some non-trivial internal re-factoring. Regarding distribution: The book will recommend downloading classic99 from Harmlesslion.com, since classic99 comes with TF pre-installed. V1.2 will be added to the Classic99 distro (by Tursi) when it's released. I considered placing a copy of classic99 on the TF website (with Tursi's permission) for users to download, but I don't think it's as simple as that. Tursi has been granted a licence by Texas Instruments, and that probably does not extend to 're-distribution' which is what hosting it on turboforth.net may be construed as. So, it's probably better to keep things simple and reccommend that they visit harmless lion to get the software, or download the rom images/disk images from turboforth.net Mark Quote Link to comment Share on other sites More sharing options...
Rod Van Orden Posted October 11, 2012 Share Posted October 11, 2012 Thanks for the info. I would like to see that p-code card selection in Classic99 up and working too. I have all the original docs, a p-code card and a Gram Kracker.... I find Lee Stewart's efforts in TI Forth to be outstanding (as well as in many other areas). And when your book is ready on Amazon, look out! I am going to snap one up faster then TurboForth itself! Rod Van Orden San Diego, California Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 12, 2012 Author Share Posted October 12, 2012 Floating Point Math Library--- A short progress report: I have generated the memory image (5878 bytes) for the Floating Point Math Library. It is named FPL. I need to write a TF routine to LOAD (DSR disk LOAD function) the file into VDP RAM to then copy it to 2700h-3DF5h, which will be its home until I check all of the functions. The entry point into the library will be 2706h. The FPL's workspace will be at 83A0h. The only thing that will probably change is the size of the memory image as we debug my conversion of the library from MDOS to TI99/4A. The only thing I think I may need help with, @Willsy, is invoking the dsrlnk routine in the TF ROMs with the disk LOAD function. ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 12, 2012 Share Posted October 12, 2012 No problem. You need to: Select bank 1 (CLR @>6000) Fetch the *pointer* to the DSRLNK *vector* at >A00C (because the address of the vector could change between builds, but the pointer to it is guaranteed not to change) Execute DSRLNK Restore any scratchpad code. (BL to the address you find at >a010 (note: it's a bank1 address) Select bank0 (CLR @>6002) So, to execute DSRLNK, something like this: CLR @>6000 ; select bank 1 MOV @>A00C,R0 ; read pointer to DSRLNK vector BLWP *R0 ; call DSRLNK DATA xxxx ; disk io op-code MOV @>A010,R0 ; read pointer to scratchpad restore code BL *R0 ; restore scratchpad CLR @>6002 ; select bank 0 B *R12 ; back to Forth Here are the vectors that are set up by TF at wakey-wakey time, starting at >A000: endB0 equ $ ; end of bank 0 marker dorg >a000 ; note: during initialisation, GPLLNK uses >A000 to >A01F as workspace ; to load the upper case characters from console GROM. After this, ; the space is re-used. ;[ Vectors - the locations of these vectors MUST NOT change between builds intvec bss 2 ; vector for INTERPRET >a000 blkvec bss 2 ; vector for BLOCK >a002 numvec bss 2 ; vector for NUMBER >a004 fndvec bss 2 ; vector for FIND >a006 usrisr bss 2 ; vector for user isr >a008 wp bss 2 ; >a00a - workspace pointer. used by KEY to restore our workspace ; software can actually change TF's workspace while running! ; a copy of the desired workspace address MUST be written here ; so that KEY can restore the correct workspace address after its ; call into the TI ROM. dsrvec bss 2 ; pointer to DSRLNK vector in bank 1 >a00c gplvec bss 2 ; pointer to GPLLNK vector in bank 1 >a00e padvec bss 2 ; pointer to scratchpad restore code in bank 1. >a010 ; new vectors MUST be added here ;] Finally, you need to use the attached build, as I only added the pointer to DSRLNK this morning! Mark TF-V1.2-12-Oct-2012.zip Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 12, 2012 Author Share Posted October 12, 2012 No problem. You need to: ... Here are the vectors that are set up by TF at wakey-wakey time, starting at >A000: ... Finally, you to use the attached build, as I only added the pointer to DSRLNK this morning! Mark Thanks! I think I will try to get things to where I get successful returns for a couple of FP functions and then get back to documenting the TF transcendental functions. Unless, of course, you'd rather I put this baby to bed first. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 12, 2012 Author Share Posted October 12, 2012 ... Finally, you need to use the attached build, as I only added the pointer to DSRLNK this morning! Mark Will I be able to use this latest build with only remembering the different method of popping the data stack or will I also need to consider other modifications and/or an updated version of the BLOCKS file? ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 12, 2012 Share Posted October 12, 2012 Correct. There are no other mods coming through which will affect the development you are doing. You're correct: we'll have to update the companion disk before release. I've made a start on the 32 bit library changes. Mark Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 12, 2012 Author Share Posted October 12, 2012 No problem. You need to: Select bank 1 (CLR @>6000) Fetch the *pointer* to the DSRLNK *vector* at >A00C (because the address of the vector could change between builds, but the pointer to it is guaranteed not to change) Execute DSRLNK Restore any scratchpad code. (BL to the address you find at >a010 (note: it's a bank1 address) Select bank0 (CLR @>6002) So, to execute DSRLNK, something like this: CLR @>6000 ; select bank 1 MOV @>A00C,R0 ; read pointer to DSRLNK vector BLWP *R0 ; call DSRLNK DATA xxxx ; disk io op-code MOV @>A010,R0 ; read pointer to scratchpad restore code BL *R0 ; restore scratchpad CLR @>6002 ; select bank 0 B *R12 ; back to Forth ... What about saving, disabling and restoring the user ISR vector? ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 12, 2012 Author Share Posted October 12, 2012 ... CLR @>6000 ; select bank 1 MOV @>A00C,R0 ; read pointer to DSRLNK vector BLWP *R0 ; call DSRLNK DATA xxxx ; disk io op-code MOV @>A010,R0 ; read pointer to scratchpad restore code BL *R0 ; restore scratchpad CLR @>6002 ; select bank 0 B *R12 ; back to Forth ... Does the highlighted code mean that fixSP in the TF FP package must be changed for TF v1.2? ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 12, 2012 Share Posted October 12, 2012 Possibly! If could remember how fixSP works Does it get the address from a vector or is hard-coded? It would be better if FP AL routines restored the scratch-pad environment prior to returning to Forth, IMHO. It would certainly be faster. I guess you are looking for a definitive answer. Please proceed along the lines of AL routines restoring scratch-pad themselves by means of the built in subroutine in the TF ROM. So, yes, the FP Forth code would change in so far as calls to fixSP would be removed, and fixSP itself would be eliminated. Mark Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.