Jump to content

TheBF

Members
  • Content Count

    1,403
  • Joined

  • Last visited

Community Reputation

1,179 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

5,264 profile views
  1. Not sure if this helps, but I think of Assembly labels with DATA directives or BYTE directives, as "variables". So you are correct. A label with a DATA directive allocates(reserves) 2 bytes of memory for storing data. Since you know some Forth this is what the word VARIABLE does in Forth as well when you compile your programs.
  2. My memory is telling me that I read 32,767 somewhere deep in an old TI document. I will have to search to be certain. I know the PAB has a 16 bit field to hold the number, so 32,767 fits.
  3. I published a video to demonstrate what it's like to use CAMEL99 Forth on Classic99. I am pretty happy with the usability of the system now. Compile times are pretty fast with the changes I made recently. Just need to decide on the best way to make a file editor. https://youtu.be/__PtCJ473Zk
  4. Sometimes I am reminded of the words of that famous English philosopher, Mic Jagger, who said: "You can't always get what you want"
  5. This looks like a good site for details on this stuff http://retrotechnology.com/herbs_stuff/drive.html#term Lee is correct. It appears to be 150 ohms. (for most drives)
  6. I think I found a faster C! for my Forth. So far it's working... Old version used a SWPB instruction. CODE: C! ( c addr -- ) *SP SWPB, *SP *TOS MOVB, SP INCT, TOS POP, NEXT, END-CODE New one just reads memory with indexed addressing CODE: C! ( c addr -- ) 1 (SP) *TOS MOVB, SP INCT, TOS POP, NEXT, END-CODE One less instruction is always good on the 9900. Edit just checked and this is how FbForth does it. No prize for me.
  7. I seem to have this RTS/CTS thing working however to make it work I had to make CTS logic high to hold of the PC from sending. I thought it would the reverse. (?) Here is the code primitive that checks for a key and leaves in R4 (TOS cache) if it finds one. (in RPN assembler of course) Configuration is held in variables: CARD contains >1300 UART contains CARD+>40 (or >80 for RS232/2) CODE: CKEY? ( -- n ) \ "com-key" 0 LIMI, R12 RPUSH, \ save R12 on return stack CARD @@ R12 MOV, 5 SBZ, \ CTS line LOW. You are clear to send TOS PUSH, \ give us a new TOS register (R4) TOS CLR, \ erase it UART @@ R12 MOV, \ select >1340 CRU address 21 TB, \ test if char ready EQ IF, TOS 8 STCR, \ read the char 18 SBZ, \ reset 9902 rcv buffer CARD @@ R12 MOV, 5 SBO, \ CTS line HI. I am busy! TOS SWPB, \ shift to other byte ENDIF, R12 RPOP, \ restore old R12 2 LIMI, NEXT, END-CODE For the curious... This primitive routine is then used in the Forth kernel to make the "keyword" KEY which waits for a key (forever) and returns it if CKEY? returns a non-zero : KEY ( -- char) BEGIN PAUSE \ multi-tasking switch CKEY? \ test for key ?DUP \ dup if not zero UNTIL \ loop until not zero on stack 83D6 OFF ; \ reset VDP screen timeout Now when I paste source code into Tera term it stops at the end of a line automagically until the compiler has digested the code and then continues. Before I had to put a 300ms delay in Teraterm to prevent over-running the Forth compiler. I still need a 1mS delay between characters because Forth echoes each character back and without a receive interrupt I can't do duplex but it's better than it was. I am pleased.
  8. Thank you. That was my error. I was looking at the chip doc only. The card is the key.
  9. OK I will give that a try. Thanks!
  10. Hardware Handshaking for the 9902 Receive side? I am not the sharpest knife in the drawer, but when I look at TMS9902 data sheet, I see only hardware handshake control for when I want to send data. I can control the RTS line to signal that TI-99 wants to send. I cannot see anything that relates to preventing a sender from sending data TO the TI-99. What am I missing? Use case: I want to prevent the PC from sending source code while TI-99 is digesting a line in the input buffer and then enable sending when Forth is ready to swallow the next line.
  11. I worked for a guy who always said "The only stupid questions are the ones you didn't ask"
  12. For reference when I put the Forth workspace in RAM on the 8 bit buss versus in the 16bit memory things move only about 20% slower. However if the entire program including ALL the intrinsic routines (assembler code) were in 16bit RAM it might be more than 20% faster I think. (?)
  13. lol. Yes I type a great deal and very poorly.
  14. I have never used this device but I am interested in doing this too in the future. I just found this and I am sure there are others out there. https://microcontrollershop.com/product_info.php?products_id=5031 At some point I want to create a PCL lexicon for Forth so I can do interesting things with a modern printer, but that's a few dozen bugs away.
  15. I can't prove it but I swear that time moves faster in the the 12st 21st century. Nice to see you back BTW. Hope life is treating you well. I have been recounting my fun and travails over on the Camel99 Forth topic. I will have to give some thought to some meaningful content for here. I started a Youtube channel and the plan was to create some video to explain how to use my system and I wanted to give some demonstrations of how to do some real things in Forth. Maybe that can be my contribution over here.
×
×
  • Create New...