TheBF

* UPDATE * I have had a few other matters to attend to but when I get a bit of time I have been integrating the features from VI99 shell into this TTY version. They way the program works now is very different and so I have some bugs to kill around cutting and pasting but I am slowly making progress. I hope I will have a version some folks can try and beat-up in a week or so. Side-note: It's a little slower building software on floppy disks but Forth's "incremental compiling" features has proved invaluable. What this means is that as I add features I save off the system with the working code in it, essentially making a new Forth compiler, that has more of the working code pre-compiled. The game then is to keep doing that until you have compiled and tested everything and that's the final program. Back to the trench...

And related to this... https://jmmv.dev/2023/06/fast-machines-slow-machines.html

OK. I think I have something people can enjoy now. I had a big error in the logic around winning the game. I have also slowed down the level 2 play just a bit so it is more accessible. BREAKOUT-REPLAY.mp4 These files are the new build and the video shows me winning a game, pressing fire and restarting. BREAKOUT BREAKOUU

Thank you. That's the stuff I need. Ok. I will try to find how that is happening and fix it.

Nah. That's just me, not reading the message well. I eventually understood it.

Yes that's what I thought. Maybe I need to renew my subscription. I don't remember when I last paid something.

Things you learn when forced to use your own system. I did some work to improve the Breakout game clone and I learned something that others might want to know about how to better handle cooperative tasking under Forth. The new version makes a separate task for the paddle so the player has better control of it. The original paddle task called the joy stick function JOYST, which is small and fast but it ran the output through a case statement, did a timed delay and looped around again. It worked but it was not ideal. I could not get the ball moving fast enough for "Olympic" level play. I tried re-compiling with the direct threaded compiler and it was almost no different. That's when the light went on! : PADDLE-MOVER BEGIN 0 JOYST CASE 2 OF -2 PADDLE+! ENDOF 4 OF 2 PADDLE+! ENDOF ENDCASE SPEED @ 2* TICKS AGAIN ; (TICKS is multi-tasking friendly delay that reads the 9901 timer for duration) The problem was that even when the joystick was not outputting anything, the loop ran the entire case statement, which used CPU power for no purpose. The solution is to make a joystick version of KEY that passes control to other tasks if the joystick is doing nothing. The reason why pause is first is so that when the joystick is used the loop exits right away. : JOYKEY ( -- n) \ wait for any joystick output BEGIN PAUSE 0 JOYST ?DUP UNTIL ; Then put JOYKEY is the task loop. : PADDLE-MOVER BEGIN JOYKEY CASE 2 OF -2 PADDLE+! ENDOF 4 OF 2 PADDLE+! ENDOF ENDCASE SPEED @ 2* TICKS AGAIN ; ' PADDLE-MOVER CONSTANT PADDLE-TASK This worked much better at preventing the paddle movement from slowing down the ball movement. Updated code is here: CAMEL99-ITC/GAMES.TI/BREAKOUT/src/BREAKOUT-MTASK.FTH at master · bfox9900/CAMEL99-ITC · GitHub BTW the way, compiling this same program with the direct threaded Forth compiler added 4K to the image size !!!

It looks like I can no longer edit the first post so here is new version of the game with better paddle handling. I made use of the Forth multi-tasker to give the paddle it's own workspace so it interferes much less with the ball motion. I can't seem to make the ball go into the wall with this version. Let me know if it happens to you. I can beat it at GAMER level, but I struggle at Olympic level. There is also a score multiplier now that multiplies your score by the number of balls you have remaining. EDIT: UPDATED FILES ARE IN A POST BELOW.

Another thing that the game developers do around here is do multiple writes inside the loop to reduce the number of jumps. The simplest one is to write two bytes and decrement the loop counter by two. That should give you a version that is faster than the stock version as long as you are writing and even number of bytes. I have seen some examples of 8 byte writes inside the loop. I think using the AI, instruction gives you a way to decrement by 8 with good speed. R15 VDPW LI, BEGIN, R1 *+ R15 ** MOVB, R1 *+ R15 ** MOVB, R2 DECT, EQ UNTIL,

For Jesper's study, my tests have shown this buys you about 12% faster loops for VDP reads/writes versus symbolic addressing inside the loop.

A while back I saw code for erasing memory that was created by GCC. It was 2X faster than 0 FILL and so I took it as is and put it in a library. I got around to testing it and found that it was erasing 1 cell more than in the input argument. This is version is correct. It will always erase an even number of cells even if you give it an odd number which is ok if you keep you Forth memory aligned to word boundaries. CODE ERASE ( addr cnt -- ) \ 2x faster than 0 FILL *SP+ R1 MOV, BEGIN, TOS DECT, OC WHILE, *R1+ CLR, REPEAT, TOS POP, NEXT, ENDCODE

I will but I need to add deletions. I got sidetracked because I joined a community orchestra a month ago and I have to practice. (because I have not played a string instrument for 30 years and Viola was not one of the ones I played) I need to add line deletion from my old version into this new code. Now that I have a victim I mean customer, I will get on it for you. At the moment it only has 8K for data space but the strings are stored end to end with byte counts so it's very dense. If that's no enough for your project I will need to look into SAMS.

While working on this editor, I thought it would be nice to put debug info over on the VDP screen. But that means I need a VDP driver. Fortunately in the TTY kernel I had to have a minimal number of VDP words. For this I need a way to write a byte to VDP RAM. I call that VC! (vdp character store) So here is what it took to add a simple, not ultra fast, VDP driver to print text strings and numbers to VDP. This one has no scrolling. It just wraps to the top of the screen. I changed the Camel Forth kernel to separate the signed number conversion to a string, from the output in the word (.) (.) does Forth 'dot' but returns an (address, length) string pair. Then you can TYPE it or add spaces for right justification as required. DECIMAL CREATE VDP.ROW 0 , 0 , VDP.ROW CELL+ CONSTANT VDP.COL : VDP.AT-XY ( col row -- ) VDP.ROW 2! ; : VDP.CURS ( -- Vaddr) VDP.ROW 2@ 5 LSHIFT + ; : VDP.PAGE ( -- ) 0 768 BL VFILL 0 0 VDP.AT-XY ; : VDP.WRAP VDP.CURS 767 > IF 0 0 VDP.AT-XY THEN ; : VDP.COL+! ( n) VDP.COL +! VDP.WRAP ; : VDP.EMIT ( c -- ) VDP.CURS VC! 1 VDP.COL+! ; : VDP.TYPE ( addr n ) 0 DO COUNT VDP.EMIT LOOP DROP ; : VDP.SPACES ( n -- ) 0 MAX 0 DO BL VDP.EMIT LOOP ; : VDP.CR ( -- ) VDP.ROW 1+! VDP.COL OFF ; \ single number printing : VDP. ( n -- ) (.) VDP.TYPE BL VDP.EMIT ; : VDP.R ( n n -- ) >R (.) R> OVER - VDP.SPACES VDP.TYPE ; \ unsigned double number printing, right justified : VDP.UD.R ( ud n --) >R <# #S #> R> OVER - VDP.SPACES VDP.TYPE ; \ usigned single number printing, right justified : VDP.U.R ( u n -- ) 0 SWAP VDP.UD.R ;

Can you post the source for that one Mark? I have struggled to make a small text file editor and they are always way bigger than a block editor. So with a block to file convertor that lets people edit and test blocks of code interactively but save library code as files. I think for this little machine it's a good compromise. The challenge I guess is being keeping the text files formatted so they easily can come back into blocks for editing but that's not too much trouble.

Answer: The way G_d intended. 🤣

Could be a hardware problem at some memory location where Chess is active. Try running a memory test program or ... If you are using a PEB, you might want to try removing the expansion ram card and cleaning the edge connector with contact cleaner or 99% isopropyl alcohol. If that's not it, do the same thing on the fire hose edge connector and the cartridge connector just because it's there.

Minor point of order Mark. s" myfile.txt" included would make it standard Forth if that is of any interest to you. Then you can define: : INCLUDE BL PARSE INCLUDED ; \ OR : INCLUDE BL WORD COUNT INCLUDED ; (it was nice to see colour spelled in a civilized manner.)

Someone can correct me if needed but since the PIO is accessed via the OPEN command in XB, it's a pretty safe bet that it is using DSR code on the board. Yes the file name field in the PAB is a byte counted string at the end of the PAB data structure, as you have discovered. It documented in the editor assembler manual in the file section with other good stuff on file access that might be useful in your search. ?

This is wild. You show that there is a one to one correspondence here between GPL and 9900 Ass'y language. The only advantage with this kind of interpreter would therefore be portability. Program size is going to be the same or similar.

Yes the 16 bit buss is a huge advantage on the 99 for sure. Very hard to top that. Tursi's comparison to Forth is true as long as you limit the comparison to the indirect threaded Forth's like all the Forth's made for TI-99 in the past. I have a directed threaded compiler that is about 15% faster than Turbo Forth on most things I have tested. I have not made a sub-routine threaded Forth yet, but I want to make one to see what happens. What this means is that Forth compiles real machine code, but each word is a 9900 sub-routine. It should be about 2X faster than threaded Forths out there right now. Downside is that programs will be much bigger. The fix for that is to do a lot "inline" instructions rather than calling every command. We shall see if I can figure that out. (This is how the commercial Forth compilers work since 1995 or so) I have a machine Forth system that generates native code which is 3X to 5X faster on some tests I have done. It is only a compiler, no interpreter. And if you want to get really crazy, I made something called ASMFORTH. It is a Forth virtual machine with two stacks, Forth syntax for loops and branching but you can also use the registers. :-) I made this one because @Reciprocating Bill made a sieve benchmark that blew everything out of the water including GCC and was 10X faster than threaded Forth. Here is what the code looks like. (It's really an assembler in a disguise) https://github.com/bfox9900/ASMFORTH/blob/main/demo/ASMFORTH-SIEVE.FTH All that to say Forth is really just an idea about computing. How you implement it is a personal choice.

If you have memorized the entire instruction set in numerical form this is no advantage at all. Charles Moore who invented Forth, was very fond of writing programs in machine code for his CPUs. They only had 21 instructions so was simple to do. In fact on these small systems after using the assembler to make and debug a word, most of the time we translate it to machine code in the source code so the Assembler is not needed when we compile the code. Mark has made a very nice ASM2CODE (or some such name) word that takes data from memory at saves it as a machine code word.

It would be the about same speed as byte-coded Forth. Byte code Forth is about 30% .. 40% slower than indirect threaded code Forth (Most TI-99 Forth systems) ITC is 15% slower than direct threaded code Forth DTC is ~20% .. 30% slower than sub-routine threaded code Forth (Camel99 DTC Forth) STC is ~2.5X slower than native code generating Forth compilers.

Making some progress. I think I have correctly emulated the basic editing features. Now I have to add multi-line deletes, word skipping, copying and pasting which I should be able to borrow from the VDP version. (he said optimistically) <removed old video>

Lee got here first but here is another little tidibit of info. It is simpler to test these things from the console if you take arguments from the data stack. This is easy with the *SP+ indirect auto-increment on the SP register. Here is an example word that I wrote up but it is not tested. $8C02 CONSTANT VDPA $8C00 CONSTANT VDPW VARIABLE SMAX 24 SMAX ! ASM: VFILL ( ascii Vaddr bytes -- ) \ get the arguments from the data stack *SP+ R2 MOV, \ pop loop counter *SP+ RO MOV, \ pop VDP address *SP+ R7 MOV, \ pop ascii char R7 SWPB, \ fix byte order R0 $4000 ORI, \ set write bit on Vaddr \ set the VDP address once, 1st write goes to that address and VDP auto-increments R0 SWPB, R0 VDPA @@ MOVB, R0 SWPB, R0 VDPA @@ MOVB, \ loop only needs to count bytes, VDP chip does the rest BEGIN, R7 VDPW @@ MOVB, R2 DEC, EQ UNTIL, ;ASM

Mine too. My ultimate goal is to have a TTY console and the main console running together in little multi-user version of Forth. Another thing that would be cool would be file pipes. I have some ideas on how to do that but it could take me a while.