mrvan Posted February 27, 2023 Share Posted February 27, 2023 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). Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 27, 2023 Share Posted February 27, 2023 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. 4 Quote Link to comment Share on other sites More sharing options...
mrvan Posted March 2, 2023 Author Share Posted March 2, 2023 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. 2 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted March 2, 2023 Share Posted March 2, 2023 2 hours ago, mrvan said: I remember paying around $320 for a 350MB HD in 1993. I paid $615 for a 47MB HD for my Amiga2000A in 1988. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 2, 2023 Share Posted March 2, 2023 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. 1 Quote Link to comment Share on other sites More sharing options...
mrvan Posted March 2, 2023 Author Share Posted March 2, 2023 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 1 Quote Link to comment Share on other sites More sharing options...
mrvan Posted March 3, 2023 Author Share Posted March 3, 2023 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. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 3, 2023 Share Posted March 3, 2023 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.. Quote Link to comment Share on other sites More sharing options...
mrvan Posted March 3, 2023 Author Share Posted March 3, 2023 Well, that's a shame. I very much appreciate you checking on that. I'll see what I can do from a pre-processor stand point. It'll be ugly code but should work. Quote Link to comment Share on other sites More sharing options...
mrvan Posted March 4, 2023 Author Share Posted March 4, 2023 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 4, 2023 Share Posted March 4, 2023 1 hour ago, mrvan said: I've been using a Mac with MAME but couldn't find a way to use GEM and XB 2.9. Does anyone know if XB 2.9 G.E.M. runs on MAME, or if there is a trick to make this happen? Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted March 4, 2023 Share Posted March 4, 2023 2 minutes ago, senior_falcon said: Does anyone know if XB 2.9 G.E.M. runs on MAME, or if there is a trick to make this happen? As far as I'm concerned I can't say as I don't use MAME, all I can say is that XB 2.9 G.E.M. works fine with Fred's ti994w emulator. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 4, 2023 Share Posted March 4, 2023 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 4, 2023 Share Posted March 4, 2023 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 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 4, 2023 Share Posted March 4, 2023 29 minutes ago, mizapf said: It certainly runs on MAME. Here is the RPK. Thanks for checking that. I assumed it worked, but you know what happens when you assume. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 4, 2023 Share Posted March 4, 2023 (edited) 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 March 4, 2023 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
mrvan Posted March 4, 2023 Author Share Posted March 4, 2023 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. Quote Link to comment Share on other sites More sharing options...
mrvan Posted March 4, 2023 Author Share Posted March 4, 2023 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. 1 Quote Link to comment Share on other sites More sharing options...
mrvan Posted March 4, 2023 Author Share Posted March 4, 2023 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 5, 2023 Share Posted March 5, 2023 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). 1 Quote Link to comment Share on other sites More sharing options...
mrvan Posted March 5, 2023 Author Share Posted March 5, 2023 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.