Strange error, using Wilhelm Compiler (latest Classic99)

[Retrospect]

Hi guys. I've had a rather strange thing happen just now, attempting to compile an old game.

 

First of all, I've tried to make sure the code itself will sit well with the Wilhelm compiler, but it came up with this error.

 

The file itself is included if anyone can spot where I went wrong?

 

 

TESTER.zip

 

EDIT:

 

I've got the SAME error when trying to compile Sometimes99er's TI Basic program (the one where the aliens animate scrolling down)

 

There's an issue with a Runtime library?

Edited July 29, 2015 by Retrospect

[senior_falcon]

I think I know what is happening. On the compiler package that I released there are two versions of the runtime library. One has the .TXT extension and the other is in TI format. What I sent to Tursi only has the runtime library with the .TXT extension. I tried to make the compiler smart, so that if your assembled source code was in TI format it would use runtime routines that were also in TI format. If your compiled source code has the .TXT extension, then you clearly are not using real iron, so it looks for runtime routines with the .TXT extension. Try adding .TXT to the filename when you are compiling and see if that does not fix the problem. Also, be sure the compiler disk is in disk 1.

[senior_falcon]

Yep, that's it. With Classic99 you do not have to use the TI editor but can use a more advanced text editor, which you should be doing as you will see below. What I sent to Tursi has only the runtime routines in windows format with the .TXT extension and as noted above, you should use the .TXT extension on the source code created by the compiler.

 

With the compiler in DSK1 and TESTER-M in DSK3, run the compiler:

 

XB file to be compiled?

DSK3.TESTER-M

Assembly output file name?

DSK3.TESTER.TXT

Runtime routines are on DSK1

 

and compile as usual.

Now to assemble:

 

SOURCE file name ?

DSK3.TESTER.TXT

OBJECT file name ?

DSK3.TESTER.OBJ

 

and the rest as usual.

 

You get the following error message:

SYNTAX ERROR - 0499

0001 ERRORS

 

What's this all about? Let's take a look:

Open up TESTER.TXT with a text editor. I like to use Notepad++ but any should work. Line 499 is:

499 NC42 DATA .5

Aha! There is a floating point number that the compiler calls NC42. Do a search for NC42 and we find it in only one place:

L780
DATA SBTRCT,RND,NC42,NT1

In the XB program:

780 CALL SPRITE #B,46,RND*2+9,Y,X,-10,SGN(RND-.5)*20)

We have to get rid of the .5

SGN(RND-.5)*20 gives either 20 or -20 randomly

this can be replaced by INT(RND*2)*40-20 which will give the same results but without using a floating point number.

 

And that's a quick tutorial in how to debug a program you are trying to compile.

[Tursi]

I think I know what is happening. On the compiler package that I released there are two versions of the runtime library. One has the .TXT extension and the other is in TI format. What I sent to Tursi only has the runtime library with the .TXT extension. I tried to make the compiler smart, so that if your assembled source code was in TI format it would use runtime routines that were also in TI format. If your compiled source code has the .TXT extension, then you clearly are not using real iron, so it looks for runtime routines with the .TXT extension. Try adding .TXT to the filename when you are compiling and see if that does not fix the problem. Also, be sure the compiler disk is in disk 1.

Oh gosh... please don't write code that looks for Classic99 idiosyncrasies.. that's the last thing I want. I've overlooked CLIP before because it's useful, but something like that is yikes! (Plus the DSR /is/ intended to be on real iron eventually, so the assumption isn't going to be true forever...)

 

Can we please update the package in Classic99 /not/ to be Windows-based? I would rather not distribute that.

[senior_falcon]

The compiler with the two versions of the runtime routines (.TXT and native TI99) is in the attached folder.

 

My thinking in eliminating the native TI99 runtime routines was that there would be no need to use them in Classic99. Also, they are easier to make modifications to if someone wanted to do that. I will admit their absence would be a problem if you were to move the compiler over to a real TI, so it does indeed make sense to include them.

 

It sound like you think the ability to read and write DV files in windows format is an idiosyncrasy that should be eliminated. If that happens there will be some VERY unhappy users of Classic99!

XBGameDevelopersPackage061215.zip

[Retrospect]

Thanks for your help Mr Senior Falcon, I shall have another bash at compiling in a little while .... Hi Tursi , how are you? .....

I've just gotten hold of a new laptop today, it's an Acer Aspire V3 112 and it looks like a little TI with it's silver keyboard and black keys, very impressed with it, and of course, the first thing I downloaded? ... Why, classic99 of course ... and it runs it sweet as a nut with no lag or chug .... brilliant stuff

[Tursi]

The compiler with the two versions of the runtime routines (.TXT and native TI99) is in the attached folder.

Thanks

 

It sound like you think the ability to read and write DV files in windows format is an idiosyncrasy that should be eliminated. If that happens there will be some VERY unhappy users of Classic99!

No, it's an important feature. But the /software on the TI side/ should not assume that is what is happening - I have a real bee in my bonnet about software tying itself down to a specific disk interface - keep it generic and don't assume. In addition, the Classic99 DSR is going to be lifted wholesale into my MPD project for interface to the real world (which is why I keep trying to get you guys to help debug it ). There is /nothing/ going on in there that can't be done in the real world, and that's always been the goal of Classic99. Even the emulated keyboard is emulating my PS/2 adapter, it's not just faking it. (Try the Konami code ).

 

(Edit: I should note, too, that reading/writing Windows files in place of D/V is /also/ an OPTION - users can turn it off )

Edited July 31, 2015 by Tursi

[senior_falcon]

After thinking about this for a while I have come around to your way of thinking. For me there is a real advantage in having the runtime routines in windows format with the .TXT extension. That's just because it is so much easier to debug them. Once they are debugged there is no real advantage in having them in that format; the standard TI format would be fine. So I think I will put the windows format runtime routines in a separate folder that is part of the package. In the unlikely event that someone wanted to make improvements to them they would be available in a format that is easier to edit. The compiler would use TI format files as default and not try to be too clever. I will probably add a line early in the compiler program to specify what the file extension should be. Something like: 20 FE$="" as default that can be changed to 20 FE$=".TXT" if you had a reason to use the windows format runtime routines, and then later FE$ gets concatenated with the string being created by the compiler. I will get to this this weekend and send it to you.

[Tursi]

Okay, thanks! That's pretty much what I did with the files you posted above - I moved the Windows files to a separate folder (because yes, it's nice to have them for editing!) I'll replace the package with what you send!

 

I see what you're going for.. it's just that relying on side effects will cause the software to break. I'm already planning a change to how extensions are handled - I've been working on a recommendation paper for dealing with PC files and while building it, I've decided that a few things need to change for better compatibility.

 

On the other hand -- your FE$ concept will NOT break when I implement anything, just that the extension character will change to something TI legal.

[Retrospect]

Tursi, hello again ... just to ask a quick question, I have windows 8.1 , I've already been offered the free upgrade to win10 , which I clicked "remind me later" or something like that ... because I'm worried about compatibility issues - will Classic99 run on 10?

[Tursi]

Classic99 runs fine on the Windows 10 beta.. I haven't tested on release (not decided yet when I'll take the upgrade).

[Retrospect]

Classic99 runs fine on the Windows 10 beta.. I haven't tested on release (not decided yet when I'll take the upgrade).

 

I decided to take the upgrade yesterday .... Classic works just fine. I underestimated how long the whole download and install process would be though!