XB256

[senior_falcon]

Attached is a zipped folder containing XB256, 256DEMO, a PDF with the manual for XB256, and a Win994a disk with XB256 and 256DEMO. The demo is the same as the teaser demo 2 weeks ago.

 

March 12, 2013 - I have uploaded a revised version of the program in a new topic called "XB256 revised." That's the one you should download.

XB256.zip

Edited March 12, 2013 by senior_falcon

[kl99]

wow! cool release. congrats on this!

will test it asap! do you plan to merge these set of commands into your XB Compiler?

Klaus

[unhuman]

Reading the manual... A few questions:

 

1. SCPXUP - it says that the string must be followed 15x without the string. Shouldn't that be 7?

2. there is no documented SCPXDN.

3. When setting sprite EARLYC, the sprite will not fade out on the right side, then, correct? Not coding anything yet, but this is something I could try myself.

4. Your example at the bottom probably should be updated to move the CALL LINK on line 20 inside the FOR loop...

5. Possible to make EARLYC configurable? For example, if using double-size, non-magnified, a value of 16 would work and allow smooth entry and egress. Also, does EARLYC work vertically too?

 

Sounds like this is incompatible with the compiler, but, perhaps with some tweaking or something, at least we'll be able to test before going to the compiler.

Edited February 26, 2013 by unhuman

[senior_falcon]

Reading the manual... A few questions:

 

1. SCPXUP - it says that the string must be followed 15x without the string. Shouldn't that be 7?

2. there is no documented SCPXDN.

3. When setting sprite EARLYC, the sprite will not fade out on the right side, then, correct? Not coding anything yet, but this is something I could try myself.

4. Your example at the bottom probably should be updated to move the CALL LINK on line 20 inside the FOR loop...

5. Possible to make EARLYC configurable? For example, if using double-size, non-magnified, a value of 16 would work and allow smooth entry and egress. Also, does EARLYC work vertically too?

 

Sounds like this is incompatible with the compiler, but, perhaps with some tweaking or something, at least we'll be able to test before going to the compiler.

 

Taking your questions in order:

1-The 15x is correct. Remember that this package does not offer full bit mapped graphics. (If you're interested in bit-mapped graphics I'll put in a shameless plug for The Missing Link). Imagine the letter "A" on row 24. The ASCII for A is 65. Directly above the "A" display ASCII 193 (65+128). Define ASCII 193 to be a blank. Now shift the patterns for ASCII 65 and 193 up one byte. Put the byte that is shifted out of 65 into the bottom of 193. Put the byte shifted out of 193 into the bottom of 65. Shift the patterns 8 times and the pattern for A will have become the pattern for 193 and A will be a blank. Now that A is blank you can move it to row 22 above ASCII 193. Move the patterns up one bit at a time just like before. Move the patterns 8 times and the A will look like an A again but will be 16 pixels above where it started.

2 - No documented SCPXDN. It doesn't exist. I envisioned SCPXUP as a way to get fancy title screen graphics. To scroll down would mean reading the text in reverse. I don't see how SCPXUP could be used in actual gameplay, but will be happy to eat crow when you guys prove me wrong!

3 - sprite early clock makes a sprite fade in/out at the left of the screen. Normally it fades in/out at the right.

4 - First off, thanks for reading all the way through the manual!! The example is correct (almost):

 

10 FOR I=1 TO 7 :: READ A$ :: NEXT I

20 CALL LINK("PRINT",1,1,A$) ! Print String7 on the screen

100 DATA String1,String2,String3,String4,String5,String6,String7, String8,String9,String10

This reads the seventh string in line 100 and prints it. This section is copied from The Missing Link manual and I forgot to change the name of the subroutines. Line 20 should be CALL LINK("DISPLY"...) or just PRINT A$. However, the meaning should be clear.

5 - The early clock is annoying because it would be so easy to implement - if only there were no limit check on the sprite color! Simply add 128 to the sprite color to set it. (Actually, adding 144 makes it compatible with Win994a). Not sure what you mean by making it configurable. There is no early clock for vertical movement and none is needed because sprites fade in/out at the top and bottom.

 

Hope that helps.

[kl99]

and are you planning to integrate these commands into your xb-compiler?

[senior_falcon]

Yes, they will become part of the compiler. It shouldn't be too hard to do that. The assembly routines are written, but the numeric values get passed in a different way. I'm going to take about a week vacation from programming and then get started on that.

[unhuman]

Now serving crow:

 

SCPXDN could be used to make a scrolling background for a space game or a top-down racer. At least in a compiled environment.

[senior_falcon]

Two points:

1 - Every other line is blank. There might be a way to work around this and have it look good, but I sure can't see how.

2 - SCPXUP is relatively bulky at around 280 bytes. There is plenty of room in low memory for XB subroutines, so there's no problem with that size in XB, but every byte added to the compiler means one less byte available for your program. You need to convince me that it's worth spending the memory on this.

[unhuman]

1 - Oh yeah... That doesn't bode well for a game

2 - If every other line is blank, this is broken for driving games for sure, but for a space game with a black background, perhaps not... But... No reason to go crazy. Not sure I have enough of a need other than theory here.... Makes me wonder if the upward scrolling is even a necessary feature...

[RXB]

My XB to GPL compiler is about half done before I gave up.

The reason is the TI community is all about Assembly or C or Forth, so what is the point of a GPL compiler.

 

Anyway what I did was use the SAMS as a buffer for Variables names and storage.

This allowed me to tackle any size program and compile into GPL.

 

I made videos on the process. Hope it gives you ideas:

 

http://www.youtube.com/watch?v=TQzp25sSa1A&list=UUULwPKqrRFCtNv5_xMuOqQw&index=3

 

 

Good luck

 

Rich

[senior_falcon]

Thanks Rich, will look at this tonight.

[senior_falcon]

Good videos! It sounds like you were using all floating point numbers. What sort of speed increase were you seeing? As I recall, there was about a 3x speedup with my compiler when using floating points. This was not necessarily very representative - I think I wrote a couple of routines in floating point just to see what would happen.

In your GPL compiler you had low memory available for A/L subs, the high memory for variables, so where was the program kept - in VDP ram?

[RXB]

Good videos! It sounds like you were using all floating point numbers. What sort of speed increase were you seeing? As I recall, there was about a 3x speedup with my compiler when using floating points. This was not necessarily very representative - I think I wrote a couple of routines in floating point just to see what would happen.

In your GPL compiler you had low memory available for A/L subs, the high memory for variables, so where was the program kept - in VDP ram?

 

 

Well using XB and files to create a source then using all the memory including the SAMS the final run would compile into a GPL source for GRAM/GROM that loaded at >6000 to >FFFF (40K)

So after the GPL source is created the GPL Assembler is used to turn the Source into a GPL GROM/GRAM program to be loaded in Cart space.

This would leave the upper 24K for variables, lower 8K for any Assembly you would want to load (was looking for XB compatibility) and VDP RAM would be entirely for Graphics or Files only.

 

To me this sounded like something very desirable. But as everyone poo poos GPL I could see no reason to contiue.

 

Rich

Edited March 1, 2013 by RXB

[sometimes99er]

But as everyone poo poos GPL I could see no reason to contiue.

 

A bit off topic. Sorry.

 

Well, your videos have had some healthy number of views. I’ve enjoyed them too. Personally I know XB and Assembly, and so Forth and GPL becomes interesting yet with speed etc. makes me more like wanting to do "my own thing" and without “restrictions” in Assembly. I can understand that this attitude in itself might be perceived as somewhat poo pooing, but I don't want to scare you off whatsoever. I think it’s absolutely sensational to have someone with your knowledge and talent in this forum. I value your input here and there, and try to be objective (not always succeeding).

 

I don’t think I’ll be up and compiling my own GPL stuff (choose to prioritize something else), but actually looked into manipulating the console GROM to skip the 4K and 16K VDP clears. A bit of curiosity about how many cartridge really rely on the console clearing VDP beforehand. Also wanting my emulation to be generally as fast and furious as possible - why not ? I managed the 4K bit, but the 16K thing was more complicated.

 

[CantStopClicking]

Sorry for keeping this off topic. But me, personally, and I am not a programmer by any means, so I feel safe to say as a programming newb, what turned me off of GPL was the perception that it was the cause of TI's super slowness and therefore I disliked anything to do with GPL. Avoid it like the plague. I believe that others may have that perception too, especially from back in the day when GPL was TOP SECRET and locked up tighter than a drum.

 

However, after 20+ years of being ignorant/unaware, I now realize it wasn't GPL that was necessarily the fault and I'm changing my view on it. But, like Sometimes99er stated, I've just chosen to put my project time elsewhere at the moment. (If only I could cut out sleeping and eating, I'd have more time!)

 

So, Rich, you've tackled an area that most people wouldn't have ever dreamed about even attempting. You should be proud that, AFAIK, you're the king of GPL! I WILL be asking questions, just not sure when. No poo poo'ing here!

 

As Tony Robbins would say; You just need to change your mindset!

 

-Dano

[Bones-69]

I downloaded XB256, read through the documentation and tried the demo. This is bloody fantastic!! Only problem is now that this does everything I ever wanted, I don't know what to do with it!

 

Looking very forward to messing around more with this and additionally excited if/when the XB compiler can handle these new commands.

 

Great work Senior. For the dedicated XB programmers amongst us that could never get our minds around assembler, we can finally produce stuff that is somewhat comparable with the assembly guys. AWESOME.

[senior_falcon]

Glad that you like it. Be sure to post any programs that you write using it. It will indeed be incorporated into the compiler. It may take a little longer than I had hoped. I will have company for the next couple of weeks and that will tend to keep me from the computer. Also, I have realized that the compiler has grown to the point where I have to re-think how the runtime routines combine with the compiled code. I think that it makes sense to put them into the 8K low memory, which is not used by the compiler. The downside to this is that the runtime routines will no longer be a part of the compiled XB program and so would have to be loaded separately. The upside is that you would get more room for the program, plus you would only have to assemble and load the program, because the runtime routines are already assembled and in a fast loader. This would speed things up a lot, especially on shorter programs. As things are now you assemble both the compiled code and the runtime routines and then you load both the compiled code and the runtime routines, which is quite a bit slower. BTW, if you save the program as EA5 the runtime routines would be part of the program and not need a separate loader.

[sometimes99er]

I downloaded XB256, read through the documentation and tried the demo. This is bloody fantastic!! Only problem is now that this does everything I ever wanted, I don't know what to do with it!

 

Hehe, luxury !

 

For the dedicated XB programmers amongst us that could never get our minds around assembler, we can finally produce stuff that is somewhat comparable with the assembly guys. AWESOME.

 

True.

 

I’ve released about a hundred assembler demos in cartridge format and I guess more than 80 percent of them can (easily) be redone in the Wilhelm’s XB Compiler. Part of the production line output problem is getting the ideas (at least write it down when you get one) and having the time. For full blown games, I wish I could be more persistent and stick with one project at a time.

 

[sometimes99er]

Also, I have realized that the compiler has grown to the point where I have to re-think how the runtime routines combine with the compiled code.

 

I guess all runtime routines are loaded no matter if they’re used or not. I don’t know how much it would complicate things at your end, but it would be nice if the “foot print” (runtime routines only included if used) could be kept at a minimum - hence maybe also allowing for larger programs ?

 

The downside to this is that the runtime routines will no longer be a part of the compiled XB program and so would have to be loaded separately.

 

Personally, also comparing with other platforms of the time, I like the “one file” solution. A manual option for the runtime routines in separate 8K area would be nice.

 

BTW, if you save the program as EA5 the runtime routines would be part of the program and not need a separate loader.

 

Do you consider the XB solution (one file as is) as having a separate loader ?

 

[senior_falcon]

The runtime routines are all loaded whether or not they are used. At first I had planned to have the compiler only load the routines that are actually used. The only way I could see to do it would lead to a very messy disk with 60 or 80 files for VCHAR, GCHAR, SPRITE, etc. I didn't like that solution. Moving them to low memory gives the smallest footprint possible - zero! With the full 24K high memory available there should be room for any XB program you can write.

 

I, too prefer the one file solution, but think the advantages of faster compiling and loading and more program space outweigh the slight inconvenience. It should be pretty invisible.

 

The point of the EA5 comment is that the runtime routines would be just another 8K block included in the several files that make up the program and would be loaded automatically along with the rest of the program. In other words EA5 would load it just like any other EA5 program.

[kl99]

Btw: The mimimised funnelweb version -included in your XB compiler for compiling the assembler source file - doesn't work with CF7+/NanoPEB devices. Funnelweb as such doesn't like the CF7+/NanoPEB. There exists a modified Funnelweb version that is compatible, but I don't have it. Maybe you can point that iisue in the docu and/or the menu screen.

 

Since a lot of people that work on real hardware are using the CF7+/NanoPEB, this should get pointed out.

 

I don't understand why you would need each routine as a dedicated file on the disk if you want to go for an approach, where you only load those routines into RAM which are used by the program?

[TheMole]

I don't understand why you would need each routine as a dedicated file on the disk if you want to go for an approach, where you only load those routines into RAM which are used by the program?

 

Same here. You might have to load them all, but you could free memory for unused subroutines during program initialization. All you need is a list of called routines somewhere in the compiled program file that can be used to clean memory after load. Wouldn't necessarily give you more code space, but could give you more space for data.

[jacquesg]

The runtime routines are all loaded whether or not they are used. At first I had planned to have the compiler only load the routines that are actually used. The only way I could see to do it would lead to a very messy disk with 60 or 80 files for VCHAR, GCHAR, SPRITE, etc. I didn't like that solution. Moving them to low memory gives the smallest footprint possible - zero! With the full 24K high memory available there should be room for any XB program you can write.

 

I, too prefer the one file solution, but think the advantages of faster compiling and loading and more program space outweigh the slight inconvenience. It should be pretty invisible.

 

The point of the EA5 comment is that the runtime routines would be just another 8K block included in the several files that make up the program and would be loaded automatically along with the rest of the program. In other words EA5 would load it just like any other EA5 program.

 

Harry,

 

Art Green wrote a Library Manager for use with the SAMS card. This program allowed you to create a large file that contained a number of separate functions used by the SAMS version of c99. Only the functions used in your program were included in your program. Previous versions of c99 included the full file even though only one or more function was needed. This seems to be similar to what you are trying to do.

 

A number of years ago Art Green released a cd disk containing the source codes for most of his programs. I believe that these files are on the SWPD site on Yahoo. It has been a number of years since I last used this Library Manager program but I was impressed although I did not know exactly how it worked.

 

Jacques

[senior_falcon]

Does Art Green's assembler work with the CF7+/NanoPEB? Or does anyone have the version of Funnelweb that KL99 mentioned above? BTW, all this should probably be in a new thread, since it has nothing to do with XB256.

[jacquesg]

Harry,

 

I have been trying to transfer your XB256 and 256DEMO files to run on my TI99/4A setup.

 

I can run xb256.tidisk from the Win994A simulator without a problem. I then changed the file extension to .dsk and tried running the file on Fred's TI994W emulator. It did not run properly.

 

Somehow I got the XB256 program file transferred to DSK1. on my TI-99/4A but I do not remember what I did. I then decided to create a text file to transfer the 256DEMO program usng TI99DIR. I ran HyperTerminal on my PC and Bruce Harrison's TRAN1 program to transfer the text file to my TI,. Using TextLoader I converted this text to an XB program file. I tried to run XB256 on my TI using both from the RUN statement in line 10 and running from the command line. In both cases the 256DEMO program did not RUN.

 

I then decided to transfer the contents of my DSK1 to PC99 using RSECTOR/WSECTOR. Except for a small FOR NEXT matching problem which was easy to find I got XB256 to run the demo file on PC99. Smelling success I transferred the same program files to my TI again using RSECTOR/WSECTOR. The program again hung up and could not access the 256DEMO program file.

 

My speculation is that I have inconsistencies in use of Disk Controllers. My TI uses a BwG DC while PC99 uses a Myarc DC. I do not know what DC Win994A or TI994W use. Perhaps you have other suggestions. My TI system is built around using standard FW and I do not own or run a CF7 card.

 

Jacques