Jump to content
IGNORED

Harry Wilhelm BASIC Compiler support for named subroutines?


mrvan

Recommended Posts

I'm trying to sort out why subroutines aren't called. I get errors when compiling in E/A. After studying the resulting ASM code, I can see the errors occur where the call for the subroutine should be. I can hand edit the resulting file and use GOSUB along with copying input and copying output after. Not sure this is the best way, and I'd certainly prefer the compiler to do the work. The compiler seems to include machine code that is called internally so I cannot see what the internal code is doing. Perhaps I have an older copy of the BASIC COMPILER, or one that only supports the original TI BASIC? No version is specified (that I can find).

 

Source Basic program:

90 MY$="KNOCK"

100 CALL CLEAR

110 FOR I=1 TO 4

115 K=I

120 GOSUB 175

130 NEXT I

160 PRINT "K=";K

170 GOTO 200

175 MY2$=MY$

180 PRINT "GOSUB I=";I;MY2$

190 RETURN

200 FOR I=1 TO 7

210 CALL PR(I)

220 NEXT I

230 END

240 SUB PR(V)

250 PRINT "SUB PR V=";V

260 SUBEND

Generated asm: Problem occurs at L210 and L240.

 

       DEF RUN,CON

RUNEA  B @RUNEA5

FRSTLN

L90

       DATA LET,SV1,SC1

L100

       DATA CLEAR

L110

FOR1

       DATA FOR,NV1,NC1,NC2,ONE,0,0

L115

       DATA LET,NV2,NV1

L120

       DATA GOSUB,L175

L130

       DATA NEXT,FOR1+2

L160

       DATA PRINT,SC2,SEMI,NV2

L170

       DATA GOTO,L200

L175

       DATA LET,SV2,SV1

L180

       DATA PRINT,SC3,SEMI,NV1,SEMI,SV2

L190

       DATA RETURN

L200

FOR2

       DATA FOR,NV1,NC1,NC3,ONE,0,0

L210

...PR.NV1..

L220

       DATA NEXT,FOR2+2

L230

       DATA STOP

L240

.NC4,NV3.

L250

       DATA PRINT,SC4,SEMI,NV3

L260

..

LASTLN DATA STOP

OPTBAS DATA 0

NC0

ZERO   DATA 0

ONE    DATA 1

PI     DATA 3

RND    DATA 0

NC1    DATA 1

NC2    DATA 4

NC3    DATA 7

NC4    DATA PR

NV0

NV1    DATA 0 I

NV2    DATA 0 K

NV3    DATA 0 V

SC0

SC1    DATA SC1+2

       BYTE 5,75,78,79,67,75

       EVEN

SC2    DATA SC2+2

       BYTE 2,75,61

       EVEN

SC3    DATA SC3+2

       BYTE 8,71,79,83,85,66,32,73,61

       EVEN

SC4    DATA SC4+2

       BYTE 9,83,85,66,32,80,82,32,86,61

       EVEN

SV0

SV1    DATA 0 MY$

SV2    DATA 0 MY2$

SA0

NA0

FRSTDT

LASTDT

       EVEN

       COPY "WDS1..lib..bc..rt1"

       COPY "WDS1..lib..bc..rt2"

       END

Handed edited fixed (or at least working) asm: Augmented at L210, L240 and L260.

       DEF RUN,CON

RUNEA  B @RUNEA5

FRSTLN

L90

       DATA LET,SV1,SC1

L100

       DATA CLEAR

L110

FOR1

       DATA FOR,NV1,NC1,NC2,ONE,0,0

L115

       DATA LET,NV2,NV1

L120

       DATA GOSUB,L175

L130

       DATA NEXT,FOR1+2

L160

       DATA PRINT,SC2,SEMI,NV2

L170

       DATA GOTO,L200

L175

       DATA LET,SV2,SV1

L180

       DATA PRINT,SC3,SEMI,NV1,SEMI,SV2

L190

       DATA RETURN

L200

FOR2

       DATA FOR,NV1,NC1,NC3,ONE,0,0

L210

       DATA LET,NV3,NV1

       DATA GOSUB,L250

       DATA LET,NV1,NV3

L220

       DATA NEXT,FOR2+2

L230

       DATA STOP

L240

L250

       DATA PRINT,SC4,SEMI,NV3

L260

       DATA RETURN

LASTLN DATA STOP

OPTBAS DATA 0

NC0

ZERO   DATA 0

ONE    DATA 1

PI     DATA 3

RND    DATA 0

NC1    DATA 1

NC2    DATA 4

NC3    DATA 7

NC4    DATA PR

NV0

NV1    DATA 0 I

NV2    DATA 0 K

NV3    DATA 0 V

SC0

SC1    DATA SC1+2

       BYTE 5,75,78,79,67,75

       EVEN

SC2    DATA SC2+2

       BYTE 2,75,61

       EVEN

SC3    DATA SC3+2

       BYTE 8,71,79,83,85,66,32,73,61

       EVEN

SC4    DATA SC4+2

       BYTE 9,83,85,66,32,80,82,32,86,61

       EVEN

SV0

SV1    DATA 0 MY$

SV2    DATA 0 MY2$

SA0

NA0

FRSTDT

LASTDT

       EVEN

       COPY "WDS1..lib..bc..rt1"

       COPY "WDS1..lib..bc..rt2"

       END

~             

I'm using primarily TI Extended Basic, but also have TI Extended Basic 2.5. I'm running in MAME. I've noticed Harry seems to be producing a Game Engine for / with Extended Basic 2.9, but doesn't seem to load in MAME. Maybe its because I'm still a noob. 

 

So do I have an older version of the compiler, or do I need a different version to support Extended Basic? I don't really want to write a post-processor to fix the otherwise fine output (but I will if need be).

Link to comment
Share on other sites

1 hour ago, mrvan said:

I'm trying to sort out why subroutines aren't called. I get errors when compiling in E/A. After studying the resulting ASM code, I can see the errors occur where the call for the subroutine should be. I can hand edit the resulting file and use GOSUB along with copying input and copying output after. Not sure this is the best way, and I'd certainly prefer the compiler to do the work. The compiler seems to include machine code that is called internally so I cannot see what the internal code is doing. Perhaps I have an older copy of the BASIC COMPILER, or one that only supports the original TI BASIC? No version is specified (that I can find).

I'm using primarily TI Extended Basic, but also have TI Extended Basic 2.5. I'm running in MAME. I've noticed Harry seems to be producing a Game Engine for / with Extended Basic 2.9, but doesn't seem to load in MAME. Maybe its because I'm still a noob. 

So do I have an older version of the compiler, or do I need a different version to support Extended Basic? I don't really want to write a post-processor to fix the otherwise fine output (but I will if need be).

I am pretty sure you are using the original BASIC Compiler. You will find this very limiting because it only supports TI BASIC instructions. Sprites, named subroutines, and all the other features that make us like XB are not supported.

You want Extended Basic Game Developer''s Package. The latest version of the compiler is included in that package.

 

What does not load in MAME? XB 2.9 G.E.M.? You should be able to use your favorite flavor of XB, but if G.E.M. doesn't load then I would like to know about it to see if a fix is possible.

 

Here is your compiled program.

MRVAN.GIF.130418c223ab6fe71092210c105f7bd2.GIF

  • Like 4
Link to comment
Share on other sites

On 2/27/2023 at 4:55 AM, senior_falcon said:

I am pretty sure you are using the original BASIC Compiler. You will find this very limiting because it only supports TI BASIC instructions. Sprites, named subroutines, and all the other features that make us like XB are not supported.

You want Extended Basic Game Developer''s Package. The latest version of the compiler is included in that package.

Thanks senior_falcon. You are correct that I was using the original compiler. I've now tried with the juwel994. The assembler that was included seemed to choke on the underscores in the subprogram names but otherwise worked ok. There also seemed to be a length limit (6 I think) on the subprogram names. That limit seems to be imposed by the XB compiler. Are there ways around these limits in juwel994?

 

None of these are insurmountable issues. 

 

I'm very much enjoying re-entering programming in this what was once relatively advanced development environment. And your compiler has made all the difference. The TI was my second computer (ZX81 was first at $99 and dog slow) and I had big dreams that were quickly dashed by the speed. I was ruined having seen the speed of Forth compiled and demonstrated at a users group meeting, all to find I couldn't get it. That drove me to writing ASM as a young teenager, all so I could tap the speed of the machine. Fast forward to 2023 and you've made available the compiler I needed so many years ago. I'm applying my many years of professional SW dev experience to this environment to see how far I can take it. It's fun and relaxing. And, I can run with a full suite of HW including the biggest of hard disks at almost 256MB--have no idea how much that would cost in 1984. I remember paying around $320 for a 350MB HD in 1993.

  • Like 2
Link to comment
Share on other sites

15 hours ago, mrvan said:

The assembler that was included seemed to choke on the underscores in the subprogram names but otherwise worked ok. There also seemed to be a length limit (6 I think) on the subprogram names. That limit seems to be imposed by the XB compiler. Are there ways around these limits in juwel994?

None of these are insurmountable issues.

The 6 byte limit comes from the TI assembler, which cannot use labels longer than 6 bytes. With an assembler that could handle longer labels, there is a (small) chance that the compiler could be modified to use longer subprogram names.

  • Like 1
Link to comment
Share on other sites

15 hours ago, sometimes99er said:

I paid $615 for a 47MB HD for my Amiga2000A in 1988.
 

Yep. i found this list at https://notebooks.com/2011/03/09/hard-drive-prices-over-time-price-per-gb-from-1981-to-2010/. It roughly jives with my experience. So my now virtual 256MB HD would have cost perhaps $12K in 1987 and perhaps $75K in 1981. How nice it is to have such hardware! 

 

Price per GB of Hard Drive Storage:

1981 — $300,000

1987 — $50,000

1990 — $10,000

1994 — $1000

1997 — $100

2000 — $10

2004 — $1

2010 — $0.10

  • Like 1
Link to comment
Share on other sites

2 hours ago, senior_falcon said:

The 6 byte limit comes from the TI assembler, which cannot use labels longer than 6 bytes. With an assembler that could handle longer labels, there is a (small) chance that the compiler could be modified to use longer subprogram names.

OK, that makes sense.

 

I don't know who controls which products, whether either/both are as-is, updates based on bug reports/requests for features, open source, ability to contribute updates, etc. Both could be updated to allow long labels, a pre-processor could be written to augment the labels in either product, etc. Working on text is fairly easy as a pre-processor to the assembler, but not sure it's so easy reading the merged tokens in the XB files to pre-process there.

 

xba99 allows for editing XB in plain text outside of the TI environment (on PC) and converting to tokenized XB files. In the absence of anything else a pre-processor could be written to replace long names with names of length <= 6. Doing that extends the xba99 ecosystem but makes the debugging process you describe (test in XB before compiling) much more difficult with names that are not human understandable. Maybe comments could help but still would be a bit ugly. I like the idea of preserving the names as close as possible to the final target.

 

Perhaps a question I should ask is "What tools (and where) do you use for development?" All the way from editor to assembler to loader/linker. This last question is open to everyone. I'd certainly like to know.

 

I'll start: I'm use a Mac at the command line (bash) with vi for editing XB code in text mostly without line numbers, a small script I wrote to package the main program and libraries (string manipulation, file operations, etc.) into one text file, then xbas99 to add line numbers and tokenize into a XB file, xdm99 to generate a fresh diskette and copy the XB file to it, and my TI simulator always starts with that diskette location loaded as DSK2. In the TI environment, I load my XB file, save as merge format, run the XB Compiler, Assembler and Load(er). Those last three are from the juwel994 package.

  • Like 1
Link to comment
Share on other sites

6 hours ago, senior_falcon said:

The 6 byte limit comes from the TI assembler, which cannot use labels longer than 6 bytes. With an assembler that could handle longer labels, there is a (small) chance that the compiler could be modified to use longer subprogram names.

I took a look at this and and don't think there is a practical way to allow longer subprogram names. Sorry..

Link to comment
Share on other sites

I found your wonderful cartridges and all built into classic99. I've been using a Mac with MAME but couldn't find a way to use GEM and XB 2.9. So here I am staring at classic99 on an emulated Windows PC using Parallels on a Mac. Complexity running this way or on MAME are about the same. But the ability to map the disks to directories in Windows is very nice, and mine map from Windows to the Mac, so there's very nice integration.

 

I can see you've eliminated a lot of the shortcomings of Ti Extended BASIC. I like the 80 column editing and the CALL RUN that accepts a string rather than a literal. I'm still finding more. I can't seem to be able to list a directory for some reason.

Link to comment
Share on other sites

On 3/2/2023 at 7:29 PM, senior_falcon said:

I took a look at this and and don't think there is a practical way to allow longer subprogram names. Sorry..

This is due to CALL LINK limitation mostly of only allowing 6 character long names.

Meanwhile XB programs allows 15 character names.

 

Link to comment
Share on other sites

On 3/2/2023 at 12:23 AM, mrvan said:

The assembler that was included seemed to choke on the underscores in the subprogram names but otherwise worked ok. There also seemed to be a length limit (6 I think) on the subprogram names. That limit seems to be imposed by the XB compiler. Are there ways around these limits in juwel994?

None of these are insurmountable issues.

The compiler uses the first 6 letters of the subprogram name, but you can use longer names for the subprograms. If you had 3 subprograms named:

FINDTHESQUARE

FINDTHECUBE

FINDTHEROOT

The compiler would see them all as FINDTH. So this would not work.

It may be a little cumbersome, but something like this might be acceptable:

FIND1THESQUARE

FIND2THECUBE

FIND3THEROOT

So now the compiler would see FIND1T, FIND2T, FIND3T and would be happy with that. And for you, the subprograms would still have human understandable names.

Edited by senior_falcon
  • Like 2
Link to comment
Share on other sites

5 hours ago, mizapf said:

It certainly runs on MAME. Here is the RPK.

 

mame ti99_4a -cart extended_basic_29_gem.rpk -ioport peb -ioport:peb:slot2 32kmem -ioport:peb:slot3 speech -ioport:peb:slot8 ddcc1 

 

extended_basic_29_gem.rpk 86.77 kB · 2 downloads

Thank you, mizapf. I was able to use your rpk file, and on the Mac. MAME seems to have a set of known cartridges and looks for them where it expects (the roms/ti99_carts directory) and expects them to have a specific name. XB GEM doesn't seem to be known directly in MAME, as many other cartridges are, and that has been confusing me. It seems MAME uses a different set of sequences for loading unknown cartridges and in this case loading the cartridge by path. And if the files are repacked in a zip file MAME fails to load them claiming the zip file is corrupted.

Link to comment
Share on other sites

5 hours ago, senior_falcon said:

Thanks for checking that. I assumed it worked, but you know what happens when you assume.

Thanks senior_falcon for asking about GEM XB running on MAME. I'm half way in the middle of transitioning to classic99 and have spent nearly a full day learning its strengths and weaknesses. The latter are few (runs only on Windows, no natural keyboard mapping). Big strengths are pretty much every desirable cartridge are included which eliminates so much work, ability to map the disks to one's hard drive, and I only had to download it for it to work immediately. It's easier than unpackaging the original computer and setting it up to get it going. So the trade is open again...classic99 or MAME. I use MAME for other things, so there's that.

  • Like 1
Link to comment
Share on other sites

4 hours ago, senior_falcon said:

The compiler uses the first 6 letters of the subprogram name, but you can use longer names for the subprograms. If you had 3 subprograms named:

FINDTHESQUARE

FINDTHECUBE

FINDTHEROOT

The compiler would see them all as FINDTH. So this would not work.

It may be a little cumbersome, but something like this might be acceptable:

FIND1THESQUARE

FIND2THECUBE

FIND3THEROOT

So now the compiler would see FIND1T, FIND2T, FIND3T and would be happy with that. And for you, the subprograms would still have human understandable names.

Thanks that is a good idea. It's not perfect but good. I know i'm "expecting" a lot from a machine that's 40 year old.

Link to comment
Share on other sites

26 minutes ago, mrvan said:

Thank you, mizapf. I was able to use your rpk file, and on the Mac. MAME seems to have a set of known cartridges and looks for them where it expects (the roms/ti99_carts directory) and expects them to have a specific name.

This is a longer story, and I plan to write some text on www.ninermame.org about that.

 

Basically, I was involved in the RPK design at the beginning, and the format worked quite well, but the other MAME devs chose another way, that is, to use the software lists (via the hash/xxx.xml file) and ZIP packages.

 

This does have its advantages (we can make sure that the ROMs are authentic), but it is not flexible if you have ongoing development. Since the other guys did not come up with an improvement of the ZIP concept over the last 10 years, the RPK format was now kept in the code base and just recently lifted up to be usable for other drivers (like CoCo).

  • Like 1
Link to comment
Share on other sites

28 minutes ago, mizapf said:

This is a longer story, and I plan to write some text on www.ninermame.org about that.

 

Basically, I was involved in the RPK design at the beginning, and the format worked quite well, but the other MAME devs chose another way, that is, to use the software lists (via the hash/xxx.xml file) and ZIP packages.

 

This does have its advantages (we can make sure that the ROMs are authentic), but it is not flexible if you have ongoing development. Since the other guys did not come up with an improvement of the ZIP concept over the last 10 years, the RPK format was now kept in the code base and just recently lifted up to be usable for other drivers (like CoCo).

Yes, that would be helpful. I'm glad you were able to provide me an RPK because a zip probably wouldn't have worked. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...