Jump to content

senior_falcon

Members
  • Posts

    3,157
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by senior_falcon

  1. I should be able to give some more definite information soon. So far what I have written is from memory, which as we all know, can be fallible.
  2. You are almost there. With JUWEL in drive 1, type: OLD DSK1 HMLOADER then RUN Load your files, something like: DSK3.TURSIPLAYER.OBJ DSK3.MUSIC.OBJ When done enter a blank line. CONTINUE LOOKUP IN LOW MEMORY? Enter Y The files are loaded into high memory starting somewhere around >A000 to find out how big they are. When that is known they are loaded again, this time embedded in a 1 line xb program. If you use XB2.9 the loading process goes a lot faster. The xb program pokes an address to >2000. This tells CALL LINK where to find the lookup routine. I think that address is always the same. All you need is the tweak to TURSIPLAYER so it knows that new location. If a match isn't found after looking through the DEF table in high memory, then the normal CALL LINK lookup is done, so it will be able to find the TML routines. Add xb program lines to the embedded program created by HMLOADER.
  3. I think this should be possible. (Perhaps that's just the optimist in me coming out.) This is assuming each section of the program has its own music that gets loaded with the XB program when it is loaded. I will need music files from you and instructions on how to use them. I won't be able to do anything till this weekend. It's a bit of a dance - both music and the program must fit in 24k, so you should plan carefully how much to allot to each.
  4. I misunderstood the question. Sounds like you are not compiling, but instead are running TML normally from XB. As Tursi notes, TML uses all of low memory. In the XBGDP there is a utility called HMLOADER. This adjusts some pointers so you can put assembly code in high memory. The code is embedded in a one line XB program. Then you can merge in lines of code, or"paste XB". When you CALL LINK, XB first looks through the def table in high memory. If the al sub is not found, then it looks for the sub in the table in low memory. So this should let you use the sound player and the TML routines as well. No need to use AORG. But be sure to reserve needed buffer space with BSS.
  5. I am on vacation now, but when I return I will study your problem in more detail. I have been working with SteveB on how to add additional A/L subs to a compiled program, and this method may work for you. How long is your program? That may be a limiting factor.
  6. Good idea to keep them appeased.. You don't want the computer gods to smite you. They have done that to me many times.
  7. Polytheism in the retrocomputing world. Who would have guessed?
  8. The McGoverns of Funnelweb fame did an article about assembly that showe some neat tricks, with C *R2+,C*R2+ being one f them. As I recall, much of their focus was conserving registers, which you can low on, even with 16 of them. As far as clarity, C *R2+,*R2+ add 4 to R2 And then there is no mystery about what is happening.
  9. Then of course, there is C *R2+,*R2+ which is not intuitive for a beginner.
  10. 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)
  11. 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.
  12. 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?
  13. Thank you! That should help the unwary avoid this in the future.
  14. 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
  15. 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.
  16. Can you either post or PM me the game so I can try to track down the problem?
  17. 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
  18. 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)
  19. 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.
  20. How on earth did you get elephantiasis? That is super rare. Dominican Republic?
  21. "tinkering away with old-school Texas Instruments calculators." LOL
  22. 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
  23. Very nice! It is up to your usual high standards.
  24. Yes, all the enhanced graphics modes can be compiled. XB256, The Missing Link for bit mapped graphics, T40XB/T80XB for 40/80 column text mode, and SteveB's multicolor routines. The process is described in the docs, but let me know if more information is needed.
×
×
  • Create New...