Willsy

Very sorry to hear to this and sincerest condolences to family and loved ones. I'd like to suggest that Yesterday's News be pinned at the top of this forum. It's a fascinating read, and it would be a shame for it to fall in obsolescence and be forgotten as it gets pushed down further and further with each new post.

Yeah, I'm lurking and post the odd drive-by here and there! Doing a lot of embedded electronics and C++ these days, and that's not even my main job! For my main job I've been developing a comms driver in C# to talk to legacy RTUs are that used over the entire length and breadth of the UK (controlling railway switching) - so pressure then :-)

Been racking my brains to remember why I did it, but came up short. I *thought* I may have done it because it produced faster code, but as Lee has pointed out, it doesn't. Unless I did it under the mistaken assumption that the produced code was faster. The only other thing I can think of is perhaps it made the internal words that calculate jumps (that would be (IF) (THEN) and friends) a little bit shorter? I remember literally scouring the code base looking for ways to save single instructions here and there in order to fit some new word/feature into the 16K ROM space.

Compiled fine on my Mint system (once I installed SDL lib!) - it's asking for the rom files - Failed to load ROM/GROM files: 994arom.bin 994agrom.bin Any pointers? Thanks Mark

I'm pretty sure the original source for this is a magazine article. I'm 90% sure it would have been a TI*MES article since I'm a Brit and us Brit 99ers were fed on a diet of TI*MES back in the day. Stephen Shaw will probably remember. I can't remember his handle on this forum. Yeah, I was pretty impressed with the Forth cut, until @sometimes99er did a version in assembly which blew everything away! Doh!

It's been fun catching up with all this SAMS shenanigans! I remember my Eureka moment when I did that SAMS library for TF. I thought it was pretty neat. You've taken it even further which is really great . Will any of this run on TF?

A 9995 accelerator did exist for the 4A, but not in a commercial form. It was built by Colin Hinson who was a TI UK (Bedford) employee. It was in my possession for a while, but it was already non-functional when I got it. From memory, it consisted of a project board upon which Colin had soldered legs to sit in the original 9900 slot on the motherboard. On the project board was a crystal, a 9995, and maybe two other chips - a PALs or GALs. Can't remember. I never saw it running but according to Colin it worked fine until the board it was hosted on was cannibalised for parts. This was in 1994. I'd be surprised if Colin was still with us now, as he was in his late 60s and already retired when I met him.

Nice game! I changed the code to make the loading of screens much faster. It will now load each screen in a few seconds. I had to convert the level files to a different format to do that - just wrote some XB to do the hard work for me. Been years since I wrote XB! I also updated the level editor to use the new file format. The editor could be improved by adding an option to load a screen into the editor for editing. MARBLEMAZE.zip

"Easing yourself back in"? You just can't let the butt jokes go, can you? Hope you're feeling tip-top soon, man!

I just see programming as learning to break a problem down into little steps and solve them one at a time. The language that we use to express our instructions to the computer is irrelevant. It's the problem solving aspect that is the important thing.

Listening to the Darknet programme, boy did Gary get a raw deal. Nintendo, frankly, should be ashamed of themselves.

Gary Bowser was recently featured on the Darknet Diaries podcast. Very interesting. Episode 136. Search for it, or try the following link... https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5tZWdhcGhvbmUuZm0vZGFya25ldGRpYXJpZXM/episode/NWYwNmYyYTAtMTkzNS0xMWVlLWFhZTctNmZjMjMwNGQ5NmIx?ep=14

Yep. That works too. Though I'll need to study the code to understand why. I'm somewhat rusty! I've never seen COUNT used in a loop like that, so my eyebrows are on the ceiling right now!

Wow that's great! I learned something about my own Forth system! I actually had to type it in to TF and try it. Worked like a charm

Yep. Classy. Love the Philips look! Just don't make it beep with every character typed! I have traumatic memories of my 800XL beeping with every single keypress in BASIC. It was like a dentists drill. It wasn't a nice gentle decaying "ping!". It was like the TI BASIC "HONK" but much worse. Why didn't I just turn the TV volume down? Atari carried the legacy on with the Atari ST. At least it went ping. But you still wanted to throw the computer through a window. A pox on all their houses!

Can I just say how happy I am and how proud I am to see 5 pages of what one could ostensibly call "toilet humour". I didn't know you yanks "had it in you" (boom tish!)

Meh. It's assembly. You're free to screw up in any way you like! You're in control. And with that comes responsibility. I'm sure I use this trick in TF somewhere to save two bytes. As a space saver it's a useful technique when bytes matter more than speed. Meh.

NLQ! Wow! Haven't heard that for donkeys years! Near Letter Quality! Took twice as long to print your doc, and twice the ink, because it printed each line twice, just offset by 0.5mm or so!

That's really impressive! It kind of irks me that, back in the day, the C64 got all the attention, but the potential was always there in the TI - it was just kind of locked away. The games and demos we've seen in recent years for the TI show it quite comfortably hold its own with the C64 IMO. And it doesn't have 175 different shades of brown in its colour pallete, so the TI wins all 'round

Dunno about C on the TI, but in general, you wouldn't call a function from within an ISR. Generally, you'd just set a flag in the ISR to flag that an action is required, and pick it up in your main loop, then reset the flag. That's how I implement all ISRs on AVR/ESP32/ARM. The C function stack could be a little heavy to set up and tear down in an ISR? If you restrict your ISRs to just setting simple flags you may not have to change the WP for the ISR at all. Just my two cents

Saw this online. Could be interesting. https://www.hackster.io/news/shiela-dixon-s-prototype-add-on-turns-a-raspberry-pi-rp2040-into-a-tms9918a-video-card-with-extras-4dbabbe231d1

Sure. First, the code; --BLOCK-00020--------- CR 16 CLOAD file-type TRUE VALUE cswtch .( BLK>FILE - dumps a range of blocks to a text file.) .( e.g. 1 21 BLK>FILE DSK2.BLKDUMP) : SZ ZEROS ! ; : HDR cswtch NOT DUP TO cswtch IF ." On" ELSE ." Off" THEN CR ; : BAR S" --BLOCK---------------" 2DUP >R >R DROP 8 + SWAP -1 SZ N>S 0 SZ ROT SWAP CMOVE S" " file-out #PUT DROP R> R> file-out #PUT ; .( HDR toggles headers on and off.) : BLK>FILE ( start end -- ) DEPTH 2 < NOT IF file-type DROP out-spec CMOVE [ CHAR O LITERAL ] out-spec + 1- C! set-out-file file-out #OPEN ABORT" Can't open output file" 1+ SWAP DO I cswtch IF BAR THEN DROP I BLOCK 16 0 DO DUP HERE 64 VMBR HERE 64 -TRAILING DUP IF file-out #PUT ELSE 2DROP S" " file-out #PUT THEN DROP 64 + LOOP DROP LOOP file-out #CLOSE ELSE TRUE ABORT" Syntax error" THEN ; That's directly from the disk block (block 20 on the TF boot disk). Here's a tidier version (note: this is old code, and is likely really terrible): CR 16 CLOAD file-type TRUE VALUE cswtch .( BLK>FILE - dumps a range of blocks to a text file.) .( e.g. 1 21 BLK>FILE DSK2.BLKDUMP) .( HDR toggles headers on and off.) : SZ ZEROS ! ; : HDR cswtch NOT DUP TO cswtch IF ." On" ELSE ." Off" THEN CR ; : BAR S" --BLOCK---------------" 2DUP >R >R DROP 8 + SWAP -1 SZ N>S 0 SZ ROT SWAP CMOVE S" " file-out #PUT DROP R> R> file-out #PUT ; : BLK>FILE ( start end -- ) DEPTH 2 < NOT IF file-type DROP out-spec CMOVE [ CHAR O LITERAL ] out-spec + 1- C! set-out-file file-out #OPEN ABORT" Can't open output file" 1+ SWAP DO I cswtch IF BAR THEN DROP I BLOCK 16 0 DO DUP HERE 64 VMBR HERE 64 -TRAILING DUP IF file-out #PUT ELSE 2DROP S" " file-out #PUT THEN DROP 64 + LOOP DROP LOOP file-out #CLOSE ELSE TRUE ABORT" Syntax error" THEN ; It relies on common file routines on block 16: --BLOCK-00016--------- \ Common routines for file utilities : file-type S" DV080SI" ; FBUF: thefile FBUF: file-out : >ftype file-type SWAP 1+ SWAP DROP SWAP CMOVE ; : rec-len BL WORD NUMBER 0> ABORT" Invalid record length" file-type DROP 3 + DUP 3 + SWAP DO BL I C! LOOP N>S file-type DROP 3 + SWAP CMOVE ; : D/V S" DV" >ftype rec-len ; : D/F S" DF" >ftype rec-len ; : I/F S" LF" >ftype rec-len ; : I/V S" LV" >ftype rec-len ; : open-file HERE COUNT thefile FILE thefile #OPEN ABORT" Can't open input file" ; : out-spec S" DV080SO" ; : get-filename BL WORD DUP -ROT HERE 1+ SWAP CMOVE DUP HERE 1+ + file-type ROT SWAP CMOVE 8 + HERE C! ; : set-out-file BL WORD DUP -ROT HERE 1+ SWAP CMOVE DUP HERE 1+ + out-spec ROT SWAP CMOVE 8 + HERE C! HERE COUNT file-out FILE ; : FT? ." Configured for" file-type 2- TYPE CR ; The common file routines above allow the file utilities to work on different types of files - DV80, DF80 etc.

Another quick one, for the benefit of anyone interested. You can use BLK>FILE to copy a block, well... to a file. Again, in Classic99 (in Linux or Windows) it's very handy to export a block to a text editor for some deft editing: Untitled 25.mp4

Ooh nice! That works like a charm! Regarding the colour/color debacle, I literally asked myself the other day "how do the Canadians spell colour?" and you've just answered it!

Yeah, that's pretty much it. And, as Brian said, the reason for CODE is to allow the fast loading of code words, without needing to load the assembler. If you're storing your application in a blocks file then CODE is your friend. You would build the application using the assembler, then, when finished, convert those ASM words to CODE words and incorporate into your source code. It's very useful when using Classic99 with the CLIP device. You can copy them into a text file on your host PC. Latterly, I've been building apps using text files rather than blocks. Blocks are fine until you want to insert a line halfway through your application! (Though there are some utilities to help move blocks around your disk. Type FILES when booted from the TF boot disk). I write the code as a text file on the PC, save it (as a .txt file) in the Classic99 DSK1 directory, then use the TF Text File Interpreter (block 44 of the utils disk - at least on my copy!) to load those text files directly into TF. Here's a video of me using it while working on a silly game I'm developing when the mood takes me. It's deliberately designed to look like a Sinclair ZX81 (which had no colour, no sound, and no graphics to speak of). Hence I add the grey background which is the only colour the ZX81 has! Luckily the audio was disabled when recording, so yoou can't hear me cursing with each dumb ass mistake! By the way, you can turn line display off in the text interpreter: FALSE TO SHOW should do it. It loads much faster. You can even turn it off in the text file itself. And then turn it on (TRUE TO SHOW) in the text file just before a word that you've modified. Then you can see it load, and turn the line display off again: : someWord ( -- ) blah blah blah ; true to show \ we want to see the next word being loaded : anotherWord ( -- ) even more blah ; false to show \ okay, as you were Untitled 24.mp4