Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

2,167 Excellent

1 Follower

About senior_falcon

  • Rank
  • Birthday 10/14/1951

Profile Information

  • Gender
  • Location
    Lansing, NY, USA

Recent Profile Visitors

10,704 profile views
  1. As noted in an earlier post, XB 2.8 G.E.M. lets you customize XB so it looks the way you want. CALL LOAD(-2,COLOR,FONT) does the trick. If you add 128 to the font number it tells GEM to invert the DSK1.LOAD routine. Normally when you hold a key down it suppresses DSK1.LOAD. If you add 128, you have to hold a key down for a few seconds to make DSK1.LOAD happen. Also, if you set the second bit by adding 64, GEM should return to Force Command. I'm not positive this will work because I get no feedback from those who care about this feature, but in any case I see nothing else that can be done, and if it doesn't work at least nothing else will be broken.
  2. No. The compiler will work with XB256 but at present it is not compatible with The Missing Link, T40XB or T80XB. In the future I hope to be able to make it compatible with not just these, but most assembly support programs. I hope to have XB 2.8 G.E.M. finished in a week or so and then will take a long vacation from this stuff. Maybe in the winter I will look into combining assembly with the compiler.
  3. XB2.7 has CALL HELP which brings up a help menu. I like the idea, but the menu is not very complete and frankly, not all that helpful. I have come up with a more complete menu for XB2.8 G.E.M. Here are two videos showing it. Right now I am just finishing up testing it so it is still an assembly program loaded using CALL LOAD. The first video shows XB and XB2.8 G.E.M. side by side. This shows the HUGE speed improvement provided by the loader I borrowed from MiniMemory. The second shows the features of the help menu. This has most of the information that I cannot remember and usually have to look up. Now I just need to add it to the cartridge which should be straightforward.
  4. Well, it it's 4*35 then it would be 140 minutes per move. If it is 4^35 then it would be 2.25^15 years which is 2.25 million billion years which is WAY longer (162659 times longer) than the age of the universe. I hope it runs faster than that!
  5. Yes, the XB Game Developer's Package has a compiler that will convert an XB program into assembly. There is about a 20-30x speed increase. You have to use integer arithmetic which may require some rewriting. It's much easier to use integers when you are developing the XB program. An example 10 IF RND>.5 THEN 100 does not work with compiler 10 IF INT(RND*2) =1 THEN 100 works properly
  6. Normally RUN is what you would want to use, but CALL RUN can use a string variable. 5 A$="DSK1.PROGRAM2" 10 CALL RUN(A$) (RUN A$ errors out of the program (all 5 of these can use a string variable)
  7. I am finally done with the additional disk routines. The filenames can be a string constant such as "DSK1.FILE" or a string variable such as A$: CALL LFONT(filename) Loads a font CALL SFONT(filename) Saves a font CALL SAVEIV(filename) Saves an XB program in IV254 format CALL RUN(filename) Runs an XB program CALL RUNL1(filename) Used to chain XB programs together. With RUNL1 you can chain together a very large XB program of almost any size and way larger than the normal 24K limit. The video below shows this capability with two very short programs. Notice how the variables A and B$ are carried into the new program and used by it. RUNL1A - the first part of program 5 CALL LOAD(9458,0,0) 10 PRINT "SEGMENT 1 OF THE PROGRAM" 20 A=3.14 :: B$="HELLO WORLD" 30 CALL RUNL1("DSK9.RUNL1B") RUNL1B - the second part of program 40 PRINT "SEGMENT 2 OF THE PROGRAM" 50 PRINT A:B$ (The comments in line #1 are inserted by SAVEIV. This is only needed for programs less than 256 bytes long.
  8. Hi Omega: I didn't get an answer, so I thought I'd repost my question.
  9. Yes, that is correct. I think you will find there is a big speed penalty when using subprograms.
  10. A simple enough program to test how much difference there is might be: 10 FOR I=1 TO 10000 20 GOSUB 101 ! then try GOSUB 1100 30 NEXT I 40 PRINT I::END 101 RETURN 102 RETURN 103 RETURN ***PUT IN 1000 RETURNS UP TO 1100 RETURN
  11. The version number is now a floating point number. If GEM were finished today the version number would be: 2.820200731 which is version 2.8 plus the date in ISO 8601 format YYYY-MM-DD I'm hoping the finished version will be in august.
  12. You might give the XB Game Developer's Package a try. With XB256 you can have a screen that has 256 definable characters, not 112 like XB. And much much more. Oh yes, and you can compile the XB program you write for XB256 to get MUCH more speed (20x-30x faster). You could try XB G.E.M. which offers T40XB for a 40 column text mode screen, XB256 described above, and The Missing Link which provides bit mapped graphics. I am in the final stages of developing XB 2.8 G.E.M. which is a huge improvement over XB G.E.M.
  13. @Omega: Can you try this for me: Get into Extended BASIC CALL INIT CALL LOAD(-1,10) RUN "TIPI FC.FCMDXB" Does this reset the computer to Force Command the way you want? Get into Extended BASIC again CALL PEEK(-1,X)::PRINT X Does X=10? (In other words, does the memory persist through the reset?)
  14. Someone has to enlighten me. I understand the english word "Force" and I understand the english word "Command". It's when you put them together that I get lost. What is "Force Command"
  15. So typing: RUN "DIPI FC.FCMDXB" from the command line will do it? If that does the trick then this should be easy to do. Is there a way to detect whether there is a TIPI? It would be nice to do "BYE" or "QUIT" the usual way if there is no TIPI or this way if it is detected.
  • Create New...