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

Hi,
As of today, I am the proud owner of an HRD4000B Ramdisk card.

 

I read the manual completely and still destroyed my configuration when I set up the card.

 

Maybe it helps others or Tim can do something about the next update here:

My problem: I started the configuration and I am in the EDIT menu for setting up the background color and foreground color.
I only changed the foreground color from 16 = white to 1 = transparent. My input was 1 and spacebar.
>>> That's it with the screen display! <<<

 

After a complete reset (remove the battery) and set up the ramdisks everything worked again.

Then I set up the menu program and leave it start automatically.
It works as it should for now, I think.

 

Now for my second problem with MENU739C:
I mostly use RXB 2015 for my Extended Basic working. However, the menu program does not recognize this.
With menu item C (RXB 2015) I get into the XB, but a "SYNTAX ERROR" is output. After that I can continue working normally.

 

My problem is, however, if I want to start an XB program via the menu, then it does not work, there is only an error message "No EX-Basic ..." because the menu does not know RXB.

With the original TI XB or XB 2.6 there are no problems.

 

Perhaps this can be corrected as part of a next revision?

 

All in all, the HRD4000B Ramdisk card is an excellent and very useful extension for my TI.

The computer responds super quickly when a program is loaded from the ramdisk, and I have a lot of space on the ramdisk.

Working together with my TIPI / RPi card also works without any problems.

 

Thank You for making this possible!

  • Like 4

Share this post


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

Hi,
 I started the configuration and I am in the EDIT menu for setting up the background color and foreground color.
I only changed the foreground color from 16 = white to 1 = transparent. My input was 1 and spacebar.
>>> That's it with the screen display! <<<

 

Ah, yes.  This should be an easy change to disable the transparent color and prohibit the user from selecting the same values for foreground/background.

 

1 hour ago, wolhess said:

Now for my second problem with MENU739C:

 

I mostly use RXB 2015 for my Extended Basic working. However, the menu program does not recognize this. With menu item C (RXB 2015) I get into the XB, but a "SYNTAX ERROR" is output. After that I can continue working normally.  Perhaps this can be corrected as part of a next revision?

 

I don't have source code for MENU739C however, I can theoretically disable the check for the existence of the XB cartridge.  I do not recall the reason for the SYNTAX ERROR.  Where is RXB loaded - into a cartridge or some other device ?  Which GROMs and GROM base?

Share this post


Link to post
Share on other sites
2 minutes ago, InsaneMultitasker said:

Ah, yes.  This should be an easy change to disable the transparent color and prohibit the user from selecting the same values for foreground/background.

 

I don't have source code for MENU739C however, I can theoretically disable the check for the existence of the XB cartridge.  I do not recall the reason for the SYNTAX ERROR.  Where is RXB loaded - into a cartridge or some other device ?  Which GROMs and GROM base?

RXB is exactly like XB Cart, but with many many enhancements, and XB or XB 2.6 both kept the 110 version numbers.

Version numbers have changed since RXB 2000 on, and some previous programs (Assembly) used oddball GPL address to run routines.

An example FW Boot used to be an address was used that just took for granted those bytes lead to a routine, but really just appeared that way to someone guessing.

When RXB changed a Branch to fix an issue it resulted in this Assembly routine not working in RXB 2001 on.

FW Boot got fixed and no longer has this issue.

Share this post


Link to post
Share on other sites
9 minutes ago, InsaneMultitasker said:

Where is RXB loaded - into a cartridge or some other device ?  Which GROMs and GROM base?

I‘m loading RXB from a FG99. If I load XB or XB2.6 from the FG99 these XB‘s are working.

 

I tried to run a XB program with the auto start Funktion and this is also not working when I have selected

the RXB2015 cartridge. 


Only for information:

I also have tested BOOT with the same results. 
 

Share this post


Link to post
Share on other sites
17 minutes ago, InsaneMultitasker said:

Which GROMs and GROM base?

What do you mean about GROM or GROM base?

 

I never changed anything about GROMs.

 

 

Share this post


Link to post
Share on other sites
22 minutes ago, InsaneMultitasker said:

I don't have source code for MENU739C however, I can theoretically disable the check for the existence of the XB cartridge.

If you can disable the check this would be very helpful in my case.

  • Like 1

Share this post


Link to post
Share on other sites

 

44 minutes ago, wolhess said:

I‘m loading RXB from a FG99. If I load XB or XB2.6 from the FG99 these XB‘s are working.

 

I tried to run a XB program with the auto start Funktion and this is also not working when I have selected

the RXB2015 cartridge. 


Only for information:

I also have tested BOOT with the same results. 
 

Sorry, I don't use or own the FG99;  I use the UberGROM cartridge.  The problem sounds similar to what was reported with the FG99 during ramdisk powerup.   I will check the 9640 Menu code for any clues to a solution however, I think this is a  problem I need help from others to resolve, then I can patch accordingly.

  • Like 1

Share this post


Link to post
Share on other sites

Don‘t worry, currently I disabled the auto start function and use my own compiled XB mega menu with RXB.

 

This is working with the HRD4000 Ramdisks I configured today.

 

Next I will test to assemble and compiling with small c and turbo pascal 99 with ramdisk access.

I guess this will be a little faster then with the tipi.

 

And I will get more familiar with the HRD4000 Rambo functionality.

 

There is still a lot to discover.

 

Thank you for your help.


 

 

 

  • Like 4

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