Horizon RAMdisk ROS and CFG Development

[+dhe]

Heck, I'm interested in what it was like to be an east german TI user in the 80's! ?

[DomLeBel1]

HI Ksarul,

i am interested in two 400B bare board with difficult parts to get if available.

Thank you

Dominique

[DomLeBel1]

4000B

[GDMike]

On 2/21/2023 at 7:09 AM, DomLeBel1 said:

4000B

I picked up the last one on arcade shopper today I think it's the 8mb version though..

Corrected....I was thinking a 8000B would be a 8MB version, my bad...

Edited February 23, 2023 by GDMike

[+Ksarul]

2 hours ago, GDMike said:

I picked up the last one on arcade shopper today I think it's the 8mb version though

That one is the last assembled and tested one I had on hand, @GDMike. I have a few more assembled boards I need to test, but I don't want to make them available until they pass the tests. I have LOTS of bare boards on hand, as my aim is to keep them (and any other board I make) available for at least as long as I remain alive. 

[+DuaneAL]

47 minutes ago, Ksarul said:

That one is the last assembled and tested one I had on hand, @GDMike. I have a few more assembled boards I need to test, but I don't want to make them available until they pass the tests. I have LOTS of bare boards on hand, as my aim is to keep them (and any other board I make) available for at least as long as I remain alive. 

May you live happily forever!

[GDMike]

@KSARUL, thank you again for building these!

[+InsaneMultitasker]

On 7/24/2021 at 4:01 PM, InsaneMultitasker said:

Does someone have a copy of the CHART file that is required to interpret the TST program results?  I've been asked to incorporate it into the distribution.  In the meantime, I had a few free clock cycles today:

• Post #1 has been cleaned up to show only the most recent release files
• CFG now prohibits the user from selecting the "transparent color" for foreground/background
• When loading/saving ROS, the file IO routine error trap now informs the user there was a disk/file error

Still looking for CHART.  Anyone?   

It seems that I never uploaded these last few changes to Github, so I'm sorting through the code today.

There is also a problem with SAMS detection if a previously run program changed the default mapping, so I may end up removing that routine for the time being. SAMS detection is neat but not necessary for program operation.  There is also an experimental option that tries to pull ROS from Github via TIPI but I don't think that Github allowed me to pull the binary file in that fashion, so I'll probably disable that too. 

 

[+InsaneMultitasker]

On 5/8/2020 at 6:07 AM, apersson850 said:

On the second line, the MOV @SRHADR,R1 is supposed to get the address of the found subprogram in the DSR. The address SRHADR is >83D2, which works with the console's operating system, when it uses its DSRLNK routine to find the proper DSR. This is a clever trick to make the DSR code smaller.

The p-system, however, uses a more efficient method to call a DSR than the regular DSRLNK routine does. With this method, the address of the desired program in the DSR program isn't available at >83D2, so this clever trick backfires.

This is in response to the conversation from the 4000B topic. I re-read our posts from a few pages back.  If I understand the PCODE startup process, the system identifies the peripherals and caches the sector IO subroutine address. The problem with the Horizon Ramdisk ROS is the common entry point and the use of >83D2 (SRHADR), since the latter doesn't exist as "defined" once the PCODE system is operational.

 

Instead of reworking the level 2 table and its common operation, would a simple fix like this suffice?  The proposed change would bypass SRHADR for sector routine >10. 

 

The follow-up question is whether the common entry point the only stumbling block? 

NEXT0  DATA NEXT1,SECPCO, TEST,>0110,SECIO      Sector Input/Output

;pcode fix
secpco lwpi hiws
       li   r1,next0    ;intercept >10 and bypass >83D2 usage
       jmp  tstpco

 

; common entry from the subprogram table for >10,>11...>15
TEST   LWPI HIWS              Load our workspace
       MOV  @SRHADR,R1        Get pointer to CALL table
tstpco MOV  @6(R1),R11        Get address of CALL program
       MOVB @>834C,R2         Get drive # for this CALL

[apersson850]

I think it is the only issue. The p-system doesn't use anything but the sector access routine. It implements it's own file system on the disk.

 

And yes, you're right about the p-system boot sequence. It looks for the appropriate DSR for each of its devices, disks included, when it starts the first time. When it finds a disk controller, it caches the CRU base address and the subprogram entry address, so it can just enable the card and jump to the routine it wants to execute.

This means no conventional DSRLNK is running during all normal calls, and the first one isn't executed by a DSRLNK code that uses memory in the same way as the standard DSRLNK in the machine either. The p-system uses scratch pad RAM differently and also has some maneuvers to handle the issue that it's already running from a card enabled by a CRU address and present in DSR space when it's supposed to access another DSR.

 

This is also the reason for why the p-system (officially) can only have one disk controller. It finds one and simply accesses it with different disk numbers. You can easily expand from three (TI standard) to four (CorComp, for example) drives, since that's just a question about copying values for drive three to empty slots in the table for drive four. And drives five and six, if you like. But if you want the fifth drive to be a RAMdisk, that implies it's not accessed by the same controller as handles physical disks. Hence you have to create a new PCB (that's the p-systems version of a PAB) and hide it somewhere in VDP RAM where you don't need the space. You can't change the p-system's pointer to end of VDP memory, since it's such a tight fit that if you do, you can't use system programs like the editor. It needs all the memory normally available.

 

Note: A PCB (Peripheral Control Block) is used by the p-system's BIOS. It's more or less a PAB augmented by information about the found CRU base address and branch address to the routine you want to run. It does the same for units like REMIN:, REMOUT: and PRINTER:, which normally are directed to the RS 232 card.

[+InsaneMultitasker]

25 minutes ago, apersson850 said:

I think it is the only issue. The p-system doesn't use anything but the sector access routine. It implements it's own file system on the disk

I added an entry to the issue tracker with a link back to this thread.

Today I made a few edits to the user guide and reviewed the open issues. My goal is to update the repository before I make any more code changes. 

[+InsaneMultitasker]

On 9/11/2023 at 5:24 PM, apersson850 said:

This means no conventional DSRLNK is running during all normal calls, and the first one isn't executed by a DSRLNK code that uses memory in the same way as the standard DSRLNK in the machine either. The p-system uses scratch pad RAM differently and also has some maneuvers to handle the issue that it's already running from a card enabled by a CRU address and present in DSR space when it's supposed to access another DSR.

ROS 8.42c has 16 bytes available in the affected DSR segment. My proposed fix requires 10 bytes.  There are additional uses of >83D2 within ROS, for auto-start and some of the CALLs that are executed via the MENU or via BASIC. I don't think these will affect the PCODE card. 

 

Does the ROS autostart feature override the PCODE startup?  If so, the ROS autostart bypass key (SHIFT) might be an option to cede control to the PCODE card, for a manual dual-boot configuration.

 

I am ready to compile the fix into a usable ROS file for you to test before I move to release stage.  If interested, let me know when you would like to try it. 

[apersson850]

The p-code card uses RAM for different purposes, but some of them are the same as for the ordinary operating system. Can't say about 83D2 without a lot of checking.

 

How does the ROS autostart? The p-code card does that by never returning from the power up routine. This normally works fine since the p-code card has the last CRU base address. Everybody else can run their startup first, provided they do return from them.

 

Testing would be interesting, but I've never made a really good way of transferring files from the internet/PC side to the TI. The other way around I normally print text files to a PC running Hyper Terminal using a serial port. The ROS I do have came of disks with the card.

Edited September 24, 2023 by apersson850

[+Ksarul]

On 9/24/2023 at 2:19 PM, apersson850 said:

The p-code card uses RAM for different purposes, but some of them are the same as for the ordinary operating system. Can't say about 83D2 without a lot of checking.

 

How does the ROS autostart? The p-code card does that by never returning from the power up routine. This normally works fine since the p-code card has the last CRU base address. Everybody else can run their startup first, provided they do return from them.

 

Testing would be interesting, but I've never made a really good way of transferring files from the internet/PC side to the TI. The other way around I normally print text files to a PC running Hyper Terminal using a serial port. The ROS I do have came of disks with the card.

I can always send you a 5.25 disk with the most recent ROS release on it. . .just PM me with your address data.

[Gary from OPA]

Now that I can transfers files from my PC to my ti99, I am trying to switch up my ros on my horizons from my last official release 8.14f to the latest 8.42c but I have two issues.

 

On one system I have the corcomp 512k memory card it detects fine with cfg838 and I can load ros8.42c and everything works. But if I use the two part cfg1/2 for 8.42c it sees the corcomp 512k myarc hdfc and it fucks up when loading ros8.42c the power-up goes directly into e/a module not the menu.

 

On my other system I running my avpc and Myarc 512k and whtech Scsi and Myarc FDC and it works perfectly with cfg1/2 and ros838 but when I try ros8.42c the boot menu comes up with weird letters for the numbers 1 thru 9.

 

There some issue with the avpc and newer latest ros as I can't even run my replacement new menu program ramos but works fine on my other system.

 

Time to debug what is wrong in the power-up cycle. Wish I had my ros9 still but so far no luck finding the code but haven't finished my searching my archives and discs.

 

I still need to get more horizon Ramdisks working so far got only two of my 480k ones going a Midwest and original hrd1000.

 

I got my original 4000 and 3 more hrd2000 one with Rambo but for some reason they all only detect around 30k of ram, weird.

[+InsaneMultitasker]

 

Adjustments were made to ROS to implement boundary checks and other corrections, to fix bugs that plagued users for 25+ years.  A few issues were directly responsible for file and disk corruption. Rambo  code had no boundary test for its page map. And 800k capacity was a primary reason for my early updates.   See the change history and this topic for many of the details.

 

Some programs rely on addresses in ros or cfg that should never have been considered static; MENU739 does this, and had to be corrected by implementing a well-known address.    I am almost certain this is the issue you describe with the boot menu numbers. The menu you are using most likely needs to be fixed to reference the new address pointer for character defs. 

 

3 hours ago, Gary from OPA said:

But if I use the two part cfg1/2 for 8.42c it sees the corcomp 512k myarc hdfc and it fucks up when loading ros8.42c the power-up goes directly into e/a module not the menu

This is not necessarily a problem.  You must NOt load ROS842 with cfg838 as you described.  I updated how the load/save operations save and restore the drive table, colors, and powerup settings.  The powerup setting may also be the reason.  Read the posts from 2020 where there was some chatter about powerups.  What you describe sounds familiar so the issue needs to be tested thoroughly without mixing/matching ROS and CFG versions.  I think CFG 8.42e is latest for that series. Maybe I will need to keep that letter after all. Hmm.   

 

Lastly, keep in mind that the avpc/corcomp ramdisk hardware you are using is not common.  I know of only one avpc user.  Testing is good.  Debugging is good.  
 

I will look for my source archives this week as time permits.  With help, I would hope the problems can be identified and with luck, corrected without causing new problems.  

[+InsaneMultitasker]

Note: first post directly references a powerup correction.  Remove the batteries and retest.  

[Gary from OPA]

Is there any code or releases later than what is in the first post. Once I get both of my main systems running I want to study the source changes and see what else can be improved.

 

For sure the latest cfg in the first post sees the corcomp Ramdisk as a myarc hfdc and doesn't seem to load ros8.42c correctly. Reason why I used the cfg838 with it there no issues at all.

 

As for my avpc system I tried the menu739c you supplied in the first post and still issues with ros8.42c and the character definitions but with ros838 no issues at all. And as for my own unreleased Ramos directory it doesn't use any static dsr addresses so that not the issue and works fine on my corcomp 512k system.

 

I suspect the avpc dsr has a bug still all tho I using my 3.2 dsr for it I going to study the code as well and see what is possibly wrong.

 

Yes, I got a lot of weird and uncommon hardware so will be great fun debugging any tiny remaining little issues, plus I still digging around for my ros9 I think I have a printout at least as that had a number of great improvements I made a while ago I want to revisit and hopefully merge into the changes you made.

 

Thanks

Edited February 19 by Gary from OPA
wording

[atrax27407]

You might want to try Tony Knerr's AVPC DSR. I used it and had no problems with the HRD.

[+InsaneMultitasker]

9 minutes ago, Gary from OPA said:

Is there any code or releases later than what is in the first post

The github repository is in my signature; it is a link to the wiki so just go to the code section.  The code should be the same or very close to the release but I would have to do some closer review.  Life and other things got in the way and I haven't done a lot except for what is documented in this topic. 

 

13 minutes ago, Gary from OPA said:

For sure the latest cfg in the first post sees the corcomp Ramdisk as a myarc hfdc and doesn't seem to load ros8.42c correctly

This is strange. Should be easy to compare the HFDC test (in CFG) with the CorComp. It might be a case where the Corcomp has an entry that looks like the HFDC.  The order of device testing is important, especially when more than one device overlaps names and subprograms.  Not sure why ROS won't load properly. No one else has reported this being a problem, then again, that doesn't always mean there isn't a problem.

 

 

[Gary from OPA]

1 hour ago, atrax27407 said:

You might want to try Tony Knerr's AVPC DSR. I used it and had no problems with the HRD.

My own 3.2 dsr should be better, but then I never tested it before. And for some reason looking at my old avpc dsr release the tested 3.0 file is the same as 3.2, so I a screwed up a save there decades ago. Might have to switch to my 2.0 for now. Is there a published version of Tony kneers avpc? With source or not?

 

@InsaneMultitaskeraas for the cfg and corcomp Ramdisk cfg838 detects the card perfectly just 842 cfg doesn't. Even my old cfg detected corcomp Ramdisk as I had that card for longest time. But strange how it doesn't load ros right even if the card list is incorrect unless it making a change based on the fact it thinks I have a hdfc card installed but I don't really.

[GDMike]

Just FYI, plus the fact it would make good use of my F18A... but when you guys develop and finish an app, can you make sure to include an F-18A qualified version as well, or keep it in the back of your head. Yay

[+InsaneMultitasker]

9 hours ago, Gary from OPA said:

 

@InsaneMultitaskeraas for the cfg and corcomp Ramdisk cfg838 detects the card perfectly just 842 cfg doesn't. Even my old cfg detected corcomp Ramdisk as I had that card for longest time. But strange how it doesn't load ros right even if the card list is incorrect unless it making a change based on the fact it thinks I have a hdfc card installed but I don't really

8.42 looks for subprogram >25, to differentiate between the HFDC and Personality card.  CorComp Ramdisk uses the "RAMGR" call subprogram.  Can you load Fred's DU2K to inspect the DSR tables and take some pics of what you see?  The only way the HFDC should be detected in error is if there is a CRU conflict with both cards or subprogram >25 is also used in the CorComp subprograms, which would be very interesting as that means they conflict with the HFDC.

 

Here is 8.42 lookup:
WDSCRD BYTE 1         ;8  HFDC - Use level 2 to distinguish w/Personality #25
       BYTE >25

CCRAM5 BYTE 5

       TEXT 'RAMGR'      ;22 CorComp MemoryPlus 512K

 

both 838 and 842 look for the RAMGR subprogram.  but in 842, you aren't getting that far. 

 

       BL   @FINDSR
       DATA >A,CCRAM5,ENDCHK  corcomp Memory Plus (1000)
       BL   @FINDSR
       DATA >A,FND128,ENDCHK  Foundation 128K card w/DSR (1E00)
       BL   @FINDSR
       DATA >A,GRAM11,ENDCHK  GRAM 1.1 Gram Card

 

Update: according to this binary dump,Corcomp did indeed use the same subroutine numbers as the HFDC hard drive level 2. Perhaps this is how they ensured no conflicts within the ram manager.  Anyway, if you sector edit CFG to replace >0125 with >0127, that should in theory fix the identification problem.  >27 is the 'current path' routine which is not found in the CC ramdisk, but it is found in the hfdc.  since SCSI and IDE are tested prior to the HFCD, this should be the right order of operations.

 

9 hours ago, Gary from OPA said:

But strange how it doesn't load ros right even if the card list is incorrect unless it making a change based on the fact it thinks I have a hdfc card installed but I don't really

I don't know of any code that looks for a specific peripheral to make changes.  Let's figure out the Corcomp issue first, then see about the load issue.  We might need to strip down the system to just the Horizon Ramdisk, to see if the CorComp is interfering somehow.  

[+InsaneMultitasker]

@Gary from OPA Also, does the Corcomp 512K ramdisk provide 32K in place of a standard 32K card?  I seem to recall that it does.  Do you have a standard 32K card or 32K on board the ramdisk? Just thinking about potential conflicts that would explain why you cannot load ROS properly. Need to isolate which card is causing the issue and from their, backtrack what could be the issue.

[Gary from OPA]

28 minutes ago, InsaneMultitasker said:

@Gary from OPA Also, does the Corcomp 512K ramdisk provide 32K in place of a standard 32K card?  I seem to recall that it does.  Do you have a standard 32K card or 32K on board the ramdisk? Just thinking about potential conflicts that would explain why you cannot load ROS properly. Need to isolate which card is causing the issue and from their, backtrack what could be the issue.

Good point I will dig out a normal original to made 32k card and try it with that instead of the corcomp and see. Corcomp Ramdisk is also one of those cards that also modify the TI99 startup screen. I also think there more than one version of corcomp dsr so should check to see what version I have.