Jump to content

senior_falcon

Members
  • Content Count

    2,418
  • Joined

  • Last visited

Community Reputation

3,228 Excellent

2 Followers

About senior_falcon

  • Rank
    River Patroller
  • Birthday 10/14/1951

Profile Information

  • Gender
    Male
  • Location
    Lansing, NY, USA

Recent Profile Visitors

11,630 profile views
  1. All true, but I bet the TI99 is at least 1000 times cooler.
  2. Years ago I added 32K to the 16 bit bus. I think the instructions came via a user group newsletter and they are probably the same as Matthew mentions above. As I remember there were 4 chips; 2-32K memory chips and 2 logic chips, plus a bunch of wires connecting everything. I installed a switch to restore the wait states for the rare cases where that is desireable. This works fine and usually speeds up assembly programs a noticeable amount. Spad13 MK 2 is much peppier. I don't think this does anything to the scratchpad ram. In any case, I never noticed any compatibility issues. I was hoping for a big boost in XB speed, but that is virtually the same, only around 1% faster.
  3. Most excellent! I hoped it would help, but wasn't sure, because string handling is often slower than numbers.
  4. It started life as a TI BASIC compiler which has limited IF THEN ELSE capabilities. It took a while to add the XB style IF THEN ELSE. That is what 1980gamer is referring to.
  5. CALL LINK("VREAD",0,16,A$,32,16,B$,64,16,C$,96,16,D$,128,16,E$) will read 16 bytes from screen position 0 (row 1,col 1) to A$, 16 bytes from screen position 32 (row 2,col 1) to B$, 16 bytes from screen position 64 (row 3,col 1) to C$, and so on for D$ and E$
  6. XB can pass numeric and string variables or constants to an assembly sub. Here is the problem: #1 is not a number "#1" is a string and could be passed, but then you need the quotes. I could never see a way around this.
  7. Try: 10 CALL LINK("VREAD",ROW*32+COL-33,1,A1$) Remember that you can read more than one byte into the string: 10 CALL LINK("VREAD",ROW*32+COL-33,10,A1$)
  8. I don't see the big picture yet, but it looks like you are trying to find a faster way to read 10 consecutive bytes from the screen and see if they are all spaces. If so, this will work and can be compiled: CALL LINK("VREAD",vdpaddress,10,A$)::IF A$=" " THEN GO SOMEWHERE (XB256 is needed here.) From the manual: CALL LINK(“VREAD”, memory address, # bytes, string[ , . . .]) VREAD reads the specified number of bytes from the VDP ram into a string variable of up to 255 bytes. Up to 5 strings can read with one call to VREAD.
  9. There is about 4K of memory left for more music. And also, I would think that being able to play different music at different places in the game would be desirable.
  10. In compiled code, OR is slightly faster than AND. But I don't think you would be able to notice. Using arrays is definitely slower, both compiled and in XB. Wherever possible you should use variables.
  11. I have worked out how to include Tursi's music player in a compiled program. The docs for the compiler do not properly describe how to include assembly subs with XB256 programs. Here's how to do it: (Throughout this I will assume all the files are all on DSK1. If they are on a different disk, then use that disk number) First, you were able to use Tursi's software to create BGM_XB.TXT This file contains the compressed sound data. You need to make one small modification to it: Modify BGM_XB.TXT by removing AORG >A000 (or any other AORG) Save the modified BGM_XB.TXT file Now you must assemble the file. With XBGDP in DSK1: Choose Assembler from menu For SOURCE file name, use DSK1.BGM_XB.TXT For OBJECT file name, use DSK1.BGM_XB.OBJ Press ENTER three times. and BGM_XB should be assembled Now you can test it out. Get into Extended BASIC, then: CALL INIT CALL LOAD("DSK1.TISNONLY.OBJ") This loads the player. Be sure to use the new version that Tursi just posted. CALL LOAD("DSK1.BGM_XB.OBJ") This loads the music file that you just assembled CALL LINK("SONGGO") to play CALL LINK("STOPSN") to stop sound Now you must convert it so it is compatible with the compiler. From Extended BASIC: CALL LOAD("DSK1.FIXAL") CALL LINK("X") LIST (optional) and you will see 10 CALL LOAD(8192,255,172):: CALL LINK("X") SAVE DSK1.GAMEMUSICC Now the compressed music and the player have been saved as an XB loader that will load the music and player to low memory when it is run. (Edit) About 4K of memory is left that can be used for more music When the game music is the way you like it, you do not have to repeat this step. Now you compile the XB256 program: QUIT; PRESS 2 FOR XB; and select XB256 at the menu. For testing I made a small XB program called HVTEST. This randomly uses HCHAR and VCHAR to put stuff on the screen. OLD DSK1.HVTEST to load the program Test it out, but remember you cannot use Tursi's sound player and XB256 at the same time. They are built into the compiler so DO NOT use "UC2LC" to convert the CALL LINKs to lower case Add a line to start the music: 90 CALL LINK("songgo") this must be lower case. It should be at the place in the program where you want the music to start. SAVE and compile as usual. After the Compiler and Assembler have done their jobs you come to the lMUSICTEST.zipoader. Enter Y for "Using Assembly Support?" You are prompted for "Compiled file to load?" This should be the file you just compiled and assembled. DSK1.HVTEST.OBJ Then you are prompted "Assembly routines to load?" DSK1.FILENAME change this to DSK1.GAMEMUSICC Press Enter when the cursor appears. Then you can save as EA5: DSK1.HVTEST-E And you can save as XB: DSK1.HVTEST-X RUN lets you test out the hybrid A/L and compiled program. EA5 programs need no modification. One more step is needed if you want to run the program from XB: OLD DSK1.GAMEMUSICC Modify line 10: 10 CALL INIT :: CALL LOAD(8192,255,172):: CALL LINK("X"):: RUN "DSK1.HVTEST-X" Then: SAVE DSK1.HVTEST-AL When you run DSK1.HVTEST-AL the assembly routines (in this case the music and player) are loaded to low memory, then the compiled program, DSK1.HVTEST-X, is loaded and run. if you are running from XB and break the program with Fctn 4, the music hangs up on the last note. Press a letter, press enter, and the error message will clear the sound generator. MUSICTEST.zip
  12. Got it working fine with compiled code. I will post step by step instructions tomorrow. A few tricks are necessary to be successful.
  13. I will look at this tonight. It should be pretty easy to get it all working together. One problem is that Tursi's player and XB256 want to be in the same place when running in XB. However, that problem goes away when compiled. "Flight of the Bumblebee" in Game Engine 256 is from "Bumblebee Boogie", an XB music program by Sam Moore. I used one of the compilers (Probably SLCONVERT) in XBGDP to convert it to a sound list. XB256 can play 2 sound lists at the same time. Bumblebee Boogie plays all the time, with additional sounds superimposed when the player jumps or falls. I don't know if this can be done with Tursi's player. The performance of Game Engine 256 is marginal. I believe that the ability to incorporate assembly subs could make this much more satisfactory. An assembly sub to handle the scrolling should leave plenty of time for the actual gameplay.
  14. I have no idea what this is or what to do with it. It assembled without error. I loaded it with CALL LOAD The DEF table has one entry, MUSIC, but CALL LINK("MUSIC") just crashes the computer. (Edit) The real question is, how did this come into existence? Did you start with an XB program that used CALL SOUNDs to make the music and then use one of the sound list compilers in XBGDP? If so, then PM me the music program and I will get it to work and show you how you can do that. Tursi's utility was discussed in another thread. I know nothing about that. I understand that the sound table and player reside in low memory, so that should be compatible with the compiler. But first it needs to be in a form that can be played from XB.
×
×
  • Create New...