Jump to content
IGNORED

Horizon RAMdisk ROS and CFG Development


Recommended Posts

yes, I have, as a test, copied the complete ROS842cc 03-27-2020 onto the Ramdisk #DSK5

 

I´ve pulled a 3rd Ramdisk from the shelf, but this one seems to be defect :( not recognized.

I think, many people sold many crap in the last years.... don´t know, and I am waisting my time on that, maybe.

 

Back to the HRD16 3MB, I wanted to completely delete it now, but I cannot answer this question here:

Any idea ?

 

IMG_2558.thumb.jpg.5f55abf674bbc7dfb386f67bce15a550.jpg

Link to comment
Share on other sites

1 minute ago, atrax27407 said:

FYI, The HRD16 has a jumper that, when pulled, will temporarily disable the battery backup and thereby summarily delete everything on the HRD16 - including ROS.

 

ah yes, and I forgot about just pulling the nuklear plant, that I socketed days ago

And I thought, "why not trying this destructive test"  :)

 

 

Link to comment
Share on other sites

On the blue screen, I saw the same behavior when I had a RAM Disk setup without a MENU program present on the disk and POWER UP=Y. I just turn POWER UP to N and the problem disappears, as it isn't trying to find the nonexistent MENU program anymore. One other note, The blue screen appears with an UberGROM as well. I think it has to do with the multiple MENU items on the FinalGROM, FinalROM, or UberGROM cartridge images. I suspect it would also show up with a Guion-modified SEB cartridge.

  • Thanks 1
Link to comment
Share on other sites

The answer to the MEGTEST question is 32 chips. It will test the first meg of the board (8 of the 128K chips), which translates to 32 of the 32K chips (4 (per 128K chip) x 8 (128K chips) = 32).

 

Note it ONLY tests the first meg of the board. . .

Edited by Ksarul
  • Thanks 1
Link to comment
Share on other sites

44 minutes ago, Ksarul said:

On the blue screen, I saw the same behavior when I had a RAM Disk setup without a MENU program present on the disk and POWER UP=Y. I just turn POWER UP to N and the problem disappears, as it isn't trying to find the nonexistent MENU program anymore. One other note, The blue screen appears with an UberGROM as well. I think it has to do with the multiple MENU items on the FinalGROM, FinalROM, or UberGROM cartridge images. I suspect it would also show up with a Guion-modified SEB cartridge.

This is a good clue.  I'll play around with this and the ubergrom this weekend if time permits, to see if I can isolate the routine and/or reason.

  • Thanks 1
Link to comment
Share on other sites

Thank you all, good to know not to be alone with any "problems" (it´s not a problem at all)

My beginners "problem" everyday is, that I do not know my hardware at all, the reliability. It´s still almost untested.

So, if I have a glitch, at the moment I never know if it´s me, (the oblivious man), or my own hardware, or just a problem.

So for now, I just use my standard cartriges to be sure when playing around.

Thx

xXx

 

Link to comment
Share on other sites

8 hours ago, InsaneMultitasker said:

This is a good clue.  I'll play around with this and the ubergrom this weekend if time permits, to see if I can isolate the routine and/or reason.

Note that the UberGROM image I used in my tests was Tony's XB 2.7 Suite. The issue isn't the UberGROM per se.  I think it is that the cartridge doesn't jump straight into XB, but takes a detour to the giant menu selection. The HRD thus detects that Extended BASIC is present, but doesn't know how to branch to it in this circumstance as it trys to gracefully fail back from the missing MENU program.

  • Like 2
Link to comment
Share on other sites

2 hours ago, Ksarul said:

Note that the UberGROM image I used in my tests was Tony's XB 2.7 Suite. The issue isn't the UberGROM per se.  I think it is that the cartridge doesn't jump straight into XB, but takes a detour to the giant menu selection. The HRD thus detects that Extended BASIC is present, but doesn't know how to branch to it in this circumstance as it trys to gracefully fail back from the missing MENU program.

Agreed, this is a reasonable possibility.  Branching directly into the detected cartridge is the most likely problem here, as I believe you can hold the SHIFT key and get to the title screen under these conditions. 

Link to comment
Share on other sites

I've had a few mixed results.

 

With powerup "Y" (on) and no MENU program on the ramdisk, the ubergrom w/XB27 suite is auto-starting XB. If I hold the SHIFT key and turn on the console, I get the XB27 suite menu.    If I pull the cart, I get the TI title screen with the "ROS842" version displayed to the right.   With powerup "N" (off) the ubergrom xb27 menu pops up at restart.  

 

Earlier tonight my system was stuck in a powerup loop if the MENU file wasn't on the ramdisk.  I reloaded ROS and the problem disappeared.

 

Now I cannot re-create the issue so I'm a bit perplexed. 

 

 

 

  • Like 1
Link to comment
Share on other sites

Yes, so was I. (But sorry, I don´t know enough about)

Is there another difference using >1000 and i.e. >1400 (means any other, greater than >1000) maybe ?

What I understand is, that the >1000 is used to boot >before< any other controller (standard at >1100)

 

Link to comment
Share on other sites

Since I cannot reproduce the problem with the powerup/menu routine, and since I don't have hardware besides an Ubergrom to test, my recommendation for now is to turn off the ramdisk powerup. 

 

I believe the powerup defaults to ON.  I am thinking it is a good idea to turn off the autostart for a newly formatted ramdisk.  

  • Like 1
Link to comment
Share on other sites

10 hours ago, InsaneMultitasker said:

Since I cannot reproduce the problem with the powerup/menu routine, and since I don't have hardware besides an Ubergrom to test, my recommendation for now is to turn off the ramdisk powerup. 

 

I believe the powerup defaults to ON.  I am thinking it is a good idea to turn off the autostart for a newly formatted ramdisk.  

That is what I usually do, @InsaneMultitasker. I only turn it on once I've built a MENU for that card.

  • Like 2
Link to comment
Share on other sites

On 4/2/2020 at 3:44 PM, Schmitzi said:

So I used the correct filename now (ROS842CC) and the ROS loads :)

 

One thing that I see is, if I set the "Power Up" parameter to "Yes", then, at restart, I only get a light blue screen.

I found out that this is due to the FinalGROM99 usage (TI XB or XB2.5 loaded, or whatever)

If I use a real iron Extended Basic cartridge, the system starts up......

 

So I pulled an old HRD3000 card (1 MB, all tests = OK) and it´s the same behaviour.

No reaction after loading the ROS if the FinalGROM is inserted

 

I also switched the HRD3000 to >1400 and loaded the original 8.14-F with an Extended Basic cart,

this is OK, until I insert the FinalGROM99. Then after power up the TI (with parameter "Power up=Y), only a light blue screen

So... I've been looking into a stable way to "cold boot" from my FinalGROM, for the last couple days(somewhat successfully!). My current understanding is that, when power is initially applied, the FGROM immediately begins loading it's "cartridge selection menu" into it's 1 MEG RAM. The .bin G. and C. images of this cart have been intentionally kept short, to keep wait time down. While the cartridge BOOTS/RAM loads, a BUS on the TI becomes unstable. Trying to execute INSTRUCTIONS on the 9900 during this period, results in false op-codes appearing to execute, usually benign, but sometimes fatally. The first several instructions I execute after a power-up routine will be susceptible to this activity(possibly only on the SRAM). The only work-around I have found is to "keep the BUS inactive(LOW?)", for about maybe... the first 20 addresses, accomplished by attempting to execute >0000 as an instruction, repeatedly. While attempting a power-up ROUTINE, the FGROM's bus-activity, is blocking the loading of the CHARACTER SET, COLOR TABLE, etc., resulting in a light blue screen.

 

  P.S. I'm still trying to figure out a good way to reload the character-set-tables.:D

Edited by HOME AUTOMATION
reordered paragraphy
  • Like 1
Link to comment
Share on other sites

1 hour ago, Schmitzi said:

Is it that MENU file from the ROS disk (hmm, did I see one there?),

or is it this MENU739 disk (that I will have my first look on, tomorrow) ?

 

I am asking for a neighbour :grin:

If you are using ROS8.42C, then you MUST use the MENU739C file that is in the distribution.   Rename it to MENU and you can use it accordingly.  The menu739 disk file MENU will load just fine, but the character set will be incorrect and look like garbage. 

 

(When I distribute files, I expect that the user will rename some files as needed. I got tired of looking at 15 versions of the same file all named the same!  I anticipate doing the same with CFG's name if I release a new version)

 

51 minutes ago, Ksarul said:

The MENU 739 disk is where you want to go, @Schmitzi

Sorry, no longer true if using ROS8.42c (or future versions) due to how the character set is stored.  The menu documentation on that disk will still be relevant.   

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

30 minutes ago, InsaneMultitasker said:

If you are using ROS8.42C, then you MUST use the MENU739C file that is in the distribution.   Rename it to MENU and you can use it accordingly.  The menu739 disk file MENU will load just fine, but the character set will be incorrect and look like garbage. 

 

(When I distribute files, I expect that the user will rename some files as needed. I got tired of looking at 15 versions of the same file all named the same!  I anticipate doing the same with CFG's name if I release a new version)

 

Sorry, no longer true if using ROS8.42c (or future versions) due to how the character set is stored.  The menu documentation on that disk will still be relevant.   

Yes, I forgot about that particular gotcha, @InsaneMultitasker.  Many thanks for the quick correction!

  • Like 1
Link to comment
Share on other sites

As we get closer to more hardware being released and more interest in the ramdisk,  there is now a Github site in process for the source code and other materials.  A Wiki has also been created to cover things at a high level. I posted this in the HRD4000B topic as well.

 

Wiki:

https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/wiki

 

Source:

https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a

 

  • Like 4
  • Thanks 3
Link to comment
Share on other sites

On 4/5/2020 at 3:33 PM, HOME AUTOMATION said:

Trying to execute INSTRUCTIONS on the 9900 during this period, results in false op-codes appearing to execute, usually benign, but sometimes fatally. The first several instructions I execute after a power-up routine will be susceptible to this activity(possibly only on the SRAM). The only work-around I have found is to "keep the BUS inactive(LOW?)", for about maybe... the first 20 addresses, accomplished by attempting to execute >0000 as an instruction, repeatedly.


o.k.--- This turned out to be a false alarm! The .bin file I was modifying, was offset by 1 byte. Sometimes I was forgetting, then putting my test code on word bounderies, causing problems!

 

On 4/5/2020 at 3:33 PM, HOME AUTOMATION said:

While attempting a power-up ROUTINE, the FGROM's bus-activity, is blocking the loading of the CHARACTER SET, COLOR TABLE, etc., resulting in a light blue screen.


This was an assumption on my part, based on "rule outs". But I forgot about "screen blanking". Turns out the CHARACTER SET, COLOR TABLE, did load!:-D

 

So... The real issue is that the FGROM, blocks/bypasses some of the initialization of CPU RAM during a power-up routine!(Verified). The Byte at >83D4, is not the expected >E0, this byte is copied to VDP REGISTER 1 on key-presses, causing screen blanking, there may be other initialization errors, dunno yet.

 

I'm looking into a mock-up re-initialization procedure.:ponder:

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

32 minutes ago, HOME AUTOMATION said:

 

So... The real issue is that the FGROM, blocks/bypasses some of the initialization of CPU RAM during a power-up routine!(Verified). The Byte at >83D4, is not the expected >E0, this byte is copied to VDP REGISTER 1 on key-presses, causing screen blanking, there may be other initialization errors, dunno yet.

 

Unless I'm misunderstanding the intent here of this conversation - which is entirely possible - might be better to  move this fgrom conversation to another topic :)

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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