RXB - Rich Extended Basic

[RXB]

Hello so CALL MOD(number,divisor,quotiant,remainder) is done.

Say number=10 and divisor=3 then quotiant=3 and remainder=1

This should be useful for some XB programs as that remainder is the hard one to calculate.

 

Also new routine is CALL EXE(address) that works like RXB 2001 command CALL EXECUTE(address) but works differently.

CALL EXE(address) does a Assembly BL @address so will end with a RT (return) in Assembly.

Demo is CALL EXECUTE(31450) calls the XB ROM routine in bank one assembly SCROLL routine.

 

  3455            * R12  total number of bytes to move  
  3456            * R10  move from  
  3457            * R9   move to  
  3458            * R8   minor counter (buffer counter)   
  3459            * R7   buffer pointer   
  3460                
  3461 7ADA 020C  SCROLL LI   R12,736           Going to move 736 bytes   

 

This works with NO MEMORY EXPANSION to use Assembly from XB.

I will make a video showing this working from console alone with only FinalGROM cart and a Console running Assembly routines.

Like another is CALL EXE(29656) is BL @COMPCT which does a VDP garbage collection of VDP RAM again from CONSOLE only.

************************************************************
  2633            * COMPCT - Is the string garbage collection routine. It can  *
  2634            *          be invoked by GETSTR or MEMCHK. It copies all      *
  2636            *          suppressing out all of the unused strings                 *
  2638            *    OUTPUT: UPDATED @STRSP AND @STREND                  *
  2639            *    USES  : R0-R6 AS TEMPORARIES                                  *
  2640            *************************************************
  2641 73D8 C1CB  COMPCT MOV  R11,R7            Save rtn address  

 

Personally, I think this is a dream come true for Console only people. 

 

Do you think I am wrong?

[RXB]

RXB 2021 DEMO 6

Shows CALL MOD and CALL EXE

 

RXB2021 demo 6 - YouTube

[+dhe]

You got 10 days left!

[RXB]

HERE IT IS RXB 2021 RELEASED:

 

 

RXB 2021.zip

[+TheBF]

1 hour ago, RXB said:

HERE IT IS RXB 2021 RELEASED:

 

 

RXB 2021.zip 23.57 MB · 4 downloads

Congratulations on beating the deadline Rich.

[+dhe]

This didn't work for me in Classic99.ini

  What am I missing?

     It loads, but RXB doesn't run, I get a nice light show though.....

 

[usercart24]
;  
name="RXB 2021"
rom0=G|6000|A000|MODS\rxb2021g.BIN
rom1=C|6000|2000|MODS\rxb2021c.BIN

 

 

[+Lee Stewart]

14 hours ago, dhe said:

This didn't work for me in Classic99.ini

  What am I missing?

     It loads, but RXB doesn't run, I get a nice light show though.....

 

[usercart24]
;  
name="RXB 2021"
rom0=G|6000|A000|MODS\rxb2021g.BIN
rom1=C|6000|2000|MODS\rxb2021c.BIN

 

You might try

rom1=C|6000|6000|MODS\rxb2021c.BIN   <<---WRONG...See below

RXB2021C.BIN is 24 KiB (3 ROM banks), not 8 KiB.      <<<Rich will get in on this if I am wrong. 

 

[EDIT: The above “rom1” entry should probably definitely be the following.]

rom1=8|0000|6000|MODS\rxb2021c.BIN

...lee

Edited December 23, 2021 by Lee Stewart
CORRECTION

[HOME AUTOMATION]

I just use drag-n-drop...

 

[+Schmitzi]

6 hours ago, dhe said:

This didn't work for me in Classic99.ini

  What am I missing?

     It loads, but RXB doesn't run, I get a nice light show though.....

 

[usercart24]
;  
name="RXB 2021"
rom0=G|6000|A000|MODS\rxb2021g.BIN
rom1=C|6000|2000|MODS\rxb2021c.BIN

 

 

 

same same here, light show only after selecting RXB on the title screen

 

name=RXB-2021
rom0=G|6000|A000|.\MODS\_RMS\RXB\RXB2021G.BIN
rom1=C|6000|6000|.\MODS\_RMS\RXB\RXB2021C.BIN

(I have also tried the 6000/2000er mentioned by Lee)

 

 

My older version looks different, but this still works:

Maybe this 3rd file is missing ?

 

name=RXB-2020-D
rom0=G|6000|A000|.\MODS\_RMS\RXB\RXBG.BIN
rom1=C|6000|2000|.\MODS\_RMS\RXB\RXBC.BIN
rom2=X|6000|2000|.\MODS\_RMS\RXB\RXBD.BIN

 

 

PS @HOME AUTOMATION Interesting. Where/how can I "drop" files onto Classic99 ?

 

[RXB]

In Classic99:

CARTRiDGE

USER

OPEN

folder with RXB2021C.bin 

it will load RXB2021G.bin for you.

 

That's it.

 

Using FinalGROM just put it into the HOMEBREW folder.

Edited December 23, 2021 by RXB

[+dhe]

@RXB did this, light show only for me and my configuration. But I did learn a new way of doing things. Thanks.

[+dhe]

neither Drop and drag, nor modifying the ini worked... I'm sure it will get sorted.

[senior_falcon]

3 hours ago, RXB said:

In Classic99:

CARTRiDGE

USER

OPEN

folder with RXB2021C.bin 

it will load RXB2021G.bin for you.

 

That's it.

 

Using FinalGROM just put it into the HOMEBREW folder.

Rename the files to:

RXB2021G.bin to RXB2021_G.bin

RXB2021C.bin to RXB2020_8.bin

and it should work with Classic99

[senior_falcon]

On 12/17/2021 at 4:20 PM, RXB said:

Also new routine is CALL EXE(address) that works like RXB 2001 command CALL EXECUTE(address) but works differently.

CALL EXE(address) does a Assembly BL @address so will end with a RT (return) in Assembly.

Demo is CALL EXECUTE(31450) calls the XB ROM routine in bank one assembly SCROLL routine.

CALL EXE(31450) works as advertised.

CALL EXECUTE(31450) hangs.

[atrax27407]

Has anyone been successful in converting RXB2021 to HSGPL format? If so, please post the files. Thanks.

[+Lee Stewart]

Per corrections to my earlier post, the “rom1” entry should use ‘8’ for the cartridge type and ‘0000’ for the cartridge address offset (ROM start is presumed to be >6000). The BIN file size is 24 KiB, so the third number should be ‘6000’ (hex for 24 KiB):

rom1=8|0000|6000|MODS\rxb2021c.bin

As long as you specify the cartridge type properly, you do not need to rename the BIN file.

 

...lee

[HOME AUTOMATION]

8 hours ago, Schmitzi said:

PS @HOME AUTOMATION Interesting. Where/how can I "drop" files onto Classic99 ?

I just dropped the file ending in G, onto the main window. Though, I suppose the C file needs to be in the same folder.

[+mizapf]

May I add this here for the MAME users. I recommend to mount the samsmem expansion, e.g. like this

 

./mame ti99_4a -window -ioport peb -ioport:peb:slot2 samsmem -ioport:peb:slot3 speech -ioport:peb:slot8 ddcc1 ...  

 

On first glance, seems to work correctly.
 

rxb2021.rpk

[RXB]

5 hours ago, senior_falcon said:

CALL EXE(31450) works as advertised.

CALL EXECUTE(31450) hangs.

CALL EXECTUTE is a BLWP @address while CALL EXE(address) is a BL @address 

So yea you have to have a address space for registers or it will crash.

[RXB]

4 hours ago, atrax27407 said:

Has anyone been successful in converting RXB2021 to HSGPL format? If so, please post the files. Thanks.

The only difference between RXB 2020 and 2021 is an extra 8K ROM page.

So if you can figure out how to switch that page like Classic99 or FinalGROM I am at a loss on how to do it?

[RXB]

RXB 2021 DEMO 7

 

https://youtu.be/Fh8hKyNHiVw

[Tursi]

On 12/22/2021 at 7:02 PM, dhe said:

This didn't work for me in Classic99.ini

  What am I missing?

     It loads, but RXB doesn't run, I get a nice light show though.....

Use the Debug Log, Luke...

 

It would have told you it was only going to load 8k of the ROM, because 24k doesn't fit in that slot.

14 hours ago, senior_falcon said:

Rename the files to:

RXB2021G.bin to RXB2021_G.bin

RXB2021C.bin to RXB2020_8.bin

and it should work with Classic99

The underscore is not necessary, only the last character before the separator is checked. However, the '8' absolutely is. So the underscores help with readability to us humans.

 

"C" is a standard, non-paged, 8k ROM. That's why that mechanism with XB needs "C" and "D" - D is the second page. That's the old V9T9 mechanism. These days, even XB can be a 16k '8' type.

 

"8" is a paged ROM file using the 74LS378 mapper, so "non-inverted". Any ROM file more than 8k needs to be either type '8' or '9' (inverted), or only the first 8k will load.

 

Remember, the INI is definitive, and for auto-detect, the metadata rules. The emulator assumes you mean whatever you write in there - even if it doesn't match reality. The loader will emit warnings in the debug log if reality doesn't match, but will still do what you ask (assuming it's possible!) It's not possible to load 24k of data into the 8k memory space of the cartridge port, so it will warn you and truncate the data. But if you enable paged memory, then you have megs and megs of space.

 

Auto-detect is also supported in the INI files, so if you don't care to work it out, and drag-and-drop works (test with this method FIRST), use a type of "*" and it will ignore the address/size parameters, and just use the filename metadata. It won't search, though, so you still need to list all the files:

[usercart24]
; Note the 'c' renamed to '8' for correct detection 
name="RXB 2021"
rom0=*|0000|0000|MODS\rxb2021_g.BIN
rom1=*|0000|0000|MODS\rxb2021_8.BIN

It's worth noting too, that there's no way to build 24k of ROM memory at the cartridge port - it needs to be a power of two. So you might as well pad up to 32k at your leisure.  The hardware will take the 24k loaded and build a 32k memory space anyway.

 

[+OLD CS1]

43 minutes ago, Tursi said:

Use the Debug Log, Luke...

 

[RXB]

So I was thinking the real problem with Sprites is CALL COINC(ALL,numeric-variable) is 0 if no sprites collide or -1 if any sprite collides.

Thus -1 is almost USELSS as if you have 28 sprites on screen which one hit which one?

As PIXELPENDENT pointed out in a recent YOUTUBE video.

This got me thinking we need a XB routine that tells you WHICH SPRITE HIT WHICH SPRITE!

Therefore CALL COLLIDE(ALL,numeric-variable,numeric-variable) will return lowest sprite number and other sprite number that collided.

This would in most cases replace COINC as it is way more useful as both numeric variables would be zero if no hit.

 

Now the XB routine CALL COINC(#sprite-number,#sprite-number,tolerance,numeric-variable) is better but what if more than 1 hit happens?

Well how about CALL COLLIDE(ALL,numeric-variable,numeric-variable,numberic-variable) would first return the number of sprite hits,

then it would return the first sprite then finally second sprite it hit?

 

As all this is done in assembly for detection, I might need a tolerance also.

 

I AM WELCOMING SOME DISCUSSION ON THIS ROUTINE PLEASE JOIN IN....?

Edited December 27, 2021 by RXB
Spelling

[+Lee Stewart]

2 hours ago, RXB said:

So I was thinking the real problem with Sprites is CALL COINC(ALL,numeric-variable) is 0 if no sprites collide or -1 if any sprite collides. Thus -1 is almost USELSS as if you have 28 sprites on screen which one hit which one? As PIXELPENDENT pointed out in a recent YOUTUBE video. This got me thinking we need a XB routine that tells you WHICH SPRITE HIT WHICH SPRITE! Therefore CALL COLLIDE(ALL,numeric-variable,numeric-variable) will return lowest sprite number and other sprite number that collided. This would in most cases replace COINC as it is way more useful as both numeric variables would be zero if no hit.

 

Now the XB routine CALL COINC(#sprite-number,#sprite-number,tolerance,numeric-variable) is better but what if more than 1 hit happens? Well how about CALL COLLIDE(ALL,numeric-variable,numeric-variable,numeric-variable) would first return the number of sprite hits, then it would return the first sprite then finally second sprite it hit? As all this is done in assembly for detection, I might need a tolerance also.

 

I AM WELCOMING SOME DISCUSSION ON THIS ROUTINE PLEASE JOIN IN....?

 

Well—The thing about CALL COINC(ALL,numeric-variable) is that it relies on the VDP handling whether any two sprites have collided and only needs to read the VDP status register to find out. Any other hits involve reading the Sprite Attribute Table in VRAM for each sprite of interest and, then, making calculations, all of which take a lot more time. One use of checking the coincidence flag is to avoid checking for which sprites collided when the coincidence flag says none did. Of course, one problem with this is that a TRUE coincidence flag means two or more sprites overlap, but you do not know by how much until you check and, if your tolerance is large enough that a hit can happen without actual overlap, the hit could be missed. I suppose a programmer would be unlikely to compose such a scenario, so checking the flag first can still be the best procedure.

 

I am thinking, too, that a programmer is not interested so much in how many sprites have collided, but, rather, whether a particular pair have collided or a particular sprite has collided with a spot (wall?) on the screen.

 

Regarding CALL COLLIDE(ALL,numeric-variable,numeric-variable), it would probably be useful to read the entire Sprite Attribute Table (128 bytes) and deal with the sprite positions from that RAM table. I would think it best to check for the number of active sprites by looking for the lowest numbered sprite with y = >D0. This way, you would not be checking 28 sprites for coincidence when only 5 are in play.

 

I’ll stop rambling for now.

 

...lee