This old Horizon.

[+dhe]

I pulled this unit out of storage and attempted to format.

 

It behaves very oddly, one minute it's seen by cfg and the next minute it's gone.

 

I did find through trial and error - up is enabled on the switch and down is disabled.

 

To give an example, I started MEMTEST - it started fine, then the card just disappeared.

 

I was thinking pull the cards, clean edge connector, deox switch, verify voltage across terminals, but it the batteries are missing, the card should still appear when powered on?

 

Thanks for any troubleshooting tips.

 

[+Ksarul]

I seem to remember a warning in the older Horizon manuals not to power the card on without batteries. . .

[+dhe]

That's a picture from being pulled out of storage.

I purchased some new nicads from the 'zon.

I charged them with an 1989 GE Charger for 8 hours.

 

The batteries are in, guess I will pull and deox.

 

Maybe phase two is test the TTL and make sure the cru select is working?

[+dhe]

This AM, I tried again, every time I access the horizon - it is shown at >1000!

 

So, first things first, I loaded memtest via basic, with E/A in slot.

I tested both memchip U11, and the card as a Double Sided.

 

Both test passed with the following screen:

 

Finally I tried 8.14F.

   Ran CFG, no valid ROS found, Load:

         When I tried to load ROSMYRK,  I received --ERROR.

 

I then tried Tim's 8.42 - which also found the card, and said no Valid ROS found.

   Load: ROS842, again, ERROR.

 

 

Tim, since your familiar with the code. Does that mean it had an error while trying to load the ROS from the Diskette, when it tried to write the first byte, and tried to read it back?

 

FWIW - This pbox has a Myarc FDC in it.

 

[+dhe]

My theory on the Horizon going in and out completely, is that the tiny switch to shunt the card on/off - in the corner at the end of the battery pack - hadn't been messed with since it was built in ~1986 - it might not have fully snapped back immediately, and an over the night sit allowed it to return back to position.

 

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

 

And:

(L)oad ROS

The Ramdisk Operating system (ROS) must be loaded first. Specify the device and ROS file location, e.g., DSK1.ROS842C. If successful, ROS will inform you whether or not the CRC error detection value was valid or if no CRC was found. Only the distribution ROS will contain a CRC. Once loaded you may continue with the configuration.

 

^^ So .. Error, Problem Loading the ROS file from disk, or placing Image in DSR Ram?

 

Looking at the code, I did figure out the error message is at line 130 in cfg-s3.txt

 

ERR    TEXT ' Error, press any key to return to menu '

That's called from 1163 in cfg-s1.txt

BROKEN BLWP @VWTS
       DATA 920,ERR,40

Unfortunately, that's from a sparsely documented area of code:

***********************
* SETUP/EXECUTE A DSR *
***********************

 

I did learn from the code, that the ROS appear to me to be loaded from a RORG code loader directly in to the DSR Ram Area...

 

 

[+InsaneMultitasker]

On 7/6/2021 at 8:49 AM, dhe said:

Tim, since your familiar with the code. Does that mean it had an error while trying to load the ROS from the Diskette, when it tried to write the first byte, and tried to read it back?

Well, that's a pretty nondescript Microsoft-esque error message, isn't it?   You are encountering the generic message for a DSRLNK failure, which means you entered the wrong filename, the wrong device, had a bad sector, or a mismatched file type (eg, the file is DF128 not a program) to name a few possibilities.  CFG isn't getting to the point where it transfers the loaded file from VDP to the ramdisk ROS area. 

 

Check to make sure the filename you are typing is indeed the file on disk and go so far as to use a disk manager to copy the file.  Since the failure happens with both 814f and 842, I'm inclined to suspect the floppy device or the filename.

 

do you have another ramdisk that you can test to run through the same steps using the same files?

45 minutes ago, dhe said:

I did learn from the code, that the ROS appear to me to be loaded from a RORG code loader directly in to the DSR Ram Area...

some of the comments are misleading where code is re-used or multi-purpose.  ROS is loaded into VDP RAM (via the load opcode) where it is then copied into the ramdisk DSR space by CFG. 

[+dhe]

I am not going to mention, 814F again, because I think it would just serve to confuse things....

 

I found a mis-match between the software and the docs. Doc's say to load ROS842C for ALL cards. The Image I pulled down and moved as a DSK image to the GoTek USB has a Program File called ROS842CC - I like the name in the !README better, as when I read CC - I think of a CorComp version.

 

 

I also noticed TST for All Horizons, but it requires chart for results.

 

As you can see from the screen grab, Chart is not to be found in the disk image. I also didn't see chart on github.

Maybe I need to load up the infocom interpreter and try to: find chart

 

[atrax27407]

It looks like a filename mismatch. You can call ROS anything you want and it will load as long as you load it by that name. I have mine as "ROS1" and ROS2" depending on which HORIZON I am loading. I just type "DSK1.ROS1 or DSK1. ROS2". It works every time as long as the names match. 

[+dhe]

Ok. Success!

 

 

Tim,

  FWIW, and maybe you have it setup this way on purpose, the file defaults to ROS842 in CFG1, the default filename on the disk is ROS842CC, probably should be ROS842C - as discussed previously.

 

   I would recommend the following enchantment requests, if you think they are worth while, I will put them on github.

    1) A file not found error would be nice.

    2) I'd make the default filename, the filename of the default ROS on the DSK image.

 

 

[+InsaneMultitasker]

Glad to see it was an 'easy' issue.

 

Yes, please, add the error report enhancement to github; that's a simple change.   I have no idea what CHART is, I rarely if ever have used the test programs. Is the file on the 814F disk?

 

I seem to recall that similar filename issues have come up a few times, most recently with the MDOS 7.30 release. Perhaps @9640News can shed some light on what happened there as it may be related to one or more tools. Something to do with renaming the file leads to an inconsistent name in the image and/or file.  As for ROS842 vs. ROS842C, that was probably just an oversight. 

 

Check the ROS development and/or release topics as well.

 

 

[+9640News]

I would suggest using TIDIR to look at the file to see if the filename and the filename in the TIFILES header match up.  I've seen some issues renaming a file on a TIPI device resulting in a TIFILES header and the filename observed with Windows explorer not matching.

 

[+dhe]

Incidentally, one mystery solved, Gary Bowser told me that the chart for the TST Program can be found in Horizon 4000B Construction Guide.