Jump to content
InsaneMultitasker

Horizon RAMdisk ROS and CFG Development

Recommended Posts

That board seems to work.. I imagine the lithium battery is due for replacement... 

 

Forgive me if this was covered in the earlier 17 pages... auto-starting GROM ( at least the one in ForceCommand ) seems to cause a fit if the ROS (3.14.2020) PowerUP is enabled.  Seems to behave nice when PowerUp is disabled in ROS CFG tool.

 

I would have thought cartridge powerup routines happen after expansion card ROM powerup routines.  I've got the TIPI at >1000, TIFDC at >1100, HRD at >1200, SAMS at >1E00

The fit is basically a blank cyan screen with the cards all cycling, occasionally a beep, but generally just each of the card lights taking their turn, and repeating.

 

Share this post


Link to post
Share on other sites
18 minutes ago, jedimatt42 said:

That board seems to work.. I imagine the lithium battery is due for replacement... 

 

Forgive me if this was covered in the earlier 17 pages... auto-starting GROM ( at least the one in ForceCommand ) seems to cause a fit if the ROS (3.14.2020) PowerUP is enabled.  Seems to behave nice when PowerUp is disabled in ROS CFG tool.

 

I would have thought cartridge powerup routines happen after expansion card ROM powerup routines.  I've got the TIPI at >1000, TIFDC at >1100, HRD at >1200, SAMS at >1E00

The fit is basically a blank cyan screen with the cards all cycling, occasionally a beep, but generally just each of the card lights taking their turn, and repeating.

 

With powerup "Y" (on), try holding the SHIFT key when you turn on the TI.  It should get you past the cycling stage.

 

The powerup "Y" option enables a second powerup within the DSR.  It looks for and launches the first configured user-defined program (see ConFiG) program, defaulted to "MENU" on the first formatted drive.  With some cartridges like the FG, ROS seems to get lost or is encountering something in the cartridge powerup and/or TI powerup sequence it cannot recover from.   Two ways around this are to either turn off the ROS powerup option or add MENU (or as-defined program) to your first ramdisk drive.  I neither own an FG99 nor have I come across any further insight that would aid in a resolution.

 

 

Share this post


Link to post
Share on other sites

Random thought... run CFG and with powerup "Y", rename the first option from MENU to something random. It just occurred to me that perhaps the FG99 has a defined subprogram MENU that causes the cycling....

Share this post


Link to post
Share on other sites

Thanks, not an interaction specific to the FinalGROM99... more the ForceCommand module I loaded that has a GROM powerup routine... pressing shift gets it out of the loop and proceeding per normal. changing the menu entry name does nothing.. 

 

there is no subprogram named MENU.. but my ForceCommand has a GROM menu entry 'AUTOCMD' and a GROM powerup, and the ROM has a menu entry 'FORCE COMMAND' ... the GROM powerup jumps into the ROM entry point. Something seems to be related to how the ROS powerup wants to jump into the GROM menu entry...   Doesn't happen if I only load my ROM and not my GROM into FG99.

 

I'm assuming this isn't a problem with XB 2.7 Suite?   -- I'll read the ROS code and maybe discover something. 

  • Like 1

Share this post


Link to post
Share on other sites

Not sure if this relates...

 

As I recall, a seemingly odd behavior of the FG99, is that if a cartridge has both GROM and ROM image files, and both images have headers with program entries, selecting the entry from the GROM's header will cause the FG99 to load both GROM and ROM images, conversely, selecting the entry from the ROM's header will cause The FG99 to load only the ROM image.

 

For some reason, I don't believe this is the console's normal behavior.:ponder:
 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, jedimatt42 said:

Thanks, not an interaction specific to the FinalGROM99... more the ForceCommand module I loaded that has a GROM powerup routine... pressing shift gets it out of the loop and proceeding per normal. changing the menu entry name does nothing.. 

 

there is no subprogram named MENU.. but my ForceCommand has a GROM menu entry 'AUTOCMD' and a GROM powerup, and the ROM has a menu entry 'FORCE COMMAND' ... the GROM powerup jumps into the ROM entry point. Something seems to be related to how the ROS powerup wants to jump into the GROM menu entry...   Doesn't happen if I only load my ROM and not my GROM into FG99.

 

I'm assuming this isn't a problem with XB 2.7 Suite?   -- I'll read the ROS code and maybe discover something. 

Shortly before the latest release a few of us were seeing the cyan screen with the XB27 suite.  One day I noticed the problem had cleared up and I was no longer able to reproduce it.  My suspicion at the time was that the ROS I created was somehow corrupted during transfer. 

 

anyway, it sounds like you are on to something with the ROS powerup and the GROM interaction. I don't know if Home Automation's observation is expected behavior for rom/grom selections.  

Share this post


Link to post
Share on other sites
5 hours ago, HOME AUTOMATION said:

Not sure if this relates...

 

As I recall, a seemingly odd behavior of the FG99, is that if a cartridge has both GROM and ROM image files, and both images have headers with program entries, selecting the entry from the GROM's header will cause the FG99 to load both GROM and ROM images, conversely, selecting the entry from the ROM's header will cause The FG99 to load only the ROM image.

 

For some reason, I don't believe this is the console's normal behavior.:ponder:
 

 

Loading here refers to populating the RAM so that it can pretend to be GROMS and ROMs to present to the 4A. After the ARM cpu on the final grom loads the RAM state, things are presented to the 4A in a way the console cannot tell.   

 

So, its is just like a ROM only cartridge at that point... It'll work the extent that the ROM is self sufficient.  In my case, with Force Command it was designed to be self-sufficient so it can go on ROM only carts if desired. The GROM is just there for the joy of auto-loading... 

 

ROS secondary powerup or whatever it is called is the accumulation of all the most arcane spells an assembly programmer can issue to our 4A's little DSR system... hoisting code into expansion ram so it can interact with other cards... Inspecting the cartridge port to autostart any cartridge ( I imagine this is a QI work around also ) 

 

Basically in my case, if the ROS secondary powerup routine is enabled, there is no value in my ForceCommand GROM.  - So, also no value in further investigation, for me. 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

I use an UberGROM cartridge with the XB 2.7 Suite on it to test all of my Horizon 4000B boards during assembly. I generally turn the Autostart selection off, but it works normally if it finds MENU when it is on.

  • Like 2

Share this post


Link to post
Share on other sites

With the "completion" of ROS 8.42c, I shifted my limited programming time to the Geneve and MDOS.  Earlier this week I noticed that my Horizon 3000 card at CRU >1400 showed signs of file corruption and degradation, most likely due to weakening alkaline batteries.  The same batteries have held the card for 3+ years, so I got my money's worth.  I replaced the batteries and loaded CFG 8.42c (via rompage) where I ran into a problem: the 4000B at CRU >1600 was not turning off after the peripheral scan and it was interfering with the 3000.  I ruled out most of the hardware possibilities and turned to software.  The problem was in CFG. 

 

For display purposes, I use CRU "9640" to list the Geneve as a peripheral during the scan.  Unfortunately, the device display routine also turns on each card!   CRU >9640 gets masked down to >1640 which in turn activated the Ramdisk.  Talk about a chance observation.   I have since corrected the problem and will push the fix at a later date.  I hadn't really tested Geneve support, being the target audience is TI users ;)  

 

That said:  OS space-willing, my intent is to allow a CFG-formatted RAMdisk to operate within standard GPL mode, similar to how I am approaching TIPI support. This will probably require the use of REMAP due to the very limited DSR name list table space. Early research indicates expanding the table size is no easy feat.   Right now I am going through nearly 20 (!!!!) years of OS changes and code....

  • Like 6

Share this post


Link to post
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.

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...