senior_falcon Posted April 12, 2022 Author Share Posted April 12, 2022 20 minutes ago, pixelpedant said: Ah, indeed, it looks like this data is just structured in a way that isn't compatible with a compiled program, and should be restructured for use with LINPUT. With integers and strings in separate records. I think the structure is fine. I think if you make this change it will work. 60 INPUT #1:CNUM::LINPUT #1:CPAT$ Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 12, 2022 Share Posted April 12, 2022 59 minutes ago, senior_falcon said: Saving as a cartridge requires XB2.9 G.E.M. and Classic99 version QI399.055 or later. Great feature. Is it only the ?X that makes it dependent on Classic 99? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 12, 2022 Author Share Posted April 12, 2022 1 hour ago, Asmusr said: Great feature. Is it only the ?X that makes it dependent on Classic 99? The file must be saved without the >80 byte header. If there is a way to do that on a real TI99 then it should work. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 12, 2022 Share Posted April 12, 2022 6 minutes ago, senior_falcon said: The file must be saved without the >80 byte header. If there is a way to do that on a real TI99 then it should work. Is the >80 byte header the TIFILES header? As long as you're on a real TI it doesn't exist, so I guess it depends of how you transfer files from your TI to your PC or FinalGROM. 1 Quote Link to comment Share on other sites More sharing options...
pixelpedant Posted April 12, 2022 Share Posted April 12, 2022 2 hours ago, senior_falcon said: I think the structure is fine. I think if you make this change it will work. 60 INPUT #1:CNUM::LINPUT #1:CPAT$ The result with the following: 40 CALL CLEAR 45 OPEN #1:"DSK1.PATS",INPUT 50 FOR X=1 TO 2 60 INPUT #1:CNUM 65 LINPUT #1:CPAT$ 70 CALL CHAR(CNUM,CPAT$) 75 PRINT :"Loop "&STR$(X)&": ": :"CNUM: "&STR$(CNUM):"CPAT$: "&CPAT$ 80 NEXT X 90 CLOSE #1 100 PRINT :"HERE IS WHAT THESE CHARACTERS LOOK LIKE: "&CHR$(128)&CHR$(129)&CHR$(130)&CHR$(131)&CHR$(132)&CHR$(133)&CHR$(134)&CHR$(135) 110 CALL KEY(0,K,S):: IF S=0 THEN 110 i.e., an INPUT (for the integer) followed by LINPUT (for the string) is as follows: Which is to say, the INPUT reads only the integer with which the first record starts, followed by the LINPUT reading the entire record, for the second record. Which is to say INPUT and LINPUT do have distinct behaviours, once compiled, but not in a way that is immediately useful, here. So I think I do need to just put the values in separate records, which is easy after all. Also preferable because, for me, it's preferable (when possible - it isn't always) to have code which behaves pretty much the same in XB and after compiled, rather than having different behaviours in each case. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 13, 2022 Author Share Posted April 13, 2022 5 hours ago, pixelpedant said: Which is to say, the INPUT reads only the integer with which the first record starts, followed by the LINPUT reading the entire record, for the second record. Which is to say INPUT and LINPUT do have distinct behaviours, once compiled, but not in a way that is immediately useful, here. So I think I do need to just put the values in separate records, which is easy after all. Also preferable because, for me, it's preferable (when possible - it isn't always) to have code which behaves pretty much the same in XB and after compiled, rather than having different behaviours in each case. This works the same in both XB and compiled XB. RUN 200 makes the file, then RUN reads the file and prints what was read. (I did not test making the file from compiled code.) Maybe this is what you meant by having separate records? At first I though you were saying you need to open two separate files. It is definitely true that compiled code should run the same as XB. That way you can do your debugging in XB where it is easy. 100 OPEN #1:"DSK1.CHARDATA",INPUT 110 FOR J=1 TO 9 111 INPUT #1:I :: LINPUT #1:I$ 112 PRINT I:I$ 120 NEXT J 130 CLOSE #1 140 END 200 OPEN #1:"DSK1.CHARDATA",OUTPUT 202 FOR I=1 TO 9 205 I$=RPT$(STR$(I),64) 210 PRINT #1:I:I$ 220 NEXT I 230 CLOSE #1 Quote Link to comment Share on other sites More sharing options...
pixelpedant Posted April 13, 2022 Share Posted April 13, 2022 53 minutes ago, senior_falcon said: At first I though you were saying you need to open two separate files. Oh, no, indeed, I just meant separating the values into individual records so that LINPUT can be used to read all of them gracefully, whether compiled or interpreted. Which has indeed worked out fine as a solution, of course. There's no particular reason both values in each pair should need to be in the same record as they were originally. Just splitting them in this way is fine, so that the file is now: 128 00000000000304080000000000BB00AAA02040800000000000AA00BB00000000 132 0A080A080A080A080A08040300000000A020A020A020A0200000000000804020 0 0000000000000000545454545400FC00282828282800FC004464745444C4C404 4 90989C9490B0B080007C1C6C74787C00007C7C0C74787C00007C7C007C7C7C00 8 80808080808080FC0010187C181000FC04040404040404FC00704870484800FC 12 00784070404000FC00304878484800FC0010387C101000FC80B8A0B4A4A480FC 16 000008DC484000FC04344424146404FC00784070404000FC00000000000000FC 20 FC000000000000FCFC0000000000000000704870404000FC0010307C301000FC 24 00384040403800FC04040404040404FC00704870487000FC0010107C381000FC 28 04444444447404FC040404040404040480808080808080800000000000000000 35 082C386C3868200000007878FC000000 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 3, 2022 Author Share Posted May 3, 2022 I have uploaded a revised version of JUWEL which fixes a bug that Alessandro found. This happened when you used DISPLAY AT(..)SIZE(..) The entire line was cleared and not just the characters specified by SIZE. All fixed. Another bug was found that might have caused problems when putting the runtime routines in low memory. Post #1 and post #918 on page 37 have the revised version. 5 3 Quote Link to comment Share on other sites More sharing options...
tmop69 Posted May 3, 2022 Share Posted May 3, 2022 5 hours ago, senior_falcon said: I have uploaded a revised version of JUWEL which fixes a bug that Alessandro found. This happened when you used DISPLAY AT(..)SIZE(..) The entire line was cleared and not just the characters specified by SIZE. All fixed. Another bug was found that might have caused problems when putting the runtime routines in low memory. Post #1 and post #918 on page 37 have the revised version. Many thanks Harry for your beautiful software and the support you provide. It's the de facto standard, without any doubt, for anyone still wanting to use BASIC to develop games for the TI. Apart from my compilation of legacy games, we have the tons of games by @Retrospect, games from @SteveB, @Bleepbit, @Cheung, etc. and the creations from new TI99 users like @whoami999ster and @Sergioz82. 6 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 11, 2022 Author Share Posted May 11, 2022 I have uploaded another revised version of JUWEL which fixes yet another bug in the compiler that Alessandro found. This bug could almost never happen, and I was fortunate in tracking down the place in the code where it occurred. Once found the fix was easy. An earlier fix caused two programs to fail. MAKECARTG and the loader when creating EA5 files with the runtime in low memory. Since they worked before, the fix was easy once I figured out what had happened. I am thinking of renaming this project the INSECTARIUM, which is a 50 cent word meaning "Bughouse". Sometimes I feel this project will cause me to end up there. Post #1 and post #918 on page 37 have the revised version. 7 1 Quote Link to comment Share on other sites More sharing options...
+Retrospect Posted June 15, 2022 Share Posted June 15, 2022 On 5/3/2022 at 9:04 AM, tmop69 said: we have the tons of games by @Retrospect, There will be another one before the end of this year simplescreenrecorder-2022-06-15_06.20.11.mp4 7 Quote Link to comment Share on other sites More sharing options...
wolhess Posted June 16, 2022 Share Posted June 16, 2022 @senior_falcon Hello Harry, I installed the new XBGEM 2.9 (from the Juwel 4 package) on my F18a TI with the result that the console blocked at the XB 2.9 prompt. If I autoload my Mega Menu program (compiled with your compiler) the program will also work with tipi access and with tipi/internet weather access. When I press FCTN+4 to pause the Program menu, I see the corrupted XB prompt and the console is stuck. Is this a known behavior that the new version doesn't work with an F18a modded console? On a second XB console with an F18a (console pure without 32K expansion) I see the same behavior. In the XBGEM 2.8 version I have no problems with my F18a system. On my normal console (no F18a) XB2.9 works fine. 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted June 16, 2022 Share Posted June 16, 2022 @senior_falcon Hi again, reight now I tested the new XB 2.9 on my console with a EVPC2 80 column card. The running program changed to the normal 32 column mode. This system shows me the first time a 80 column XB version. I can list and edit the XB programs in 80 column direct at the console. AMAZING!!!! My Mega Menu (compiled) program is autoloading and working fine. But when I break the program the system hangs at the normal XB prompt. Maybe this is because I compiled the program with the "Put runtime in low memory" option? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 16, 2022 Author Share Posted June 16, 2022 6 hours ago, wolhess said: @senior_falcon Hello Harry, I installed the new XBGEM 2.9 (from the Juwel 4 package) on my F18a TI with the result that the console blocked at the XB 2.9 prompt. Hard to say what is happening here. Debugging from a distance and without a debugger is challenging. Do you have the 32K ram expansion? Is this screen shot right after pressing 2 for XB 2.9? There are 3 extra characters before the cursor-I wonder why that is? If I autoload my Mega Menu program (compiled with your compiler) the program will also work with tipi access and with tipi/internet weather access. When I press FCTN+4 to pause the Program menu, I see the corrupted XB prompt and the console is stuck. A compiled program needs 32K to run, so obviously you have that. It looks like autoload works fine, but somehow the editor cannot be used, either from normal startup (Press 2) or when a program breaks? Is this a known behavior that the new version doesn't work with an F18a modded console? I do not know this. On a second XB console with an F18a (console pure without 32K expansion) I see the same behavior. I do not know this for a fact, but would be surprised if this worked without 32K. In the XBGEM 2.8 version I have no problems with my F18a system. On my normal console (no F18a) XB2.9 works fine. Compared to XB 2.8 G.E.M., there is an additional bank of 8K memory, which is where the new editors are kept. Is it possible that your cart is not seeing that bank? Since you can autoload a program it should be possible to resolve this. I will PM you later today so we can figure this out. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 17, 2022 Author Share Posted June 17, 2022 18 hours ago, wolhess said: @senior_falcon I installed the new XBGEM 2.9 (from the Juwel 4 package) on my F18a TI with the result that the console blocked at the XB 2.9 prompt. Hi Wolfgang: Take a look at my post #8 in "TI99/4a OS Version" There is a one line program listed there. Save it to DSK1.LOAD using any XB that works, then put in XB 2.9 G.E.M. and press 2. What number is printed? Quote Link to comment Share on other sites More sharing options...
wolhess Posted June 17, 2022 Share Posted June 17, 2022 14 hours ago, senior_falcon said: Hi Wolfgang: Take a look at my post #8 in "TI99/4a OS Version" There is a one line program listed there. Save it to DSK1.LOAD using any XB that works, then put in XB 2.9 G.E.M. and press 2. What number is printed? Hi Harry, Do you have the 32K ram expansion? --> Yes I have a 1MB SAMS card in the PEB and it defaults to the normal 32K expansion. Is this screen shot right after pressing 2 for XB 2.9? --> The screen shows the status after pressing BREAK (FCTN+4). --> The same result comes up If I press 2 from the TI Menu. There are 3 extra characters before the cursor-I wonder why that is? --> The prompt with the extra character is the same if I autoload and break the program or if I press 2 and the system shows the prompt the first time. It looks like autoload works fine, but somehow the editor cannot be used, either from normal startup (Press 2) or when a program breaks? --> Both ways reults in the same blocking prompt screen. I do not know this for a fact, but would be surprised if this worked without 32K. --> In the console with an F18a built in, the system shows the same blocking prompt screen (with the same caharacters befor the very fast blinking cursor). --> In my console witout an F18a, I can work with the XB 2.9 without an issue! Even without or with 32K expansion. Is it possible that your cart is not seeing that bank? --> Maybe it is possible. There is a one line program listed there. Save it to DSK1.LOAD using any XB that works, then put in XB 2.9 G.E.M. and press 2. What number is printed? --> The number is "8", after BREAK I see again the prompt wit the three character before and the console stucks. --> With XB 2.8 I see also "8", after BREAK I see the normal prompt and I can edit the program. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 17, 2022 Author Share Posted June 17, 2022 Well now, that's a bit of a mystery. It seems that the F18A is blocking the editor somehow. Even though the editor seems to be frozen, try typing BYE and Enter. Maybe the editor is working, but just not appearing on the screen. I will look to see if there is something obviously different between 2.8 and 2.9 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 17, 2022 Share Posted June 17, 2022 Can it be reproduced in JS99er.net with F18A enabled? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 17, 2022 Author Share Posted June 17, 2022 16 minutes ago, Asmusr said: Can it be reproduced in JS99er.net with F18A enabled? It seems to work fine. However, JS99er has version 2.920220202. The latest version is 2.920220317. It would be nice if the latest version did not work in JS99er; that way it should be possible to track down the problem. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 17, 2022 Share Posted June 17, 2022 35 minutes ago, senior_falcon said: It would be nice if the latest version did not work in JS99er; that way it should be possible to track down the problem. Updated. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 17, 2022 Author Share Posted June 17, 2022 I am still seeing 2.920220202 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 18, 2022 Author Share Posted June 18, 2022 (edited) 4 hours ago, Asmusr said: Updated. OK, now it is version 2.920220317. F18A is enabled and the good news is that everything seems to work normally. I can press 2 and get the command line as expected. I ran a simple program and when it ended the command line came back. The bad news is that everything seems to work normally, so I have absolutely no idea what might be going on. (edit) I do notice that the keyboard response is a bit sluggish when using the F18A. You have to type slowly or key presses are missed. With it disabled the response seems normal. The 80 column hack in Classic99 is not available, so EDIT80 does not work properly unless the F18A is enabled. Edited June 18, 2022 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 18, 2022 Author Share Posted June 18, 2022 @wolhess As expected, without the 32K expansion, there are things that do not work and the computer crashes. I think the XB 2.7 core of this works fine, but many of the CALLs and other features I added such as the 40 and 80 column editors, XB256, The Missing Link, etc. all need 32k and will not work. Quote Link to comment Share on other sites More sharing options...
wolhess Posted June 18, 2022 Share Posted June 18, 2022 15 hours ago, senior_falcon said: Well now, that's a bit of a mystery. It seems that the F18A is blocking the editor somehow. Even though the editor seems to be frozen, try typing BYE and Enter. Maybe the editor is working, but just not appearing on the screen. I will look to see if there is something obviously different between 2.8 and 2.9 Hi, I tried to type BYE but nothing happens. Only a reset helps to get the title screen. In the version 2.820210712 I can break the program to the XB prompt and I can edit, list, save and load back the program without an issue. Quote Link to comment Share on other sites More sharing options...
wolhess Posted June 18, 2022 Share Posted June 18, 2022 11 hours ago, senior_falcon said: @wolhess As expected, without the 32K expansion, there are things that do not work and the computer crashes. I think the XB 2.7 core of this works fine, but many of the CALLs and other features I added such as the 40 and 80 column editors, XB256, The Missing Link, etc. all need 32k and will not work. You are right, I only tested the short "100 CALL VERSION(V)::PRINT V" program. Normaly I always have the 32K RAM expansion active. 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.