Jump to content

senior_falcon

Members
  • Content Count

    2,288
  • Joined

  • Last visited

Community Reputation

2,879 Excellent

1 Follower

About senior_falcon

  • Rank
    River Patroller
  • Birthday 10/14/1951

Profile Information

  • Gender
    Male
  • Location
    Lansing, NY, USA

Recent Profile Visitors

11,389 profile views
  1. Having used it way more than anyone else on the planet, it is probably not surprising that tmop69 would discover a bug in the compiler. This is a tricky one that almost never manifests itself. This only happens when you are using IF THEN ELSE and have a GOSUB in the program line. If low byte of the line number is 134 then the code generated by the compiler is faulty. So any line number with a combination of N*256+134 such as 134, 390, 646, etc. could cause trouble. I believe this has been fixed in a way that will not cause other unexpected bugs to appear. I will post the revised version once tmop69 has verified that it is actually fixed.
  2. How many characters do you need? You might have problems with standard XB. There are 112 patterns available and the buildings shown above are already using 64 patterns. But remember that XB256 lets you use all 256 patterns plus 112 patterns for sprites. Seems like that would be plenty, but I don't know anything about the game you are trying to port. Certain characters such as "N" are tough to do with a width of 3 pixels. The font below is about as good as you can do. The N in "saloon" should be changed from "L"
  3. I did some work converting the character patterns into compressed data statements to run with XB256. Earlier, I was a little over optimistic about the amount of compression that would happen, thinking the data would be about 1K long. As it turned out, after being compressed, the data statements use 1760 bytes of memory. (Compared to 9000 bytes in the original program). As I speculated, when using compressed data statements and CWRITE the speed while running in XB is about the same as the compiled version of the original program. Of course, this program can be compiled and the results are in the short video below. In the folder are: RUNNING-X compiled version of original program RUNNING256 Requires XB256. XB version using compressed data and CWRITE to write the definitions to VDP. RUNNING2-X compiled version of RUNNING256 (shown in video below) 1 !RUNNINGMAN DEMO FOR XB256 USES COMPRESSED DATA STATEMENTS 100 CALL CLEAR 190 RESTORE 30572 200 GOSUB 400 ! redefine character set 202 FOR I=33 TO 96 :: A$=A$&CHR$(I):: NEXT I :: CALL LINK("WINDOW",1,3,10,10):: CALL LINK("DISPLY",1,3,A$,0) 209 REM Display initial graphic 285 RESTORE 30508 289 REM Animation loop 290 FOR ANI=1 TO 9 300 GOSUB 400 310 NEXT ANI 320 RESTORE 30508 ! restore reads to second data set (last set is repeat of first) 330 GOTO 290 ! restart animation 399 REM Redefine character set 400 READ A$ :: IF A$="" THEN 440 420 CALL LINK("CWRITE",A$):: GOTO 400 440 RETURN 30508 (DATA STATEMENTS REMOVED) RUNNINGMAN.zip
  4. "It takes XB a god-awful long time to load the 4884-byte routine!" I hate to turn every post into an advertisement for XB 2.8 G.E.M., but if you tried it out, you would see this is no longer a problem.
  5. Yep, CALL CHAR is not the quickest way to do this, nor is it the most compact. The fastest and most compact would be to use XB256 which lets you save an area of VDP ram as a compressed data string. You can take a picture of the character definitions from 32 to 96, and put it in one (or more) strings. This uses RLE compression and the first couple of bytes has the address in VDP. The subroutine CALL LINK("CWRITE",...) decompresses the string and moves it into VDP ram in the same place from which it was saved. Very fast and very compact. I would guess the definitions would take less than 1K of memory. I would estimate that this technique would let the program run in XB at the same speed as the compiled demo, and if compiled it would be like your forth demo. A big downside is that the process is cumbersome and changes are difficult to make.
  6. Since we're advertising our wares, here is Lee's running man demo in compiled BASIC. No changes required, just saved and compiled. Not as fast as the forth demo, but there are ways to get more speed...
  7. You can download it right now and run it as a user cartridge. (sorry about the big blue heart-dunno where that came from!)
  8. "Or can you do this in XB 2.8 without doing anything but just type it in or run it without a CALL to make it work?" Of course it can be done. XB 2.7 is not the same as XB 2.8 G.E.M.!!!!!
  9. Incorrect. XB 2.8 G.E.M. can also run TI BASIC programs without modifications.
  10. The key to doing this is "programming skill". I don't have enough of it.
  11. There is no inherent reason why this should be incompatible with XB. With enough memory and programming skill this would be possible.
  12. Here's something to chew on. Variables must start with an alphabetic character, or @ or _. You could use @ or _ as the first character in a variable name to indicate an integer. For example: CALL HCHAR(@1,@1,@42,@768) When the XB interpreter sees @ as the first character in the variable name it knows that a 2 byte integer is to be used instead of the usual procedure of reading the characters, converting to FP, converting to integers, and using them. Or CALL HCHAR(@ROW,@COL,@CH) Of course, this must be preceded with @ROW=1::@COL=1::@CH=42 so XB knows what the values of the variables are.
  13. Without a GPL interpreter, most of the memory from >0000 to >1FFF would be available. Most of the memory from >8000 to >9FFF is wasted. We're up to 16K already. >4000 to >5FFF might be available but you'd have to be careful not to mess up peripherals. Up to almost 24K. (I think apersson has a memory expansion that provides all 64K of memory) You can bank switch all you want at >6000 to >7FFF. You don't need to reserve the lower 4k in the bank. 128 or 512 bytes would probably be plenty. When changing banks, you just need to have an area that is the same in every bank so XB doesn't get lost.
×
×
  • Create New...