TheBF

That's a monster. You spent some time on that I reckon. Do we have any idea if it would be better than say, a 32 bit integer PRNG scaled and converted to a float? I know it would be a different sequence, but does the float version have any better characteristics?

That's clever. Another thing I have to try. I scratched my head for awhile trying to figure out a minimal way to context switch. I didn't like taking up memory to make vectors for each task when they would just be copied into registers which is also memory. My solution was to also play a game with RTWP for round-robin mutli-tasking by presetting R13,R14,R15 in every task so they all point back to each other in a circle. This means the vectors live in registers not data memory. Then to context switch, I just run RTWP. I think that with later CPUs in the TI universe they added an instruction that did something like this but I can't remember where I saw it or how it worked.

I have had too many interruptions to my coding time over the last while so the most I can do is cleanup. The conductor of of the community orchestra I joined decided it would great for us to play the Telemann concerto for two Violas. I started playing the darned thing only a year ago! This old guy needed to do a lot of practicing. Also, the homeschool coop is doing a play version of the Greatest Showman and my daughter, who I can't refuse, ask me to be in the band. Anyway during my cleanup time I reviewed my rendition of @Reciprocating Bill 's Asm sieve converted to ASMForth. If we re-name registers, they look like variables in Forth code. This code gets much more readable IMHO. This model of "machine Forth" fits much better with 9900 than Chuck Moore's machine Forth for the same reason Chuck's machine Forth was mostly one to one with his instruction set. ASMForth is mostly one to one with 9900 except for loops, sub-routines and whatever high level Forth words you wish to create. And here is the resulting code from Classic99 Dissassembler with some comments

That sounds very good. I may fool around with that. I don't use BLWP for setting VDP addresses because its a leaf and a fast BL seemed all I needed I reserve full context switching for task switching in my system. With a return stack implemented it not a big deal to save a register or two if you are short somewhere but so far I find with passing parameters on the data stack and 6 scratch registers I have never needed to push/pop registers. YMMV as they say. But if I understand you correctly I can READ VDP without worrying about using LIMI 0 ??

Not a popular idea but here is what I did. @dhe I put my LIMI 0, in my address setter sub-routine. There is one entry for writing (ORing a register with >4000) WMODE and another entry for reading, RMODE. It slows it down, but it's always in the right place. At the end of each VDP routine I re-enable interrupts. This allows me to do sprites and motion interactively from the interpreter which is pretty fun. In the for what it's worth department... It's all in RPN Assembler but if you feel the need to read code while hanging from the ceiling upside down here it is. CAMEL99-ITC/Compiler/cc9900/SRC.ITC/TI99IOX.HSF at master · bfox9900/CAMEL99-ITC · GitHub

Could be worse. Japanese students have four alphabets to learn. Hiragana, katakana, Kanji (sub-set Chinese characters) and "romanji". (our alphabet) I have read it can take up to twelve years of school for full fluency.

"Write the game snake in Python" 🤯

It's nice to have a smart person around the house. That's really neat to see that explained so clearly. Your work gives me the impression that this should be a very good PRNG. My burning question: When we dumb it all down to a >300 byte screen position or a random direction vector, is there a way to know that the BASIC or XB PRNGs would provide a material benefit versus a simpler solution? (You helped me with a simple analysis tool a few years back, but I am a humble business weanie so the amount of rigour involved was slightly less. One might say it was completely devoid of rigour.)

Those eyes are making me think of this screen saver I made. eyes.mp4 EYESII EYESIJ EYESIK

Wow that's important stuff. Bravo. There was a guy in the 90's in the UK who was doing railway systems in Forth. He had developed a method of proving the code was safe I believe which was a specification requirement. His name is escaping my old brain at the moment. Did some googling. It's Paul Bennet. https://wiki.forth-ev.de/lib/exe/fetch.php/en:projects:a-start-with-forth:certifyingforthsource_004_.pdf But nobody would begin to believe you can do anything well in Forth in the 21st century. I mean really, how could you, the compiler is not even 1MB.

Ya that was an insight that simplified my coding of Forth conditionals. ( = < > 0= etc.) Since CLR and SETO don't play with status you can compare a register, then clear it or set it to -1 as a default result. Then you can change the register based on the previous comparison instruction. It's almost like the 9900 designers knew how to write an instruction set. Something like: ( Apology in advance. I don't use normal Assemblers often) ZEROEQ CI R4,0 * 0= compare top of stack cache to zero CLR R4 JNE $1 SETO R4 $1 NEXT * return to Forth However even though it's only four instructions you can see why a native code compiler would be more efficient on 9900. In MACHFORTH or ASMForth this is only two instructions, compare to zero and the jump.

Very naughty photo. Your nerds are showing.

Nice to see you back Mark. I suspect life has gotten in the way of the serious job of playing with Forth on a 40 year old machine.

If you can convince a local TV station to do the story that gets people's attention. Better if it's a national network station where the story can get distributed across the country.

Excellent. Why? For that time that you need it and it won't work as expected. However if that is unthinkable then you are correct. Don't write code for stuff that "might" happen.