Jump to content

senior_falcon

Members
  • Posts

    3,148
  • Joined

  • Last visited

  • Days Won

    2

senior_falcon last won the day on March 14 2023

senior_falcon had the most liked content!

5 Followers

About senior_falcon

  • Birthday 10/14/1951

Profile Information

  • Gender
    Male
  • Location
    Lansing, NY, USA

Recent Profile Visitors

13,208 profile views

senior_falcon's Achievements

River Patroller

River Patroller (8/9)

5k

Reputation

  1. I finally have an answer for you. You don't want to mess around with that area of memory. It is used for stack pointers, string variables, etc. much like the way XB uses the VDP memory. But there is a way to add a block of memory that can be accessed by compiled code. In the source code file created by the compiler (the file with the .TXT extension), you can add a block of code right after the ENDCC. Below is my test example, and this method works whether the runtime is in high memory or low memory, or if the program is loaded via XB or as EA5. You can find the beginning of the block in the compiled code by subtracting the length from >FF9E. In this case the block is 10+256+6 for a total of 272 bytes. >FF9E->110 is >FE8E and that is where the B in BEGINNING is. You can preload this block any way you want. CALL MOVE from XB2.9 is supported by the compiler, so you can move character patterns or screens directly to the VDP. You want to be careful not to use too much memory and leave enough room for the stack to function. Once you have added the block to the source code and it should be assembled and loaded as usual. The program can then be saved as an XB loader, EA5 or a cartridge and the data will be included as part of the program. FRSTDT LASTDT EVEN COPY "DSK1.RUNTIME5.TXT" COPY "DSK1.RUNTIME9.TXT" COPY "DSK1.RUNTIME10.TXT" ENDCC TEXT 'BEGINNING ' \ BSS 256 or COPY "DSK1.YOURCODE.TXT" TEXT 'ENDING' / AORG >2008 COPY "DSK1.RUNTIME1.TXT" COPY "DSK1.RUNTIME2.TXT" COPY "DSK1.RUNTIME3.TXT" COPY "DSK1.RUNTIME4.TXT" COPY "DSK1.RUNTIME6.TXT" COPY "DSK1.RUNTIME7.TXT" EORT AORG >3FFE DATA EORT (edited 3/10 for a simpler method)
  2. I made a few small tweaks to my patch for TORPEDOX. Now it starts automatically just like the original, without the need for CALL LINK("X") Here is the modified patch: AORG >F000 this is where my interrupt routine will be loaded C @HX045B,@>20F6 when >20F6 is >045B then the CALL INIT code has been restored and it is safe to start the real interrupt routine JNE HX045B not equal, so just go back MOV @HXA206,@>83C4 load the address of the real interrupt routine HX045B B *R11 HXA206 DATA >A206 address of TORPEDO interrupt routine AORG >83C4 DATA >F000 TORPEDOX It takes about 123 seconds to load in XB, and about 6 seconds to load in XB2.9 G.E.M. I see there is code in high memory. It may be that a large XB program will overwrite this and cause trouble.
  3. I tried out TORPEDO BASIC using XB2.9 G.E.M. and found that it would get hung up while loading. After some analysis, I found that TORPEDO BASIC runs using an interrupt routine, and that the interrupt routine is started up with AORG >83C4. This would be OK using GEM, except that the interrupt routine uses subroutines loaded with CALL INIT. The assembly loader in GEM is adapted from the MiniMemory loader. It overwrites memory locations loaded with CALL INIT, then when the assembly code has been loaded, those memory locations are restored to the expected values provided by CALL INIT. But the AORG starts the interrupt routine before the loader is finished, and so it crashes. I modified TORPEDOX so instead of starting up automatically, you have to type CALL LINK("X") to start it up. CALL LOAD("DSK1.TORPEDOX") CALL LINK("X") TORPEDOX The GIF below shows why you might want to use XB2.9 for this. The manual is written in German, so I only have a rough idea of what additional capabilities are in TORPEDO BASIC. Is this a useful tool, or just a curiosity from the past?
  4. Thank you! That should help the unwary avoid this in the future.
  5. Yes, you are right on both counts. The statement separator :: will not compile properly if it is at the end of a line, whether it is followed by a comment or not. REM can be used in XB following the statement separator, but that will not compile, so it has to be like your 10 A=B+C ! summation of variables or my 1170 IF YEL+BLU+RED=0 THEN 690 ! CLEARED
  6. I tried to compile 1980gamer's program, and just as he described, the compiler crashed. Here is what I saw: Since the compiler crashes while analyzing line 1170, there is something in that line that the compiler doesn't like. Let's take a look: 1170 IF YEL+BLU+RED=0 THEN 690 :: REM CLEARED Nothing at all exotic in that line, except the double colon is immediately followed by a REM. Since that is the only thing at all unusual, let's take out the double colon and try again. 1170 IF YEL+BLU+RED=0 THEN 690 ! CLEARED Using a text editor, I quickly found there were 3 lines with a double colon followed by a REM or a ! 1170 IF YEL+BLU+RED=0 THEN 690 :: REM CLEARED 3598 IF MDL=32 AND MDL2=32 THEN 3594 :: ! mdr 3530 3960 MOV=MOV+1 :: REM MOV2=MOV2+1 Once the double colons are removed the program compiles, assembles, and runs properly. (edit) the statement separator :: cannot be used at the end of a line, whether followed by a comment or not. XB is happy to end a line with :: REM comment, but that cannot be compiled. Any time the compiler crashes, you can see where it happened by watching the line numbers as they are analyzed. Finding and fixing this would take way too much time, so I have updated the docs to describe this "feature" and how to avoid it. I should be able to post the latest version soon.
  7. Can you either post or PM me the game so I can try to track down the problem?
  8. Although TI BASIC and XB 2.9 G.E.M. give the same results with the same random number seed, the random numbers created by the compiler are different. So if you intend to use this in a compiled program, you must use a compiled program to determine what seed gives the desired results. If you run this program in basic and compiled, you will see the results are different. 10 CALL LOAD(-31808,12,34) 20 FOR I=1 TO 20 30 PRINT INT(RND*99); 40 NEXT I Here is something interesting. Run this program in E/A Basic or XB 2.9. It sets the random number seed, then peeks the value that RANDOMIZE actually loaded A seed from 100 to 199 will actually give the same seed, as the PEEK shows. Likewise 200 to 299, etc. The BASIC manual explains why, but it is still surprising to me. The seed can even be something like 1.234e+126 10 RANDOMIZE (I) 20 CALL PEEK(-31808,A,B) 30 PRINT I;A;B 40 I=I+1 50 GOTO 10
  9. AlexJ seems to have a real knack for finding errors in my code. Here are 2 anomalies that he found in the compiler, along with one request and its solution. 1 - If the compiled code uses CALL LINK then the name of the subroutine must be in the call link statement. i.e. 10 CALL LINK("CLS") but not 10 A$="CLS"::CALL LINK(A$) Here is the code that led to the discovery: 35 FOR W=1 TO WN :: _PR$="PRINT" :: IF WC(W)=P THEN _PR$=_PR$&"I" 40 CALL LINK(_PR$,WY(W)+1,WX(W)*2-1,SEG$(SN$,W,1),1):: NEXT W This code is clever in that it lets one CALL LINK do either PRINT or PRINTI. Unfortunately the compiler balks at this and so you must make 2 lines, one with CALL LINK("PRINT",..) and one with CALL LINK("PRINTI",..) 2 - This is a really weird line of code that works in XB, but fails in the compiler. 570 IF V=-10 THEN GOSUB 1420 :: ON FL+1 GOTO 500,730 here the sub at 1420 sets FL to 0 or 1, then the ON FL+1 sends it to the right program line It seems really strange to put ON GOTO or ON GOSUB in an IF/THEN/ELSE statement, but it does work in XB. The solution here is simple: IF FL=0 THEN 500 ELSE 730 or else put the ON GOTO in a separate line. 3 - He found an error in T40XB that will also be in T80XB: 5010 CALL LINK("T40") 5150 CALL LINK("PRINT",25,1,"",0) this just scrolls the screen by printing a null string on line 25 5170 RETURN This causes "RETURN WITHOUT GOSUB IN 5170" If you make the length a 1 then the problem goes away. CALL LINK("PRINT",25,1,"",1) Rather than spend hours trying to fix the code, I will amend the docs to describe the errors and how to avoid them. 4 - Is there a way to set the random number seed and store it so you can reset it to give the same "random" numbers if you replay the game. The answer is "yes." Here is my revised paragraph in the manual that describes RANDOMIZE: RANDOMIZE can be used, but has no effect; it is done automatically. The random number seed is the 2 bytes at >83C0 or -31808. The TI is constantly scrambling this value until the program starts up. You can CALL LOAD(-31808,N1,N2) to get the same random number sequence, or CALL PEEK(-31808,N1,N2) to store the seed so it can be restored later. (-31808 is the random number seed for TI BASIC, compiled XB, XB2.9 G.E.M. and probably RXB. It is not the random number seed for normal XB)
  10. That is horrible! Thankfully it is very rare in North America, but that's not much consolation if you are one of the victims. I hope you can get some relief. If that isn't a disability, then I don't know what one is.
  11. How on earth did you get elephantiasis? That is super rare. Dominican Republic?
  12. "tinkering away with old-school Texas Instruments calculators." LOL
  13. Yes, that can be done. Of course the ideal would be to have multiple pages of assembly code that could be paged in and run as necessary. But that's not going to happen, at least from me! Much of the VDP is not used by a compiled program, so you could use it to store multiple fonts, character definitions, colors, sprites, etc. But the data has to get there first. One possibility would be to have the first program in the chain copy data from DATA statements into the unused areas of the VDP. It would be a little cumbersome, but it should work. For example: 5 I=8192 !vdp at >2000 10 READ A$ 20 IF A$"" THEN run the next program 30 FOR J=1 TO LEN(A$)::CALL POKEV(I,ASC(SEG$(A$,J,1)))::I=I+1::NEXT J 40 GOTO 10 (I have not tested this so it may have errors, and of course in XB it is likely to crash the program) Now that the vdp is loaded, then it gets easier. The next program in the chain could CALL MOVE(1,8192,1024,768) move 768 bytes from v>2000 to v>0400
  14. Very nice! It is up to your usual high standards.
×
×
  • Create New...