Jump to content

TheBF

Members
  • Content Count

    1,089
  • Joined

  • Last visited

Community Reputation

827 Excellent

About TheBF

  • Rank
    Stargunner

Profile Information

  • Gender
    Male
  • Location
    The Great White North
  • Interests
    Music/music production, The Forth programming language and implementations.
  • Currently Playing
    Guitar
  • Playing Next
    Trumpet ;)

Recent Profile Visitors

4,668 profile views
  1. Checking in I have been distracted lately by nice weather, grandchildren and a cousin with a bunch of vintage vacuum tube guitar amplifiers that need serious attention. I have been trying to find out why my RS232 Forth does not like to have the output vectored to other devices on real hardware. That is proving to be a challenge. All that to say I am still lurking but have a few other things to deal with. Hope to get a current copy of the system up on Github before end of July. (no promises) 🙂 0xBF
  2. I am laughing out loud regarding your use of the word "ruse".😃 Excellent. If the shoe fits I guess. Thanks as always for the extremely lucid description. What with Flat earth advocates and Moon Landing deniers I may have to re-consider my options lest my ruse be lumped together with that lot. 🙂 0xBF
  3. I only read 8374 (16 bits) when the status byte is non zero so I don't think I need to care if >8374 is reset to zero by the system? A bigger question is that I just plugged a bunch of different byte values into >83C6 and I don't see a difference in my keyboard values. Edit: I can see a difference. Maybe I have to do it every time I call KSCAN to get it to change. (?) Ah yes when I did this : KEYTEST 1 83D6 C! KEY ; I got difference values for control keys. So I will do some further testing to understand if my heresy can stand the inquisitional rigor of Atariage. 🙂 And still I am learning
  4. Thanks Lee. That's good to know.
  5. I remember doing a lot of trial and error to get a version than ran in Forth to my liking. Here is my latest which test for a keystroke and moves it on the top of the Forth stack (cached in R4 here, called TOS) if a key-press is detected. It shows how to use BL to call KSCAN by manually changing work-spaces to GPL and back to Forth. (In case it might be useful to someone) Like FBForth, Camel99 runs with interrupts on so I only disable them while in the KSCAN routine. Put your Yoda ears on when you read it and it makes more sense. 🙂 FYI: The NE IF, line assembles the instruction JEQ ENDIF Edit: I know about my terrible heresy, reading >8374 with MOV instead of MOVB but it works and I don't need to SWPB to put the character on the correct side for Forth to work with it CODE: KEY? ( -- ?) \ *WARNING* it takes 1,128uS for KEY? scan to run TOS PUSH, TOS CLR, \ TOS will be our true/false flag 0 LIMI, 83E0 LWPI, \ switch to GPL workspace 000E @@ BL, \ call ROM keyboard scanning routine 8300 LWPI, \ return to Forth's workspace , interrupts are restored 2 LIMI, 837C @@ R0 MOVB, \ read GPL status byte (=2000 if key pressed) NE IF, 8374 @@ TOS MOV, \ read the key ENDIF, NEXT, \ return END-CODE
  6. This is a little convoluted but I think you could do it with Classic99 if you know the start address and the end address of the program's image in memory. Load the object file program into Classic99 Press F1 to stop the program Press Select the "Make" Menu in Classic99 and click the "Save memory as a program option" Typically you would click the high RAM box and enter the start and end addresses. (make end address 1 byte more if end is an even number) Enter the start address which is the address the program enters to run itself. Click Include E/A utilities and character set if your program depends on those things (I have never used this) Press the build button Its one way to "skin the cat"
  7. I like the fish too! 🙂
  8. I am gonna steal this little gem Lee. I think much of it could be done in Forth with the addition of an LIMI word. Merci!
  9. I know Willsy got kind of excited when he saw that I was working on a driver for RS232 for my Forth system. I know it's a pain to translate Forth Assembler to TI Assembler. ( I have done my share the other way) But this code actually works to provide an OPEN, SEND and RCV routine. So here it is. Happy to answer any questions. (It shows the signs of my trial and error in the comments.) 🙂 This code is in my home-made cross-compiled Forth dialect but it could be adapted to Turbo Forth or FB Forth pretty simply I think. Here are some preliminary docs to explain it: CONSTANT: is just a CONSTANT VARIABLE: is just a VARIABLE T! is just ! (means "target" store" ie: for the TI progam image) EQU is like EQU but backwards syntax to TI ASM l: means create a "label" . It's like CREATE in Turbo Forth and kind of like "0 VARIABLE" in FB Forth (I think) Stuff you won't need: [CC] (CROSS-COMPILING) lets me use the interpreter to do simple calculations or change the RADIX interpretatively [TC] switches back to the [TARGET-COMPILING] mode to make TI programs RPUSH is macro. Below are the macros for both stacks. \ PUSH & POP on both stacks : PUSH, ( src -- ) SP DECT, *SP MOV, ; \ 10+18 = 28 cycles : POP, ( dst -- ) *SP+ SWAP MOV, ; \ 22 cycles : RPUSH, ( src -- ) RP DECT, *RP MOV, ; : RPOP, ( dst -- ) *RP+ SWAP MOV, ; There is some code below "housekeeping on USER VARIABLES..." It just increments your variables to keep track of the video column and OUT which counts characters since the last carriage return. /explanations
  10. And just for the sake of discussion, after reviewing some of the high speed game code I found here on Atariage here is VFILL with VDPWD loaded into R3. When I timed it versus the normal version Lee showed it seems to go about 12.9% faster. Not bad for a small code change. Just a thought. Here is the code in my Forth Cross-Assembler dialect but it's not too different from TI Forth Assembler. Weird stuff: TOS is just an alias for R4 which is a "cache" for top of stack item. I use a sub-routine called WMODE to setup the VDPWA, to save space POP, is a Forth macro for: : POP, ( dst -- ) *SP+ SWAP MOV, ; \ 22 cycles CODE: VFILL ( VDP-addr count char-- ) TOS SWPB, \ fix the TMS9900 byte order R2 POP, \ R2=count R0 POP, \ VDP-addr popped into R0 WMODE @@ BL, \ setup VDP write address IN R0 R3 VDPWD LI, \ vdp addr. in a reg. makes this 12.9% faster BEGIN, TOS *R3 MOVB, \ write byte to vdp ram R2 DEC, \ dec the byte counter EQ UNTIL, \ jump back if not done TOS POP, NEXT, END-CODE
  11. Just imagine how much faster you could find that in Forth.
  12. And of course his pronunciation of Huygens gives away where he grew up. (It is much softer in a southern accent.)
  13. And <shameless plug> if you want to use files for source code you could use CAMEL99 Forth which leaves the cartridge space open as well. 🙂 If you need some help with that I am happy to help. Lee's eagle eyes are much better than mine however. Switching to TEXT mode happens when it boots like the other the Forths but currently you need to use E/A Editor on your disk when working with real hardware so its not as fun as an integrated editor but times are pretty fast. There is library file for loading and saving fonts that I worked on with Lee's oversite. You can also load fonts at compile time as well like the hidden file shows. It remembers the dictionary pointer, compiles the data into CPU RAM, blits the data it into VPD RAM then restores the old dictionary pointer. This might let you try your idea ? I really need to get an editor finished and working for this darn thing...
  14. This translates very nicely to Forth. I did not know how to do this. Thanks! (The error checking may be a little over kill but it is easily removed.) NEEDS 0SBO FROM DSK1.CRU HEX : DSK# ( -- n) 83D0 @ DUP 0= ABORT" No disk" CRU! \ store top of stack to R12 83D2 @ DUP 0= ABORT" No ROM" 0SBO \ turn the card on ( 83D2) @ 8 + [email protected] \ fetch char from address on stack+8 0SBZ \ turn the card off [CHAR] 0 - \ subtract ascii '0' to return integer ;
  15. So the table on page 41 is correct for ABS right?
×
×
  • Create New...