+Schmitzi Posted April 2, 2020 Share Posted April 2, 2020 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 ? Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 2, 2020 Author Share Posted April 2, 2020 Not sure... probably should put this into a thread or in the hardware thread now that we got ROS working.... 1 Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted April 2, 2020 Share Posted April 2, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted April 2, 2020 Share Posted April 2, 2020 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" Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted April 3, 2020 Share Posted April 3, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted April 3, 2020 Share Posted April 3, 2020 (edited) 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 April 3, 2020 by Ksarul 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 3, 2020 Author Share Posted April 3, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted April 3, 2020 Share Posted April 3, 2020 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 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted April 3, 2020 Share Posted April 3, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 3, 2020 Author Share Posted April 3, 2020 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 4, 2020 Author Share Posted April 4, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted April 4, 2020 Share Posted April 4, 2020 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) Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted April 4, 2020 Share Posted April 4, 2020 I have my HRD16 at >1600 and Horizon 2000 at >1700 ( the BWG is at >1100). 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 5, 2020 Author Share Posted April 5, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted April 5, 2020 Share Posted April 5, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted April 5, 2020 Share Posted April 5, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted April 5, 2020 Share Posted April 5, 2020 (edited) 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. Edited April 5, 2020 by HOME AUTOMATION reordered paragraphy 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted April 5, 2020 Share Posted April 5, 2020 The MENU 739 disk is where you want to go, @Schmitzi 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 5, 2020 Author Share Posted April 5, 2020 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 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. 1 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted April 5, 2020 Share Posted April 5, 2020 Okey Dokey, will play around with it, thx Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted April 5, 2020 Share Posted April 5, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 6, 2020 Author Share Posted April 6, 2020 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 4 3 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted April 6, 2020 Share Posted April 6, 2020 This is so cool! Thank you for setting up the Github repo and wiki! It is much appreciated ? 1 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted April 7, 2020 Share Posted April 7, 2020 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! 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. 1 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 7, 2020 Author Share Posted April 7, 2020 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.