Willsy

The only annoying thing about the PEB is the fire-hose. Or, more specifically, the console end of the fire-hose. It's absolutely huge. And when you remove the cover, you find nothing more than 4 or 5 buffers. The PCB could have been much much smaller. I always found that bloody huge PEB connector poking out of the side of the 4A to be a right PITA. The box itself? Brilliant.

I always had a soft spot for the Plus/4. It's actually quite a nice little machine. They fixed a bunch of stuff with it and the Commodore 16 - namely they put in a decent BASIC, and fixed the appalling disk drive performance. The built in machine code monitor was really cool!

I think the above is correct practice for FIG Forth systems. However for other systems, I would advocate the use of CREATE: CREATE WRDAD 30 ALLOT If you wanted 30 bytes of alloted space using VARIABLE (in TF) you would do: VARIABLE WRDAD 28 ALLOT Because the variable definition reserves 2 bytes for its own storage. Either approach will work just fine though. Then, as Lee mentions, since you are reading and writing 8 bit bytes (called characters in Forth parlance) then you need to be using C@ and C!. These work the same as @ and ! but they store 8 bits to a BYTE address, not a word address. @ and ! read and write from/to EVEN address only, and read/write two bytes at a time (16 bits). c@ and c! read/write from any address, and read/write single bytes (8 bits) at a time.

If you're trying to store some characters (from the keyboard) to an address in RAM, then the word EXPECT does exactly that. In TurboForth, using HERE to store data can potentially lead to confusing results. This is because TF itself sometimes uses memory pointed to by HERE as a temporary workspace. For example, IIRC, the upwards screen scroll when you press Enter at the bottom of the screen - it uses HERE as a line buffer when doing the screen scroll. Yep.... ; Scroll screen up by one line. Used by EMIT and CR to scroll the screen up if ; necessary (sub-routine, not a FORTH word). scrlup mov @noscrl,r8 ; test NOSCROLL jeq scrlno ; scrolling is supressed dec @scrY ; clip y coordinate to 23 mov @here,r8 <----- HERE BE DRAGONS - TURN BACK ALL YE FAINT OF HEART ai r8,4 li r6,23 ; 23 lines to shift clr r0 ; screen address sclup_ a @xmax,r0 ; move down one line mov r8,r1 ; address of buffer to store in mov @xmax,r2 ; number of bytes to store in the screen I've been bitten by that before it. It was a naive design decision on my part. You would have some data stored at HERE, and if the screen scrolled (like when you're working at the command line) your data gets wiped. You can get around it though: : HERE ( -- n ) HERE 80 + ; That should get you out of trouble. TF will use the internal version of HERE, but your code would use this version and store its data out of the way of the scroll buffer.

This sounds like an insanely complex joystick circuit! What were they thinking? Why, for example, is the -5v line even involved in such a circuit?!

This is nice. Local Variables is something I've played around with in TurboForth. It can make coding a LOT easier!! I have an uber complex version on github, with syntax stolen from Stephen Pelc's VFX. But I really like my Local Variables for the Common Man (*) because it is so simple! It would probably port over to Camel99 almost as is! * other genders are available

I wrote a starfield demo for TF years ago (2012). I tried running it today in the current version of TF and it doesn't work - TF has moved on since the early days. So, here's an updated version of the starfield program that I knocked together this morning, based on the old one: \ Sprite Demo for TurboForth 2022/10/10 MW : Message ( -- addr ) S" The power of Forth! " drop ; \ note: the string above should be 32 characters long : RollMsg ( -- ) Message DUP >R C@ R@ 1+ R@ 32 CMOVE R> 31 + C! ; : .Message ( -- ) RollMsg 0 0 GOTOXY Message 32 TYPE 0 23 GOTOXY Message 32 TYPE ; \ sprite character codes for small, medium, and big stars 0 CONSTANT Sml* 1 CONSTANT Med* 2 CONSTANT Big* \ joystick codes 1 CONSTANT JoyFire 2 CONSTANT JoyLeft 4 CONSTANT JoyRight 8 CONSTANT JoyDown 16 CONSTANT JoyUp \ define colours 15 CONSTANT White 0 VALUE FlipFlop : DoFlipFlop ( -- flag) FlipFlop NOT DUP TO FlipFlop ; \ set up user defined graphics for the 3 star sizes : UDG ( -- ) DATA 4 $8000 0 0 0 Sml* 256 + DCHAR ( small star ) DATA 4 $40E0 $4000 0 0 Med* 256 + DCHAR ( medium star ) DATA 4 $70F8 $F870 0 0 Big* 256 + DCHAR ( large star ) ; \ generate a random Y coordinate : RndY ( -- n ) 180 RND ; \ generate a random X coordinate : RndX ( -- n ) 256 RND ; \ set up our sprites. 10 small, 10 medium, 10 large : SetupSprites ( -- ) 10 0 DO I RndY RndX Sml* White SPRITE LOOP 10 0 DO I 10 + RndY RndX Med* White SPRITE LOOP 10 0 DO I 20 + RndY RndX Big* White SPRITE LOOP ; \ these routines set up the sprite movement list for each direction : GoLeft ( -- ) 10 0 DO I 0 -1 SPRVEC LOOP 10 0 DO I 10 + 0 -2 SPRVEC LOOP 10 0 DO I 20 + 0 -3 SPRVEC LOOP ; : GoRight ( -- ) 10 0 DO I 0 1 SPRVEC LOOP 10 0 DO I 10 + 0 2 SPRVEC LOOP 10 0 DO I 20 + 0 3 SPRVEC LOOP ; : GoUp ( -- ) 10 0 DO I -1 0 SPRVEC LOOP 10 0 DO I 10 + -2 0 SPRVEC LOOP 10 0 DO I 20 + -3 0 SPRVEC LOOP ; : GoDown ( -- ) 10 0 DO I 1 0 SPRVEC LOOP 10 0 DO I 10 + 2 0 SPRVEC LOOP 10 0 DO I 20 + 3 0 SPRVEC LOOP ; : Delay ( -- ) 100 0 DO LOOP ; : ScanJoystick ( -- n ) 0 JOYST CASE JoyUp OF GoUp 0 ENDOF JoyLeft OF GoLeft 0 ENDOF JoyRight OF GoRight 0 ENDOF JoyDown OF GoDown 0 ENDOF JoyFire OF 1 ENDOF 0 ( default case ) ENDCASE ; : Setup ( -- ) 1 GMODE 0 SCREEN 0 SSCROLL ! UDG SetupSprites GoRight ; : GO ( -- ) Setup BEGIN 0 30 SPRMOV ( move all 30 sprites ) Delay DoFlipFlop IF .Message ScanJoystick ELSE 0 THEN UNTIL ; This uses sprites. Use the joystick (or cursor keys on your PC keyboard) to change direction. Use Fire (tab on a PC keyboard) to quit. I've tried to make the code self-explanatory. You can always use the TurboForth Glossary to look up any words you're not sure of. Just use the search facility.

Oooh! Nice! Of course, this puts me in mind of the string stack that I knocked up years back, after discussions with your good self IIRC :-) http://turboforth.net/resources/string_library.html

Yes. They can be both be used together. TurboForth has as library (on block 5 of the companion disk) for SID support. I actually have a SID card so I wrote it in conjunction with Marc Hull back in the day. The code say's it's untested code. I can't remember if I tested it or not, but this would be be a good starting place for SID support for other Forth's too. --BLOCK-00005--------- \ SID chip support code. M.Wills, May 16th, 2011 $5800 CONSTANT SID : DUMMY ( -- ) [ SID $32 + ] LITERAL 0 C! ; : W>SID ( addr word --) DUP 2+ 2 PICK >< SWAP C! C! DUMMY ; : B>SID ( addr byte --) SWAP C! ; : SIDF ( freq ch# --) 14 * [ SID ] LITERAL + W>SID ; : SIDP ( pulse ch# --) 14 * [ SID 4 + ] LITERAL + W>SID ; : SIDW ( wform ch# --) 14 * [ SID 8 + ] LITERAL + B>SID ; : SIDA ( atdec ch# --) 14 * [ SID 10 + ] LITERAL + B>SID ; : SIDS ( susrl ch# --) 14 * [ SID 12 + ] LITERAL + B>SID ; : SFIL ( value --) [ SID $2A + ] LITERAL W>SID ; : SRES ( reson --) [ SID $2E + ] LITERAL B>SID ; : SVOL ( vol --) [ SID $30 + ] LITERAL B>SID ; CR .( SID support loaded.) .( Note: This is un-tested code)

Pleeeeeeease delete me........

IIRC JGT is a signed comparison. Have a look at the JHE which is (IIRC) unsigned. I could have that the wrong way around! The Editor Assembler manual is your friend!

Apologies - I see I have more or less copied @apersson850's post - I should have read down-thread first!

Yes that's a very import distinction. In Assembler parlance, we call the instructions of our code 'instructions', and the instructions for the assembler are called 'directives'. An instruction is assembled into your program. That's it's job after all. Directives are there to tell the assembler to do something while it is assembling your program. LI, BLWP, INC, DEC etc. are instructions (they are TMS99xx processor instructions). DATA, BYTE, BSS, BES, AORG are directives - they tell the assembler to do something while it is assembling the program.

'Twas @Stuart

Just curious, but where on does does one get C15 and other similar length cassette tapes these days?

I think Bob @atrax27407 might have the source code to Funnelweb or something like that. Bob?

In case it's of interest, I did yet another implementation of locals for TF back in February or so. It's only had minimal testing so far. https://github.com/Mark-Wills/TF-MegaLocals

Good luck with the upgrade and migration. Thanks for giving us TI-99/4A fans a great home over the last 10+ years!

Usagi connects his Centurion Mini computer to his TI-99/4A via RS232. I've been following the whole Centurion series with a mixture of fascination and overt jealousy, so this is the icing on the cake!

Presumably it's a linked list that has to be "walked" from the beginning to find a particular line number.

Yeah, >6000 to >7fff is cart ROM space, right? (It's been a while!) - there's no way you can get around that with TF. Use one of the other Forths, or roll your own assembly language test program. Wouldn't take much. We can help you with either.

@Ksarul makes a great point in this thread: "After reading thrugh this, it becomes quite obvious that this BASIC was NOT for a Dimension 4 or a TI-99/4. It expected an 80-column, Model 911 VDT, had numerous hooks that would have connected to TI's TX operating system (to include all 15 XOPS), and it was expecting a full 64K of system memory space in the form of RAM. All of this tells me that the two BASIC specification documents go together though, as the first document posted provided the required framework for TI BASIC on all machines, whereas this second document specified TI BASIC on some flavor of the TI-990. Since the first specification applied to anything developed at TI using the BASIC language and enforced high-level compatibility, the fact that folks conflated the Microsoft Assembler development of BASIC for a professional system (a TI-990) with the internal work on the GPL-based BASIC in the Dimension X/99/4 systems is quite understandable. It is even likely that there were instances where Mr. Greenberg talked to the consumer team to iron out potential differences between the two implementations, all in the effort of maintaining the enforced conformity between system implementations. That would also explain the recollections of having seen him once or twice during the development process, as he wouldn't have been tied to that team, but he would have had to coordinate some specifics of what he was doing on the other side (the 990 side) with them."

@FarmerPotato this is great. Thanks for the info and the links. I'll be having a read this weekend.

Mike, For a TF tutorial on IMMEDIATE words, have a look at this article. Once you understand it you've got immediate words down. Try the examples. Type them in and see what they do! Ask if you get stuck

Trivia time, Robert (Bob) Greenberg, of Microsoft. The guy who wrote TI BASIC: https://microsoft.fandom.com/wiki/Bob_Greenberg Bios: https://www.businessinsider.com/microsoft-1978-photo-2016-10?r=US&IR=T#steve-wood-went-on-to-become-a-serial-entrepreneur-9