Jump to content
IGNORED

Extended BASIC G.E.M.


senior_falcon

Recommended Posts

Maybe it's easier with the editor/assembler cartridge?

 

E/A seems to give a different seed every time I start it so every time I start Forth the first random number is always different.

Looks like 83C0 is spinning in the main menu and then locks when you select menu item 2, which is a kind of "random" number.

 

So you could make a start up routine that reads the screen timer and/or the interrupt timer and creates a new seed when the first key is pressed in RXB and load that new timer value into >83C0. Or am I missing something obvious?

 

 

 

Edited by TheBF
typo
Link to comment
Share on other sites

19 minutes ago, RXB said:

Currently no XB does this, but if a BYE is used and goes back to Title Screen and the computer is not turned off I can sample the clock and save it in VDP.

Of course anything like going to REA cart or changing carts than returning to RXB would just give you the same number.

As every other XB cart made does this, RXB does not stand out other then it does have a better faster RND number output then any other XB.

Actually there is one XB cart that can generate a unique random number from a LOAD program: XB G.E.M. Oh yes, and there is another XB that has a better faster RND generator. You guessed it; XB G.E.M.

  • Like 2
Link to comment
Share on other sites

17 minutes ago, TheBF said:

Maybe it's easier with the editor/assembler cartridge?

 

E/A seems to give a different seed every time I start it so every time I start Forth the first random number is always different.

Looks like 83C0 is spinning in the main menu and then locks when you select menu item 2, which is a kind of "random" number.

 

So you could make a start up routine that reads the screen timer and/or the interrupt timer and creates a new seed when the first key is pressed in RXB and load that new timer value into >83C0. Or am I missing something obvious?

 

 

 

Yes in EA cart the menu code has a RND call everytime you push a key.

 

To do this in XB would seriously slow down XB even more.

The EA cart is not doing much like Converting TEXT to Program Code or is it doing anything other than looking for a key. (Just 1 to 5 only at main menu)

 

Assembler, Editor, PRINT, LOADER do nothing till selected, XB has check it all every time you press a key.

Link to comment
Share on other sites

16 minutes ago, senior_falcon said:

Actually there is one XB cart that can generate a unique random number from a LOAD program: XB G.E.M. Oh yes, and there is another XB that has a better faster RND generator. You guessed it; XB G.E.M.

Backwards compatible with TI Basic and XB programs including Assembly programs using CALL LINK?

 

Link to comment
Share on other sites

Though I like a more random, random number generator...
I actually routinely REM my Randomize command so I can have repeatable "randomness"  when testing things!
 
Maybe a SEED value could be supplied to create repeatable result for testing?
Seed is a command in xb

Sent from my LM-G820 using Tapatalk

Link to comment
Share on other sites

What?  I have only been using XB for 38 years.  Why would I know this?:dunce:
RANDOMIZE

Format:

RANDOMIZE [numeric-expression]

Description:

The RANDOMIZE statement resets the random number generator to an unpredictable sequence. If RANDOMIZE is followed by a numeric-expression, the same sequence of random numbers is produced each time the statement is executed with that value for the expression. Different values give different sequences.

Options:


Examples:

The program below illustrates a use of the RANDOMIZE statement. It accepts a value for numeric¬-expression and prints the first 10 values obtained using the RND function.

>100 CALL CLEAR
>110 INPUT "SEED: ":S
>120 RANDOMIZE S
>130 FOR A=1 TO 10::PRINT A;RND::NEXT A::PRINT
>140 GOTO 110


Sent from my LM-G820 using Tapatalk

Link to comment
Share on other sites

1 hour ago, 1980gamer said:

I guess, not putting a value does what I wanted.

That is, RND without using Randomize.

 

This works because XB always starts with the same seed as does TIB (different seed than XB). With Harry’s XB G.E.M, this will not work because it starts up with an unpredictable seed. You would need to use

RANDOMIZE <num>

 

...lee

  • Like 2
Link to comment
Share on other sites

3 minutes ago, GDMike said:

Lee, how can I interrupt the screen timeout counter in assembly. And is there a way to read that counter. I'd like to add it into my program where if the counter (keyboard untouched) = 9 mins I want to have a subprogram run AND I don't want the screen to blank.

 

I am not sure what you mean by “interrupt the screen timeout counter”. You read the counter by reading address >83D6. However, if all you want to do is prevent the screen from blanking, just jam an odd number there (>83D6). The counter increments by 2 and the console ISR blanks the screen when it rolls over to 0. That can never happen if the number is odd. Of course, it is reset at every keystroke, so you would need to set it odd every time keystrokes are done.

 

...lee

Link to comment
Share on other sites

36 minutes ago, Lee Stewart said:

 

This works because XB always starts with the same seed as does TIB (different seed than XB). With Harry’s XB G.E.M, this will not work because it starts up with an unpredictable seed. You would need to use


RANDOMIZE <num>

 

...lee

Right now XB G.E.M. does not work as expected with RANDOMIZE S. As a stopgap, you can use CALL LOAD(-31808,N1,N2) which does the same thing. I will have to see why this does not work as it should.

(EDIT) It turns out that RXB has this same problem. 

Edited by senior_falcon
  • Like 1
Link to comment
Share on other sites

3 minutes ago, senior_falcon said:

Right now XB G.E.M. does not work as expected with RANDOMIZE S. As a stopgap, you can use CALL LOAD(-31808,N1,N2) which does the same thing. I will have to see why this does not work as it should.

 

I do not think XB uses the console ISR’s seed location (>83C0) for seeding RND. I intend to look for where XB stores its seed, but I do not yet have all of my software transferred from my Win7Pro disk to my Win10 disk. (I was obviously cutting it close with Win7 losing support in less than 2 weeks!)

 

...lee

Link to comment
Share on other sites

9 hours ago, Lee Stewart said:

 

I do not think XB uses the console ISR’s seed location (>83C0) for seeding RND. I intend to look for where XB stores its seed, but I do not yet have all of my software transferred from my Win7Pro disk to my Win10 disk. (I was obviously cutting it close with Win7 losing support in less than 2 weeks!)

 

...lee

I believe that is correct. There are 2 random number seeds in VDP ram. So it appears that XB versions using the TI BASIC random number generator should borrow the RANDOMIZE routine from BASIC as well.

Edited by senior_falcon
  • Like 1
Link to comment
Share on other sites

Does anyone have any insight in how to accomplish what Wolfgang wants to do?
Specifically take XBGEM_G.BIN and XBGEM_8.BIN and load them into the final grom.
It looks like BINs for the final grom are all in one file.
Likely we have to break it up in v9t9 format like the original xb cart with c and d files for the ROM

Sent from my LM-G820 using Tapatalk

Link to comment
Share on other sites

8 minutes ago, senior_falcon said:

I believe that is correct. There are 2 random number seeds in VDP ram. So it appears that XB versions using the TI BASIC random number generator should borrow the RANDOMIZE routine from BASIC as well.

 

Agreed.  Using XB’s “RANDOMIZE <num>” will not start with <num> as the new seed as one would expect, so it will not start a predictable sequence for testing. It certainly does change >83C0, but not to <num>.

 

...lee

Link to comment
Share on other sites

Suppose you had 8 banks of rom. Surely you wouldn't have c,d,e,f,g,h,i,j files?

Good question. I don't know perhaps ralf can enlighten us

 

Or rtfm

A mixed ROM and GROM image is always split into up to 3 files, ending with C and D for the ROM files and G for the GROM file:

 

helloc.bin hellod.bin (optional) hellog.bin

 

For mixed images, the ROM file must always end in C, but an optional second ROM bank ending in D may be present. The GROM G file may be up to 40 KB in size, whereas the ROM C file may be up to 960 KB in size. If a D file is given, it must be exactly 8 KB in size.

 

 

 

Sent from my LM-G820 using Tapatalk

 

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...