Topics

SS80 emulation and large disks? Barfs over approx 37000h

Anders
 

Can someone, perhaps @Ansgar can shed some light on this? Take the BASIC5 Utilities 1 disk as an example. When emulating I can run it just fine as AMIGO, but with SS/80 I run into problems that seem to happen only after a certain address.

The last program on that disk is VERIFY. It s located at 037E and is 99h sectors long. When running AMIGO the host fires off a read and then interrupts after it has gotten the data. That is the way reads work in AMIGO. In CS/80 or SS/80 the read is more orderly. You set a length and then do a read. 
When doing the same as SS/80, I first see a one-sector read of 37E, then a read from 37F of 1700h bytes, clearly much shorter than the file and then I get a disk error. On my emulator I see the read going through and then the host asking for a QStat, which it gets. Nothing else?

Also: The LIF header claims the disk has 66 tracks, one head and 16 sectors. Does CS/80 use this info or does it go by what it gets from the DESCRIBE command?

Note that I can read a much larger file, located at a lower address on that disk just fine and if I force te read to do 9900h instead of 1700h then VERIFY loads just fine. This is naturally not a viable solution, so I am really interested in what is going on here?? This happens on both 200 and 300-series computers.

Anders
 

Incidentally does BAS5UTIL2 claim in its LIF header that it has one track, one head and 1056 sectors :)

The last two files on that disk are:
VME_DRIVER at 39300h and it issues a read for 31300h
VME_TEST at 3d300h and it issues a reda for 35300h

The difference in both cases are 8000h

So, something is mucking with the linear addressing and it happens somewhere after 235008 bytes 

Ansgar
 

Hi Anders,

as far as I know, the HP 9000 series 200/300 BASIC handles CS/80 and SS/80 mass storage with a single (CS80) driver. However, of course the routines within that driver can handle the protocols differently. Utilizing the disk geometry information in the LIF header is completely up to the driver, and in fact I assume that no HP software is really making use of that data. The data derived from the DESCRIBE command, however, is more reliable and usually works as the authoritative source especially for geometry information, which again is used by the driver and has not much to do with the CS/80 protocol itself.

I never had that issue you are describing with reproducible failures above a certain address with HPDrive. I also have never re-engineered the BASIC 5.0 CS/80 driver, so I'd recommend to compare what you observe on GPIB bus level against a real (non-emulator) setup and with special focus on the timings. It may happen that if a response is not fast enough, the driver gives up and terminates the read before the requested amount of data has been served. HP drivers then tend to issue a Clear command and sometimes to retry before giving up, but I don't know how the BASIC 5.0 drivers handle this.

Normally there should no by any difference between CS/80 and SS/80 on that point, but maybe two different programmers have done the code, or the programmer tested with a certain CS/80 device, saw that it didn't work and relaxed the timings for CS/80 but not for SS/80, what do we know? HP did test the drivers roughly with the existing hardware, and if it worked they got released. There obviously were no special specs that had to be enforced, at least not regarding the timing.

You also may check whether you get the same problems with HPDrive, and compare to the HPDrive logs.

-Ansgar

Anders
 

Thanks!! Yes, I think that I have a NI ISA card that I could set up with HPDive and compare. That would give me a baseline where I could compare against the exact same image file. I could then either use my old HP1632D analyser or set up one of my own GPIB Cards as a sniffer to get the actual traffic.

I am leaning towards something being wrong with how I answer to DESCRIBE and not a timeout error. That is because when I look at the actual read of a file that happens to start before the magic limit, the starting address of that read is corrrect, but the length given (looking at the actual bytes passed)  is wrong. If I patch the code, looking for that incorrect length and instead to a read of the correct length, then all is fine and the file loads.

Had it been a timing issue, then I would have seen the HP 340 issue a read of the correct length and then stopping midway.

So, my assumption at this point is that something in my replies throws off the 340 and puts a cap on where it thinks it can read, but I assume that a compare to what HPDrive does.

Ansgar
 

I always assume the cause of a failure in anybody's code as the last possible option ;-)

You might also counter check with known DESCRIBE responses from the peripheral manuals or with what "hpdir -info" returns on a connected drive.

-Ansgar

Stephen Hanselman
 

Hmmmm, we were always told the difference between Command Set 80(CS80) and Sub-Set 80 (SS80) was that SS80 only had a subset of the full CS80 implementation. For example 9153, 9133, etc. did not need the ability to do diagnostics, format, or report status as the larger CS80 drives did.  

To my knowledge drive geometry really didn’t enter into the mix with respect to the driver.  It only had to know what the maximum block address was and  past that it really didn’t care. Everything else data formatting, conversion to CHS addressing was the responsibility of the drive.  The drives were so intelligent that when we were running diagnostics, etc. on large drives we would tell the drive what we wanted to do, unplug the HP85 move to the next drive and repeat while the diagnostic was still running. When they finished you just went down the line again to read the status back from the drive. K 

Regards,

 

Stephen Hanselman

Datagate Systems, LLC




On May 18, 2020, at 05:25, Ansgar <ansgar@...> wrote:

Hi Anders,

as far as I know, the HP 9000 series 200/300 BASIC handles CS/80 and SS/80 mass storage with a single (CS80) driver. However, of course the routines within that driver can handle the protocols differently. Utilizing the disk geometry information in the LIF header is completely up to the driver, and in fact I assume that no HP software is really making use of that data. The data derived from the DESCRIBE command, however, is more reliable and usually works as the authoritative source especially for geometry information, which again is used by the driver and has not much to do with the CS/80 protocol itself.

I never had that issue you are describing with reproducible failures above a certain address with HPDrive. I also have never re-engineered the BASIC 5.0 CS/80 driver, so I'd recommend to compare what you observe on GPIB bus level against a real (non-emulator) setup and with special focus on the timings. It may happen that if a response is not fast enough, the driver gives up and terminates the read before the requested amount of data has been served. HP drivers then tend to issue a Clear command and sometimes to retry before giving up, but I don't know how the BASIC 5.0 drivers handle this.

Normally there should no by any difference between CS/80 and SS/80 on that point, but maybe two different programmers have done the code, or the programmer tested with a certain CS/80 device, saw that it didn't work and relaxed the timings for CS/80 but not for SS/80, what do we know? HP did test the drivers roughly with the existing hardware, and if it worked they got released. There obviously were no special specs that had to be enforced, at least not regarding the timing.

You also may check whether you get the same problems with HPDrive, and compare to the HPDrive logs.

-Ansgar

Anders
 

On Mon, May 18, 2020 at 05:09 PM, Ansgar wrote:
You might also counter check with known DESCRIBE responses from the peripheral manuals or with what "hpdir -info" returns on a connected drive.
Thanks for the tip! I happened to have a NI TNT488 PCI card that I installed in an old XP PC that I have kept to be able to run the IMD disk utilities against physical floppies. I have not played with HPDrive before, just read the docs, many times :) Wow is it fast! Compared :) But then again do I do everything in software and there is a penalty for doing that. Your log is also very thorough. I have run a test boot of HP5SYS.HPI on both and will now compare traces.

Anders
 

OK. Your describe was diferent from mine. You had the max track/head/sector which to the best of my knowledge is optional, but that was not the issue. What bugged me was that I definitely remebered running largish images in the past.  I had to add one small change to the code to accomodate the 340 and that change broke it... Hang on! This will be interesting:

 - AMIGO identify
Amigo Clear - CS80-AMIGO CLEAR:
9F5F SS80:Rpt QSTAT 0 [5F 1][3F 1] - CS80-REPORTING
 - AMIGO identify
D1E2 SS80:Ch ind Clear 8 - CS80-CHANNEL INDEPENDENT CLEAR: unit=0
D214 SS80:Rpt QSTAT 0 - 19:53:06-506:511 Trace: CS80-REPORTING
32C9 SS80:NOP [3E 0][ 0 0][ 0 0][ 0 0][ 0 0][ 0 0][ 0 0][1F 0][7F 0] - 19:53:06-522:612 Trace: CS80-COMMAND: 34 3E 00 00 00 00 00 00 1F FF (10) [nop][status mask=0000000000001FFF]
5F59 SS80:Rpt QSTAT 0 - 19:53:06-537:767 Trace: CS80-REPORTING
2B57 SS80:Set unit 0 - 19:53:06-553:680 Trace: CS80-COMMAND: 20 35 (2) [unit=0]
C409 SS80:Describe
7AF5 SS80x:Describe 
Describe B34 32

 80 01 02 E8 05 00 09 13 40 01 00 01 00 01 F6 00 | €..è....@.....ö.
 8C 11 94 11 94 1F 01 00 00 03 D0 04 00 31 00 00 | Œ.”.”.....Ð..1..
 00 02 62 A0 07 00 00 00 00 00 00 00 00 00 00 00 | ..b ............
 00 00 00 | ...

19:53:06-569:034 Trace: CS80-EXECUTION: 
19:53:06-569:209 Debug: GPIB send data: 
 80 01 02 E8 05 01 09 12 20 01 00 01 00 17 00 00 
 2D 11 94 20 D0 0F 00 01 00 00 4F 01 00 0F 00 00 
 00 00 09 FF 00 (37)
19:53:06-570:247 Trace: <-- <37 data bytes sent>

Now I have to be economical when logging so I just have a small counter for timing also I had put a dump of 50d bytes after the describe. My data is different, but I had inadvertently specified a 9134L drive, but that was not the issue, instead look at the command to set the error mask:

HPDrive: 00 00 00 00 00 00 1F FF
HPDisk: 00 00 00 00 00 00 1F 7F

Then it dawned on me! The 340 does HPIB partity something no unit I have encountered in the past have done, but I had accomodated that in the parser and masked all commands before decoding, but the actual IDENT is done outside for speed reasons. When I got the 340 it failed the IDENT as it blindly looked at what the bytes would be without parity, so I masked, but then did I send on the masked byte to the parser... That certainly explains why I would see errors by 80h 8000h 800000h pop up!

Ansgar
 

Yes, the "flat" record numbering scheme was a big improvement, comparable to LBA (logical block) addressing in the PC area, replacing the old drive dependent CHS addressing.

However, file systems normally tend to align themselves to track boundaries, so that kind of information may become relevant again when working on file system level.

Anyway, back to CS/80 vs. SS/80 there are more differences than being just a subset of the other. There are special rules for the two flavors, which have to be applied. For instance, the complementary commands in read/write commands need to match certain rules which are different. In general, SS/80 has more restrictions on the protocol side in order to simplify writing rudimentary drivers in smaller (and therefore cheaper) firmware ROM packages, but also tolerates some not implemented CS/80 commands as NOPs and so on...

-Ansgar