Forth Tutorials

[+Vorticon]

I thought the DSK image on Atari age was the bug free one as it was posted by Lee...

[+Lee Stewart]

You need to have Lutz Winkler's version of the TI Forth disk. He did all the bug fixes.

I have it, and I will upload it here tomorrow. I'll put it up in Win994a.

 

Rod

 

I thought the DSK image on Atari age was the bug free one as it was posted by Lee...

 

I am reasonably sure that the DSK image I uploaded is free of all the known bugs. When Rod uploads his DSK image, I will compare the two to see if there are any differences.

 

...lee

Edited October 8, 2012 by Lee Stewart

[Rod Van Orden]

Lee:

Here it is.

I have included the Win994a TI Forth disk with Lutz's corrections, Lutz's tutorials from 1987 and a list of

the corrections and screen numbers. I suspect you have all of these on your copy, and you probably

found more and fixed everything previously. But double checking is the safe way to go......

 

 

 

 

ROD VAN ORDEN

San Diego, California

TI Forth to Lee.zip

[+Lee Stewart]

Lee:

Here it is.

I have included the Win994a TI Forth disk with Lutz's corrections, Lutz's tutorials from 1987 and a list of

the corrections and screen numbers. I suspect you have all of these on your copy, and you probably

found more and fixed everything previously. But double checking is the safe way to go......

 

 

 

 

ROD VAN ORDEN

San Diego, California

TI Forth to Lee.zip

 

Thanks! I'll get to it soon.

 

...lee

[+Lee Stewart]

Lee:

Here it is.

I have included the Win994a TI Forth disk with Lutz's corrections, Lutz's tutorials from 1987 and a list of

the corrections and screen numbers. I suspect you have all of these on your copy, and you probably

found more and fixed everything previously. But double checking is the safe way to go......

 

ROD VAN ORDEN

San Diego, California

 

Yeah, the disk image I posted does, in fact, have those corrections and a few more. See "Appendix J" of my edition of the TI Forth Instruction Manual available in the "TI-99/4A development resources" sticky thread at the top of this forum.

 

At first glance, Lutz's tutorials look to be good instruction. More, later.

 

...lee

Edited October 9, 2012 by Lee Stewart

[+Vorticon]

Quick question: it seems that >F in the floating point package of TIF is corrupting an area outside of the VDP rollout area and VSTPR stack (>03C0 - >045F) when in bitmap mode. I have been experimenting with floating point operations under bitmap mode, and I am able to eliminate all the screen corruption by saving that area prior to the operations, blanking the screen by placing a 0 in bit 1 of VR1, performing the operations, restoring the VDP area then re-activating the screen with a 1 in bit 1 of VR1. All except what looks like 3-4 bytes in the left lower 1/3rd of the screen, which I have isolated to the >F word through interactive testing (one of the great advantages of TIF).

Any idea what VDP area this might be?

[+Lee Stewart]

Quick question: it seems that >F in the floating point package of TIF is corrupting an area outside of the VDP rollout area and VSTPR stack (>03C0 - >045F) when in bitmap mode. I have been experimenting with floating point operations under bitmap mode, and I am able to eliminate all the screen corruption by saving that area prior to the operations, blanking the screen by placing a 0 in bit 1 of VR1, performing the operations, restoring the VDP area then re-activating the screen with a 1 in bit 1 of VR1. All except what looks like 3-4 bytes in the left lower 1/3rd of the screen, which I have isolated to the >F word through interactive testing (one of the great advantages of TIF).

Any idea what VDP area this might be?

 

The culprit is VAL , which is used by >F . The FP number string accepted by >F is first stored at PAD . >F then stores the string from PAD at 1000h in VDP RAM and adds a trailing blank before calling XMLLNK with the console subroutine number for CSN (convert string to number), which requires the string to be in VDP RAM. The problem in bitmap mode is that 1000h is 2/3 of the way into the bitmap color table, which is right where you noticed spurious stuff on the display. It is also the beginning of the TI Forth disk buffer, which is changed from 1000h to 1C00h in bitmap mode. The user variable DISK_BUF contains this address, so I do not understand why the TI Forth programmers did not use it instead of explicitly using 1000h. I have not tried this yet; but, you might try changing the definition of VAL in lines 13-14 of screen 47 from

 

: VAL PAD 1+ 1000 DUP FAC C + ! PAD C@ OVER OVER + 20 SWAP VSBW VMBW 1000 XMLLNK ;

 

to

 

: VAL PAD 1+ DISK_BUF @ DUP FAC C + ! PAD C@ OVER OVER + 20 SWAP VSBW VMBW 1000 XMLLNK ;

 

Just be sure to back up the disk or disk image first! Please, let me know what happens if you try this.

 

...lee

Edited October 10, 2012 by Lee Stewart

[+Lee Stewart]

The culprit is VAL , which is used by >F . The FP number string accepted by >F is first stored at PAD . >F then stores the string from PAD at 1000h in VDP RAM and adds a trailing blank before calling XMLLNK with the console subroutine number for CSN (convert string to number), which requires the string to be in VDP RAM. The problem in bitmap mode is that 1000h is 2/3 of the way into the bitmap color table, which is right where you noticed spurious stuff on the display. It is also the beginning of the TI Forth disk buffer, which is changed from 1000h to 1C00h in bitmap mode. The user variable DISK_BUF contains this address, so I do not understand why the TI Forth programmers did not use it instead of explicitly using 1000h. I have not tried this yet; but, you might try changing the definition of VAL in lines 13-14 of screen 47 from

 

: VAL PAD 1+ 1000 DUP FAC C + ! PAD C@ OVER OVER + 20 SWAP VSBW VMBW 1000 XMLLNK ;

 

to

 

: VAL PAD 1+ DISK_BUF @ DUP FAC C + ! PAD C@ OVER OVER + 20 SWAP VSBW VMBW 1000 XMLLNK ;

 

Just be sure to back up the disk or disk image first! Please, let me know what happens if you try this.

 

...lee

 

OK, I could not wait. I tried the correction and it works! I will include it as a correction in the second edition of the TI Forth Instruction Manual after positive feedback from @Rod Van Orden, @Vorticon, @Willsy (if you have a setup for TIF) and anyone else who wants to chime in. I want to be sure I have not corrupted the TIF system before I include it.

 

...lee

Edited October 10, 2012 by Lee Stewart

[Rod Van Orden]

Lee:

I have your TI-FORTH up and running under Win994a. However, I seem to be having a lot of trouble getting it over to

Ti994w and to Classic99. Come to think of it, I never ran TI Forth on any other emulator / simulator than Cory Burr's

Win994a. Normally, I just bring stuff over using TiDir. I think its a file v. sector issue....... Do you know how to convert over?

 

Rod

 

[+Lee Stewart]

Lee:

I have your TI-FORTH up and running under Win994a. However, I seem to be having a lot of trouble getting it over to

Ti994w and to Classic99. Come to think of it, I never ran TI Forth on any other emulator / simulator than Cory Burr's

Win994a. Normally, I just bring stuff over using TiDir. I think its a file v. sector issue....... Do you know how to convert over?

 

Rod

 

As you probably know, TI Forth can only be run with disk images. This is a problem only with Classic99, though @Tursi indicated he would soon enable sector writes. You can run TI Forth very nicely in Classic99; but, you cannot write screens back to disk when you make changes. For testing, you can EDIT a screen and LOAD it as long as no actual FLUSHing occurs in the process. The FLUSH will attempt to write to disk and throw an error. You should, however, be able to have a non-TI-Forth disk in FIAD mode to happily read/write normal TI files.

 

That said, to set up the disk image file for DSK1 in Classic99, you need to open the "Disk" menu and choose the first option, whether it shows a path or simply says "Set DSK1". For "Disk Type:", choose "Image (DSK)". Under "Path:", click on the ellipsis button to open the path dialog, find the disk image (it does not need to be any place special), highlight it and click "Open". Be sure then that "Editor/Assembler" is checked in the "Cartridge-->Apps" menu.

 

For TI994W, click the "File" menu and choose "Fiad and Doad". In the dialog that pops up, click the radio button beside "DOAD file" under "DSK1" and press the "Select" button to the right. This will bring up a path dialog similar to Classic99. You can even choose the same image file as long as it is not open in another program. Be sure then that "Editor Assembler" is checked in the "Modules" menu.

 

...lee

[+Vorticon]

OK, I could not wait. I tried the correction and it works! I will include it as a correction in the second edition of the TI Forth Instruction Manual after positive feedback from @Rod Van Orden, @Vorticon, @Willsy (if you have a setup for TIF) and anyone else who wants to chime in. I want to be sure I have not corrupted the TIF system before I include it.

 

...lee

Yes, it works perfectly. Lee you're a genius! Thanks!

[+Lee Stewart]

I am having trouble getting mounted disks to work in MESS v147. In fact, I have had this trouble with any version after v143. I would like to use the up-to-date version for TI Forth if I could; but, I guess I will just have to retreat to v143 unless someone here has some clue to what I might be missing.

 

...lee

[+Vorticon]

Hi.

Has anybody here ever tried running TIF on the v9t9 emulator? The reason I am asking is that I was able to run v9t9 on my Nexus 7 Android tablet using DosBox for Android, and it runs great except that I have been unable to get TIF to work... It would so cool if I could play with TIF on the go without needing a bulky laptop...

 

EDIT: Never mind... I had a typo in the disk path It works just fine albeit faster than a real TI.

Edited October 11, 2012 by Vorticon

[+Lee Stewart]

I am having trouble getting mounted disks to work in MESS v147. In fact, I have had this trouble with any version after v143. I would like to use the up-to-date version for TI Forth if I could; but, I guess I will just have to retreat to v143 unless someone here has some clue to what I might be missing.

 

...lee

 

 

OK, I figured it out! It was MESS itself, not MESSUI. MESS used to auto-populate the PEB with the ROMs it found in TI99_4A.ZIP. Now you must do it with the MESS popup menu. I say it is not MESSUI's fault; but, MESSUI actually ought to have a menu that allows you to set the PEB slots. Of course, the problem with not getting to the mounted disks was that the disk controller was missing from its "slot" in the "PEB"!

 

...lee

[Rod Van Orden]

Lee:

 

Thanks for the assist in installing TI Forth into Classic99 and Ti994w. I verified the problems in writing to sectors under Classic99.

However, I found that Ti994w allows TI-FORTH to operate and work fine. You can read and write Forth Blocks, etc. You seem to be limited

for now to the 40-column editor in Ti994w. The 64-column support, and the two Split Screen presentations don't operate...... could be the

character set not being in the right place..... Everything else seems to work fine, though. I have had very good luck and operation of

TI-FORTH (and TurboForth, as well) using Cory Burr's simulator, Win994a.

 

By the way, I placed the DSK image files for all of this into the DOAD folder for Ti994w. I ran across an 80-column TI-Forth that seems

to run under Ti994W using the V9938 VDP emulation. If you want this, I could upload it. However, its all in German. You might have to

break out the German dictionary to figure out what is going on.......

 

 

Rod Van Orden

San Diego, California

 

[+Vorticon]

Is there a repository for TI Forth software somewhere? The whtech ftp site does not seem to have any.

[+Lee Stewart]

Is there a repository for TI Forth software somewhere? The whtech ftp site does not seem to have any.

 

There are TI Forth program disks there, but finding them is painful. Some of the user group libraries have some. I do believe you're right about there not being one place on whtech labeled as such.

 

...lee

[+Vorticon]

I seem to have a bit of a problem transferring my TIF disks from the CF7 to the PC. Neither TIDir nor the cf2dsk utilities seem to produce usable images with Win994a or Classic99.

Is there any way someone could look at the attached DSK images produced by TIDir and see what to problem could be? Thanks!

TIF.zip

[+Lee Stewart]

I seem to have a bit of a problem transferring my TIF disks from the CF7 to the PC. Neither TIDir nor the cf2dsk utilities seem to produce usable images with Win994a or Classic99.

Is there any way someone could look at the attached DSK images produced by TIDir and see what to problem could be? Thanks!

 

I am not sure what you are trying to do here. TF.DSK has a file on it that looks to be a TF BLOCKS file. If you are trying to access this disk with TIF, you cannot do it as TIF screens. You will need to use it as a normal TI disk and open BLOCKS as a DF128 file. I have not yet looked at either TF.DSK or WORK.DSK as TIF screen disks to see what might be on them that way. I'll do that a little later. Right now I need to get outside to take advantage of the nice weather to work on re-routing a downspout.

 

...lee

[+Vorticon]

TF.DSK is my master TIF disk and WORK.DSK is my TIF work disk. I usually have TF in DSK1 and WORK in DSK2 and put all my non-system screens in WORK starting at screen 91. Of course I make sure to have 180 in DISK_HI prior.

The problem I have is that when I transfer these disks to the PC via either TIDir or cf2dsk, they are not recognized by Win994a or Classic 99.

Not sure if I'm doing something wrong here...

[+Lee Stewart]

TF.DSK is my master TIF disk and WORK.DSK is my TIF work disk. I usually have TF in DSK1 and WORK in DSK2 and put all my non-system screens in WORK starting at screen 91. Of course I make sure to have 180 in DISK_HI prior.

The problem I have is that when I transfer these disks to the PC via either TIDir or cf2dsk, they are not recognized by Win994a or Classic 99.

Not sure if I'm doing something wrong here...

 

If TF.DSK is your master TIF disk, it is corrupted because there should be only three files on it (FORTH, FORTHSAVE and SYS-SCRNS), none of them named BLOCKS. I checked the images with TI Forth and they do not have any TI Forth screens. WORK.DSK is blank except for disk header information, which, as you probably know does not need to be there for TI Forth unless you are working with TI files, in which case you should never put TI Forth screens on it. TF.DSK is devoid of TI Forth screens, as well. It has only a TurboForth BLOCKS file on it, which, of course, you can read with TI Forth, but it does not start on a TI Forth screen boundary.

 

...lee

[+Vorticon]

Here's a quick demo of my experimentation with bitmap graphics under TI Forth. This short clip will show 2D bitmap translation, scaling and rotation of a triangle. The first screen demonstrates translation and scaling, the second rotation, and the third all three combined.

As you can see, it's pretty slow, especially for larger triangles, primarily because the LINE function in TIF is quite sluggish. Initially rotation was way too slow to be usable because the transcendental functions, namely SIN and COS which are needed are slow themselves and also corrupt the bitmap screen, thus necessitating VDP cleanup operations which slowed things further. So I created Sin and Cos look-up tables instead in 1 degree increments and this sped things up significantly.

I have written a bresenham line algorithm in assembly for Sky Chart previouly, but I don't think it's any faster than the one in TIF. If you guys have a better algorithm, please let me know.

 

Next step: 3D!

 

http://www.youtube.com/watch?v=ivgLqaJwWzM

Edited October 14, 2012 by Vorticon

[+Vorticon]

If TF.DSK is your master TIF disk, it is corrupted because there should be only three files on it (FORTH, FORTHSAVE and SYS-SCRNS), none of them named BLOCKS. I checked the images with TI Forth and they do not have any TI Forth screens. WORK.DSK is blank except for disk header information, which, as you probably know does not need to be there for TI Forth unless you are working with TI files, in which case you should never put TI Forth screens on it. TF.DSK is devoid of TI Forth screens, as well. It has only a TurboForth BLOCKS file on it, which, of course, you can read with TI Forth, but it does not start on a TI Forth screen boundary.

 

...lee

This is problematic... My disks are fine on the CF7, so something must be happening during the transfer. I'll keep fiddling with it and see. Thanks for looking into it.

 

UPDATE: Solved it. I was transferring the wrong volume, namely Turbo Forth's disk instead of TIF... Take head, stick it in arse

Edited October 14, 2012 by Vorticon

[Willsy]

Yowsers! That's totally cool isn't it!

 

Wow, the line drawing routine IS slow isn't it? Compare it to the line drawing routine in the MiniMem LINES demo, which is pretty fast. It would probably benefit from something coded to run from PAD RAM.

[+Vorticon]

Quick question: when an array is first declared, are all the elements zeroed out?