Willsy

Yes. AHA!! *That's* what F9 is for in Classic99! I always wondered what use that feature was! Of course!!!!

That's done with CALL COLOR is it?

Ah! Ok... Don't think I've seen that before! Here you go... : WAIT BEGIN $8802 [email protected] $80 AND UNTIL ; : TEST 1 GMODE 1 SCREEN 5 3 12 COLOR 7 0 DO I 11 + 0 I 40 + 32 HCHAR LOOP BEGIN HEX DATA 10 FF00 0 00FF 0 0 0 0 00FF 0 0 0 0 0 0 FF00 0 28 DCHAR WAIT DATA D 0 0 0 0 0 0 0 FF00 0 0 0 0 0 2C DCHAR WAIT DATA 10 00FF 0 0 00FF 0 0 0 0 0 FF00 0 0 0 0 0 0 28 DCHAR WAIT DATA A FF00 0 0 0 0 0 0 0 0 00FF 2C DCHAR WAIT DATA B 0 FF00 0 0 00FF 0 0 0 0 0 00FF 28 DCHAR WAIT DATA D 0 0 FF00 0 0 0 0 0 0 0 0 0 FF00 2C DCHAR WAIT DATA D 0 00FF 0 0 0 0 FF00 0 0 0 0 0 FF00 28 DCHAR WAIT DATA F 0 0 0 0 00FF 0 0 0 0 0 0 0 0 0 00FF 2C DCHAR WAIT BREAK? AGAIN ; TEST

How do wait for the next frame in assembly? (I can't remember... )

: TEST 1 GMODE 1 SCREEN 5 3 12 COLOR 7 0 DO I 11 + 0 I 40 + 32 HCHAR LOOP BEGIN HEX DATA 10 FF00 0 00FF 0 0 0 0 00FF 0 0 0 0 0 0 FF00 0 28 DCHAR DATA D 0 0 0 0 0 0 0 FF00 0 0 0 0 0 2C DCHAR DATA 10 00FF 0 0 00FF 0 0 0 0 0 FF00 0 0 0 0 0 0 28 DCHAR DATA A FF00 0 0 0 0 0 0 0 0 00FF 2C DCHAR DATA B 0 FF00 0 0 00FF 0 0 0 0 0 00FF 28 DCHAR DATA D 0 0 FF00 0 0 0 0 0 0 0 0 0 FF00 2C DCHAR DATA D 0 00FF 0 0 0 0 FF00 0 0 0 0 0 FF00 28 DCHAR DATA F 0 0 0 0 00FF 0 0 0 0 0 0 0 0 0 00FF 2C DCHAR BREAK? AGAIN ; TEST It's a bit quick. Still, plenty of cycles left for other processing I suppose!

While we're talking about features, I have one that I think/assume would be fairly trivial to add? Can we have a 'warm reset'? I.e Reboots the TI but does *not* zero the RAM in the TI. In other words, it would mirror the behaviour of turning off the console, but leaving the PEB switched on? This would make post-mortem crash investigation easier in some circumstances (i.e. buffers would still be present in memory for inspection etc). So, I would propose to rename the current Reset entry in the File menu to Cold Reset, and add a Warm Reset menu entry as well. Just to be clear: Clearly *some* memory would be changed in RAM (mostly in pad) even during a warm reboot - there's nothing that can be done about that, that's just the TI running it's ROM - I'm just talking about skipping the initialisation of memory to 0 during start-up. As a total aside, not associated with Classic99, it's interesting the note the different behaviour of the TI 32K memory card and the SAMS card. When I power up my system with the TI card in (from power off) memory is mostly 0, with the odd FF in there. However, the SAMS memory is almost completely randomised! It's all over the place! Thanks

That would be a nice feature. TI994W has that feature.

Don't worry about that. By making the software available you increase the chances of people writing software to target the SID99, be it an emulated one or a real one. That's good news for SID99 owners like me! My card has died The card itself appears to be working ok, just no sound. I suspect the SID chip itself, which I bought from FleeceBay... I'll probably buy another sid chip in the next week or so and give it a try. My card is in slot 1 (next to the PSU) - it does get quite hot in there... Perhaps I should move it to another slot... Ouch. Try re seating the card a couple of times and /or changing it's location. Also clean the fire hose connection. That audio line path may be dirty/corroded somewhere. Ooh! Good point, I'll give that a try, thanks!

Don't worry about that. By making the software available you increase the chances of people writing software to target the SID99, be it an emulated one or a real one. That's good news for SID99 owners like me! My card has died The card itself appears to be working ok, just no sound. I suspect the SID chip itself, which I bought from FleeceBay... I'll probably buy another sid chip in the next week or so and give it a try. My card is in slot 1 (next to the PSU) - it does get quite hot in there... Perhaps I should move it to another slot...

A book, teaching all about Turboforth is in development. I must admit I got distracted and let it languish, but I've started work on it again this week. I'm now up to 160 pages!

How about this: : IF LOVE FORTH HONK THEN ;

Thank's we appreciate it a lot Hmmm, you are an Atariage site moderator. Pushing my luck now: Any chance you could add us as a news topic on the Atariage main page. The TI-99/4A and this group can for sure use some publicity Yeah, that's true. The 4A community is a great community; mostly because we have 'known' each other for years. However, there's not many of us. It would be lovely to get some new blood into the community!

Wow! I like that one! I managed to implement it with a little extra functionality and fit it into the spare space in bank 1 with 2 bytes to spare! Thanks So will you consider a 32K (4x8) ROM for the future version of Turboforth? Here's an idea, perhaps add the possibility for loading screens from ROM. You could use the remaing space to include a standard library of words with super-duper fast access. I don't think the 64K EEPROMS are that much more expensive than 16K EEPROMS nowadays. The current TurboForth lineage will end with V1.1 I think. I've taken it as far as I can in 16k. TurboForth 2.0 will probably be 32 or possibly 64K. If I ever start it. Some of the features: * Compile Forth code to native machine code (not threaded code) with inlining of certain words (e.g DROP DUP SWAP etc would be inlined). * Multi-tasking * Bitmap mode * A full suite of DOS words built in (DIR, COPY, TYPE, FORMAT etc) * Save/load memory image files It will essentially be a self contained alternative operating system on a cartridge. Marc Hull's idea of a multi-banked cart with RAM on it is the target (for me). Multi-tasking requires each task to have its own set of private variables, which can eat RAM, so the idea of 4K of ram in the cartridge is attractive. Since Marcs cart contains Flash memory, you could also load/save/edit code to 'virtual blocks' contained in the Flash memory chip. You would have access to around 200 blocks actually on the chip, living inside the cartridge. If these were compiled and BSAVED then they would load instantly. :-) We'll see.

Wow! I like that one! I managed to implement it with a little extra functionality and fit it into the spare space in bank 1 with 2 bytes to spare! Thanks

Thanks!

Does anyone have any suggestions for a random number generator in assembly language? A routine that generates a number between 0 and 65535 would be fine. I'm not satisfied with the Forth routine I have been using in TurboForth, so I'd welcome any suggestions. If anyone has any ideas, and the routine is short enough, I'd like to add it to the TF V1.1 code. I'll check MicroPendium etc but I thought I would give a shout out in case anyone has code already done, that they don't mind sharing. Cheers Mark

Okay...now we need a t-shirt Like this one? They're bloody expensive though - I don't set the prices, unfortunately. I ordered one for myself, so we'll see how it goes. I was going to get some done as gifts, but they're just too expensive... I looked at CafePress also, but their editor is rubbish

No problem - the only reason you have to hold break for a while is that I am only testing the break key at the end of the loop

That's by design. You can only "break" a program in TF if the program designer allows it There are two words associated with breaking a program: BREAK? ( -- ) Scans for FCTN+4 and terminates the program immediately if detected. (So, with BREAK? TF will stop the program for you) TERMINAL? ( -- true|false ) Scans for FCTN+4 and pushes TRUE if detected, else FALSE. (So, you can *detect* a break condition, and then decide what to do in your code) : BREAK-TEST 0 BEGIN DUP . 1+ BREAK? AGAIN ; : TERM-TEST 0 BEGIN DUP . 1+ TERMINAL? ABORT" Break was pressed - see ya!" AGAIN ; (in this code, the true/false pushed by TERMINAL? is fed into ABORT" - look up ABORT" in the gloassary FCTN+QUIT is disabled, because it is evil! You can test for it though. KEY? returns 5 when you press QUIT... So... KEY? ( -- keycode ) : TEST 0 BEGIN DUP . 1+ KEY? 5 = ABORT" Quit was pressed" AGAIN ;

Thought I would show some of the programming concepts in TurboForth. Most people will be able to follow this, I hope 1 GMODE 1 SCREEN \ 32 column mode, black screen \ define a hatch shape... : HATCH DATA 4 $AAAA $5555 $AAAA $5555 ; \ set up characters 144 to 248 with hatch pattern... : SET-HATCH 248 144 DO HATCH I DCHAR 8 +LOOP ; SET-HATCH \ execute SET-HATCH \ define a list of colours for our patterns CREATE COLORS \ this creates a dictionary entry called COLORS \ if you *execute* colors, it returns an address to the stack \ we will now compile a list of color values (bytes) directly \ to memory... 2 C, 3 C, 4 C, 5 C, 6 C, 7 C, 8 C, 9 C, 10 C, 11 C, 12 C, 13 C, 14 C, 15 C, \ at this point, we have effectively created an array called \ COLORS. COLORS returns an address, which is the start of the \ list of data compiled above. \ now we will set up the colors using the list... 0 CONSTANT TRANSPARENT : SET-COLORS 14 0 DO I 18 + \ color set number COLORS I + [email protected] \ fetch a color from the list TRANSPARENT COLOR \ set the color with transparent BG LOOP ; SET-COLORS \ execute SET-COLORS \ we can now remove ALL of the above code and data from memory. \ we dont need it any more... FORGET HATCH \ the above removes everything from HATCH downwards from \ memory, by resetting the dictionary pointers appropriately. \ the code below will compile over the top. This is a nice \ 'overlay' technique to save memory. \ scroll directions... 0 CONSTANT LEFT 2 CONSTANT RIGHT 4 CONSTANT UP 6 CONSTANT DOWN \ random number generator... $8379 [email protected] VALUE SEED : RND SEED 31421 * 6927 @ + $8379 [email protected] TO SEED ; \ initialise screen coordinates and character code... 0 VALUE X 0 VALUE Y 144 VALUE CHR \ clear the screen in a fancy way... : WIPE 16 0 DO 0 0 16 12 PANEL LEFT SCROLL 16 0 16 12 PANEL RIGHT SCROLL 0 12 16 12 PANEL UP SCROLL 16 12 16 12 PANEL DOWN SCROLL LOOP ; : KSCOPE PAGE \ clear the screen BEGIN RND 300 MOD 1+ 0 DO \ random repeat loop \ get random x & y for upper left quarter of screen: RND 16 MOD TO X RND 11 MOD TO Y \ display character CHR at x and y: Y X CHR 1 HCHAR \ display in lower left quarter: 23 Y - X CHR 1 HCHAR \ display in upper right: Y 31 X - CHR 1 HCHAR \ display in lower right: 23 Y - 31 X - CHR 1 HCHAR \ add 8 to CHR. if CHR>248 then reset to 144: 8 +TO CHR CHR 248 > IF 144 TO CHR THEN LOOP \ go back to BEGIN until finished WIPE \ clear the screen TERMINAL? UNTIL \ repeat, unless FCTN 4 is pressed PAGE ." Thanks for watching!" CR ; Just paste into TF and type KSCOPE. Press FCTN 4 to break. A more compact version of the code, with comments removed follows. Note how the first section of the program is essentially a 'script', and we only retain the second half in memory. 1 GMODE 1 SCREEN : HATCH DATA 4 $AAAA $5555 $AAAA $5555 ; : SET-HATCH 248 144 DO HATCH I DCHAR 8 +LOOP ; SET-HATCH CREATE COLORS 2 C, 3 C, 4 C, 5 C, 6 C, 7 C, 8 C, 9 C, 10 C, 11 C, 12 C, 13 C, 14 C, 15 C, 0 CONSTANT TRANSPARENT : SET-COLORS 14 0 DO I 18 + COLORS I + [email protected] TRANSPARENT COLOR LOOP ; SET-COLORS FORGET HATCH 0 CONSTANT LEFT 2 CONSTANT RIGHT 4 CONSTANT UP 6 CONSTANT DOWN $8379 [email protected] VALUE SEED : RND SEED 31421 * 6927 @ + $8379 [email protected] TO SEED ; 0 VALUE X 0 VALUE Y 144 VALUE CHR : WIPE 16 0 DO 0 0 16 12 PANEL LEFT SCROLL 16 0 16 12 PANEL RIGHT SCROLL 0 12 16 12 PANEL UP SCROLL 16 12 16 12 PANEL DOWN SCROLL LOOP ; : KSCOPE PAGE BEGIN RND 300 MOD 1+ 0 DO RND 16 MOD TO X RND 11 MOD TO Y Y X CHR 1 HCHAR 23 Y - X CHR 1 HCHAR Y 31 X - CHR 1 HCHAR 23 Y - 31 X - CHR 1 HCHAR 8 +TO CHR CHR 248 > IF 144 TO CHR THEN LOOP WIPE TERMINAL? UNTIL PAGE ." Thanks for watching!" CR ; Enjoy

Firstly, you are not closing the file after you have finished writing to it. That is SERIOUSLY bad. You would almost certainly lose records, even on a real TI. Secondly, it depends how you have set up DSK3. Check out the file options for DSK3.

You are not closing your output file (#2) at the end of the program. Why?

Buffers in the flex interface, or in the console. I imagine the memory cards, TI and SAMS will use the +12V line in the PEB and regulate it down to +5V so check the voltages on the PEB power rails. This is difficult to do, because you need to do it with the cards in - in other words, the power supply has to be loaded or otherwise it will look like it's fine when it might actually be weak under heavy load. There's a circuit board of electronics in the PEB associated with the PSU, but I'm not sure what it does.

It's a bug. Should have been [email protected] Sorry