fabrice montupet Posted January 15, 2022 Share Posted January 15, 2022 I have a problem with one of my programs. It runs fine under XB256 but after I compiled it, the program stalls just before the execution of these lines: 600 OPEN #1:"DSK1.LV"&NIV$,DISPLAY ,INPUT 601 FOR T=1 TO 20 :: LINPUT #1:STN$ :: CALL LINK("DISPLY",T,1,STN$) :: NEXT T 610 INPUT #1:MNB$,YM$,XM$,MOV$ :: INPUT #1:MNB2$,YM2$,XM2$,MOV2$ :: CLOSE #1 At first, I thought that there was free memory missing. Here is the available memory under the XB256 editor: 8056 Bytes of Stack Free 7372 Bytes of Program ... and after a break when the program is executed just before the execution of the above code : 5341 Bytes of Stack Free 4002 Bytes of Program Another information: During the compilation, the loader says : 7228 free. So to understand the problem, I made a new program just containing the above code, I compiled it , run it, and... it works! Do you think that there is a lack of free memory? or something else? Thank you for any help ? Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 15, 2022 Author Share Posted January 15, 2022 (edited) I'm progressing. The problem doesn't come from the OPEN command. I replaced " "DSK1.LV"&NIV " with an existing file ("DSK1.LV1") and the program read it without any problem, but the program had a unexpected behavior just after. In fact, I was surprised to notice that some variables didn't contain their value although they are upstream set in the program; the proof is that the program works fine under XB256, non compiled. Now, I'm searching in which condition the compiler loose some variables settings. Edited January 15, 2022 by fabrice montupet Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 16, 2022 Share Posted January 16, 2022 Can't say for sure this is the problem, but you should always use LINPUT for your disk access. From the compiler manual: Disk and other peripheral access is now supported with some limitations: DISPLAY, VARIABLE is the only file type recognized, but you can use any length desired from DV1 to DV254. Up to three files can be open at a time. You must use #1, #2, or #3 – do not use other file numbers. You can only use colons in a print statement. Commas and semicolons will not save as in XB. 10 PRINT #1:”Now, is, the, time “ will print the entire string contained in the quotes. 20 PRINT #2:”Hello”:”World” or 20 PRINT #2:”Hello”::PRINT #2:”World” are equivalent. Use LINPUT for reading strings – INPUT will be treated as LINPUT if used LINPUT will read the entire entry including any ASCII characters (like in XB) Use INPUT for reading numbers (like in XB) You must specify INPUT or OUTPUT when opening a peripheral for reading or writing files. DELETE device-filename is supported but does not work with FIAD on Classic99 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 16, 2022 Author Share Posted January 16, 2022 Thank you for your message. I always specify INPUT or OUTPUT when I open a peripheral. LINPUT or INPUT choices for reading is not the problem here. As I said before, I put aside the idea of a file access problem when I corrected the file access by setting the NIV$ value just before the OPEN line, and it works fine now (when it didn't work, the NIV$ was set by using a GOSUB to a line that gave a string value to NIV$ then RETURN). I made a step forwards but I encounter again a problem with some other variables. The problem comes from variable values conservation when I compile the program. The program works when I run it from XB256 and not after compiled. Note that the program only uses integers and I use CLASSIC99 to compile, in normal speed. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 16, 2022 Share Posted January 16, 2022 Impossible to know what is happening without seeing the program. But to reiterate: If you are reading strings from disk using INPUT there will be problems. You must use LINPUT in both XB and compiled. If LINPUT works in XB then try compiling. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 16, 2022 Author Share Posted January 16, 2022 (edited) I have already tested the program using LINPUT in place of INPUT but that changes nothing. alas. The problem arrived after I have added new features but without modify the core of the program. The program uses massively the GOSUB command, with imbrication. This is why I thought about a memory problem although I have no error message. Has the compiler some GOSUB limitation? I continue my investigations, to re-read all the code again and again, and If I see nothing abnormal, I will back to you but I will be sorry to impose you the study of 300 lines of code. Edited January 16, 2022 by fabrice montupet 1 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 16, 2022 Share Posted January 16, 2022 Probably not from the GOSUBs. When compiled, the following program prints up to 9070, then issues the error "Memory Full in 10" (one of the few error messages the compiler will issue!) 10 GOSUB 100 100 X=X+1 :: PRINT X 110 GOSUB 100 1 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 16, 2022 Author Share Posted January 16, 2022 (edited) Strange behavior when GOSUB: Doesn't works when compiled: 599 GOSUB 2770 600 OPEN #1:"DSK1.LV"&NIV$,DISPLAY ,INPUT 601 FOR T=1 TO 20 :: LINPUT #1:STN$ :: CALL LINK("DISPLY",T,1,STN$) :: NEXT T 610 INPUT #1:MNB$,YM$,XM$,MOV$ :: INPUT #1:MNB2$,YM2$,XM2$,MOV2$ :: CLOSE #1 2770 NIV$=STR$(NIV):: RETURN Works when compiled: 600 NIV$=STR$(NIV) :: OPEN #1:"DSK1.LV"&NIV$,DISPLAY ,INPUT 601 FOR T=1 TO 20 :: LINPUT #1:STN$ :: CALL LINK("DISPLY",T,1,STN$) :: NEXT T 610 INPUT #1:MNB$,YM$,XM$,MOV$ :: INPUT #1:MNB2$,YM2$,XM2$,MOV2$ :: CLOSE #1 Edited January 16, 2022 by fabrice montupet Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 17, 2022 Share Posted January 17, 2022 To reiterate: If you are reading strings from disk using INPUT there will be problems. You must use LINPUT in both XB and compiled. If LINPUT works in XB then try compiling. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 17, 2022 Author Share Posted January 17, 2022 I know that but the problem is elsewhere. Even with I replace the two last INPUT with a series of LINPUT, I get the same problem. 599 GOSUB 2770 600 OPEN #1:"DSK1.LV"&NIV$,DISPLAY ,INPUT 601 T=1 TO 20 :: LINPUT #1:STN$ :: CALL LINK("DISPLY",T,1,STN$) :: NEXT T 602 LINPUT #1:MNB$ :: LINPUT #1:YM$ :: LINPUT #1:XM$ :: LINPUT #1:MOV$ 610 LINPUT #1:MNB2$ :: LINPUT #1:YM2$ :: LINPUT #1:XM2$ :: LINPUT #1:MOV2$ :: CLOSE #1 One more time, it works in XB256 but not when compiled. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 17, 2022 Share Posted January 17, 2022 (edited) The program below uses your code. The first part creates the file, so the second part, which is your code, has something to read. It works the same in XB256 and when compiled. Since I do not know how you created the files that are being read, are you sure that your program works properly running under XB256 while using LINPUT in lines 602 and 610? 100 NIV$="ABC" 110 OPEN #1:"DSK4.LV"&NIV$,DISPLAY ,VARIABLE 80,OUTPUT 120 FOR T=1 TO 20 :: STN$=RPT$(CHR$(T+64),32):: CALL LINK("DISPLY",T,1,STN$):: PRINT #1:STN$ :: NEXT T 130 PRINT #1:"MNBDOLLAR" :: PRINT #1:"YMDOLLAR" :: PRINT #1:"XMDOLLAR" :: PRINT #1:"MOVDOLLAR" 140 PRINT #1:"MNB2DOLLAR" :: PRINT #1:"YM2DOLLAR" :: PRINT #1:"XM2DOLLAR" :: PRINT #1:"MOV2DOLLAR" :: CLOSE #1 399 GOSUB 2770 600 CALL CLEAR :: OPEN #1:"DSK4.LV"&NIV$,DISPLAY ,VARIABLE 80,INPUT 601 FOR T=1 TO 20 :: LINPUT #1:STN$ :: CALL LINK("DISPLY",T,1,STN$):: NEXT T 602 LINPUT #1:MNB$ :: PRINT MNB$ :: LINPUT #1:YM$ :: PRINT YM$ :: LINPUT #1:XM$ :: PRINT XM$ :: LINPUT #1:MOV$ :: PRINT MOV$ 610 LINPUT #1:MNB2$ :: PRINT MNB2$ :: LINPUT #1:YM2$ :: PRINT YM2$ :: LINPUT #1:XM2$ :: PRINT XM2$ :: LINPUT #1:MOV2$ :: PRINT MOV2$ :: CLOSE #1 1000 END 2770 PRINT "SUB 2770" 2771 CALL KEY(0,K,S):: IF S<1 THEN 2771 2772 RETURN Edited January 17, 2022 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 17, 2022 Author Share Posted January 17, 2022 (edited) If I make a new XB256 program that just contains this code: 598 NIV=1 599 GOSUB 2770 600 OPEN #1:"DSK1.LV"&NIV$,DISPLAY ,INPUT 602 LINPUT #1:MNB$ :: LINPUT #1:YM$ :: LINPUT #1:XM$ :: LINPUT #1:MOV$ 610 LINPUT #1:MNB2$ :: LINPUT #1:YM2$ :: LINPUT #1:XM2$ :: LINPUT #1:MOV2$ :: CLOSE #1 ... 2770 NIV$=STR$(NIV):: RETURN and I compile it, the DSK1.LV1 file is well read. But it doesn't work any more when this same code is included in my 300 lines programs. note: there is no variables in conflict. I think that the focus has to be on the way the variables are set, like for NIV$ , with GOSUB or not, because here is the problem and not with OPEN, LINPUT or something else because the files are well read when the program is compiled and when NIV$ is directly set just before I open the file. And they are not read when NIV$ is got via a GOSUB. (see message #8) But I repeat it. The problem is not only with the NiV$ variable, the problem is encountered with some other variables manipulated in a GOSUB. Lines 602 and 610 are not important here, they read strings from a file for a usage in a next part of the program. You can omit them. Edited January 17, 2022 by fabrice montupet Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 18, 2022 Share Posted January 18, 2022 I am very skeptical that the problem lies in the subroutine. It's easy enough to find out. Here's how. Generally you are using either screen1 or screen2. For your test program I am assuming you are using screen1, so we will use screen2 for the debug screen. Here line 596 goes to the sub at line 2770. After return, line 598 changes to screen2, clears it, and prints NIV$. It goes to a sub to wait for a key press, then returns and resets to screen1. Similarly, line 601 prints that the file was opened and you are at line 601, After keypress it returns and resets to screen1. You can do this wherever you want to check a value. 594 NIV=1 596 GOSUB 2770 598 CALL LINK("SCRN2"):: CALL CLEAR :: PRINT "NIV$ = ";NIV$ 599 GOSUB 10000 :: CALL LINK("SCRN1") 600 OPEN #1:"DSK4.LV"&NIV$,DISPLAY ,INPUT 601 CALL LINK("SCRN2"):: PRINT "OPENED FILE. AT LINE 601" :: GOSUB 10000 :: CALL LINK("SCRN1") 603 FOR T=1 TO 20 :: LINPUT #1:STN$ :: CALL LINK("DISPLY",T,1,STN$):: NEXT T 606 LINPUT #1:MNB$ :: LINPUT #1:YM$ :: LINPUT #1:XM$ :: LINPUT #1:MOV$ 610 LINPUT #1:MNB2$ :: LINPUT #1:YM2$ :: LINPUT #1:XM2$ :: LINPUT #1:MOV2$ :: CLOSE #1 620 END 2770 NIV$=STR$(NIV):: RETURN 10000 CALL KEY(0,K,S):: IF S<1 THEN 10000 ELSE RETURN Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 18, 2022 Share Posted January 18, 2022 I should also add that, if you just want to know whether the compiled program has been able to execute the line, you can do this: 100 XB CODE::LN=100::GOSUB 10000 110 MORE XB CODE::LN=110::GOSUB 10000 etc. 10000 CALL LINK("SCRN2")::PRINT LN 10001 CALL KEY(0,K,S)::IF S<1 THEN 10001 10002 CALL LINK("SCRN1")::RETURN Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 19, 2022 Author Share Posted January 19, 2022 (edited) Thank you for the time you spent to find a solution. Yes, I use SCREEN1 (only). And here is what I have done: - I have deleted all the lines between 599 and 610 in my program: 598 NIV=1 599 GOSUB 2770 600 OPEN #1:"DSK1.LV"&NIV$,DISPLAY ,INPUT 602 LINPUT #1:MNB$ :: LINPUT #1:YM$ :: LINPUT #1:XM$ :: LINPUT #1:MOV$ 610 LINPUT #1:MNB2$ :: LINPUT #1:YM2$ :: LINPUT #1:XM2$ :: LINPUT #1:MOV2$ :: CLOSE #1 - I replaced them with the lines in your #13 message; (I have just changed DSK4 with DSK1 as all the LV* files are on DSK1) 594 NIV=1 596 GOSUB 2770 598 CALL LINK("SCRN2"):: CALL CLEAR :: PRINT "NIV$ = ";NIV$ 599 GOSUB 10000 :: CALL LINK("SCRN1") 600 OPEN #1:"DSK1.LV"&NIV$,DISPLAY ,INPUT 601 CALL LINK("SCRN2"):: PRINT "OPENED FILE. AT LINE 601" :: GOSUB 10000 :: CALL LINK("SCRN1") 603 FOR T=1 TO 20 :: LINPUT #1:STN$ :: CALL LINK("DISPLY",T,1,STN$):: NEXT T 606 LINPUT #1:MNB$ :: LINPUT #1:YM$ :: LINPUT #1:XM$ :: LINPUT #1:MOV$ 610 LINPUT #1:MNB2$ :: LINPUT #1:YM2$ :: LINPUT #1:XM2$ :: LINPUT #1:MOV2$ :: CLOSE #1 620 END 2770 NIV$=STR$(NIV):: RETURN 10000 CALL KEY(0,K,S):: IF S<1 THEN 10000 ELSE RETURN - I ran the program in XB256 and it works, not surprised because it worked before under XB256 - I compiled it and ... It works! I was stunned! ? But, what is this mystery? as both of all do the same about the file opening, reading and using the same value with DISPLY. Edited January 19, 2022 by fabrice montupet Add information Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 19, 2022 Share Posted January 19, 2022 This happens a lot. If your car is not running well, it is guaranteed to work perfectly when you take it to the mechanic. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 19, 2022 Author Share Posted January 19, 2022 Can you tell me more? ? Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 19, 2022 Author Share Posted January 19, 2022 (edited) just a precision: in my message #10 , the 601 line was missing, it is a copy/past problem here but it was well present in my program. Edited January 19, 2022 by fabrice montupet Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 19, 2022 Share Posted January 19, 2022 Is this able to run properly in the entire 300 line program or just in the short test program you listed? Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 19, 2022 Author Share Posted January 19, 2022 It runs OK on my about 300 lines program, this is what was surprised me. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 19, 2022 Share Posted January 19, 2022 "All's well that ends well" as Shakespeare wrote, but it would be nice to know why this did not work at first. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 19, 2022 Author Share Posted January 19, 2022 ... That is the question ? I will analyze that. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 19, 2022 Author Share Posted January 19, 2022 In fact, this is not the story's end. Because if I remove all the code that calls SCREEN2, the compiled program doesn't work anymore again. And if the compiled program works with your code, it works only for the NIV$ variable, which keeps now its value et permits to read the files. But the program continues to run non properly with some other variables that loose their values... Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 19, 2022 Share Posted January 19, 2022 This makes no sense. Can you PM me the code so I can take a look. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 20, 2022 Author Share Posted January 20, 2022 Yes, this makes no sense! And I absolutely want to understand what's the hell it means. I will come back to you soon to tell you more. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.