XB Game Developers Package

[senior_falcon]

Yep, just as I expected. Byte 1 of the PAB was not being cleared after the error and so the second error this causes forces the compiled program to halt. Here is a revised version of RUNTIME7. There are two changes:

The error bug is fixed.

I now reserve >110 bytes for the PAB which should allow a name with a length of up to 255 characters.

Replace RUNTIME7 in the FRAPPATO disk with this one. With any luck this will fix up the problems you are having.

This works in my (not very thorough) testing but it is a good idea to save the old version of RUNTIME7 just in case...

RUNTIME7103018.zip

[+arcadeshopper]

Yep, just as I expected. Byte 1 of the PAB was not being cleared after the error and so the second error this causes forces the compiled program to halt. Here is a revised version of RUNTIME7. There are two changes:

The error bug is fixed.

I now reserve >110 bytes for the PAB which should allow a name with a length of up to 255 characters.

Replace RUNTIME7 in the FRAPPATO disk with this one. With any luck this will fix up the problems you are having.

This works in my (not very thorough) testing but it is a good idea to save the old version of RUNTIME7 just in case...

 

That resolved it!

Greg

[+arcadeshopper]

btw.. with the new version on the latest classic99 I get a screen like this (and lockup/beeeeeeee) when i go to assembler.. i end up running fw from the old version to assemble

 

 

Greg

[senior_falcon]

btw.. with the new version on the latest classic99 I get a screen like this (and lockup/beeeeeeee) when i go to assembler.. i end up running fw from the old version to assemble

 

Greg

That is a mystery to me. It works fine on my system. I was using QI398 so to be sure I just downloaded the latest version, QI399.004. It works the same - no funny colors and no lockup.

Maybe there is some setting in classic99 that is wrong? Maybe you downloaded a corrupted copy of either Classic99 or my program?

I am using Windows XP. Maybe it is a problem with Windows 10, but I don't see why that would matter.

Edited November 1, 2018 by senior_falcon

[Tursi]

I develop in Windows 10. If there's a Windows conflict with Classic99, it's from NOT running Windows 10.

[senior_falcon]

I develop in Windows 10. If there's a Windows conflict with Classic99, it's from NOT running Windows 10.

As I remember you thoroughly tested Encruzado and had no problems like this.

[+arcadeshopper]

That is a mystery to me. It works fine on my system. I was using QI398 so to be sure I just downloaded the latest version, QI399.004. It works the same - no funny colors and no lockup.

Maybe there is some setting in classic99 that is wrong? Maybe you downloaded a corrupted copy of either Classic99 or my program?

I am using Windows XP. Maybe it is a problem with Windows 10, but I don't see why that would matter.

 

Ok well I had this problem in cl99 older version and in the latest (I downloaded latest and overwrote the dir..) I'll try first..resetting cl99 to stock (remove the ini) and then second re-downloading the compiler and try that..

 

Greg

[+arcadeshopper]

 

Ok well I had this problem in cl99 older version and in the latest (I downloaded latest and overwrote the dir..) I'll try first..resetting cl99 to stock (remove the ini) and then second re-downloading the compiler and try that..

 

Greg

 

It took resetting the ini AND redownloading the package.. /shrug I can crash again with the old ini..(attached)

classic99gmold.zip

[senior_falcon]

 

It took resetting the ini AND redownloading the package.. /shrug I can crash again with the old ini..(attached)

I tried your ini file and the assembler worked fine. Be sure to check "Write DV80 as windows text". Also it is helpful (but not essential) to "Enable long file names" and "allow more than 127 files"

[Tursi]

I tried your ini file and the assembler worked fine. Be sure to check "Write DV80 as windows text". Also it is helpful (but not essential) to "Enable long file names" and "allow more than 127 files"

 

Both of those options are for directories only. They default to off, and I recommend they not be turned on in the general case, as any software that makes assumptions about the directory will probably crash. (My experience was that long filenames were often tolerated, but more than 127 files was almost always a crash).

 

New software that wants to read the directory in a more flexible manner may open the directory as IV0 rather than IF38 (IF0 was also legal for legacy) -- if it succeeds, you can expect long filenames and a potentially unlimited file count. If it fails, fall back on IF38 and expect the legacy behaviour.

 

https://docs.google.com/document/d/1zIMDd9gv5xTAa3ym_YcFc3FqLxDTFGIvHcY3xMVVEaw/edit?usp=sharing

Edited November 2, 2018 by Tursi

[senior_falcon]

Tursi knows best. And come to think of it, you'll have trouble if you try to transfer a long filename to a real TI99.

[Tursi]

Oh, I use long filenames extensively, I just don't recommend letting Classic99 return them in the standard directory reads. Too much software was written with strong assumptions.

 

When I first did it I thought it was great, cause the standard TI BASIC directory program worked just fine. Then assembly software started crashing. Having the different open mode lets programs that can deal with long filenames directly ask for them.

[senior_falcon]

I'm excited about a change that is in the works. Currently the bottleneck in the compilation process is the compiler, which is an XB/Assembly hybrid program. I thought it would be too complex to convert it all to assembly, but I figured out how to modify it so that at least the main loops are totally in assembly. Although it is still an XB/Assembly hybrid, there is about a 5x improvement in speed. A program which used to take 60 seconds to compile now takes 12.

I am still in the testing stages at this point.

[+TheBF]

A program which used to take 60 seconds to compile now takes 12.

I am still in the testing stages at this point.

 

I am curious. Is that compile time in Normal speed or overdrive? Any idea how many lines are compiled in that time?

 

In normal speed I can't get Forth past 14 lines per second last time I checked. That is using the DSRLINK in Assembler and the wordlist search (linear linked list) in Assembler.

[senior_falcon]

 

I am curious. Is that compile time in Normal speed or overdrive? Any idea how many lines are compiled in that time?

 

In normal speed I can't get Forth past 14 lines per second last time I checked. That is using the DSRLINK in Assembler and the wordlist search (linear linked list) in Assembler.

This is compiling the BASIC program APERTURE. The modified compiler is now fully functional. Using CPU overdrive on an old Dell Optiplex 780, APERTURE is compiled in 14 seconds with the new version vs 89 seconds with the old version, so the speed increase is more than 6x to fully compile the program.

APERTURE has 506 lines. Running in normal speed compiling it takes 95 seconds which gives 5.3 lines per second. The 506 line XB merge file is read in two passes. The first time through no DATA statements are processed, and the second time through only DATA statements are processed. An assembly source code file of 2068 lines is created during the compilation process. (If you were running this on a real TI99 I think it would be slower; as far as I know Classic99 has faster disk access.)

[+TheBF]

Thanks for the info. After asking you the question I stayed up and looked for any roadblocks in the Camel Forth compiler code and I got it up to 18 lines per second.

(EDIT: This was loading my tools file which has more empty lines. I tried again this morning with my Assembler which is 252 lines in total and much denser text and I only got 12 lines per second.)

Added a video of the test process In the CAMEL99 thread:

 

http://atariage.com/forums/topic/273872-camel99-forth-information-goes-here/?p=4158571

 

I removed a repeated call to a memory copy routine and put it inline in the parsing routine. Makes the kernel a bit bigger, but I had room.

 

So old fashioned Forth is still pretty good in the compiling department. But yes it is much slower waiting for my floppy drives to move their heads around the tracks than Classic99. However when you consider that it compiles directly to memory, with no Assembly phase it makes for a pretty productive environment on the old TI-99.

 

The negative is that it is not generating native code like your compiler. (unless you load the Forth Assembler and write assembly language)

 

I know the guy who runs MPE Forth in the U.K. On modern systems, they claim their native code compiler can generate about 500KB of binary code per second, limited only by the disk drive speed! Things have certainly changed in 40 years.

Edited November 16, 2018 by TheBF

[senior_falcon]

Here is the newer compiler mentioned in the posts above. As near as I can tell the code created is exactly the same as the earlier version, only 5 to 6 times faster. Just replace COMPILER in the FRAPPATO package with this COMPILER.

 

The thing that made this fairly straightforward was the realization that you can open a file in XB and write lines to it, then an assembly routine can use the pointer at >833C to find the address of the PAB. The PAB has the address of the buffer, and with that information you can have the assembly routine write lines to the same file that was opened in XB. When done you can jump back to XB and write still more lines to the file. The disk system doesn't care whether the lines are created in XB or Assembly.

Faster Compiler.zip

Edited November 17, 2018 by senior_falcon

[senior_falcon]

Here is a "real world" speed comparison between the old and new compilers. First I loaded APERTURE and made a change to it. At that point, to save the modified program, compile it, assemble it (using Asm994a), load it and save the resulting program in both EA5 and XB format it took:

35 seconds with the new version

110 seconds using the old compiler.

This is using Classic 99 and cpu overdrive on my 10 year old Dell Optiples 780. With a newer and faster computer you would be able to get almost instant feedback on the results of changes.

[RXB]

Brilliant! Love this examination of the way XB works.

[senior_falcon]

I have just finished some modifications to the compiler that allow the programmer to use "nested arrays".

If you have:

10 DIM A(5,5,5)

20 DIM B(10,10)

and you want a line like this:

30 X=A(1,2,B(3,4))

previously you had to break it into two segments:

30 T=B(3,4)

40 X=A(1,2,T)

Now the compiler handles that automatically. The code works, but I want to be sure it is thoroughly tested before releasing.

 

While I am at it I will also add this capability:

10 A,B,C,D=7

Till now, I never knew that XB permitted this in a program line like this:

10 IF Z=3 THEN A,B,C,D=7

 

Going away on vacation, so it will be a while...

Edited December 12, 2018 by senior_falcon

[senior_falcon]

The compiler now supports nested arrays and multiple variables in a LET statement such as 10 A,B,C=7 and even nexted arrays in a LET statement like 10 A,B,C(1,(D,4))=7

I fixed a minor bug in printing a value in an array followed by a semicolon.

I am looking into adding speech. I have never done speech from assembly and to me, that section of the manual might as well be written in a combination of gaelic, swahili and mandarin. However, I am making progress.

 

(edit) I also added a tiny bit of error checking. The compiler now looks for decimal points in program lines. i.e.

10 X=3.14

This would give the message:

L10 NON INTEGER

and then you can go back to XB to fix the error.

 

Before it would compile fine but the assembler would complain with a cryptic message.

Edited December 26, 2018 by senior_falcon

[Opry99er]

 

How lucky are we to have this incredible stuff at our fingertips?!!

[HOME AUTOMATION]

I am looking into adding speech. I have never done speech from assembly and to me, that section of the manual might as well be written in a combination of gaelic, swahili and mandarin. However, I am making progress.

Hola senior f,

 

The pages on speech in my E/A MANUAL are "most worn" second only to; the page on "9901 interupts"(multiple error patterns). The operation and example are quite simple, however their presentation/explanation seems mythical... combining the two examples of different ways to address the system into one program was a needlessly complicating and a seemingly "dirty trick"... including use of a few new lines not described anywhere else in the book... and the comments...Never mind,... I'm sure you'll get it though, with enough patience!

 

Ha!(HOME AUTOMATION)

Edited December 26, 2018 by HOME AUTOMATION

[LASooner]

Great stuff Harry!

[senior_falcon]

Speech is starting to come together. This program now talks when compiled!

10 CALL SAY("HELLO")

20 GOTO 10

Now I have to make it handle things like CALL SAY("HELLO HOW ARE YOU") and spelling out words that aren't in the resident vocabulary.