Vorticon

What I meant was that all I need is a pixel plot routine. Everything else can be derived from that, and a programmer can then create his own graphical routines which can certainly be shared with the community. I have a whole library of assembly routines I have created to put text on the bitmap screen, draw lines, etc... which I have used repeatedly with my programs (Skychart, Ultimate Planet etc...), and the same can be done in Forth. No need to reinvent the wheel everytime...

Willsy, there is really no need to have these kind of algorithms built-in (although it would be nice). I think a function to clear the bit map screen and another to put a colored pixel on the screen will be a great start. Everything else can go from there, and it will up to the individual programmer to come up with their needed graphics routines.

This is obviously crucial for games. However, I'm a big fan of the bitmap mode, and in that respect, TIF does seem to hold an edge over TF. The way I see it, I'll probably use TF for low res graphics applications, and TIF for my hi res mathematical explorations It is highly doubtful that I'll be using XB any time soon again And I can always imbedd assembly routines within Forth for even added flexibility.

TI Forth has no problem with multiple disks. They do need to all be the same size, which is irritating. You just need to change 2 user variables, DISK_SIZE and DISK_HI . Both of these are initially set at 90, which does, in fact, limit you to only one disk. If you have 3 disks you wish to use as DSK1, DSK2 and DSK3 and they are all 90KB, then you would need to change DISK_HI to 270 (3 * 90). This means that screens 0 -- 89 are on DSK1, 90 -- 179 are on DSK2 and 180 -- 269 are on DSK3. So that you don't have to remember to change the value every time you boot up, you can put 270 DISK_HI ! somewhere on lines 12 --14 of screen 3 of the system disk (for three 90KB disks) [Back it up, first!]. ...lee I got that much from the manual, but how do you FLUSH to a drive other than DSK1 the program that is currently being edited?

That I can do I was looking more for a mathematical or perhaps graphics comparision. Your Power of 7 demo clearly shows Turbo Forth being at least 35% faster Interestingly, XB is much faster than both for that specific test, at least until an overflow occurs, although it uses the scientific notation for large numbers. I do plan to experiment with the bitmap capabilities of TI Forth at some point though to see how easy it would be to work in that mode, which is notoriously a bear to use with in assembly. One annoying feature of TIF is the need to load modules at the beginning to access certain words, although this selective process likely saves memory. Another is the need to switch disks after boot because TIF can only FLUSH to DSK1, at least as far as I can tell. Overall though, not a bad implementation.

There is something weird going on with these disks... I am able to run TP99 fine from the disk images I created, but when I try to save a file entered in the Editor, the system crashes. This does not occur with the disks I received from Retrocloud, which are copies. Worse, while the linker (lk99) runs, it is refusing to link any modules, giving me an I/O error #2 everytime, even though the modules compile just fine with no errors with TP99, and seem fine when edited. Am I missing a step here? Anders, do you have original disks of TurboPasc'99 by any chance?

Incidentally, some of the disk functions for TI Forth seem to corrupt the system under Classic99, but work fine with Win994a. I was intrigued by its 64 column bitmapped editor, and I have to say that, while being very simple, it's also very easy to use, allowing the user to see an entire Forth screen (block) without scrolling. I'm not good enough yet with Forth to create a decent perfomance comparision test, and I was wondering if anyone here has compared TurboForth and TI Forth from a performance standpoint.

This program can only run under an emulator or on a real TI. Which emulator do you plan on using? IMHO, Classic99 is the easiest to use. If you use the latter, just unzip the file at the top of this thread and drop the SECTOR file in a DSK folder in the Classic99 directory. Assuming you picked DSK1, run the emulator with the Extended Basic cart, and once you see the * READY * prompt, type RUN "DSK1.SECTOR" (don't forget the quotation marks) and enjoy the game. I believe the zipped file contains a PDF scan of the game instructions. Hope that helps.

Lee, what are the major differences between your PDF manual and the original TI Forth manual? I have the latter.

OK. Here it is: TI-FORTH.zip ...lee Much obliged

Thank you guys for the explanations. Willsy, is all this info somewhere on your site?

Well, you can have more than one blocks file (for example) on the same disk. So, you can tell TF which blocks file to USE. When TF boots, by default it looks for a file called BLOCKS on DSK1 and if it finds it, it will load block 1 and obey whatever it finds in there. You can also hold down any key as TF starts (just after you select TF from the cart menu, try holding a key down) and TF will look for DSKn.BLOCKS where n is the key you are holding. So, if you hold down Z it will look for DSKZ.BLOCKS (ram disks etc permit drive letters as well as numbers). You can bypass auto-loading by holding down ENTER as TF starts, and you'll just go straight to the command line. I tend to have a blocks file for each application I am writing. So, if I were going to write a space invaders, I would probably create a blocks file called INVADERS and then just do a S" DSK1.INVADERS" USE to use it. In classic99, I have my standard blocks file, which loads automatically, and if I am always working in another application I will add a line like the following to the DSK1.BLOCKS file: S" DSK1.INVADERS" USE .( Using DSK1.INVADERS) Now, when I start TF, the normal DSK1.BLOCKS file loads, and it switches to INVADERS. Now, all block related operations (EDIT, BLOCK, LOAD etc) are directed towards my invaders file. Does this help, or does it create more questions? It definitely does. Thanks What about my question about editing?

That would be great! Thanks

Hi. I have some very basic questions: I understand that we have to create a BLOCKS file before we can enter a program using MKDSK DSKx.BLOCKS nn 1- Why is USE needed (or is it)? Can the string parameter in USE be any filename I want and not necessarily DSKx.BLOCKS? 2- If I EDIT block 1, and I reach the end of it's 1K, what happens then if I still have more program commands to enter? Does it automatically flow into block 2 or do I have to manually perform a 2 EDIT etc...? Sorry if this seems very elemental...

I was checking out my TI Forth diskette, and it turned out to be completely corrupted... Does anyone here happen to have a disk image of TI Forth by any chance, or is willing to mail me a copy?

In my book, game programming can be extremely challenging because not only do you have to struggle with the limited hardware resources, but you also have to make the end product fun! On the other hand, systems programming or scientific demos, while still challenging, can usually leave the fun part out. I love games, but my programming heart has always had a leaning towards scientific and mathematical projects (Model Rocket Simulator, Pi Calculator, SkyChart, Chaos Musings), and this is frequently reflected in my games as well where I rarely create arcade games (actually I only have one which is TI Puck from 1981!) and focus more on simulations. I other words, I know where you're coming from, but I still think you should give it a shot. You might surprise yourself!

This is really impressive! The possibilities are huge here.

Great! That makes 6 contestants so far, which should be enough to keep the contest alive This should be interesting.

Well, I can't say that the response to this contest was overwhelming... It's still 2 of us as of yet, even after posting on the Yahoo listserv. I guess this is going to be DOA unfortunately. I'm still planning on developing a project in Forth regardless, although I'm not sure if it's going to be a game or yet another geeky demo I feel that there is a lot of reluctance from TI ers to learn a new programming language, and I honestly can't blame them given the effort involved and the limited hobby time each of us has. Just look at the list of unfinished projects cluttering this forum, starting with Ultimate Planet which is still in limbo and in bad need of CPR...

OK! The Turbo Pasc'99 package has been posted in the Development Resources topic pinned at the top of the forum. Please let me know if you have any issues with it. I'll also upload it to Planet 99.

These are the files for the Turbo Pasc'99 Pascal development environment for the TI 99/4A designed by Wiposoft in 1986. The zip file contains 4 disk images in V9t9 format for the compiler, libraries and demos. The original German manual was translated by apersson850 (Thanks!!!!) to English. While Turbo Pasc'99 is not as complete an implementation of Pascal as the UCSD Pascal system, it does have the advantage of not requiring any special hardware other than 32K RAM and a disk drive, and will likely meet the programming needs of most TIers. I hope you find this package useful ADDENDUM: The current compiler disk image currently has issues. I am working at finding a fix if possible. TP99.zip TurboPasc99.rtf

I'll post it the document under the pinned Development thread here and on Planet 99 as well. I'll also create disk images of the disks I have for posting as well.

You are on a roll my friend I think you are now a prime candidate for Turbo Forth

It's really a shame it did not gain wider acceptance among TIers. However, now that we have excellent emulators available, it should become easier to program in UCSD Pascal. I picked up the manual last night and started reading it, and the first thing that struck me was how clunky the editor seemed, although quite functional once one gets used to it. This will take some getting used to again...

Do you think you could put in a short document the high level principles involved in accessing the bitmap mode from within Pascal? While I am extremely lousy at following someone else's code (and frequently mine as a matter of fact ), I can probably, at some point, recreate your processes from scratch and tailor them to my future needs.