When I ran the DCIP utility and asked it to dump a sector to the console printer, the typewriter tabbed back and forth a few times, typed RRR? and then went back to its main menu. I thought it might be a problem with the 1053 itself, so during one run I turned on my mirror driver to capture what was sent by the program to the console printer. Lo and behold, it was the same junk as I was seeing physically.
 |
| DCIP run with garbage looking dump output |
I tested with my new instrumentation that would tell me:
- If I ever triggered on an XIO Control for the disk (seek)
- If I latched up the values for the seek
- The relative disk seek amount that was latched
When I requested that the DCIP program dump sector x0123 of 2310 disk drive D (my virtual drive), it did a seek to cylinder 36 and then read sector 3 of that cylinder. The contents were an exact match for the virtual sector on the PC disk cartridge file.
Sector x0123 is 256 + 32 + 3 or 291 decimal.There are eight sectors per cylinder thus the decimal cylinder number, when dividing 291 by 8, is 36.375. That is, cylinder 36 and sector 3/8 or 03. Sector numbers range from 00 to 07, with the first four on one head and the other four using the other head to read from the same cylinder, as information is recorded on both sides of the platter.
My diagnostic indicators were 0xE4 - the top two bits show that a Seek command was recognized and that the value was latched up. The remaining six bits are the seek amount. In this case, 0x24 which is 32 + 6 or . . . 36. I will change the diagnostic to drop my special bits and show me the active cylinder, not the seek amount. That would be the same value for a single sector dump, but would increment if multi sector dumps or other processing was occurring that issued more than one seek.
I planned for some other testing:
The DCIP program reads the cylinder 16 times, thus it is 128 read operations. On a real drive, even if there were a complete rotational miss on every read try, it would take a bit more than 5/100 second per read, thus I should be finishing each cylinder in way under a minute. Instead, it seems to take somewhere between 3 and 6 minutes per cylinder (I didn't time it but that is my sense of the glacial speed).
I know that my logic for cycle steal read/write can be optimized to be 2-3 times faster than it is currently. When I load and then verify the contents of core from a PC file, it uses the same process and I can see that it is kinda slow. This is definitely one factor, since the analyze function is doing a real read into memory, not a read check that skips the transfer. There is a straightforward way I can juice up the speed.
Some of this is speed of the Python program, but it is also the introduction of the async polling transactions from the 2310 code which slow things down quite a bit. I will see how I can speed up both sides a bit. On a real machine, you might have to wait 15-20 minutes to analyze a cartridge, but that is way better than waiting almost an entire 24 hour day at the current performance.
My simple fix is to use a second kind of cycle steal read/write command which reads from the current address and bumps it by one. Thus, to access a sequence of locations I would only have to set the address at the beginning with one transaction and then just write words over and over until done. Now, a transfer of a 321 word disk sector requires 642 transactions but could be just 322 with the new scheme.
I will also ponder restructuring the link between PC and fpga. Since each transaction is initiated by the PC side and is self contained, two words in and two words out, I suspect that there is a lot of overhead for the relatively few bytes of payload transferred. If I increase the size of a transaction, I amortize that although the space is wasted on the simple polling transactions. Writing or reading blocks of data from core and similar transfers would be faster.
The current process for providing results to transactions is tied to the short fixed size, which would therefore require a lot of redesign to become more generalized. I don't want to take this on until I am convinced that the predominance of the delay is in the protocol itself and not in the Python interpreter. First up, the simple change to turn 642 transactions into 321.
Looking at the DCIP code, it looks like the utility should be selecting, in order, 1403, then 1132, then 1053 for output. I imagine that the IBM simulator and my fpga are both returning something that the program misinterprets as availability of the 1403. I needed to pore over the code for DCIP to figure this out.
The utility will do a XIO Sense DSW to the 1403 and look for the low bit (Not Ready) to be on. If no answer or the bit is off, it then issues an XIO to write a line, then does another XIO Sense DSW. If the DSW is all zeroes, the 1403 is not there, otherwise it tries to check the 1132.
That test issues an XIO Sense DSW to the 1132 printer, looking for a forms check (bit 5 on) as a sign that the printer is not ready. If no answer or the bit is off, it then tries to print a line and does another XIO Sense DSW. If all bits are still off, then there is no printer there and it defaults to the console typewriter. I believe that my core load which I am using to run the utility has already set up for use of one of the printers. I will check the memory location of the switch to see what is loaded there.
When I inspected the memory locations, they were zero as they should be if no line printer is ready. Therefore, I have some problem that is causing the printout of the sector to be invalid. I need to study this more to see why I am having problems with the utility, but the disk buffer content is exactly right for every dumped sector and the analyze function was working well too. My working assumption is that I have a (slow) correctly operating virtual disk drive.
Sector x0123 is 256 + 32 + 3 or 291 decimal.There are eight sectors per cylinder thus the decimal cylinder number, when dividing 291 by 8, is 36.375. That is, cylinder 36 and sector 3/8 or 03. Sector numbers range from 00 to 07, with the first four on one head and the other four using the other head to read from the same cylinder, as information is recorded on both sides of the platter.
My diagnostic indicators were 0xE4 - the top two bits show that a Seek command was recognized and that the value was latched up. The remaining six bits are the seek amount. In this case, 0x24 which is 32 + 6 or . . . 36. I will change the diagnostic to drop my special bits and show me the active cylinder, not the seek amount. That would be the same value for a single sector dump, but would increment if multi sector dumps or other processing was occurring that issued more than one seek.
I planned for some other testing:
- Analyze of the virtual disk pack which should do IR Check for all 1600 sectors. Not sure if it tries to read cylinders 200, 201, or 202, which are the alternatives that would be used if there were a defect discovered on up to three of the cylinders in the range 0 to 199. We shall see.
- Initialize a virtual disk drive, which will test the write logic. Should write only a few sectors.
- Format a virtual disk drive, which will write all 1600 cylinders and test for errors that might warrant assigning an alternate cylinder.
- Hook up the 1132 printer and dump some sectors to the printer, since my typewriter is too flaky to type out 321 words per sector.
The DCIP program reads the cylinder 16 times, thus it is 128 read operations. On a real drive, even if there were a complete rotational miss on every read try, it would take a bit more than 5/100 second per read, thus I should be finishing each cylinder in way under a minute. Instead, it seems to take somewhere between 3 and 6 minutes per cylinder (I didn't time it but that is my sense of the glacial speed).
I know that my logic for cycle steal read/write can be optimized to be 2-3 times faster than it is currently. When I load and then verify the contents of core from a PC file, it uses the same process and I can see that it is kinda slow. This is definitely one factor, since the analyze function is doing a real read into memory, not a read check that skips the transfer. There is a straightforward way I can juice up the speed.
Some of this is speed of the Python program, but it is also the introduction of the async polling transactions from the 2310 code which slow things down quite a bit. I will see how I can speed up both sides a bit. On a real machine, you might have to wait 15-20 minutes to analyze a cartridge, but that is way better than waiting almost an entire 24 hour day at the current performance.
My simple fix is to use a second kind of cycle steal read/write command which reads from the current address and bumps it by one. Thus, to access a sequence of locations I would only have to set the address at the beginning with one transaction and then just write words over and over until done. Now, a transfer of a 321 word disk sector requires 642 transactions but could be just 322 with the new scheme.
I will also ponder restructuring the link between PC and fpga. Since each transaction is initiated by the PC side and is self contained, two words in and two words out, I suspect that there is a lot of overhead for the relatively few bytes of payload transferred. If I increase the size of a transaction, I amortize that although the space is wasted on the simple polling transactions. Writing or reading blocks of data from core and similar transfers would be faster.
The current process for providing results to transactions is tied to the short fixed size, which would therefore require a lot of redesign to become more generalized. I don't want to take this on until I am convinced that the predominance of the delay is in the protocol itself and not in the Python interpreter. First up, the simple change to turn 642 transactions into 321.
Looking at the DCIP code, it looks like the utility should be selecting, in order, 1403, then 1132, then 1053 for output. I imagine that the IBM simulator and my fpga are both returning something that the program misinterprets as availability of the 1403. I needed to pore over the code for DCIP to figure this out.
The utility will do a XIO Sense DSW to the 1403 and look for the low bit (Not Ready) to be on. If no answer or the bit is off, it then issues an XIO to write a line, then does another XIO Sense DSW. If the DSW is all zeroes, the 1403 is not there, otherwise it tries to check the 1132.
That test issues an XIO Sense DSW to the 1132 printer, looking for a forms check (bit 5 on) as a sign that the printer is not ready. If no answer or the bit is off, it then tries to print a line and does another XIO Sense DSW. If all bits are still off, then there is no printer there and it defaults to the console typewriter. I believe that my core load which I am using to run the utility has already set up for use of one of the printers. I will check the memory location of the switch to see what is loaded there.
When I inspected the memory locations, they were zero as they should be if no line printer is ready. Therefore, I have some problem that is causing the printout of the sector to be invalid. I need to study this more to see why I am having problems with the utility, but the disk buffer content is exactly right for every dumped sector and the analyze function was working well too. My working assumption is that I have a (slow) correctly operating virtual disk drive.
No comments:
Post a Comment