Is it technically possible?

[Omega-TI]

With the large memory space in the UberGROM or the FinalGROM is it theoretically possible to combine a version of Extended BASIC and Force Command into paged interactive environment?

 

Example:  Say I'm in XB and want to load the DOS, could a routine, for example CONTROL-D be inserted into XB to automatically call the DOS when activated?  Then later a CONTROL-B take you back to BASIC where you left?

[+arcadeshopper]

With the large memory space in the UberGROM or the FinalGROM is it theoretically possible to combine a version of Extended BASIC and Force Command into paged interactive environment?
 
Example:  Say I'm in XB and want to load the DOS, could a routine, for example CONTROL-D be inserted into XB to automatically call the DOS when activated?  Then later a CONTROL-B take you back to BASIC where you left?

If it wasn't designed for fg99

Sent from my LM-G820 using Tapatalk

[Tursi]

Should work on either, shouldn't it...? Theoretically, if it's just pure software...

 

It seems like it's feasible. An interrupt hook could watch the keyboard. The trick is both pieces of software think they own the machine, so you'd need somewhere to backup RAM. The good news is you know where in execution you are (interrupt hook) and you know the graphics state of the system (either XB or Force Command), so it should be possible to resume.

 

I'm speaking thinking from the XB side, anyway. I don't know Force Command too well - whether it allows the interrupt hook to run and whether it does so from a fixed location (to make resume easier).

 

It's not trivial, at any rate, but I think what you do is:

 

- verify that the interrupt can be safely hooked in both apps (it can in XB, as long as assembly that takes it over isn't loaded)

- identify a safe memory location for the hook routine - it'd be easier if it was safe on both sides

- track which state you're in. I suspect it'd be easiest to load it from an XB LOAD program, so you can assume starting point is always XB.

- when the hot key is detected, back up system memory, VDP RAM and scratchpad, change out the GROM/ROM banks, and do a dedicated resume of the other application. For the first time to FC, that might mean initial startup, which may be a little different. Same thing for going back. Note that's a little over 48k RAM needed to backup one state.

- I'd probably want dedicated backup memory for each application, just to keep it simple. Otherwise you COULD backup existing memory and restore old memory at the same time, just swap one word at a time

 

(edit: one tricky part - VDP and GROM addresses. You can read out the GROM address on swap and restore it on restore, so that isn't too bad. VDP address is write-only though. For XB you should be okay - when the user interrupt hook fires the VDP address was already corrupted so doesn't need a fixed state, but you'd need to verify that's also true of FC. Also.. VDP registers are read-only, which means that you need to assume what each application needs to be set. For instance, if you assumed the XB immediate mode screen but pressed the hotkey inside a running program, you wouldn't know what screen color to restore  - minor thing though.)

 

The hard part is if either app gets fussy on resume. In theory it should "just work" if you did everything right, but in practice you never know. XB extensions like Missing Link and extended XBs like RXB which understand AMS may not be compatible. The amount of time it would take to switch would be measurable (but probably acceptable). I dunno, that's all I've got.

 

[+arcadeshopper]

Should work on either, shouldn't it...? Theoretically, if it's just pure software...
 
It seems like it's feasible. An interrupt hook could watch the keyboard. The trick is both pieces of software think they own the machine, so you'd need somewhere to backup RAM. The good news is you know where in execution you are (interrupt hook) and you know the graphics state of the system (either XB or Force Command), so it should be possible to resume.
 
I'm speaking thinking from the XB side, anyway. I don't know Force Command too well - whether it allows the interrupt hook to run and whether it does so from a fixed location (to make resume easier).
 
It's not trivial, at any rate, but I think what you do is:
 
- verify that the interrupt can be safely hooked in both apps (it can in XB, as long as assembly that takes it over isn't loaded)
- identify a safe memory location for the hook routine - it'd be easier if it was safe on both sides [emoji6]
- track which state you're in. I suspect it'd be easiest to load it from an XB LOAD program, so you can assume starting point is always XB.
- when the hot key is detected, back up system memory, VDP RAM and scratchpad, change out the GROM/ROM banks, and do a dedicated resume of the other application. For the first time to FC, that might mean initial startup, which may be a little different. Same thing for going back. Note that's a little over 48k RAM needed to backup one state.
- I'd probably want dedicated backup memory for each application, just to keep it simple. Otherwise you COULD backup existing memory and restore old memory at the same time, just swap one word at a time [emoji6]
 
(edit: one tricky part - VDP and GROM addresses. You can read out the GROM address on swap and restore it on restore, so that isn't too bad. VDP address is write-only though. For XB you should be okay - when the user interrupt hook fires the VDP address was already corrupted so doesn't need a fixed state, but you'd need to verify that's also true of FC. Also.. VDP registers are read-only, which means that you need to assume what each application needs to be set. For instance, if you assumed the XB immediate mode screen but pressed the hotkey inside a running program, you wouldn't know what screen color to restore [emoji6] - minor thing though.)
 
The hard part is if either app gets fussy on resume. In theory it should "just work" if you did everything right, but in practice you never know. XB extensions like Missing Link and extended XBs like RXB which understand AMS may not be compatible. The amount of time it would take to switch would be measurable (but probably acceptable). I dunno, that's all I've got. [emoji6]
 

Source is in GitHub in c

I know Matt is calling finalgrom99 routines to load cartridges from the root folder of the finalgrom99

Sent from my LM-G820 using Tapatalk

[RXB]

On 4/16/2020 at 6:47 AM, INVISIBLE said:

With the large memory space in the UberGROM or the FinalGROM is it theoretically possible to combine a version of Extended BASIC and Force Command into paged interactive environment?

 

Example:  Say I'm in XB and want to load the DOS, could a routine, for example CONTROL-D be inserted into XB to automatically call the DOS when activated?  Then later a CONTROL-B take you back to BASIC where you left?

RXB take on this idea here.

RXB 2020 has a new few features that do not exactly do what you requested, but overall do that request slightly with  twist.

Ok to explain RXB 2020 has CALL PLOAD and CALL PSAVE that load or save 4K Program Image files into any place in 32K but with boundaries.

Boundries? Like 2 = >2000 or 3 = >3000 or A = >A000 or so on up to F = >F000 as these are 4K boundries of the 32K.

Ok so saving and loading is taken care of, how about memory switching.

Using SAMS RXB 2020 has CALL SAMS(2,pagenumber) so follow along here, use CALL PLOAD to load >2000 and us CALL SAMS to switch to that page with what was loaded.

 

What does this do, well use CALL PLOAD to load the SAMS with DOS and use CALL SAMS to switch pages then use CALL LINK to run DOS.

1 Meg of SAMS could run many programs all from a single DV80 file (BATCH file) in RXB would be the result. 

This is what I have been working on so long, thus imagine a simple switch from FW to DOS to XB from RXB.

All from XB with 1MEG loaded into SAMS, exit back to XB like FW does and continue on.....

 

Edited April 17, 2020 by RXB
comment added

[Omega-TI]

I'll take a look at how this works when it's released, it sounds interesting.  At this stage of my life, I'm more inclined to adopt things that are easy to use and install and that do not require a steep learning curve.  

[Asmusr]

On 4/16/2020 at 3:54 PM, arcadeshopper said:

Example:  Say I'm in XB and want to load the DOS, could a routine, for example CONTROL-D be inserted into XB to automatically call the DOS when activated?  Then later a CONTROL-B take you back to BASIC where you left?

How important is the "where you left" part to you? 

[Tursi]

2 hours ago, Asmusr said:

How important is the "where you left" part to you? 

I would expect that at least on the XB side, it'd be mandatory. Otherwise you might as well just hit QUIT...

 

[Asmusr]

27 minutes ago, Tursi said:

I would expect that at least on the XB side, it'd be mandatory. Otherwise you might as well just hit QUIT...

 

Exactly. Or an XB command CALL FC. What is the use case?