senior_falcon Posted May 27, 2018 Author Share Posted May 27, 2018 (edited) Oops, I left out a file. ENCRUZADO_BETA1.ZIP has been posted and is the one to download. Also, when you are setting XBGDP be sure DSK1 uses ENCRUZADO_BETA1. Edited May 27, 2018 by senior_falcon Quote Link to comment Share on other sites More sharing options...
LASooner Posted May 27, 2018 Share Posted May 27, 2018 CALL LINK("RUNV") starts the program but without resetting any of the Screen2 patterns or character definitions. This lets you chain compiled programs together while retaining all the graphics created by the first program. A bug in playing sound lists from EA5 was corrected. woah, awesome new feature Harry! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 31, 2018 Author Share Posted May 31, 2018 (edited) It seems that any change, no matter how slight, has unanticipated negative consequences. Here is a bug that got through my testing and it was a real pain in the buttocks to figure out. First the problem: The compiler uses cpu memory from >FFE8 to >FFFF as a mailbox so the various components can communicate with each other. Filename, the next position in the menu, where to find the runtime routines, and a few others are kept there. Also, there is a byte that tells the compiler which of the runtime routines (1-7) should be loaded. This used to be in low memory. In making it possible to move the runtime routines to low memory, this had to go someplace else and >FFFF seemed safe enough. Absolutely no problem if you put the runtime routines in high memory as usual. If you have a large program and want to put them in low memory to free up room, you have to leave XB and plug in the MiniMemory cartridge. Doing that zeroes out cpu memory. No problem, the compiler saves the 24 bytes in the mailbox to a disk file. When the TI BASIC compiler loader runs in MiniMemory, it reads the disk file into MB$ to find out the contents of the mailbox. Simple enough, except that BASIC only allows INPUT. It does not allow LINPUT. Most of the time this works fine, but when the last byte is >1F it is not included in MB$ and now MB$ is only 23 bytes long. Why does that matter? Because I got clever with one of the assembly language support routines which reads that string and uses the length to decide what to do. If it's 24 bytes long it does one thing, if less than 24 bytes then it does a different operation. Although it doesn't crash, it gives a garbled prompt for the filename. That only took 2 hours to figure out! Here's the fix: OLD DSK1.COMPILER Edit line 520 to be: 520 DISPLAY AT(21,1):SF$&" is compiled." :: CALL LOAD(-1,0)::RUN "DSK1.LOAD" SAVE DSK1.COMPILER (EDIT) The only time this bug shows up is when you compile a program that uses XB256 and the "Star Wars scroll", no CHSETD and no disk access. Edited May 31, 2018 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted June 6, 2018 Author Share Posted June 6, 2018 (edited) Here is the newest revision of the XB Game Developer's Package "Encruzado". As noted above, a few bugs were found and squashed and now this should be ready for prime time. COMPILER: The big change is that you now have an option to put the runtime routines into low memory from >2000 to >3FFF. This is necessary is if your compiled program is too large to run in the 24K of high memory, with both compiled code and the runtime routines all located there. With the runtime routines in low memory it is safe to say that you should have no memory problems when compiling even the largest XB programs. If the program is saved as EA5 the program will be loaded exactly as before. If you save as an XB loader there are two programs. The first loads the low memory portion of the code and then automatically loads and runs the second program. Other than a brief pause while the second program is loaded, you will see no difference in how this functions. When running from XB there are now three ways to start the compiled program. CALL LINK("RUN") starts the program with a scan that breaks the program execution when F4 is pressed. CALL LINK("RUNEA") starts the program exactly as it would be when running as EA5. No F4 scan is performed. CALL LINK("RUNV") starts the program but without resetting any of the Screen2 patterns or character definitions. This lets you chain compiled programs together while retaining all the graphics created by the first program. A bug in playing sound lists from EA5 was corrected. I also added an option to use the runtime routines from the earlier TI BASIC compiler. These are more compact and may run a bit faster because the interrupt routine has less overhead. XB256: The big change here is that there is a second version of XB256 called XB256HM.This provides a way to save an XB program and XB256 in the same program; If you don't need the speed of a compiled program, this makes a nice, neat one program package (edit)-Remember that if you will be compiling a program, then RESTORE must point to a DATA statement, not to a REM before the DATA. The section discussing the COMPRESS utility was not clear about this. ENCRUZADO.zip Edited June 7, 2018 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
1980gamer Posted July 14, 2018 Share Posted July 14, 2018 Hello all, I don't know if this is an ENCRUZADO issue or a Classic99 issue or a Windows 10 issue... Must likely it is a USER issue... Anyway, I haven't updated since XB256D came out. Yeah, been a while. So, today I took the plunge. However, when I begin the process to compile an XB program, I get an I/O Error 07 when saving the MERGE file. The normal save works. Only when I try to save as merge do I get the error. I believe I have configured the disk properly. I read the docs. They even include Pictures, so I have a pretty good shot at doing it right. LOL But I just cannot get my program to save. The normal program is about 4K on the disk. In fact, the xb file can be found in the Necco thread if someone wanted to try to compile it. I'd hate to get hung up. I had been in a LONG creative slump. I have a few ideas right now and want to keep going. Thanks in advance. Quote Link to comment Share on other sites More sharing options...
1980gamer Posted July 14, 2018 Share Posted July 14, 2018 I have tried everything I can think of. I am an admin. I have full folder control. I run classic99 as admin. Starting to pi$$ me off. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 14, 2018 Author Share Posted July 14, 2018 Got me stumped. I downloaded from development resources and tried it out. Works perfectly. Without the compiler just try saving a merge format file. Quote Link to comment Share on other sites More sharing options...
1980gamer Posted July 14, 2018 Share Posted July 14, 2018 Okay, I am more stumped than ever! If I save the Merge file first it works. See image. The is without the developer package. Quote Link to comment Share on other sites More sharing options...
1980gamer Posted July 14, 2018 Share Posted July 14, 2018 i tried to cheat and do the merge save first.... No Luck ---While using the developer tools. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 15, 2018 Share Posted July 15, 2018 Classic99's debug log often gives more information about why it returns a disk error. Error 7 means "File Error". What's your DSK1 configuration? If it's a disk image, is the image full? (Yes, I know disk full is supposed to be a different message - but bugs happen). Quote Link to comment Share on other sites More sharing options...
1980gamer Posted July 16, 2018 Share Posted July 16, 2018 (edited) So, I gave up using the new laptop and fired up the old one.... I got further... But not far enough! Maybe this is a CODE issue on my end? Edited July 16, 2018 by 1980gamer Quote Link to comment Share on other sites More sharing options...
1980gamer Posted July 17, 2018 Share Posted July 17, 2018 Can someone help with a special request? Could you zip up a Classic99 config file and disk folders to match with the GDP included? I have tried multiple systems and every configuration I can think of... No luck. I get different errors on different systems with the same configuration.... I want to use the new features... But I may have to revert. Thanks in advance. Quote Link to comment Share on other sites More sharing options...
pixelpedant Posted July 18, 2018 Share Posted July 18, 2018 (edited) I have what I think is likely a fairly basic (pun...I'm not sure...intended?) question regarding the VREAD and VWRITE subroutines. When I CALL LINK ("VWRITE",[address],[string]), I notice that the character written to screen appears to be of an ASCII value 32 greater than that of the character contained in [string]. That is to say, CALL LINK("VWRITE",[address],"!") results in "A" being written to screen at the location associated with [address] and CALL LINK ("VWRITE",[address],"`") results in non-character data being written to screen at the location associated with [address]. Meanwhile, when I CALL LINK ("VREAD",[address],[bytes],var$), the character contained in var$ (if a single byte read) appears to have a value 96 greater than that of the ASCII value of the character originally written to the screen. Would anyone be able to illuminate why this is the case? Though I've had a TI 99/4A my whole life, I'm very new to the development side of things. But these subroutines seem like pretty powerful tools which I'd like to be able to utilise. Edit: I'm guessing this must just be a function of fundamental discord between the vanilla XB pattern table and the XB256 Screen 1 and Screen 2 pattern tables? But this seems to raise the question - why does VWRITE accept a string (rather than, say, an integer) as an argument, if that string is merely being treated as representative of a location on a (vanilla XB) pattern table which isn't being used? Seems confusing. Or maybe I'm just not understanding what's going on here. I'll have to experiment some more. Edited July 18, 2018 by pixelpedant Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 22, 2018 Author Share Posted July 22, 2018 Can someone help with a special request? Could you zip up a Classic99 config file and disk folders to match with the GDP included? I have tried multiple systems and every configuration I can think of... No luck. I get different errors on different systems with the same configuration.... I want to use the new features... But I may have to revert. Thanks in advance. Reverting will not help you. If you cannot save a file in merge format then no version of the compiler will work. It sounds as if you have not set up Classic99 properly. Other possibilities: -A bug in Classic99 (not likely) -Running Classic99 in Linux under wine might have compatibility issues. (not likely since you mentioned Windows 10) -You forgot to unzip the Encruzado folder. (Not likely) -Are you using Disk Image instead of FIAD? (also not likely) Were you able to get this working? If so please post what the problem was and what steps you took to address it. If not we will have to figure out what is going on. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 22, 2018 Author Share Posted July 22, 2018 I have what I think is likely a fairly basic (pun...I'm not sure...intended?) question regarding the VREAD and VWRITE subroutines. When I CALL LINK ("VWRITE",[address],[string]), I notice that the character written to screen appears to be of an ASCII value 32 greater than that of the character contained in [string]. That is to say, CALL LINK("VWRITE",[address],"!") results in "A" being written to screen at the location associated with [address] and CALL LINK ("VWRITE",[address],"`") results in non-character data being written to screen at the location associated with [address]. Meanwhile, when I CALL LINK ("VREAD",[address],[bytes],var$), the character contained in var$ (if a single byte read) appears to have a value 96 greater than that of the ASCII value of the character originally written to the screen. Would anyone be able to illuminate why this is the case? Though I've had a TI 99/4A my whole life, I'm very new to the development side of things. But these subroutines seem like pretty powerful tools which I'd like to be able to utilise. Edit: I'm guessing this must just be a function of fundamental discord between the vanilla XB pattern table and the XB256 Screen 1 and Screen 2 pattern tables? But this seems to raise the question - why does VWRITE accept a string (rather than, say, an integer) as an argument, if that string is merely being treated as representative of a location on a (vanilla XB) pattern table which isn't being used? Seems confusing. Or maybe I'm just not understanding what's going on here. I'll have to experiment some more. You are running into the "screen offset" feature of both TI BASIC and Extended BASIC. To save some memory TI decided to add 96 (>60) to the ascii of characters being printed to the screen with PRINT, DISPLAY, HCHAR, or VCHAR. The exclamation point has an ASC of 33 (>21), and if you do a CALL HCHAR(1,1,33,768) you will see the screen is filled with exclamation points. But if you look at the screen with Classic99's debugger you will see it is all >81 and not the expected >21. Similarly, if you do a CALL GCHAR(1,1,G) after the HCHAR, it will report that there is 33 (>21) at that screen location even though it is really >81. Using the screen offset made it possible to get an additional 1K or so of memory which can be helpful when you do not have the 32K memory expansion. VREAD and VWRITE do not use the screen offset. When you CALL LINK("VWRITE",[address],"!") it puts >21 at that address. If a >21 is on the screen then it uses a pattern that has the screen offset which in this case happens to be an inverse video "A" if you are using screen2. As to why the decision was made to use a string instead of a variable: You can fit 255 bytes into a string. With one CALL LINK you would only be able to transfer 15 bytes at a time and that would be slow because each byte needs to be converted to a floating point number and then 15 separate numbers must be sent to or from XB. Here is a simple example showing a possible use of VREAD and VWRITE (using XB256): 1288 is >0508 which is the starting address of the pattern for "A". Wait for a keypress, then print the pattern one byte higher, then print the patterns back in the original location. Something like this could be used to make the ground shake when a character jumps and lands on the ground again. 10 CALL LINK("VREAD",1288,64,P$) 20 PRINT "ABCD":"EFGH" 30 CALL KEY(0,K,S):: IF S<1 THEN 30 40 CALL LINK("VWRITE",1287,P$) 50 CALL LINK("VWRITE",1288,P$) 60 GOTO 30 Quote Link to comment Share on other sites More sharing options...
1980gamer Posted July 23, 2018 Share Posted July 23, 2018 I have it kind of working. Though I am the only users on the laptop and I am an Administrator. I changed the folder security settings to give full control to everything to all possible accesses. This is super secure! LOL anyway, I can save to the dsk2 now. Well, most of the time. Other times, I just think I have. When I look in the folder, the saved file is 0 bytes. No error message though. When I restart Classic99, save works again. The problem is, I don't know when it doesn't work. So I have to save as a new name while working, so I don't loose too much. I do the list "clip" also. That has saved my bacon a few times. I think this is a windows 10 issue. Can we just get Windows 7 with classic shell back!!!!! I have also set up a dsk3, 4 and 5. And save to them. When dsk2 fails ( no error ) dsk3 still works... So STRANGE. When compiling, it fails reading the OBJ file about half the time ( the first time ) but it brings up the same screen and I do the exact same thing and it works... I just don't know???? So, yeah, not working well, but I have been able to compile and run.... Though with corrupt output at times. I redo the process, changing nothing and it works... So much fun! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 23, 2018 Author Share Posted July 23, 2018 You should get in touch with Tursi to see what can be done. This seems to be a Windows 10/Classic99 compatibility issue. I tested Encruzado on my son's windows 10 computer and it seemed to work fine, but it was far from an exhaustive test. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 23, 2018 Share Posted July 23, 2018 Has anyone having problems with things like TI99Dir and Classic99 on Windows 10 tried anything like compatibility mode or running as administrator? Quote Link to comment Share on other sites More sharing options...
unhuman Posted July 23, 2018 Share Posted July 23, 2018 I had problems when I was running Classic99 in a Program Files folder. It works better for me under my own directory. Quote Link to comment Share on other sites More sharing options...
1980gamer Posted July 23, 2018 Share Posted July 23, 2018 Here is another NEW fun thing that is happening... I get random bad value messages that are invalid. If I restart Classic99, they go away for a while. Memory issue? Unfortunately, I upgraded Classic99 and the game developer package at roughly the same time. I could shut off the GDP and see if the problems continue, however, I am actively compiling and testing.... But that is the most logical thing to do. Can you add an option to not load any of the GDP? The old version had that. I don't know how this works. But I know something is resident because when I save, it auto completes the command. Select Extended basic and type NEW? Is that how I can do that? Thanks for trying to get me squared away! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 23, 2018 Author Share Posted July 23, 2018 (edited) From the last page of the document Using XBGDP: Turn off autocomplete in XB and XB256 You can temporarily turn off autocomplete by pressing F3 at the OLD DSK prompt. If you find that you prefer to not use use the autocomplete feature at all, it can be permanently turned off. For Extended BASIC, remove the underlined/highlighted text in line 180 of LOAD 180 CALL LOAD(-7,3,2):: CALL LOAD(8192,255,152):: CALL LINK("X"):: CALL LINK("ACON"):: END For XB256, remove the underlined/highlighted A in line 10 of XB256 so it is CALL LINK(“XB256”) 10 CALL INIT :: CALL LOAD(8192,255,152):: CALL LINK("X"):: CALL LINK("XB256A"):: END If you want to just get into XB and completely bypass the menu program, select XB and hold any key down when the menu program starts. 2 is as good a key as any; you have to push it to select XB so just keep holding it until XB says "READY" The version of Classic99 that I am using is QI398 which may not be the very latest, and it is running under Windows XP running in a virtual box on a linux system. It works fine set up this way. I should add that I put the Classic99 folder on my desktop, and set it up just as described in Using XBGDP. Edited July 23, 2018 by senior_falcon Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 23, 2018 Share Posted July 23, 2018 I think this is a windows 10 issue. Can we just get Windows 7 with classic shell back!!!!! I run and develop Classic99 under Windows 10. However! Windows 10 added much stricter file permissions. Don't run Classic99 from the Program Files or any other protected Windows folder - Windows will restrict writes to it and things like configuration saves won't work. (You might be able to work around it using run as administrator). My recommended solution is to create a work folder, with no spaces (cause spaces always cause file system fun). I personally run from D:\Classic99\, but subdirectories are okay too. I suspect this would solve a lot of disk access issues. The latest Classic99 is 399. I'm still brewing over what to do about the version number (also work, and other tasks, are owning me...) Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 23, 2018 Share Posted July 23, 2018 I had problems when I was running Classic99 in a Program Files folder. It works better for me under my own directory. Program Files, Program Files(x86), AppData, and various other folders are protected by Windows. Writes are virtualized or out-right denied unless running as administrator or via UAC. Quote Link to comment Share on other sites More sharing options...
1980gamer Posted July 23, 2018 Share Posted July 23, 2018 Wow, lots of good info. I was originally running from d:\classic99 when problems started. I later installed on c:\Program Files(x86) and it actually worked a little better. I then removed folder security. and got to were I am now. I will switch back to the D drive based on your help. I am running Classic99 QI399a I do think something strange is occurring though. The Bad value messages and when I run my program, when the bad value message does not pop up... It does not act as programmed. Yes, first thought is my programming. However, I change nothing, restart, and it runs as i would expect. This makes it ward to trouble shoot actual bugs... A great trouble shooting tool would be CALL OVERDRIVE ( on, off ) So I could run parts fast, but when at a critical piece, I could slow it down to see variables of counters or for loops count. It overdrive is so helpful for call coiinc etc. And it is helpful to see what the compiled version will look like. I know I need to ask in the Classic99 section... Thank you all. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 23, 2018 Share Posted July 23, 2018 Well, before you blame the emulator, you need to try the same steps on another emulator or (preferably) hardware, and see if it works there. 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.