Writing an Extended BASIC game too big for memory

[apersson850]

11 hours ago, RXB said:

These ROMs use GPL Registers that are in the 16bit Scratch Pad and uses scratch pad to operate variables, but then the ROM is where the program is so about as fast as ROM can get.

Unless you have some magical way to gain 16bit RAM and run programs?

Yes, that's obvious, if you have a ROM cartridge in an unexpanded console. What I was trying to understand was if you really mean ROM, not RAM acting like ROM when the program is running? I mean, ROM is what it is, and is made in large quantities to make sense. What product would you consider in such a solution? You've put in an enormous effort into RXB, but apart from your own satisfaction it seems nobody uses it. What would you put in ROM that's of general interest? That's why I tried to ask if you're really talking about RAM, so you can change the content of such a cartridge on the fly. Or it seems it would be too constricted.

 

No, there's no magic 16-bit memory access. That was a response to a statement in another post than your's.

[SteveB]

59 minutes ago, apersson850 said:

but apart from your own satisfaction it seems nobody uses it

The downloads of each release suggests differently. Even though I develop to compile, I use RXB for being faster when interpreted while testing and debugging.

 

Rich was so kind to tell me how to patch the background color to light blue like in XB 1.1, so I feel more "at home" when in command mode.

[tmop69]

1 hour ago, SteveB said:

The downloads of each release suggests differently. Even though I develop to compile, I use RXB for being faster when interpreted while testing and debugging.

 

In general, downloads do not automagically mean user engagement, especially with free software. Specifically, as you mentioned, it can be used as a tool to speed up the test phase before compiling, in addition to CPU throttling features of the various emulators.

 

 

Edited May 4, 2022 by tmop69

[Stuart]

15 hours ago, senior_falcon said:

This can add lines to a running program? I find that very hard to believe.

This is actually something that Cortex BASIC supports - it has an ENTER statement that enables a running program to enter (or modify or delete) new program lines within itself. An example in the manual prompts for entry of a function (Y=SIN(X) sort of thing) then adds a program line defining that function which can then be called. It includes a note that self-modifying programs can be a little tricky to debug ...

[apersson850]

I based my feeling of the actual use of RXB from the actual comments (or rather lack of such) about how to use a certain feature in RXB.

 

Yes, self modifying code isn't the easiest to understand.

UCSD Pascal instead uses the concept of overlays, but they are automagic. You just define a procedure as a segment procedure, and then the operating system will make sure it's loaded in memory when it's needed. A separately compiled unit is always a segment by itself. Segments are valuable if you for example have a setup routine, that runs at startup only. Then it will not occupy memory once it's completed. Or if you have a program that has clearly defined states, like data entry, data processing, data reporting, data printout or whatever. You can have the main program memory resident, and load the other segments as needed. Doable in several languages, sure, but with the p-system, you don't bother, as the system does it by itself.

[senior_falcon]

Here is an example showing XB 2.9 G.E.M. running a program (PART1) which then loads and runs another program (PART2) using CALL RUNL1.

PART2 does not contain R,C, and A$, yet somehow they are there. Those values have been retained from PART1.

 

With this technique, the only limit to program size is the capacity of the disk drive. Of course, it will never be used, for two reasons:

1 - The programs must be written in XB, so they are slow

2 - They must run from disk, and these days everyone wants programs in cartridge format

1 !XXX*********
5 !PART 1
6 GOTO 8 :: J,K,S,CALL KEY
8 CALL CLEAR
10 FOR I=1 TO 14 :: PRINT I;I*I;SQR(I):: NEXT I
20 R=1 :: C=14 :: A$="Hello World!"
40 CALL RUNL1("DSK1.PART2")

1 !*******
90 !PART 2
100 FOR J=1 TO 8 :: DISPLAY AT(R+J,C-J):A$ :: NEXT J
110 CALL KEY(0,K,S):: IF S<1 THEN 110
120 PRINT R;C;A$

Edited May 4, 2022 by senior_falcon

[SkyPilot]

48 minutes ago, senior_falcon said:

1 - The programs must be written in XB, so they are slow

2 - They must run from disk, and these days everyone wants programs in cartridge format

 

Yes, cartridge programs seem the preferred method for fast loading.  Totally self contained is a worthy goal, but not law, there are cartridge programs that require 32K.  Couldn't a limited amount of variables be passed off to the 32K for holding, then reloaded with the next assembly language block?  It would be so fast, hardly anyone would notice.

[Asmusr]

1 hour ago, SkyPilot said:

Yes, cartridge programs seem the preferred method for fast loading.  Totally self contained is a worthy goal, but not law, there are cartridge programs that require 32K.  Couldn't a limited amount of variables be passed off to the 32K for holding, then reloaded with the next assembly language block?  It would be so fast, hardly anyone would notice.

See post #7/#10.

[RXB]

7 hours ago, apersson850 said:

Yes, that's obvious, if you have a ROM cartridge in an unexpanded console. What I was trying to understand was if you really mean ROM, not RAM acting like ROM when the program is running? I mean, ROM is what it is, and is made in large quantities to make sense. What product would you consider in such a solution? You've put in an enormous effort into RXB, but apart from your own satisfaction it seems nobody uses it. What would you put in ROM that's of general interest? That's why I tried to ask if you're really talking about RAM, so you can change the content of such a cartridge on the fly. Or it seems it would be too constricted.

 

No, there's no magic 16-bit memory access. That was a response to a statement in another post than your's.

Nobody? Now that would be a lie! And no you can not change any XB on the fly even RXB can edit itself but you have to go to edit mode with CALL USER to do that.

And another lie is I never said it was 16-bit-memory access I said it used Scratch pad Register and Scratch pad for variables for new routines like CALL HCHAR and I am not using CALL LINKS or having to COMPILE it first!

[senior_falcon]

5 hours ago, tmop69 said:

In general, downloads do not automagically mean user engagement, especially with free software. Specifically, as you mentioned, it can be used as a tool to speed up the test phase before compiling, in addition to CPU throttling features of the various emulators.

 

 

This is so true. I think people just like to hoard programs. When I was developing G.E.M. I posted this:

"The two fonts above were missing all the lower case characters and the picture above shows how they were completed. If someone feels like changing these fonts so the lower case letters were more like the upper case ones, I would include their revisions in the new cartridge." and then posted the fonts for people to download and hopefully change.

What I posted was only useful to someone wanting to try modifying the font. This was downloaded 28 times! But not one response to my question. 

[RXB]

3 hours ago, apersson850 said:

I based my feeling of the actual use of RXB from the actual comments (or rather lack of such) about how to use a certain feature in RXB.

 

Yes, self modifying code isn't the easiest to understand.

UCSD Pascal instead uses the concept of overlays, but they are automagic. You just define a procedure as a segment procedure, and then the operating system will make sure it's loaded in memory when it's needed. A separately compiled unit is always a segment by itself. Segments are valuable if you for example have a setup routine, that runs at startup only. Then it will not occupy memory once it's completed. Or if you have a program that has clearly defined states, like data entry, data processing, data reporting, data printout or whatever. You can have the main program memory resident, and load the other segments as needed. Doable in several languages, sure, but with the p-system, you don't bother, as the system does it by itself.

CALL USER is a DV80 file that does anything a user can do typing into the command/edit mode of XB.

There is no size limit so you could make a 20Meg single DV80 file and CALL USER would run it.

Look you would chain it in a single DV80 file and it would run program go back to CALL USER load more new lines or entirely new program and run it just like RUN does.

The idea is a single file with no size limit and no chain.

[GDMike]

1 minute ago, senior_falcon said:

This is so true. I think people just like to hoard programs. When I was developing G.E.M. I posted this:

"The two fonts above were missing all the lower case characters and the picture above shows how they were completed. If someone feels like changing these fonts so the lower case letters were more like the upper case ones, I would include their revisions in the new cartridge." and then posted the fonts for people to download and hopefully change.

What I posted was only useful to someone wanting to try modifying the font. This was downloaded 28 times! But not one response to my question. 

I know nothing... about 27 downloads

[senior_falcon]

10 minutes ago, RXB said:

And another lie is I never said it was 16-bit-memory access I said it used Scratch pad Register and Scratch pad for variables for new routines like CALL HCHAR and I am not using CALL LINKS or having to COMPILE it first!

There you go again, calling people liars. I checked. Nobody quoted you as saying it was 16 bit memory access. 

[apersson850]

1 hour ago, RXB said:

Nobody? Now that would be a lie! And another lie...

Oh shut up. I don't need any stupid comments like that.

 

Again, I've seen very little discussion here about how to use features in RXB. Perhaps they are in the very large thread, where you write a lot yourself, about RXB. Difficult to overview. It's of course very nice if some people benefit from your efforts.

You asked if i knew about some magic to get 16-bit RAM available, to which I said no. The only way I know is to do as I did, install it in the console. If you've never seen a console running assembly programs seemingly without any memory expansion, it may look like magic, but of course it's not.

 

I'm still interested in hearing about what that ROM you talk about really is, and what you plan to put into it, if you have any such plan?

Edited May 4, 2022 by apersson850