Compiler 2.56 teaser

[senior_falcon]

 

I have been doing some work on combining the XB256 routines with the XB compiler. The video above shows some of my efforts, but there is still much to do. The demo is not fancy. The point of it is to show 256 different characters along with 28 different sprites using unique character definitions. The first program is running from XB and the second is compiled. The algorithm that generates the character definitions is very slow; normally you would use something much faster when programming.This uses a lot of string manipulation which slows the compiler down a bit, so the speed increase is only about 12x.

[1980gamer]

I am looking forward to this!

 

Will we loose anything? Available memory, character sets etc.

 

I need to look at the xb256 manual again.

 

Thanks for all your efforts, it has really given a new lease on life to the 99/4A.

[senior_falcon]

In screen 2 you have 256 characters to play with - 32 sets of 8. In screen 1 you have the normal 112 characters. These are independent of each other, so you can have screen 1 defined one way and screen 2 with different definitions and your program can flip between them as desired. Or as in the demo above, you could have 256 characters with another 112 characters available for sprite definitions. Remember that XB256 is a standalone program - it doesn't need to use the compiler; also that it works fine with real hardware. (there is a problem with disk access and the CF7 but I believe that is resolvable.) XB256 does not reduce the amount of memory for the XB program, but the stack space is reduced to make room for the extra graphics capabilities. When compiled, there will be less memory available for the compiled program. (No one, not even Rasmus, can write programs without using memory!) How much less remains to be seen. There is the possibility of moving the runtime routines to low memory which would free up all of high memory for programming. One intriguing use for the two screens is to use one as a debugging screen. Press a key such as Fctn 8 to switch screens and get a menu that lets you change the value of variables on the fly so you can test out timing or other changes to the program without having to recompile, then go back to the main screen.

[1980gamer]

"One intriguing use for the two screens is to use one as a debugging screen. Press a key such as Fctn 8 to switch screens and get a menu that lets you change the value of variables on the fly so you can test out timing or other changes to the program without having to recompile, then go back to the main screen."

 

That sounds awesome!

Also, to clarify, I was talking stack space. Of course any program uses memory

[+OLD CS1]

(No one, not even Rasmus, can write programs without using memory!)

 

Is blaspheming necessary to make your point?

[senior_falcon]

In the compiler there is a stack for strings. This stack is in high memory, along with the program and the runtime routines. Essentially the stack is the rest of high memory that isn't used by your program. Just as in BASIC/XB, there is a "garbage collection" routine that happens when needed. In the video there are some tiny hesitations as the characters are defined which I believe to be garbage collections. Because the extra routines use memory, if your program is the same size then there has to be less space for the stack and perhaps more garbage collections will happen. Not much point in worrying about it because not much can be done about it.

[RXB]

 

I have been doing some work on combining the XB256 routines with the XB compiler. The video above shows some of my efforts, but there is still much to do. The demo is not fancy. The point of it is to show 256 different characters along with 28 different sprites using unique character definitions. The first program is running from XB and the second is compiled. The algorithm that generates the character definitions is very slow; normally you would use something much faster when programming.This uses a lot of string manipulation which slows the compiler down a bit, so the speed increase is only about 12x.

Wondering if you used RXB commands like CALL MOVES like this:

10 X$(1)=" 128 bytes of character definitions"
20 A= ADDRESS OF CHARACTER TO START WITH
30 E= ADDRESS OF LAST CHARACTER DEFINITION
40 FOR L=A TO E STEP 128
50 C=C+1 ! COUNTER INDEX FOR STRING VARIABLE ARRAY
50 CALL MOVES("$V",128,X$(C),L) ! "$V" IS STRING VARIABLE TO VDP, 128 BYTES, STRING ARRAY, ADDRESS IN VDP
60 NEXT L

This routine is just off the top of my head but loads 8 character definitions at a time. 128 could be changed to 240 to speed up the loading 15 characters at a time.

Or use DATA statements but I believe they are much slower then strings.

 

Is it possible to compile RXB also?

Edited April 15, 2014 by RXB

[senior_falcon]

Hi Rich:

There is something similar to that in XB256. There is a utility that saves VDP data as compressed DATA statements that then can be merged into your program. Then CALL LINK("CWRITE",A$) will write the compressed data to the same address in VDP that it was saved from. One big advantage of this is that, even without compression, each character definition takes only 8 bytes - in your example above each character definition takes 16 bytes. One big disadvantage is that you cannot edit the DATA statements. This would be used mainly when the program is pretty much finalized, not during the development stage.

 

As far as compiling RXB, that's an interesting idea. In principle there is no reason it couldn't be done except for the memory constraints of the machine. As you add RXB features you would reduce the room available for your program. The other factor is that someone would have to write it. As Shel Silverstein sang: "That sounds like a wonderful opportunity - for someone else, not me."

[senior_falcon]

 

Will we loose anything? Available memory, character sets etc.

Gene asked a serious question to which I gave a flippant answer and I'm sorry for that. I think his real question is something like this: "I had a heck of a time getting mirror maze to fit in the memory. Do the added features mean I will have even less room for my programming?" The answer is that it depends. If you just program the way you do in regular XB then you will have somewhat less room. I will know soon just how much less. However, it you take full advantage of what XB256 has to offer then you should have more room. When your program is nearing completion you can save areas of VDP memory as DATA statements that can then be merged into your program. Then you can eliminate all the HCHARs or CHARs that put that stuff into VDP memory and just use CALL LINK("CWRITE",A$) to define characters, load a screen, load a soundlist, etc. This is much faster and much more compact. Speaking of soundlists, XB256 has a soundlist compiler that can take an XB program with CALL SOUNDs and convert it into a soundlist. And you can have 2 soundlists playing at one time. You might have the main sound list player playing theme music and then have the second player add explosions, rocket sounds etc. as desired without interfering with the theme music. This can all be tested in XB until you are happy with the results.

[1980gamer]

Gene asked a serious question to which I gave a flippant answer and I'm sorry for that. I think his real question is something like this: "I had a heck of a time getting mirror maze to fit in the memory. Do the added features mean I will have even less room for my programming?" The answer is that it depends. If you just program the way you do in regular XB then you will have somewhat less room. I will know soon just how much less. However, it you take full advantage of what XB256 has to offer then you should have more room. When your program is nearing completion you can save areas of VDP memory as DATA statements that can then be merged into your program. Then you can eliminate all the HCHARs or CHARs that put that stuff into VDP memory and just use CALL LINK("CWRITE",A$) to define characters, load a screen, load a soundlist, etc. This is much faster and much more compact. Speaking of soundlists, XB256 has a soundlist compiler that can take an XB program with CALL SOUNDs and convert it into a soundlist. And you can have 2 soundlists playing at one time. You might have the main sound list player playing theme music and then have the second player add explosions, rocket sounds etc. as desired without interfering with the theme music. This can all be tested in XB until you are happy with the results.

You hit the nail on the head!

I did not ask the question as intended, but you certainly got the spirit of it above.

 

The sound list seems very interesting, I currently only have "chomp" OR "siren" sound in Mirror Maze. It should ALWAYS have the siren playing in the background.

I actually use the sound to slow pacman's movement. But it would be very cool to fix this, and simply lower the volume of the current sound for the proper speed.

 

Also, the sound running independent would make the siren smoother. It is very choppy and gets choppier as you advance and the durations shrink.

Compression of graphics (screen and chars would be awesome also!)

[RXB]

Hi Rich:

There is something similar to that in XB256. There is a utility that saves VDP data as compressed DATA statements that then can be merged into your program. Then CALL LINK("CWRITE",A$) will write the compressed data to the same address in VDP that it was saved from. One big advantage of this is that, even without compression, each character definition takes only 8 bytes - in your example above each character definition takes 16 bytes. One big disadvantage is that you cannot edit the DATA statements. This would be used mainly when the program is pretty much finalized, not during the development stage.

 

As far as compiling RXB, that's an interesting idea. In principle there is no reason it couldn't be done except for the memory constraints of the machine. As you add RXB features you would reduce the room available for your program. The other factor is that someone would have to write it. As Shel Silverstein sang: "That sounds like a wonderful opportunity - for someone else, not me."

Actually RXB takes up considerably less space the normal XB does. The reason is subroutines like:

Normal XB

10 CALL HCHAR(3,4,45,3)

20 CALL HCHAR(7,6,50,5)

30 CALL HCAHR(9,11,55,7)

40 CALL HCHAR(13,16,60,9)

50 CALL HCHAR(17,23,65,11)

 

RXB:

10 CALL HCHAR(3,4,45,3,7,6,50,5,9,11,55,7,13,16,60,9,17,23,65,11) ! Each line number takes up more space and label space.

 

OR Normal XB:

10 Z$="This is a test"

20 FOR C=1 TO LEN(Z$)

30 CALL HCHAR(12,C,ASC(SEG$(Z$,C,1))) ! Not possible to use DISPLAY AT

40 NEXT C

 

RXB:

10 Z$="This is a test"

20 CALL HPUT(12,1,Z$) ! Unlike XB DISPLAY AT(row,col) the RXB HPUT uses same numbering as HCHAR

 

I could list many others that show memory saved is very significant. Thus you actually could make programs much larger reducing the memory restriction is normal XB.

Edited April 18, 2014 by RXB

[senior_falcon]

This critter is ready to go in a day or two, but I wanted to describe the problem I have been wrestling with and see if there is a better way to deal with it than what I did.

 

I have been using Notepad++ to develop the assembly language runtime routines and that works fine with Classic 99 for testing. To be more universal, I like to convert them into TI format files. First thing I did was to uncheck the box in Classic99 so it can save in TI format; then I wrote an XB converter that took the .TXT format source code and converted it to DV80 and saved to disk. The result worked fine in both Classic99 and Win994a. However the TI threw a DSR error when I tried to assemble the program. So then I shortened up the longer source code files so they would fit in the E/A editor and saved from there. (This was in Classic99) The TI still threw the DSR error when I tried to assemble. Also, when I tried to look at one of the files with the TI editor it loaded but then threw another error. I then saved the file (despite the error) and now it can be loaded and will assemble fine. What the heck is going on, and is there a simpler process to do this. I should mention that I am using a HRD4000 in case that has anything to do with this behavior.

[+Lee Stewart]

This critter is ready to go in a day or two, but I wanted to describe the problem I have been wrestling with and see if there is a better way to deal with it than what I did.

 

I have been using Notepad++ to develop the assembly language runtime routines and that works fine with Classic 99 for testing. To be more universal, I like to convert them into TI format files. First thing I did was to uncheck the box in Classic99 so it can save in TI format; then I wrote an XB converter that took the .TXT format source code and converted it to DV80 and saved to disk. The result worked fine in both Classic99 and Win994a. However the TI threw a DSR error when I tried to assemble the program. So then I shortened up the longer source code files so they would fit in the E/A editor and saved from there. (This was in Classic99) The TI still threw the DSR error when I tried to assemble. Also, when I tried to look at one of the files with the TI editor it loaded but then threw another error. I then saved the file (despite the error) and now it can be loaded and will assemble fine. What the heck is going on, and is there a simpler process to do this. I should mention that I am using a HRD4000 in case that has anything to do with this behavior.

 

The only thing I can think of at the moment that might be the problem is that DV80 source files saved by the E/A Editor save only a CR (>0D) for the end of a line do not have any end-of-line characters (>0A and/or >0D), not the CR LF combination of DOS/Windows TXT files.

 

...lee

Edited April 29, 2014 by Lee Stewart

[Willsy]

 

The only thing I can think of at the moment that might be the problem is that DV80 source files saved by the E/A Editor save only a CR (>0D) for the end of a line do not have any end-of-line characters (>0A and/or >0D), not the CR LF combination of DOS/Windows TXT files.

 

...lee

 

Really? How does it do end of line then? With no end-of-line markers the only option left is pad each line to exactly 80 characters, but that would be DF80, not DV80!

 

Now I'm intrigued!

[+mizapf]

Length byte at line start.

 

Example of a DV80 file (GeneveOS AUTOEXEC file)

 

 

000000: 08 45 43 48 4f 20 4f 46 46 03 56 45 52 4b 45 43     .ECHO OFF.VERKEC
000010: 48 4f 20 46 6f 72 20 6d 6f 72 65 20 69 6e 66 6f     HO For more info
000020: 72 6d 61 74 69 6f 6e 20 61 62 6f 75 74 20 74 68     rmation about th
000030: 65 20 47 65 6e 65 76 65 2c 20 69 6e 63 6c 75 64     e Geneve, includ
000040: 69 6e 67 20 64 6f 63 75 6d 65 6e 74 61 74 69 6f     ing documentatio
000050: 6e 2c 20 6c 61 74 65 73 74 36 45 43 48 4f 20 47     n, latest6ECHO G
000060: 65 6e 65 76 65 20 4f 53 20 72 65 76 69 73 69 6f     eneve OS revisio
000070: 6e 2c 20 74 6f 6f 6c 73 20 61 6e 64 20 61 70 70     n, tools and app
000080: 6c 69 63 61 74 69 6f 6e 73 2c 20 76 69 73 69 74     lications, visit
000090: 04 45 43 48 4f 2b 45 43 48 4f 20 68 74 74 70 3a     .ECHO+ECHO http:
0000a0: 2f 2f 66 74 70 2e 77 68 74 65 63 68 2e 63 6f 6d     //ftp.whtech.com
0000b0: 2f 69 6e 66 6f 2f 67 65 6e 65 76 65 2e 68 74 6d     /info/geneve.htm
0000c0: 6c 04 45 43 48 4f 32 45 43 48 4f 20 46 6c 6f 70     l.ECHO2ECHO Flop
0000d0: 70 79 20 64 72 69 76 65 20 31 20 69 73 20 41 3a     py drive 1 is A:
0000e0: 2c 20 68 61 72 64 20 64 69 73 6b 20 64 72 69 76     , hard disk driv
0000f0: 65 20 31 20 69 73 20 45 3a 04 45 43 48 4f ff 00     e 1 is E:.ECHO..
000100: 0f 50 52 4f 4d 50 54 20 24 6e 3a 5c 24 70 24 67     .PROMPT $n:\$p$g
000110: ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................

[Willsy]

Of course! Doh! Why didn't I think of that!