Jump to content

senior_falcon

Members
  • Posts

    3,066
  • Joined

  • Last visited

  • Days Won

    2

senior_falcon last won the day on March 14

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,056 profile views

senior_falcon's Achievements

River Patroller

River Patroller (8/9)

4.8k

Reputation

  1. As I remember, you worked with Matthew180 to develop an assembly scrolling routine that kept the screen map and the scrolling routines all in low memory. For what it's worth, things have changed with the compiler, and you can now use assembly subs, so that custom screen scrolling sub is now a possibility.
  2. With a tiny change to the code, I can make the early clock toggle between off and on. CALL LINK("EARLYC",1) would turn on the early clock for sprite #1 CALL LINK("EARLYC",1) a second time would turn it off. Of course, then you must keep track of the early clock's status to be sure it does what you want. Would this be a useful addition? Or is it confusing?
  3. The problem is easy to understand. (Once you understand it!) Without giving away too much of your code, the program has: 635 CALL LINK("PLAY",2432) starts the sound list 640 CALL LOAD(-31879,TM) reset the timer 650 GOSUB 1590 Sub 1590 reads the joystick, fire button and keyboard. If you use the joystick it comes to these lines: (I have omitted some lines) 1648 IF JY<>0 OR JX<>0 OR K=0 OR K=5 OR K=2 OR K=3 THEN CALL SOUND(100+DEL,2222,30) 1670 IF JY<>0 OR JX<>0 OR K=0 OR K=5 OR K=2 OR K=3 THEN CALL SOUND(100+DEL,420,25,222,29) 1690 RETURN If XB comes to a CALL SOUND while still playing a sound list, it first must finish the current sound list. Only then can it move on to perform the CALL SOUND. The solution is simple - just make the sound duration negative. Instead of CALL SOUND(100+DEL,2222,30) you can have CALL SOUND(-100-DEL,2222,30) or CALL SOUND(-(100+DEL),2222,30) Then the currently playing sound list is stopped and the new CALL SOUND is played.
  4. Did you ever rlease the TI version of JEWEL-5?

    1. senior_falcon

      senior_falcon

      I will get around to it at some point.

  5. Hi Harry,

    It happens both in xb256 and compiled.  

    635 CALL LINK("PLAY",2432)

    just so you can find it...

     

     

    DO321.zip

    1. Show previous comments  1 more
    2. 1980gamer

      1980gamer

      1602 was only added to test increasing time passing quicker... for total time calculation testing.

       

      Is it possible to have music play and have sound fx?  I think I can set the music to the 3rd channel.. and do game sound to the first channel.. right?

       

      Either way, it works...

       

      I just need to come up with some jingles.

      Thanks again,

      Gene

       

       

    3. senior_falcon

      senior_falcon

      Is it possible to have music play and have sound fx? 

       

      Absolutely! This must be done with sound lists and not CALL SOUND.

      Starting with page 12 of the XB256 manual, there is a description of sound lists. This can be pretty deep stuff, so read it through a couple of times.

      Page 13 has section entitled SLCOMPILER TUTORIAL. Work carefully through the examples until you understand how it works, then you can use your own music and sound effects.

      SLCOMPILER makes the main sound list using sound generator 1, with 2 and 3 if necessary. PLAYER2 is used for special effects and starts using generator 3, then 2 and 1 if necessary. It does not interrupt the main sound list which continues to play.

      Good luck!

    4. 1980gamer

      1980gamer

      Ah, I remember this working.  But it had been a long time since I used it.

       

      I even remembered the channels being set up not to step on each other.

       

      I just wish I could come up with some catchy jingle that doesn't drive the player crazy after a little while!  LOL

  6. I included APERTURE, by Adamantyr with the XB game developer's package, and use it as an example of how to compile a program. I did not ask for permission to do this, and now realize that I should have done so. If this is a problem then I will remove it and substitute something else.
  7. Don't know why that would be a problem. Can you PM the program to me along with a description of where the problem lies. (edit) Also, does this happen when running from XB256, when compiled, or both?
  8. I would understand that bit 0 is the first of the four most significant bits, and bit 3 is the last. Is that correct, or am I thinking in reverse? (Edit) Below is from the 9918 VDP guide. Unlike the description in the E/A manual, here there is no ambiguity as to which bit should be set. "The fourth byte in the Sprite Attribute Table entry performs two functions. The lower four bits(nibble) define the sprite color, which can be any of the 16 available VDP colors. The MSB is the Early Clock bit, which shifts the horizontal position of the sprite to the left 32 pixels (whenset high). The remaining three bits are unused and should be set to 0."
  9. "The four most-significant bits in the fourth byte control the early clock of the sprite. If the last of these four bits is 0, the early clock is off. Then the sprite's location is its upper left^iand comer, and it fades in and out on the right edge of the screen. If the last of these four bits is 1, the early clock is on. Then the sprite's location is shifted 32 pixels to the lefti allowing it to fade in and out on the left edge of the screen" Above is what the E/A manual says. In my code I read the color byte, then ORI R1,>9000 and then write it back to the VDP. This does not accord with the E/A manual. My notes say this is necessary for compatibility with Win994a. It does set the last of the four most significant bits, as the E/A manual says, but it also sets the first. It doesn't seem to cause any problems.
  10. Here is a short program that shows what you want to do. The video shows it first running in XB and you will see a slight flicker when the sprite wraps around. The compiled version does not do this. A revised version of RUNTIME4 is below the program. This has the proper code for EARLYC. The previous version had an older version of EARLYC that combined the sprite number and the sprite color. That is not done in XB256 and now the compiled version matches that behavior. 5 CALL MAGNIFY(4) 6 ECO=0 10 CALL SPRITE(#1,65,16,100,100,0,5) 20 CALL POSITION(#1,X,Y) 40 IF Y<2 AND ECO=0 THEN CALL LINK("EARLYC",1):: ECO=1 :: GOTO 20 50 IF Y>33 AND ECO=1 THEN CALL LOCATE(#1,X,Y-32):: ECO=0 :: CALL COLOR(#1,16):: GOTO 20 60 GOTO 20 (Edit) In line 50, the CALL COLOR(#1,16) is there to turn off the sprite early clock. In code that will be compiled, there is another way to turn the early clock on/off. There is no limit check on CALL COLOR, so if you add 144 to the color it will turn the early clock on. According to the E/A manual it only needs to be 128, but my notes say it must be 144 to work in Win99/4a, and that change seems to cause no problems on other simulators. CALL COLOR(#1,160) !early clock on CALL COLOR(#1,16) !early clock off RUNTIME4.TXT
  11. I will have a short demo program for you soon, but in testing it, I found that CALL LINK("EARLYC",X) does not work properly in the compiler. I don't see how the code I wrote makes any sense. So I will study that until I have an answer, and then will post it. There is another way to do it that works fine compiled, but I want both ways to work.
  12. In theory, a word processor could be written using the jailbreak method to start up an assembly language word processor that runs in 40 columns. No cartridge required; this would need nothing more than a console and tape player. You would load the program from the tape player, and then load or create the document, which can then be saved to tape when desired. As a rough estimate, it might use about 5K for the program (depending on the bells and whistles), which would leave about 8K for the document. (About 3 or 4 pages) As far as I know, this does not exist, but it should be possible. The fly in the ointment is that a bare console has no way to send text to a printer. That requires some kind of expansion system, although I understand there was a cart that could send text to a printer.
  13. It's pretty clear that your line drawing routine is quite a bit better than the TI one!!! Guess I picked the wrong one to copy.
  14. Almost right. BASIC and XB think the screen is from row 1 to row 24 and col 1 to col 32. But the VDP thinks the screen is from row 0 to row 23 and col 0 to col 31. So one additional instruction must be added: For HCHAR or VCHAR 90 LOC=LOC+33 100 ROW=INT(LOC/32) 110 COL=LOC-ROW*32 or 100 ROW=INT(LOC/32) 110 COL=LOC-ROW*32 120 ROW=ROW+1::COL=COL+1 Just to make it interesting, DISPLAY AT starts two columns over. DISPLAY AT(3,1):"*" is the same as CALL HCHAR(3,3,42) So for DISPLAY AT: 100 ROW=INT(LOC/32) 110 COL=LOC-ROW*32 120 ROW=ROW+1::COL=COL-1
  15. Yes, but I am pretty sure I would not be able to find it. As I remember, I adapted the line plotting routine from Lines for The Missing Link. I can extract that and see how it compares. There are some things that make it a little slower in The Missing Link than it would be when running from assembly.
×
×
  • Create New...