XB - HCHAR vs DISPLAY AT

[etownandy]

I thought I'd translate TI-Trek from BASIC to XB. Mostly because it's a great game but it runs so darned slow in BASIC. I've got quite a few things cleaned up, but wanted to speed up the display of stat info and the command prompt in the game.

 

This is the loop used to display most "messages":

 

2510 FOR I1=A TO LEN(M$)::CALL HCHAR(RW,(CL+I1-1),ASC(SEG$(M$,I1,1)))::NEXT I1

 

I thought, no sweat, I can use DISPLAY AT to show the entire message instead of building it up and displaying it one character at a time (because that is indeed SLOW):

2510 DISPLAY AT(RW, CL-1):M$

 

When I tested that, I realized something I either hadn't before or completely forgot about...DISPLAY AT doesn't give you all 32 columns of the screen. As a result, I get some really nasty wrap-around effects.

 

Can anyone suggest an alternative that will let me display this text faster than a looped HCHAR in XB while avoiding the wrapping issues? I was hoping for a quick drop-in. I have a feeling I'm not going to get it.

Edited January 13, 2017 by etownandy

[Sinphaltimus]

I'm not sure what it looks like in your game but in my current project I use graphics fir Abby static text added display at for variables that change like score, lives, etc...

 

So I create a program that will accurately display the static gui as I need it to be then I use Harry Wilhelm's compressor to create the compressed graphic of the current display.

Edited January 13, 2017 by Sinphaltimus

[+adamantyr]

I ran into this issue myself a long time ago... I hate the fact DISPLAY AT is limited to 28 columns.... I think the reason why is it was originally just an alias command for PRINT.

 

One way you CAN do it is to write a subprogram to use HCHAR or VCHAR to place the characters at the start and end of a string in the first and last two columns, and then use DISPLAY AT for the rest. Messy and hacky, but it works and is faster than HCHAR alone.

 

Have you checked out Space Trek? That's an XB Trek game I converted/adapted from the Color Computer. I also have an assembly version of TI Trek on my website somewhere...

[RXB]

Hmm RXB unlike EVERY OTHER XB has HPUT and VPUT that works the same as HCHAR or VCHAR of rows 24 by 32 columns.

 

CALL HPUT(row,column,number)

CALL HPUT(row,column,numeric variable)

CALL HPUT(row,column,string variable)

CALL HPUT(row,column,quoted string)

 

Also RXB can do something with HCHAR or VCHAR no other XB can do:

 

Normal XB to draw a box:

CALL HCHAR(10,11,44,10) :: CALL VCHAR(10,11,44,10) :: CALL VCHAR(10,21,44,10) :: CALL HCHAR(20,11,44,10)

 

RXB to draw same box:

CALL HCHAR(10,11,44,10,10,11,44,10,10,21,44,10,20,11,44,10) ! Notice RXB does not need all the colons and repeating commands typed in?

 

Additionally RXB has CALL HGET and CALL VGET:

CALL HGET(row,column,number of characters,string variable)

 

CALL HGET(10,11,8,String$)

[etownandy]

I ran into this issue myself a long time ago... I hate the fact DISPLAY AT is limited to 28 columns.... I think the reason why is it was originally just an alias command for PRINT.

 

One way you CAN do it is to write a subprogram to use HCHAR or VCHAR to place the characters at the start and end of a string in the first and last two columns, and then use DISPLAY AT for the rest. Messy and hacky, but it works and is faster than HCHAR alone.

 

Have you checked out Space Trek? That's an XB Trek game I converted/adapted from the Color Computer. I also have an assembly version of TI Trek on my website somewhere...

 

 

What's the URL? If there's already effective a version of what I'm trying to do, it makes it fairly pointless.

[etownandy]

Hmm RXB unlike EVERY OTHER XB has HPUT and VPUT that works the same as HCHAR or VCHAR of rows 24 by 32 columns.

 

CALL HPUT(row,column,number)

CALL HPUT(row,column,numeric variable)

CALL HPUT(row,column,string variable)

CALL HPUT(row,column,quoted string)

 

Also RXB can do something with HCHAR or VCHAR no other XB can do:

 

Normal XB to draw a box:

CALL HCHAR(10,11,44,10) :: CALL VCHAR(10,11,44,10) :: CALL VCHAR(10,21,44,10) :: CALL HCHAR(20,11,44,10)

 

RXB to draw same box:

CALL HCHAR(10,11,44,10,10,11,44,10,10,21,44,10,20,11,44,10) ! Notice RXB does not need all the colons and repeating commands typed in?

 

Additionally RXB has CALL HGET and CALL VGET:

CALL HGET(row,column,number of characters,string variable)

 

CALL HGET(10,11,8,String$)

 

Definitely an idea. RXB was just getting off the ground when I sold my original rig. This might be a good project to get some experience with it.

[Casey]

I played with this the other night in MAME, and I basically came up with the same solution. Use CALL HCHAR to display columns 1,2, 31 and 32, and use DISPLAY AT to display what is in between. The 99/8, with it's CALL MARGINS subprogram would have made this a complete nonissue:

 

10 CALL MARGINS(0,0,0,0)::A$=RPT$("X",32)::DISPLAY AT(3,1):A$

 

One wonders if TI ever had a plan to release Extended BASIC II for the 99/4A because as good as Extended BASIC was, Extended BASIC II corrected a lot of deficiencies.

Edited January 16, 2017 by Casey

[marc.hull]

Editing your diaplay string so that it fits the display at parameters would work.

[+adamantyr]

 

 

What's the URL? If there's already effective a version of what I'm trying to do, it makes it fairly pointless.

Space Trek is up on the TI Game Shelf: http://tigameshelf.net/xb.htm

 

My old version of TI Trek is here: http://www.adamantyr.com/misc/titrek.html

[sometimes99er]

Looks like the Basic and XB versions are in the Gamebase.

 

 

 

 

 

 

 

[RXB]

I played with this the other night in MAME, and I basically came up with the same solution. Use CALL HCHAR to display columns 1,2, 31 and 32, and use DISPLAY AT to display what is in between. The 99/8, with it's CALL MARGINS subprogram would have made this a complete nonissue:

 

10 CALL MARGINS(0,0,0,0)::A$=RPT$("X",32)::DISPLAY AT(3,1):A$

 

One wonders if TI ever had a plan to release Extended BASIC II for the 99/4A because as good as Extended BASIC was, Extended BASIC II corrected a lot of deficiencies.

 

Hey for over 20 years I have been fixing problems in XB and why I created RXB!

This is just a little insulting. Really let us compare the above statements to RXB:

 

10 CALL MARGINS(0,0,0,0) :: A$=RPT("X",32) :: DISPLAY AT(3,1):A$

vs

10 A$=RPT("X",32) :: CALL HPUT(3,1,A$)

 

Which one takes less work and is more to the core of what you wanted?

[Casey]

 

Hey for over 20 years I have been fixing problems in XB and why I created RXB!

This is just a little insulting. Really let us compare the above statements to RXB:

 

10 CALL MARGINS(0,0,0,0) :: A$=RPT("X",32) :: DISPLAY AT(3,1):A$

vs

10 A$=RPT("X",32) :: CALL HPUT(3,1,A$)

 

Which one takes less work and is more to the core of what you wanted?

 

So a few points I'd like to make in response.

 

1) I posed a theoretical question about a decision TI may have been making 35 years ago about a product that ultimately was never released. That you could be insulted from that says a few things to me. My point, which you obviously missed, was that TI already knew this was a problem and had already fixed it. Just they never released the product that contained the fix. That's all.

 

2) I've *never* heard of RXB until this thread, and I've certainly never seen it or used it. Again, that you could be insulted because someone didn't fall down to mention it says a lot to me.

 

No insult was intended by my post and none should have been taken.

[RXB]

 

So a few points I'd like to make in response.

 

1) I posed a theoretical question about a decision TI may have been making 35 years ago about a product that ultimately was never released. That you could be insulted from that says a few things to me. My point, which you obviously missed, was that TI already knew this was a problem and had already fixed it. Just they never released the product that contained the fix. That's all.

 

2) I've *never* heard of RXB until this thread, and I've certainly never seen it or used it. Again, that you could be insulted because someone didn't fall down to mention it says a lot to me.

 

No insult was intended by my post and none should have been taken.

I was kinda joking about the insult.

 

Now as for XB I have the SOURCE CODE FOR XB in RXB and even all the Engineering Notes and Commented GPL Code by TI originally.

In the XB Source Code it shows time constraints and patches that were haphazard at best.

Additionally there are routines in XB GPL that make zero sense at all, with the only explanation is the some of the Assembly people had no clues how GPL worked.

Examples are ROM XML Assembly GREAD and GWRITE ? (GREAD reads GROM and they also had GWRITE in a module GROM was write protected?)

Other Examples are ROM VWRITE and VREAD but GPL has MOVE that will move any type of memory to any type and takes less bytes than the Assembly to do something?

There are other XB ROM routines that could be repaired like these.

I have done my best to repair the GPL section.

[Casey]

Nice, all is good. Some day, when I get up enough interest, I'd like to dabble in GPL. I've only barely touched assembly language on the TI (it is way more intuitive than assembly language on the 6502 seems to be), but I spend all my working day on computers, so it's hard for me to come home and want to do that in the evenings. The amount of work you've obviously put into RXB is amazing and shows how much dedication you have to the TI computer, so for that I applaud you.

[+Ksarul]

I like your 99/8 title screen Avatar, @Casey. Do you have one? Several of us here do (I have two, one of each motherboard type, and there are about ten more of them owned by others here). It was definitely an interesting machine. . .

[+Lee Stewart]

I thought I'd translate TI-Trek from BASIC to XB. Mostly because it's a great game but it runs so darned slow in BASIC. I've got quite a few things cleaned up, but wanted to speed up the display of stat info and the command prompt in the game.

 

This is the loop used to display most "messages":

 

2510 FOR I1=A TO LEN(M$)::CALL HCHAR(RW,(CL+I1-1),ASC(SEG$(M$,I1,1)))::NEXT I1

 

I thought, no sweat, I can use DISPLAY AT to show the entire message instead of building it up and displaying it one character at a time (because that is indeed SLOW):

2510 DISPLAY AT(RW, CL-1):M$

 

When I tested that, I realized something I either hadn't before or completely forgot about...DISPLAY AT doesn't give you all 32 columns of the screen. As a result, I get some really nasty wrap-around effects.

 

Can anyone suggest an alternative that will let me display this text faster than a looped HCHAR in XB while avoiding the wrapping issues? I was hoping for a quick drop-in. I have a feeling I'm not going to get it.

 

Someone (you?) could write an ALC routine to do the job. If you are not an ALC programmer, several folks here could help. I think I might do it myself, just for fun! It should be a very simple routine if it is limited to strings with no scrolling.

 

...lee

[etownandy]

 

Someone (you?) could write an ALC routine to do the job. If you are not an ALC programmer, several folks here could help. I think I might do it myself, just for fun! It should be a very simple routine if it is limited to strings with no scrolling.

 

...lee

 

Well, it would seem to be academic now, although this was literally the LAST problem. In my youth, this was the kind of problem I'd write to Bruce Harrison about, and he'd always come through with a ridiculously easy-to-use ACL solution that my XB brain could wrap itself around neatly.

[Casey]

I like your 99/8 title screen Avatar, @Casey. Do you have one? Several of us here do (I have two, one of each motherboard type, and there are about ten more of them owned by others here). It was definitely an interesting machine. . .

 

I used to have one many many years ago for a while. My very first computer was a beige 99/4A and ever since then I've always had a soft spot for the TI line. I did manage to acquire a 99/8, rather unusual in that the p-system actually worked, but the expansion port on the side for the PEB was completely blank (no contacts), so I could only save or load to cassette. At the time I had it, I had a fairly decent collection of TI equipment (99/4, 99/4A in both black and beige, and the 99/8, along with a lot of the peripherals), and other classic machines as well. I ended up selling the 99/8 a few years later when I was moving so that someone else could enjoy it. I wouldn't mind getting my hands on a 99/2 sometime, but I know those are really hard to come by also. Now I just play around in the emulators when I need a TI fix.

[+Ksarul]

I think I may understand why your side port connector wasn't populated. It seems the 50-pin Centronics-style Armadillo Interface boards for the PEB were a LOT easier to get your hands on than the 50-pin card-edge variant of the same board. I know of exactly ONE person with one of the original flat cable boards, and his board doesn't have the cable components, so it isn't usable. A lot of the later machines (they were the ones with the card-edge connector) were manually modified to install a Centronics connector with a nest of wires to move the pins around properly. The connector on yours was probably left off to allow that modification to be made--but if the owner didn't have an Armadillo Interface, it made no sense to actually do the install. . .

 

And you're right, 99/2 machines are a lot harder to find than the 99/8s. I only know of about half a dozen of them in the wild, and not all of those are working. . .

[+arcadeshopper]

 

So a few points I'd like to make in response.

 

1) I posed a theoretical question about a decision TI may have been making 35 years ago about a product that ultimately was never released. That you could be insulted from that says a few things to me. My point, which you obviously missed, was that TI already knew this was a problem and had already fixed it. Just they never released the product that contained the fix. That's all.

 

2) I've *never* heard of RXB until this thread, and I've certainly never seen it or used it. Again, that you could be insulted because someone didn't fall down to mention it says a lot to me.

 

No insult was intended by my post and none should have been taken.

 

RXB was relased in GROM device form at least 4 times over the years..

and is available now on cartridge: https://www.arcadeshopper.com/wp/?page_id=11#!/RXB-2015E-Rich-Extended-Basic-Editor-Assembler-suite/p/58077052/category=15846004

 

Greg

[Airshack]

Does RXB have a compiler? If not, is one planned?

[RXB]

Does RXB have a compiler? If not, is one planned?

No instead I would love to rewrite XB ROM's to use the SAMS replacing the VDP STACK with a RAM STACK in the SAMS.

And replacing Strings/Variables in VDP 12K to SAMS 64K RAM.

You get a huge speed increase and instead of 24K XB programs we could have 128K XB programs with true 7 dimensional Arrays being used.

(currently the largest array in XB is 4 Dimensions at best)

 

I would estimate at least a doubling speed of XB and possible a 6 times increase in speed and these are conservative estimates.

[Airshack]

128K RAM to program with would certainly be a killer feature.

 

 

Sent from my iPhone using Tapatalk

[+Vorticon]

No instead I would love to rewrite XB ROM's to use the SAMS replacing the VDP STACK with a RAM STACK in the SAMS.

And replacing Strings/Variables in VDP 12K to SAMS 64K RAM.

You get a huge speed increase and instead of 24K XB programs we could have 128K XB programs with true 7 dimensional Arrays being used.

(currently the largest array in XB is 4 Dimensions at best)

 

I would estimate at least a doubling speed of XB and possible a 6 times increase in speed and these are conservative estimates.

 

What are you waiting for??? Man the possibilities this would open...

[RXB]

 

What are you waiting for??? Man the possibilities this would open...

Winfred Winkler apparently decompiled a listing of the XB ROMs and I am hoping someone has a copy of the source code he created?

 

I lost my only copy of the XB ROM source code i got from TI and honestly I am average for Assembly Programming, but I am great at GPL Language.

 

Which is why I asked for help on this. My goal is to dump crap in the XB ROMs like GVWITE (Grom/VDP Write) or CLEAN (Garbage Collection of VDP memory) replace it with RAM versions.

When you see BASIC or XB do that delay for a second it is doing a Garbage collection of memory of VDP, a SAMS RAM version would be 20 times faster with no delays seen by humans.