Horizon RAMdisk ROS and CFG Development

[+jedimatt42]

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.

 

[+InsaneMultitasker]

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.

 

 

[+InsaneMultitasker]

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

[+jedimatt42]

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. 

[HOME AUTOMATION]

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.
 

[+InsaneMultitasker]

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.  

[+jedimatt42]

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.
 

 

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. 

 

 

 

[+Ksarul]

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.

[+InsaneMultitasker]

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

[wolhess]

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!

[+InsaneMultitasker]

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?

[RXB]

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.

[wolhess]

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. 
 

[wolhess]

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.

 

 

[wolhess]

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.

[+InsaneMultitasker]

 

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.

[wolhess]

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.

 

 

 

[+InsaneMultitasker]

Referencing potential issue for review.  Multiple files opened concurrently and one or more having filename length >8 characters results in a file error in TI assembler.  Thank you, @wolhess for helping us to understand the nature of the problem.

 

 

[+InsaneMultitasker]

The issue referenced in post #468 is resolved within the following thread.  Files previously copied from TIPI may still exhibit the symptoms.   The filename length was coincidental and not a contributing factor.  Thank you, @wolhess, for helping us to understand the nature of the problem. 

 

[+InsaneMultitasker]

ROS and CFG source code on github has been updated for compatibility with xas99.  Earlier versions allowed the  "$" symbol within labels - this is also legal in some native TI/Geneve assemblers.  More recent versions no longer allow operator symbols in labels, including the "$" and "#" characters.  Although I disagree with the imposed restriction for cross-compatibility reasons, it was simple enough to change the source. 

 

The Geneve "9640" CRU bug is now fixed in the CFG source.  I have not yet compiled and released a fix since the preferred method of formatting a Horizon on the Geneve is to use a native OS formatter, FORM v1.23 or FORM3MEG.

[+Schmitzi]

On 5/20/2020 at 10:49 PM, InsaneMultitasker said:

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.  

 

Hi, yes I think I remember that day. Wasn´t it when you integrated the TITLE into the ROS ?

(The small proggy that displays the Rambo or any picture at bootup)

 

[+InsaneMultitasker]

38 minutes ago, Schmitzi said:

 

Hi, yes I think I remember that day. Wasn´t it when you integrated the TITLE into the ROS ?

(The small proggy that displays the Rambo or any picture at bootup)

 

Splash/Title is an executable that runs only if you configure CFG to do so.  I had originally considered integrating the functionality into the ramdisk OS and decided it would be more appropriate to keep the functionality separate.     I have not had the opportunity to revisit the problem.  Edit: I added this and @wolhess transparent color issue to the Git "issues" log    

 

On 11/14/2020 at 1:12 PM, InsaneMultitasker said:

 

The Geneve "9640" CRU bug is now fixed in the CFG source.  I have not yet compiled and released a fix since the preferred method of formatting a Horizon on the Geneve is to use a native OS formatter, FORM v1.23 or FORM3MEG.

A new formatter was released 4 April 2021 along with the Geneve OS 7.30 package.  FORM 1.23 and FORM3MEG are now deprecated in favor of GENCFG, when used with the new OS.  Source code will be posted to the wiki at a future date.

[atrax27407]

Here's what I have running MAME on my laptop:

 

 

Edited May 2, 2021 by atrax27407

[rgjt]

On 7/26/2015 at 5:52 PM, Ksarul said:

The earliest Foundation cards were actually a 32K card--that worked just like the TI card. Then came the DSR-free 128K card, with a DSR that came out very soon thereafter (initially as an upgrade, but later it was standard). Last came the hack to make it run the Myarc 128K OS (and their XB 2.11). The hack also included instructions to upgrade the card to 512K (I think I have one that has all of this done to it--but I also have a standard 32K and a 128K (with DSR) version of the card).

Does anybody have the QS-Ramdisk software that allows the creation of a ramdisk for the 96k memory portion above the 32k?

That software was sold by Quality 99 Software.

[+Ksarul]

Note one thing about any Quality 99 disk--they did some bizarro copy protection on them that could be defeated with Copy-C, but not with most other disk copy programs. I believe a lot of their programs had the protection routines removed by others long after Quality 99 was no more, although I'm not sure if anyone applied that procedure to QS-Ramdisk.