Horizon Ram Disk

[+InsaneMultitasker]

Speed is probably a HRD's greatest/best attribute.

Edited September 13, 2018 by InsaneMultitasker

[+InsaneMultitasker]

I am going to have to do a bit more research on this as I am getting some odd behavior. There may be a cabling issue in play as I have had the PEBox open and tried to pull one floppy out of the system so I could put the DREM in the bay besided the other floppy.

 

Between adding the TIPI, a HRD, and then the DREM, there has been a lot going on with that system.

 

Beery

I wonder if the MENU and MDM5 are starting their CRU scans at different bases. Perhaps MDM5 is getting confused by the presence of more than one DSKx in the system. Did you try accessing the floppy drives as 5-8 on the off-chance MDM5 bumped the assignments?

[+9640News]

It wasn't MDM5 bumping the assignments. I was trying to load MDM5 and DSK1 would spin sometimes, but nothing would load. I pulled the TIPI and the HRD, and not until later when I started to move the DREM into one of the drive bays, did DSK1 go from working sometimes, to no tworking. I've probably got a cable issue, but have not chased it down yet as I am waiting on 3.5" enclosures to come in as I moved the other unit over to the Geneve.

 

Beery

[apersson850]

You have made similar statements in other topics. Incompatibility with the p-code card does not mean the ROS is the problem.

 

Can you share more specifics about these tricks and shortcuts, and the specification failings?

I did investigate why it failed. Then I made my own DSR to make sure I was right, and then the card worked wth the p-code card. So it's the ROS, for sure.

The ROS is taking advantage of knowing how the DSRLNK that calls it works. The ROS is getting some information from a memory location, where it knows the DSRLNK has left data the ROS thus can find in a quicker way.

This works fine as long as it's the normal operating system making the calls. But when you use the p-code card, it has it's own DSRLNK routine. It works a bit differently, but that doesn't matter, as long as you get the information you want via the PAB. However, when you peek into locations used by the console's standard DSRLNK routine, you'll not find relevant data there, when the call comes from the p-code card's DSRLNK. It uses memory differently.

 

Now I'm not at home, so I can't check exactly what the issue was. But in older versions of the ROS, it was different. There the DSR on the card did some more work to find out this data the way TI intended.

 

Without being able to check, I'm not 100% sure, but I do think it had to do with figuring out which subprogram call was active. The p-code card only use the sector read/write, and I have a feeling it was retrieving the opcode for that subprogram that failed. But I'm not really sure about that.

[+InsaneMultitasker]

I would be interested in knowing which data locations cause the issue. There are certain scratchpad RAM addresses, used by DSRLNK, that are reserved for specific purposes. Without more intel it is hard to know what in ROS is causing this problem, or if it is something that can/should be looked into more closely. The subprogram should be available via the "PAB" for any sector IO calls, but maybe there is a shortcut taken that creates a rare issue. Hard to say.

[RickyDean]

I just got one of my Horizon 3000 series ramdisk, functioning. I plugged it in the other day for the 1st time in over 18 years and it immediately blew a capacitor. When it did that it also took out a trace so I had to run a wire. Found the disk image, recently placed in this forum, of HRD814F, I believe, and tested the ramdisk, no issues. Now I have at least 1 of 5 Horizons working. Awesome.

[apersson850]

I would be interested in knowing which data locations cause the issue. There are certain scratchpad RAM addresses, used by DSRLNK, that are reserved for specific purposes. Without more intel it is hard to know what in ROS is causing this problem, or if it is something that can/should be looked into more closely. The subprogram should be available via the "PAB" for any sector IO calls, but maybe there is a shortcut taken that creates a rare issue. Hard to say.

I'll check it again when I get home, in a couple of days. I'm in the US right now.

 

The p-system does DSR calls on two levels. First, it has a preparational level, during startup. The p-system has a number of pre-defined I/O units, and only uses these. So if you have a printer connected via the PIO port, you make an association between the system's unit PRINTER: and make that look for PIO. If you also use a serial port for some other communication, you associate the REMIN: and REMOUT: (remote input and output) units with RS232.BA=9600.DA=8.

After that, you do all calls via the PRINTER: and REMOTE: ports. If you want to access another serial port, you re-configure the REMOTE: unit to something else.

 

This means there's a finite number of communication ports in the system. There are also blocked devices, physically represented by the floppy disks. They don't have pre-defined names, but get the name of the mounted disks. But they have pre-defined access methods.

 

Knowing this, the system does a pre-scan of all required I/O units at boot time. It will run a dummy DSRLNK to locate the actual DSR to run, when accessing a disk for a read operation or the PRINTER: port for an output operation. Then it stores the appropriate CRU base address, as well as the entry address of the correct operation to call, in memory.

 

When the disk, or printer, is actually used, once the system has completed booting and is in the user's hand, it will neither scan all CRU base addresses, nor traverse call tables to find the correct entry address. It will simply turn on the CRU address it already knows about and then branch to the address already determined. This is of course more efficient, but it also means that there are no pointers into call tables or anything like that in scratch pad RAM, left by DSRLNK. The values determined at boot time are stored in tables in the 8 K RAM memory.

 

Thus a DSR program assuming that a calling DSRLNK is leaving certain values at certain places somewhere in memory, as the later ROS (perhaps all version 8 editions?) do, fails. I had some much older ROS, with less functionality. That worked, because it was less clever in optimizing operation based on peeking into values left by the normal DSRLNK routine.

 

But I'll give the specific data when I'm in reach of the machine again.

Edited September 26, 2018 by apersson850

[apersson850]

Now I've refreshed my memory. I'm looking in the code with this version comment: VERSION 9938/RAMBO/HORIZON 8.14 SOURCE

 

The problem is in the routine labeled TEST. It uses this sequence to figure out which subprogram to call.

TEST   LWPI HIWS              Load our workspace
       MOV  @SRHADR,R1        Get pointer to CALL table
       MOV  @6(R1),R11        Get address of CALL program

But this assumes that the calling DSRLNK is doing its work of figuring out the call address of the subprogram it's looking for in such a way that the address ends up at SRHADR+6. Hence TEST can be a common routine for all subprograms, instead of having separate such routines for each subprogram. The data structure looks like this in the DSR.

***********************
* Low level DSR table * #5
***********************
NEXT0  DATA NEXT1,TEST,>0110,SECIO      Sector Input/Output
NEXT1  DATA NEXT2,TEST,>0111,FORMAT     Format a Diskette
NEXT2  DATA NEXT3,TEST,>0112,PROTCT     Modify File Protection
NEXT3  DATA NEXT4,TEST,>0113,RENAME     Rename a File
NEXT4  DATA NEXT5,TEST,>0114,INPUT      Direct File Input
NEXT5  DATA USRDSR,TEST,>0115,OUTPUT    Direct File Output

Here all subprogram calls are directed to TEST, which uses the clever trick of looking into the DSRLNK's internal data to find out which subprogram is actually called.

 

The DSR specifications from TI I've seen instead shows this list holding the different transfer addresses for the different functions in the list already in this data structure. Under that assumption, the p-code card performs DSR calls as a two-stage operation.

During startup, the p-system will call every single DSR it will ever need. It does this to find and store the jump address to the different functions it wants to call from the table above. Then, when a DSR is called to do something useful, it already knows the address and can save time jumping right into it. But that does of course imply that when the DSR is called to do some work, like reading/writing a sector in this case, it will not scan through the DSR's call tables, so the address of the subprogram it searches will not be at SRHADR+6. Obviously, when TEST is then executing, it will branch to any location except where it should. Even the first time, when it's establishing it's call table for all DSR services, it doesn't execute a DSRLNK using the same memory locations as the one normally used by the standard operating system. At that time it doesn't matter, since at that time it doesn't actually call the DSR, only retreive the address to it.

 

Summary: Since the ROS doesn't store the separate addresses of the subprograms in the table above accoring to how TI specifies it, it fails when called from a differently designed DSRLNK than the one the normal operating system uses.

 

The main reason for doing DSRLNK in a completely different way, with a different memory usage, is that the p-system is built around a PME. This p-machine emulator is executing p-code, generated by the complier, by interpretation. For speed reasons, the inner interpreter occupies a large part of scratch pad RAM, followed by the p-system's main workspace. Hence more than half of scratch pad RAM is used for completely different tasks than the normal ones. A lot of things are done in different ways than normally, due to this very different memory map.

Edited November 14, 2018 by apersson850

[+InsaneMultitasker]

Now I've refreshed my memory. I'm looking in the code with this version comment: VERSION 9938/RAMBO/HORIZON 8.14 SOURCE

 

The problem is in the routine labeled TEST. It uses this sequence to figure out which subprogram to call.

TEST   LWPI HIWS              Load our workspace
       MOV  @SRHADR,R1        Get pointer to CALL table
       MOV  @6(R1),R11        Get address of CALL program

But this assumes that the calling DSRLNK is doing its work of figuring out the call address of the subprogram it's looking for in such a way that the address ends up at SRHADR+6. Hence TEST can be a common routine for all subprograms, instead of having separate such routines for each subprogram. The data structure looks like this in the DSR.

***********************
* Low level DSR table * #5
***********************
NEXT0  DATA NEXT1,TEST,>0110,SECIO      Sector Input/Output
NEXT1  DATA NEXT2,TEST,>0111,FORMAT     Format a Diskette
NEXT2  DATA NEXT3,TEST,>0112,PROTCT     Modify File Protection
NEXT3  DATA NEXT4,TEST,>0113,RENAME     Rename a File
NEXT4  DATA NEXT5,TEST,>0114,INPUT      Direct File Input
NEXT5  DATA USRDSR,TEST,>0115,OUTPUT    Direct File Output

Here all subprogram calls are directed to TEST, which uses the clever trick of looking into the DSRLNK's internal data to find out which subprogram is actually called.

 

The DSR specifications from TI I've seen instead shows this list holding the different transfer addresses for the different functions in the list already in this data structure. Under that assumption, the p-code card performs DSR calls as a two-stage operation.

During startup, the p-system will call every single DSR it will ever need. It does this to find and store the jump address to the different functions it wants to call from the table above. Then, when a DSR is called to do something useful, it already knows the address and can save time jumping right into it. But that does of course imply that when the DSR is called to do some work, like reading/writing a sector in this case, it will not scan through the DSR's call tables, so the address of the subprogram it searches will not be at SRHADR+6. Obviously, when TEST is then executing, it will branch to any location except where it should. Even the first time, when it's establishing it's call table for all DSR services, it doesn't execute a DSRLNK using the same memory locations as the one normally used by the standard operating system. At that time it doesn't matter, since at that time it doesn't actually call the DSR, only retreive the address to it.

 

Summary: Since the ROS doesn't store the separate addresses of the subprograms in the table above accoring to how TI specifies it, it fails when called from a differently designed DSRLNK than the one the normal operating system uses.

 

The main reason for doing DSRLNK in a completely different way, with a different memory usage, is that the p-system is built around a PME. This p-machine emulator is executing p-code, generated by the complier, by interpretation. For speed reasons, the inner interpreter occupies a large part of scratch pad RAM, followed by the p-system's main workspace. Hence more than half of scratch pad RAM is used for completely different tasks than the normal ones. A lot of things are done in different ways than normally, due to this very different memory map.

hmm, I think your code is making an assumption that was not intended under most scenarios. There is no requirement that the vectors must have a one to one correspondence with specific devices or routines. ROS works well with nearly all DSRLNK-based programs, so I would consider the pcode an outlier here.

 

That said, when I next dig into ROS I'll take this into account and if there is a simple way to revert the subprograms list to a more common structure, I will consider making the changes. Of course,that will depend on what else is before (or after) the test routine and whether there is sufficient space left in the DSR space.

[apersson850]

I haven't re-read TI's DSR specifications right now, but I do remember them giving the outline of how the address table should be implemented, even if they don't explicitly states that you aren't allowed to do it differently. What I'm certain about is that they do not specify anything about how the program calling the DSR should be implemented. And for a good reason, since they themselves have obviously implemented different approaches in different operating systems.

 

I think the term different operating systems is the key. Most TI programmers aren't used to that concept, as virtually everything else runs via the normal operating system. It's the p-code card, the Geneve and the CP/M card that are obvious exceptions to this rule. But they are all getting almost as rare as hen's teeth (the CP/M card is probably even more rare than that), so very few people encounter them.

 

Figuring out whom to blame is a secondary issue. No law suits will be filed here. But now at least you know what the culprit is. I've verified that by modifying the DSR to have the common table structure. Then it works with the p-system. But my modification isn't general. The p-system uses only the sector read/write procedure in a RAM disk card, as it has its own file handling system. hence I could remove other stuff in the ROS, as it's not needed when using the p-system. So my modification can't be used in all environments.

The p-system by itself doesn't allow formatting a disk. It does support zeroing of a disk, but that is the process of creating an empty disk catalog on a disk that's already formatted. To overcome this, there's a separate utility called dformat, which is used to do the original formatting. In a physical disk controller, I'd assume the separate dformat utility accesses the disk format subprogram. But you can just as well use the Disk Manager 2, or any other program capable of formatting a disk, to do the formatting, outside the p-system. Then, from within the p-system, you give the Zero command and get a disk that's ready for use by the p-system.

I don't know for sure how dformat handles this, as the source code for the dformat program isn't provided. It also has the limit that it can't format double density disks, so I've written my own dformat for my p-system. But my dformat takes advantage of the fact that the p-system's file handling is quicker than the normal operating system's routine, so if it detects 2793 disk controller (CorComp) instead of a 1771 (TI), it will modify the double density sector interlacing to a scheme which improves disk access performance for the p-system. But it makes the normal file handling slower, as it can't keep up with this interlacing. Hence I only use that option with double density disks intended for p-system use. To make this possible, my disk formatter bypasses the disk format subprogram on the controller card. It accesses the disk controller directly instead.

Edited November 15, 2018 by apersson850

[+InsaneMultitasker]

Blame was certainly not on my mind nor was it the intent of my response. I certainly understand what you are seeing and it may interest you (and others) to know that that Geneve's master DSR handles calls in a similar fashion, with all devices responding to the same CRU address. The dsr itself parses the devices and figures out where to go based on name, device number, etc. The RAMdisk (in a Geneve system) doesn't even require a DSR, only a stub in memory to indicate there is a ramdisk present. Thus some "smart" programs that try to manage devices get tripped up. Like I said, if it is feasible and possible to change, I have no issue doing so. I'm just not in a position to do that (at the moment).

Edited November 15, 2018 by InsaneMultitasker

[jstimson]

Hey all. My TI was packed up for a long while as I was redoing my man-cave. During that period my HRD batteries lost their charge and now I'm about to reset my system.

 

I have been using 8.15f (I believe) and have the disk for that. But since I'm starting from scratch, are there newer versions I should be using?

 

I think I saw mention of a menu system that will take advantage of the f18a?

 

Thanks in advance.

[Shift838]

Hey all. My TI was packed up for a long while as I was redoing my man-cave. During that period my HRD batteries lost their charge and now I'm about to reset my system.

 

I have been using 8.15f (I believe) and have the disk for that. But since I'm starting from scratch, are there newer versions I should be using?

 

I think I saw mention of a menu system that will take advantage of the f18a?

 

Thanks in advance.

 

8.14F I believe is probably the most stable version that as commercially released. There is a 9640 menu system that has been recoded to work with the TI-99/4A and F18A video upgrade.

 

It's HERE

[Opry99er]

I use ROS834 and CFG834

 

Many updates and changes by the Insane one.

[GDMike]

Anyone want to take a stab at rebuilding my HRD+. I have only gotten it to power the board before the docs I was using stopped making sense to me and the things the instructions were wanting me to do also we're out of timing. So I'm dead in the water. Either until I get good step-step, or someone that knows these can guide me.. but I think it's probably best to just let someone rebuild it. thanks all.