XB - HCHAR vs DISPLAY AT

[Omega-TI]

This is interesting! I hope it works out. I have a spare UberGROM cart, 1284P and 49F040 ready and waiting!

[senior_falcon]

Don't mean to get your hopes up as far as this being a finished product. It is only a "proof of concept" demonstration that will show how to allocate VDP ram so there is a place to put the 80 column screen and a way to automatically toggle between the 80 column mode when running and the normal 32 column mode when a program breaks.

[matthew180]

Hmm, this thread is way off topic at this point. Some F18A comments as I read through the thread:

 

* The F18A is not a 9938 or 9958, it was never intended to be.

 

* The F18A does not have "commands" like the 9938 because it does not implement the drawing commands found in the 9938/58. Instead the F18A gives you a 100MHz 9900 CPU inside the VDP so you can implement any kind of graphics drawing routines that you want. The GPU can access all VRAM and VDP registers directly, and offers some custom instructions for high-speed pixel plotting. There is also a DMA for very fast memory block moves, a high-resolution timer, and horizontal interrupt detection.

 

* The F18A has the original 16K of VRAM (because that's all the 9918A had) plus an additional 2K of memory that is accessible only by the on-board 9900-GPU. The extra 2K *cannot* be used for things like patterns, sprite tables, etc.

 

* The F18A could offer some enhancements for XB that do not require changes to the VRAM use, i.e. pixel scrolling via the scroll registers, palette access (the F18A support 12-bit color), sprites available in text modes, screen scrolling routings in the GPU that could help support smooth pixel scrolling, etc.

 

* If anyone wants to mess with the XB VRAM layout then there are a lot of extras that could be offered, i.e. the second tile layer, enhanced colors, tile over sprite priority, tile attributes, enhanced color for text modes, sprite attributes, per-sprite sizes, etc. Personally I don't use (or like) XB much, but if anyone wants to work out the details of mixing in with XB, I'd be happy to help with the F18A side of things in terms of support, code examples, GPU routines, etc.

 

As for the original thread topic:

 

It sucks that DISPLAY AT is limited to 28 characters. I think that limitation is because TVs had this tendency to cut off some of the first and last tile columns (still, it was a dumb design decision to limit DISPLAY AT... leave that to the programmer to decide). For a while I was even running my 99/4A on a modern-ish TV (mid 2000's) and even that TV cut off the 1st and 32nd columns! That is probably one of the events that triggered me to make the F18A.

 

It is great that Lee provided the next best thing, i.e. an assembly routine to solve the problem. It always amazes me how much code it takes to deal with parameters coming from XB.

[RXB]

Let us be honest about XB, there is no way to fit XB into Assembly on a standard TI and still have 24K of XB program space.

GPL being slower then Assembly has the one single advantage of being extremely compact as a language and very versatile considering everything it can do that makes the TI so special to us.

 

And if you look at the notes in RXB GPL Source code (XB original Texas Instruments GPL source code) you will see references to the borders being required by exactly what Matthew above implied.

 

But consider that XB does not use any memory but 256 bytes of Scratch pad to do what it does, the same can not be said for Assembly unless you use the OS.

I dare someone to write something as versatile and effective as the GPL TI interface and OS in ROM 0 of only 8K, go for it.

[+Lee Stewart]

Let us be honest about XB, there is no way to fit XB into Assembly on a standard TI and still have 24K of XB program space.

GPL being slower then Assembly has the one single advantage of being extremely compact as a language and very versatile considering everything it can do that makes the TI so special to us.

 

And if you look at the notes in RXB GPL Source code (XB original Texas Instruments GPL source code) you will see references to the borders being required by exactly what Matthew above implied.

 

But consider that XB does not use any memory but 256 bytes of Scratch pad to do what it does, the same can not be said for Assembly unless you use the OS.

I dare someone to write something as versatile and effective as the GPL TI interface and OS in ROM 0 of only 8K, go for it.

 

Well...XB actually takes up 16KiB ROM and 24KiB GROM in cartridge space. It also uses console ROM (OS & GPL interpreter) and GROM (tables, ...) That is a touch more than 256 bytes. And, of course, any effort to convert XB to ALC would use ROM to do it—plenty of room there, I would think.

 

...lee

[RXB]

 

Well...XB actually takes up 16KiB ROM and 24KiB GROM in cartridge space. It also uses console ROM (OS & GPL interpreter) and GROM (tables, ...) That is a touch more than 256 bytes. And, of course, any effort to convert XB to ALC would use ROM to do it—plenty of room there, I would think.

 

...lee

I think XB3 came the closest but then it never was that popular as is had all kinds of compatibility issues with normal XB programs.

Programs would not run the same or crash and error reports were not the same as normal XB.

 

You could possibly do it in Forth, but then Forth and XB have many many issues to be compatible especially in File access and program storage formats.

 

As for what I said that GPL runs from 256 bytes of Scratch pad I am 100% correct it never uses another RAM space for GPL or the ROMs.

Not a single byte is used out side of this space to make XB work. (other then a few pointers in VDP for Stack and OS pointers.)

Upper 24K is totally XB Program and Number Line table with Numeric Variables.

Lower 8K is used for Assembly only.

 

Also true normal XB uses 24K of GROM but RXB uses almost 40K in GROM space.

And show me another XB that will run TI Basic programs or normal XB programs with so few issues. (only 4 in found in 20 years.)

Edited January 31, 2017 by RXB

[AuTomato]

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$)

 

This is good to know, I'm currently stuck with standard basic until I get my RAM expansion and you can only be so clever with the built-in display functions. I wrote a lot of stuff in Basic 20 some years ago and I'd sure forgotten about this limitation x.x

[RXB]

 

This is good to know, I'm currently stuck with standard basic until I get my RAM expansion and you can only be so clever with the built-in display functions. I wrote a lot of stuff in Basic 20 some years ago and I'd sure forgotten about this limitation x.x

Huhh RXB works with just a Console and no 32K too.

So you could use RXB CALL HPUT or CALL VPUT or CALL HGET or CALL VGET with no 32K needed just the RXB Cart.

 

Not to mention my CALL MOVES that can move any amount of any type of memory to anywhere even into strings or out of strings. i.e. VDP, RAM, ROM, GRAM, GROM

Also CALL IO to access direct CRU access and control.

(All from Console with just RXB!)

[AuTomato]

Huhh RXB works with just a Console and no 32K too.

So you could use RXB CALL HPUT or CALL VPUT or CALL HGET or CALL VGET with no 32K needed just the RXB Cart.

 

Not to mention my CALL MOVES that can move any amount of any type of memory to anywhere even into strings or out of strings. i.e. VDP, RAM, ROM, GRAM, GROM

Also CALL IO to access direct CRU access and control.

(All from Console with just RXB!)

 

Oh that's fantastic! I didn't realize that RXB would work without the 32K expansion. As of Friday I've just gotten back into the TI-99 after 20-ish years of absence so there's a lot to get caught up on.

[AuTomato]

Huhh RXB works with just a Console and no 32K too.

So you could use RXB CALL HPUT or CALL VPUT or CALL HGET or CALL VGET with no 32K needed just the RXB Cart.

 

Not to mention my CALL MOVES that can move any amount of any type of memory to anywhere even into strings or out of strings. i.e. VDP, RAM, ROM, GRAM, GROM

Also CALL IO to access direct CRU access and control.

(All from Console with just RXB!)

So I snagged the images from here:

http://atariage.com/forums/topic/163627-rxb-rich-extended-basic/page-24?do=findComment&comment=3629390

 

Followed the instructions for writing to both the code and data for the 1284P, wrote the flash chip (following the instructions that Gazoo wrote for the MiniPro) verified the contents of the chips and they looked good, loaded the cart into the console and nothing shows up in the menu. Thoughts?

[AuTomato]

Well I managed to get RXB loaded to my Uber cart! I ended up finding another post which included a project file for the 1284P and that seemed to be the required magic. I checked and double-checked my settings based on Gazoo's walkthrough to no avail, but I rewrote the chip with the project file and it worked perfectly!

 

Time for some fun!

[+Ksarul]

I build mine using Gazoo's walk-through process (I've done over 100 cartridges that way now), so it may be some minor step that you are missing. If you do identify the step that needs a tweak, please let us know, as I can then add that data to the procedure and help others when they want to build cartridges. . .