Re: TK70 maintenance--fixing capstans and making them work well again
Since my last post I've gotten pretty good at getting these tape drives working and I think I see the reasons for a lot of the tape wear: Drag on the capstans. The rear one (tach) is probably the biggest problem, but on 3 of the 4 units I have here (2 TK50, 2 TK70) the bearings are not turning and as a result the capstan is dragging along the bolt at the top, tensioned by the spring on the axle. The result is a lot of drag at best, which will require the unit to apply extra tension to keep the tape moving across the capstan and encoder at a nice 75 inches per second. This translates into more wear at the head, more shedding, and more crap on the heads that people clean till the tape goes south. Also the capstans should "float" on their axles, probably to deal with slightly misaligned tapes. If you push down on the capstan and it doesn't move then it is really bound up and needs a serious cleaning. The solution is to clean out and lubricate the bearings. To do this for the front you can unbolt and remove the capstan. A hint on unbolting: Turn the bolt in a tightening direction and count the rotations before it stops at the bottom of travel. Should be a turn or two. Note this for each capstan, that way you can put the bolt back on at about the same height. Once the capstan is off, you simply wash top and bottom bearings out with 95% isopropyl to get out the old oil and gunk, let it dry, then use watch oil and a watch oiler to put about 6 small drops of oil on the inside bearing face. As the oil seeps into the bearing you will notice you can actually turn it with your oiler. The rear one is a bit more complicated: The bottom bearing holds the encoder wheel on the shaft, so unless you want to take apart the encoder (moderately difficult, I'll write that another day if anyone's interested) focus on the top bearing. Remove the bolt, put a few drops of isopropyl first to loosen up the old oil, let it dry, then put six drops of new oil from an oiler tip on the bearing. It should now turn a *lot* easier. Then assemble, clean off any excess oil, clean the tape head and guide and give it a try. I usually retract the leader before working on all of this to get it out of the way, re-hooking it is pretty simple. The result should be a unit that runs with just enough tension to spin the encoder (good) without drag on the front capstan (better) and minimal extra pressure on the tape head (best). I could probably rebuild these for people if they would want it, what would be a fair price? So far I'm happy: I am able to back up my 300gb ESDI disk on a single tape and the drives are pretty quick all things considered. RT11 backups are easy at 33mb, and I may just load all of my RL02's on tape images so I can have them around. CZ
Re: PDP-11/70 progress (and a cry for help)
Hi Josh, In the situation you describe, I guess I would first chip clip '174s for a slice of both PCA and PBC on the LA, run the troublesome instruction sequence, and look at the trace. Check that CLKPCA H and CLKPCB H are happening when and only when expected, and that all the timing there looks okay. You would also be able to see good-data-clocked-in-but-bad-data-presented on that trace, indicating more failed '174, or see any bad data arriving from the ALU upstream. I'll take a look through the flows after dinner. The "0002" might be one operand used to increment the PC, but the other operand shows up as all zeros because of a bad ALU setup? I guess I'd trace to definitively rule out PCA and PCB first, and then move backward around the chain from there verifying the ALU, ALU muxs, mux sources, etc.? --FritzM.
WTB: HP 9000-340 memory (HP 98268A), AUI (HP 98235A), SCSI (HP 98658A)
I've acquired an HP 9000-340C+ and I'd like to kit it out with the maximum RAM, SCSI, and AUI rather than thin Ethernet. Desired: - RAM boards: HP 98268A RAM board (three of them to get to 16MB, I'd probably buy extra just to be safe) - AUI LAN board: 98571-66534, aka HP 98235A AUI LAN Upgrade - SCSI board: HP 98658A SCSI Interface Card Anyone have any of this stuff that they might be interested in parting with? I'm also always on the lookout for an HP 98556A 2D/integer graphics accelerator in case anyone happens to have one that needs a home. That's the integer accelerator with a 68020 and some RAM, which piggybacks atop the 98550A (1280x1024 8-bit color card) via its extra Eurocard connector. -- Chris
Re: Deciphering an odd floppy disk format.
Thanks for the brochure. That looks like a fascinating project! Computerworld mentioned it occasionally in 1980. I love that "Pl/1 will soon emerge as the dominant language of microcomputers" If you haven't already exhausted such leads (apologies if you already have), some trivial GOOGLE'ing turned up the name (and autobiography) of a guy who designed one of their disk controllers: https://onedrive.live.com/?authkey=%21AFZhXO9UdDh2wbg&cid=5982EE6D20F4C106&id=5982EE6D20F4C106%2111901&parId=root&o=OneUp https://www.old-computers.com/museum/forum.asp?c=1286&st=1 https://philosophycentral.org/technology/ Sorry, NO technical details of the controller that he designed. On Mon, 15 Feb 2021, Mattis Lind wrote: Well. Now this is NOT a standard 179x that has written this. As I mentioned early on in this thread it was not at all possible to read the disks with a standard controller. The bit rate was off by quite a bit and the general format is different. So this is not necessarily a CRC at all. The machine that has written these is the Q1 Lite computer. A very odd mid-seventies system. http://bitsavers.trailing-edge.com/pdf/q1/Q1_Sales_Brochure.pdf.
PDP-11/70 progress (and a cry for help)
Hi all -- Thought you all might be interested in an update, and I'm also looking for advice in debugging the current issue I'm hitting. After replacing the clock crystal on the TIG, the system started showing signs of life, but the Load Address switch would stop working after being powered on for 10-30 seconds, but would work fine single-stepping via the KM11. Brought the DAP board out onto the extender for debugging and the problem went away. Reinstalled the board after cleaning the slot (again) and the problem hasn't recurred since. First bad backplane connection, I'm sure it won't be the last. After this, addresses could be loaded, data could be toggled into memory. But instructions wouldn't execute; Tracing through the microcode with the KM11 indicated that the microcode flow was aborting early and returning to the main console loop (via BRK.90) before the instruction fetch at FET.00; this was due to the TMCB BRQ TRUE H signal being stuck high. Probing of the TMC board revealed a bad 74H30 at E70, which had its output stuck at 1.65V or so, just high enough to confuse things. Now instructions would execute but the PC would contain garbage after execution of an instruction, after tracing the microcode and staring at the flow diagrams all signs pointed to the PCB register (twin to the PCA register that is used for storing PC data) having trouble. Garbage in the PC after execution was always in bits 6-11, everything else was fine, which pointed to a 74S174 at H47 on the DAP board. Replaced and now instructions execute! Mostly. They seem to execute properly when single-stepping instructions, or running off the RC clock at a clock rate of about 16-20Mhz, any faster than that and things stop working correctly. This is what I'm currently banging my head against -- if anyone has any experience with the 11/70 or wants to stare at the manuals for a bit (and who doesn't?), I'd appreciate any extra input. There are a number of different issues, I'm currently focusing on two-operand instructions that take an immediate argument (MOV #10, R0, or ADD #42, R5) for example. The behavior here is a bit befuddling and I can't quite figure out how it ends up happening, given the microcode. I'll use ADD as a representative example. An ADD #10, R0 instruction (followed by HALT) poked in at address 1000 executes properly -- R0 gets 10 -- but afterwards the PC is corrupted: it contains 2, rather than 1004. In the general case, "ADD #X, R0" ends with PC containing 2 + . (MOV shows the exact same behavior, except that there's no addition, obviously.) This value of PC is shown in the Address lights, as well as when examining the register from the front panel (at 1707). When single-instruction-stepping the processor this instruction executes perfectly: R0 gets R0+10, PC is 1004 afterwards (both in the Address lights and when examining from the front panel). I have verified with my logic analyzer that when running normally (i.e. not single-stepping) the microcode executes the proper sequence of instructions -- which is the same as executed when single-stepping except at the very end: In FLOWS 4, after the D00.90 instruction executes, a branch is taken to BRK.90, which exits back to the console loop. I don't believe there should be any other differences in execution between the two paths -- other than the branch at the end there are no conditional branches or conditional operations based on whether the CPU is single-stepping or not. There's a signal somewhere in there that has just gone a little bit slow... the trick is finding it. For reference, the microcode sequence (starting at FET.03, see pg. 5 of http://bitsavers.org/pdf/dec/pdp11/1170/MP0KB11-C0_1170engDrw_Nov75.pdf) is: 334 (FET.03) 260 (FET.10) 343 (IRD.00) 022 (S13.01) 027 (S13.10) 205 (D00.90) 260 (FET.10) 343 (IRD.00) 010 (HLT.00) 316 (HLT.10) 164 (FET.04) 240 (BRK.90) 352 (BRK.00) 170 (CON.00) You can see it fetching and executing the ADD instruction, then returning back to FET.10 and executing the next instruction, which is a HALT instruction (because all other memory contains 0 at this point). I believe this is what causes the "+2" portion of the final (incorrect) PC value. (What's extra odd -- literally -- here is that if you start with a "1" in R0, the final PC is 3... seemingly indicating a fetch/execution of an instruction at an odd address, which you'd think would cause a trap instead...) I've been staring at this awhile and I'm puzzled; everything seems to execute properly, the instruction is fetched and decoded, and the immediate value is fetched, the ALU does the right thing and the result is properly stored in R0. And then the PC gets screwed up, and I'm not quite sure how that's possible from looking at the microcode, so I'm not quite sure where to start looking. I sort of suspect the PCB register again, as this is related to the difference in behavior between single-stepping and normal execution: the branch back to the con
Re: Systems Concepts SC-4 computer
On Mon, 15 Feb 2021 12:03:47 -0500 (EST) Noel Chiappa via cctalk wrote: > > From: Lars Brinkhoff > > > Anyone ever heard of the Systems Concepts SC-4 computer? > > Given the SF address, and Peter Samson's signature, this is the _the_ Systems > Concepts. Never heard of the SC-4, though. > > One oddity: the cover letter is dated 1972, but it talks of "the main G.E. > computer". GE's computer business was sold to Honeywell in 1970, though? I contacted Peter Samson regarding a "SC-4" and this was his response: "There was an SC-40 (made after my time there) which was a fast PDP-10-compatible system. I don’t know of any SC-4 though." Cheers, Lyle -- 73 NM6Y Bickley Consulting West https://bickleywest.com "Black holes are where God is dividing by zero"
Re: Deciphering an odd floppy disk format.
Den mån 15 feb. 2021 kl 20:51 skrev Fred Cisin via cctalk <
cctalk@classiccmp.org>:
> On Mon, 15 Feb 2021, Mattis Lind via cctalk wrote:
> > My guess is that the data that follows the sector ID is some kind of
> > checksum.
>
> yes. well, sorta. 16 bit CRC
>
>
> A typical IBM/WD style format has:
>
> a gap
> Index Address Mark
> a gap (note that WD can use a shorter post index gap than NEC can)
>
> and then, repeated for each sector:
> {
> a gap
> ID Address Mark,
> C Cylinder number
> H Head number(0,1)
> R Sector number
> N Sector Length (0:128, 1:256, 2:512, 3:1024)
> 16 bit CRC of the sector header
> a gap
> Data Address Mark
> Sector data (128, 256, 512, or 1024 bytes. Larger is possible, but
> unlikely)
> 16 bit CRC of the data
> a gap
> }
>
>
Well. Now this is NOT a standard 179x that has written this. As I mentioned
early on in this thread it was not at all possible to read the disks with a
standard controller. The bit rate was off by quite a bit and the general
format is different. So this is not necessarily a CRC at all. The machine
that has written these is the Q1 Lite computer. A very odd mid-seventies
system. http://bitsavers.trailing-edge.com/pdf/q1/Q1_Sales_Brochure.pdf.
Here is an example header:
CNT: 021D5 ADDRESS MARK: 55424954 0001 01000101 01000110 0001
00V00 0V0100100 0V00
"V" is for MFM violation, most likely due to write splicing after the
header when enabling writing. This means that the header is at most 4
bytes. First bytes is track, second byte is sector. The third byte appears
to be the sum of the track and sector byte. The fourth byte is unknown. In
all the tracks it seems to have the same value.
/Mattis
> (This is from memory (error prone?). The WD1791 datasheet should have
> more detail, including CRC algorithm?, the specific requirements for the
> address marks, and gap contents (write splice, synchronization, etc.))
>
>
> --
> Grumpy Ol' Fred ci...@xenosoft.com
>
Re: Deciphering an odd floppy disk format.
On 2/15/21 11:51 AM, Fred Cisin via cctalk wrote: > (This is from memory (error prone?). The WD1791 datasheet should have > more detail, including CRC algorithm?, the specific requirements for the > address marks, and gap contents (write splice, synchronization, etc.)) The thing to note is that the mark (data or address) is almost always included in the CRC calculation. Also, some early representations could have non-powers of 2 sector lengths. (the WD1781 for example, encoded the length in multiples of 16 bytes; the Zilog MCZ used 132 byte sectors). But they are the exceptions. --Chuck
Re: Deciphering an odd floppy disk format.
On Mon, 15 Feb 2021, Mattis Lind via cctalk wrote:
My guess is that the data that follows the sector ID is some kind of
checksum.
yes. well, sorta. 16 bit CRC
A typical IBM/WD style format has:
a gap
Index Address Mark
a gap (note that WD can use a shorter post index gap than NEC can)
and then, repeated for each sector:
{
a gap
ID Address Mark,
C Cylinder number
H Head number(0,1)
R Sector number
N Sector Length (0:128, 1:256, 2:512, 3:1024)
16 bit CRC of the sector header
a gap
Data Address Mark
Sector data (128, 256, 512, or 1024 bytes. Larger is possible, but unlikely)
16 bit CRC of the data
a gap
}
(This is from memory (error prone?). The WD1791 datasheet should have
more detail, including CRC algorithm?, the specific requirements for the
address marks, and gap contents (write splice, synchronization, etc.))
--
Grumpy Ol' Fred ci...@xenosoft.com
Re: Deciphering an odd floppy disk format.
Yes, that looks very much like PL/1.
David
> On Feb 15, 2021, at 11:33 AM, Mattis Lind via cctalk
> wrote:
>
> Spent some time. Adjusted the MARK sequences to use 55424954 for address
> mark and 55424945 for data mark.
>
> That along with a stupid error in the decoder-code that I fixed now result
> in some kind of output:
>
> CNT: 003BF ADDRESS MARK: 55424954
>
> CNT: 0040F DATAMARK: 55424945 OKEY CHAR (1),
> V
>
> CNT: 006B5 ADDRESS MARK: 55424954
>
> CNT: 00705 DATAMARK: 55424945 P POINTER,
>VV V
>
> CNT: 009B7 ADDRESS MARK: 55424954
>
> CNT: 00A07 DATAMARK: 55424945 D CHAR(6) BASED(P),
>p V V O
>
> CNT: 00CA1 ADDRESS MARK: 55424954
>
> CNT: 00CF2 DATAMARK: 55424945 DATUM CHAR(6),
> 'V V
>
> CNT: 00F87 ADDRESS MARK: 55424954
>
> CNT: 00FD9 DATAMARK: 55424945 PP POINTER,
> ( V
>
> CNT: 01277 ADDRESS MARK: 55424954
>
> CNT: 012C8 DATAMARK: 55424945 1 STR BASED(PP),
> a V V
>
> CNT: 01569 ADDRESS MARK: 55424954
>
> CNT: 015BC DATAMARK: 55424945 2 X CHAR(2),
>VV$
>
> CNT: 01868 ADDRESS MARK: 55424954
>
> CNT: 018BA DATAMARK: 55424945 2 Y CHAR(2), /* 6
> = UKTO, 7 = IKSLAG*/ VV V
>
> CNT: 01B46 ADDRESS MARK: 55424954
>
> CNT: 01B99 DATAMARK: 55424945 2 FIRMA CHAR (1),
> ( V
>
> CNT: 01E34 ADDRESS MARK: 55424954
>
> CNT: 01E86 DATAMARK: 55424945 2 OP_KOD BINARY,
> V V
>
> CNT: 02120 ADDRESS MARK: 55424954
>
> CNT: 02172 DATAMARK: 55424945 2 RADANT BINARY,
>V
>
> CNT: 02415 ADDRESS MARK: 55424954
>
> CNT: 02466 DATAMARK: 55424945 T4 CHAR(4),
>V VH
>
> CNT: 02713 ADDRESS MARK: 55424954
>
> CNT: 02765 DATAMARK: 55424945 ANTAL_KONT BINARY INIT(0),
> , V VH
>
> CNT: 029FD ADDRESS MARK: 55424954
>
> CNT: 02A4D DATAMARK: 55424945 TOT_ANTAL_KONT BINARY INIT(0),
>V
>
> CNT: 02CD1 ADDRESS MARK: 55424954
>
> CNT: 02D23 DATAMARK: 55424945 VERSION CHAR(47) INIT('
> TR10KOLJA Version
> 1.1 830603');@ V
>
>
> What is the programming language? Is it PL/1?
> It seems like a record on the disk is a line!
>
>
> Den mån 15 feb. 2021 kl 18:08 skrev Mattis Lind :
>
>> I did some more research into this and found that a pattern 0x55509255 for
>> Address mark and 0x55509251 for Data mark could be used to match against
>> the incoming synchronized data stream (pre MFM decoding). These patterns
>> contain the longer flux.
>>
>> I decoded the MFM data after the address mark and both track and sector is
>> visible as what it seems to be valid bit patterns. What is interesting
>> though is that the number of sectors appear to vary among tracks. Track 0
>> had 128 address marks, while quite many had 81 sectors. Still others had 66
>> and a few had 121. I studied track 18 more in detail and there were no gaps
>> in the sector count so I guess nothing is missing. Address marks are spaced
>> over the full number of samples (around 65k per revolution).
>>
>> My guess is that the data that follows the sector ID is some kind of
>> checksum.
>>
>> I tried to understand the data field but wasn't very successful. Tried
>> backwards and forwards and with varying bit offsets for both ASCII and
>> EBCDIC. But not a single valid string. Perhaps my decoder had some fault.
>> Will do a deeper study on the data field.
>>
>> I have put some files here if anyone has some insights:
>> https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing
>>
>> Looking a bit further on the *.addressAndData files I see that it seems
>> that the marks should probably contain the first bit of the decoded data
>> that follows, since when MFM decoded data fields always starts with a 1 and
>> address fields always starts with a 0. Including these also makes sense
>> because then the Track and sector will end up on proper 8 bit boundaries.
>>
>>
>> /Mattis
>>
>> Den lör 13 feb. 2021 kl 21:51 skrev Mattis Lind :
>>
>>>
>>>
>>> Den lör 13 feb. 2021 kl 21:06 skrev Chuck Guzis :
>>>
On 2/13/21 11:15 AM, Mattis Lind wrote:
>As to
Re: Deciphering an odd floppy disk format.
Spent some time. Adjusted the MARK sequences to use 55424954 for address
mark and 55424945 for data mark.
That along with a stupid error in the decoder-code that I fixed now result
in some kind of output:
CNT: 003BF ADDRESS MARK: 55424954
CNT: 0040F DATAMARK: 55424945 OKEY CHAR (1),
V
CNT: 006B5 ADDRESS MARK: 55424954
CNT: 00705 DATAMARK: 55424945 P POINTER,
VV V
CNT: 009B7 ADDRESS MARK: 55424954
CNT: 00A07 DATAMARK: 55424945 D CHAR(6) BASED(P),
p V V O
CNT: 00CA1 ADDRESS MARK: 55424954
CNT: 00CF2 DATAMARK: 55424945 DATUM CHAR(6),
'V V
CNT: 00F87 ADDRESS MARK: 55424954
CNT: 00FD9 DATAMARK: 55424945 PP POINTER,
( V
CNT: 01277 ADDRESS MARK: 55424954
CNT: 012C8 DATAMARK: 55424945 1 STR BASED(PP),
a V V
CNT: 01569 ADDRESS MARK: 55424954
CNT: 015BC DATAMARK: 55424945 2 X CHAR(2),
VV$
CNT: 01868 ADDRESS MARK: 55424954
CNT: 018BA DATAMARK: 55424945 2 Y CHAR(2), /* 6
= UKTO, 7 = IKSLAG*/ VV V
CNT: 01B46 ADDRESS MARK: 55424954
CNT: 01B99 DATAMARK: 55424945 2 FIRMA CHAR (1),
( V
CNT: 01E34 ADDRESS MARK: 55424954
CNT: 01E86 DATAMARK: 55424945 2 OP_KOD BINARY,
V V
CNT: 02120 ADDRESS MARK: 55424954
CNT: 02172 DATAMARK: 55424945 2 RADANT BINARY,
V
CNT: 02415 ADDRESS MARK: 55424954
CNT: 02466 DATAMARK: 55424945 T4 CHAR(4),
V VH
CNT: 02713 ADDRESS MARK: 55424954
CNT: 02765 DATAMARK: 55424945 ANTAL_KONT BINARY INIT(0),
, V VH
CNT: 029FD ADDRESS MARK: 55424954
CNT: 02A4D DATAMARK: 55424945 TOT_ANTAL_KONT BINARY INIT(0),
V
CNT: 02CD1 ADDRESS MARK: 55424954
CNT: 02D23 DATAMARK: 55424945 VERSION CHAR(47) INIT('
TR10KOLJA Version
1.1 830603');@ V
What is the programming language? Is it PL/1?
It seems like a record on the disk is a line!
Den mån 15 feb. 2021 kl 18:08 skrev Mattis Lind :
> I did some more research into this and found that a pattern 0x55509255 for
> Address mark and 0x55509251 for Data mark could be used to match against
> the incoming synchronized data stream (pre MFM decoding). These patterns
> contain the longer flux.
>
> I decoded the MFM data after the address mark and both track and sector is
> visible as what it seems to be valid bit patterns. What is interesting
> though is that the number of sectors appear to vary among tracks. Track 0
> had 128 address marks, while quite many had 81 sectors. Still others had 66
> and a few had 121. I studied track 18 more in detail and there were no gaps
> in the sector count so I guess nothing is missing. Address marks are spaced
> over the full number of samples (around 65k per revolution).
>
> My guess is that the data that follows the sector ID is some kind of
> checksum.
>
> I tried to understand the data field but wasn't very successful. Tried
> backwards and forwards and with varying bit offsets for both ASCII and
> EBCDIC. But not a single valid string. Perhaps my decoder had some fault.
> Will do a deeper study on the data field.
>
> I have put some files here if anyone has some insights:
> https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing
>
> Looking a bit further on the *.addressAndData files I see that it seems
> that the marks should probably contain the first bit of the decoded data
> that follows, since when MFM decoded data fields always starts with a 1 and
> address fields always starts with a 0. Including these also makes sense
> because then the Track and sector will end up on proper 8 bit boundaries.
>
>
> /Mattis
>
> Den lör 13 feb. 2021 kl 21:51 skrev Mattis Lind :
>
>>
>>
>> Den lör 13 feb. 2021 kl 21:06 skrev Chuck Guzis :
>>
>>> On 2/13/21 11:15 AM, Mattis Lind wrote:
>>>
>>> > As to the 8x/5xH intervals, they appear to be part of the
>>> > preamble to address marks.
>>> >
>>> >
>>> > Can you please elaborate! What do you mean by 8x/5xH intervals?
>>> >
>>> > You think that these fluxes are part of some address mark or data mark,
>>> > right?
>>>
>>> By 8x/5xh I mean the intervals that you noted were 84 clocks.
Re: Systems Concepts SC-4 computer
On 2/15/21 9:03 AM, Noel Chiappa via cctalk wrote: > > From: Lars Brinkhoff > > > Anyone ever heard of the Systems Concepts SC-4 computer? > > Given the SF address, and Peter Samson's signature, this is the _the_ Systems > Concepts. Never heard of the SC-4, though. > > One oddity: the cover letter is dated 1972, but it talks of "the main G.E. > computer". GE's computer business was sold to Honeywell in 1970, though? Honeywell was still servicing old GE mainframes well into the 1970s. When a friend who worked at the plant in Phoenix invited me for a tour ca. 1974, there were still GE systems stashed here and there. --Chuck
Re: Systems Concepts SC-4 computer
> From: Lars Brinkhoff > I suppose that main computer could be the GE-645 on which Multics was > developed? And they would still refer to it as G.E. Oh, it was clearly referring to the Multics machine. I assumed that with the GE sale being 1970, by '72 it was not a GE machine anymore. But the MIT Multics site page: https://multicians.org/site-mit.html says the H-6180 was installed in November, 1972; shortly after the letter. Noel
Re: Systems Concepts SC-4 computer
On Mon, Feb 15, 2021 at 12:11 PM Lars Brinkhoff via cctalk < cctalk@classiccmp.org> wrote: > Noel Chiappa wrote: > > One oddity: the cover letter is dated 1972, but it talks of "the main > > G.E. computer". GE's computer business was sold to Honeywell in 1970, > > though? > > The letter was directed to Project MAC. I suppose that main computer > could be the GE-645 on which Multics was developed? And they would > still refer to it as G.E. > That's what I was thinking. Bill
Re: Systems Concepts SC-4 computer
Noel Chiappa wrote: > One oddity: the cover letter is dated 1972, but it talks of "the main > G.E. computer". GE's computer business was sold to Honeywell in 1970, > though? The letter was directed to Project MAC. I suppose that main computer could be the GE-645 on which Multics was developed? And they would still refer to it as G.E.
Re: Deciphering an odd floppy disk format.
I did some more research into this and found that a pattern 0x55509255 for Address mark and 0x55509251 for Data mark could be used to match against the incoming synchronized data stream (pre MFM decoding). These patterns contain the longer flux. I decoded the MFM data after the address mark and both track and sector is visible as what it seems to be valid bit patterns. What is interesting though is that the number of sectors appear to vary among tracks. Track 0 had 128 address marks, while quite many had 81 sectors. Still others had 66 and a few had 121. I studied track 18 more in detail and there were no gaps in the sector count so I guess nothing is missing. Address marks are spaced over the full number of samples (around 65k per revolution). My guess is that the data that follows the sector ID is some kind of checksum. I tried to understand the data field but wasn't very successful. Tried backwards and forwards and with varying bit offsets for both ASCII and EBCDIC. But not a single valid string. Perhaps my decoder had some fault. Will do a deeper study on the data field. I have put some files here if anyone has some insights: https://drive.google.com/drive/folders/1URC5i8AsRyP08d_ZhWRovbDp2TMgdj4B?usp=sharing Looking a bit further on the *.addressAndData files I see that it seems that the marks should probably contain the first bit of the decoded data that follows, since when MFM decoded data fields always starts with a 1 and address fields always starts with a 0. Including these also makes sense because then the Track and sector will end up on proper 8 bit boundaries. /Mattis Den lör 13 feb. 2021 kl 21:51 skrev Mattis Lind : > > > Den lör 13 feb. 2021 kl 21:06 skrev Chuck Guzis : > >> On 2/13/21 11:15 AM, Mattis Lind wrote: >> >> > As to the 8x/5xH intervals, they appear to be part of the >> > preamble to address marks. >> > >> > >> > Can you please elaborate! What do you mean by 8x/5xH intervals? >> > >> > You think that these fluxes are part of some address mark or data mark, >> > right? >> >> By 8x/5xh I mean the intervals that you noted were 84 clocks. Consider >> a part of your sample: >> >> > 3f0 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 20 1e 20 1d 20 1e | . >> . . .| >> > 0400 20 1e 20 1e 1f 1d 20 1d 20 1e 1f 1e 1f 1e 1f 1e | . ... . >> ...| >> > 0410 1f 1e 20 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e |.. >> .| >> > 0420 22 20 39 30 1f 2e 1f 1d 20 1e 20 1d 1f 1e 20 1d |" 90 . >> ... .| >> > 0430 20 1e 20 1e 20 1d 1f 1e 1f 1e 1f 1e 20 1e 1f 1e | . . >> ... ...| >> > 0440 1f 1e 1f 1e 20 1d 20 1e 1f 1e 1f 1d 20 1e 1f 1e | . >> . ...| >> > 0450 20 1d 1f 1c 54 2d 30 2e 1f 1d 1f 2f 1f 1d 1f 1d | >> ...T-0/| >> > 0460 30 40 2f 2e 1e 1c 43 1b 44 2d 1e 1e 1f 1e 1f 1e |0@ >> /...C.D-..| >> > 0470 1f 2f 31 1d 1f 1e 1f 1e 1f 1e 1f 1c 21 1e 1f 1f >> |./1.!...| >> > 0480 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1e 1f 1e >> || >> > 0490 1f 1e 1f 1f 1e 1e 1f 1e 1f 1e 1f 1e 1f 1e 1e 1f >> || >> > 04a0 1f 1e 1f 1f 1f 1d 1d 53 2d 2f 2d 1d 42 1d 2e 30 >> |...S-/-.B..0| >> > 04b0 2f 1e 1e 1f 1e 1e 30 30 1e 1e 1e 1e 1e 30 2f 1e >> |/.00.0/.| >> >> Note that the 54 at 0454 appears to be the preamble to an address mark. >> Similarly, we can see the same here: >> >> > 0740 20 1e 20 1d 20 1e 20 1e 20 1d 20 1e 20 1d 20 1d | . . . . . >> . . .| >> > 0750 1f 1e 20 1e 1e 1c 54 2c 30 2e 1f 1d 20 2f 1e 1e |.. >> ...T,0... /..| >> > 0760 1f 1d 30 40 2f 2e 1f 1d 1f 30 1e 2f 30 1d 1f 1d |..0@ >> /0./0...| >> > 0770 31 2e 1e 2f 30 1d 1f 1e 20 1e 1f 1e 1f 1f 27 1e |1../0... >> .'.| >> > 0780 30 2f 1d 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f >> |0/..| >> > 0790 1e 1f 1e 1f 1e 1f 1e 1f 1e 1f 1f 1f 1e 1f 1e 1f >> || >> > 07a0 1e 1f 1e 1f 1f 1e 1d 53 2d 2f 2e 1d 42 1c 40 42 >> |...S-/..B.@B| >> > 07b0 2e 2e 1c 43 2c 2e 41 1c 40 42 2c 2f 2f 1e 30 1e |...C,.A.@B >> ,//.0.| >> > 07c0 30 1d 30 30 2e 1d 31 1e 1e 1f 1e 31 1d 1d 43 2e >> |0.00..11..C.| >> > 07d0 1d 30 30 1e 1e 1f 1e 1e 30 30 1d 1f 1f 1e 1e 31 >> |.00.00.1| >> >> Note the 54 at 0756 at the start of what appears to be an ID address >> mark and the 53 at 07a7 at the start of what appears to be a data >> address mark. >> > > That makes sense. I tried to hand decode the section directly after 0756 > and it decoded fine as mfm. No violations. And I could see something that > could possibly be the value 5 which would then correspond to track 5. Now I > can try to write a piece of software that handles it and see if this gives > something useful. I have a directory listing so somewhere I think I could > match up what I get with that printout. > > /Mattis > > >> --Chuck >> >> >> >>
Re: Systems Concepts SC-4 computer
> From: Lars Brinkhoff > Anyone ever heard of the Systems Concepts SC-4 computer? Given the SF address, and Peter Samson's signature, this is the _the_ Systems Concepts. Never heard of the SC-4, though. One oddity: the cover letter is dated 1972, but it talks of "the main G.E. computer". GE's computer business was sold to Honeywell in 1970, though? Noel
Re: Systems Concepts SC-4 computer
Lars Brinkhoff wrote: > > Anyone ever heard of the Systems Concepts SC-4 computer? > > "This is an two's-complement 18-bit machine, with 16 general registers > and a 16 level priority interrupt system. Its programming ascpects > are explained in great detail in the SC-4 Reference Manual, of which a > draft is enclosed." > > From page 6 here: > http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF Eric Moore wrote: > http://mnembler.com/ragooman/computers_mini_products.html > You can see some info on the systems (gould SEL) concept line here, but > looking at that PDF, systems concepts was something different. Yes, something different. Systems Concepts was formed by Stewart Nelson and Mike Levitt, made some early equipment for the MIT AI lab PDP-10 computer, and later the successful SA-10 disk controller compatible with IBM disks. In the 80s they went on to make the SC-30M and SC-40 computers which where compatible with DEC's KL10. But this SC-4 computer was apparently something else.
RE: Programming in 1946 - ENIAC's Birthday
> -Original Message- > From: cctalk On Behalf Of Paul Koning via > cctalk > Sent: 15 February 2021 15:17 > To: Paul Koning ; cctalk@classiccmp.org > Subject: Re: Programming in 1946 - ENIAC's Birthday > > > > > On Feb 15, 2021, at 10:13 AM, Paul Koning via cctalk > wrote: > > > > > > > >> On Feb 15, 2021, at 7:23 AM, osi.superboard via cctalk > wrote: > >> > >> 75 years ago, February 15, 1946 > >> The ENIAC, presented to the public in 1946, is - depending on the > definition - the first programmable digital computer in the world. Its first > programmers were primarily women: so-called refrigerator ladies (seen > here: Gloria Ruth Gordon and Ester Gerston) spent hours flipping switches > and swapping cable connections - the first computer input devices - > > > > Not so much input devices as rather program storage devices. ENIAC > wasn't a stored-program machine. > > That was confusing. I meant that ENIAC wasn't a Von Neumann machine -- > the program isn't stored in its data read/write memory. > I think it corresponds more to the "Havard" architecture, but for a machine with "unlimited" memory the two architectures can be shown to be equivalent, in terms of computing capability. > paul > Dave G4UGM
Re: Systems Concepts SC-4 computer
Yes, SEL was referred to as systems, but like I said that PDF does not seem to be referring to an SEL product. Probably just a coincidence, but maybe not. -Eric On Mon, Feb 15, 2021, 9:16 AM Bill Degnan wrote: > A clue from Dan Roganti's web page or did "they" used to refer to SEL as > "Systems" back then and are you saying that the SC=4 is an SEL product? > (Systems [engineering labs] - Concept [4] ? > > Bill > > On Mon, Feb 15, 2021 at 10:08 AM Eric Moore via cctalk < > cctalk@classiccmp.org> wrote: > >> http://mnembler.com/ragooman/computers_mini_products.html >> >> You can see some info on the systems (gould SEL) concept line here, but >> looking at that PDF, systems concepts was something different. >> >> -Eric >> >> >> On Mon, Feb 15, 2021, 4:47 AM Lars Brinkhoff via cctalk < >> cctalk@classiccmp.org> wrote: >> >> > Anyone ever heard of the Systems Concepts SC-4 computer? >> > >> > "This is an two's-complement 18-bit machine, with 16 general registers >> > and a 16 level priority interrupt system. Its programming ascpects >> > are explained in great detail in the SC-4 Reference Manual, of which a >> > draft is enclosed. Below are times for some typical instructions. >> > >> > Add word on stack (not top word) to general register 1.5 us >> > Multiply general register by memory word 6.2 us >> > Jump 750 ns >> > Push and Jump 1.5 us >> > Compare Immediate 750 ns" >> > >> > From page 6 here: >> > >> > >> http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF >> > >> >
Re: Programming in 1946 - ENIAC's Birthday
> On Feb 15, 2021, at 10:13 AM, Paul Koning via cctalk > wrote: > > > >> On Feb 15, 2021, at 7:23 AM, osi.superboard via cctalk >> wrote: >> >> 75 years ago, February 15, 1946 >> The ENIAC, presented to the public in 1946, is - depending on the definition >> - the first programmable digital computer in the world. Its first >> programmers were primarily women: so-called refrigerator ladies (seen here: >> Gloria Ruth Gordon and Ester Gerston) spent hours flipping switches and >> swapping cable connections - the first computer input devices - > > Not so much input devices as rather program storage devices. ENIAC wasn't a > stored-program machine. That was confusing. I meant that ENIAC wasn't a Von Neumann machine -- the program isn't stored in its data read/write memory. paul
Re: Systems Concepts SC-4 computer
A clue from Dan Roganti's web page or did "they" used to refer to SEL as "Systems" back then and are you saying that the SC=4 is an SEL product? (Systems [engineering labs] - Concept [4] ? Bill On Mon, Feb 15, 2021 at 10:08 AM Eric Moore via cctalk < cctalk@classiccmp.org> wrote: > http://mnembler.com/ragooman/computers_mini_products.html > > You can see some info on the systems (gould SEL) concept line here, but > looking at that PDF, systems concepts was something different. > > -Eric > > > On Mon, Feb 15, 2021, 4:47 AM Lars Brinkhoff via cctalk < > cctalk@classiccmp.org> wrote: > > > Anyone ever heard of the Systems Concepts SC-4 computer? > > > > "This is an two's-complement 18-bit machine, with 16 general registers > > and a 16 level priority interrupt system. Its programming ascpects > > are explained in great detail in the SC-4 Reference Manual, of which a > > draft is enclosed. Below are times for some typical instructions. > > > > Add word on stack (not top word) to general register 1.5 us > > Multiply general register by memory word 6.2 us > > Jump 750 ns > > Push and Jump 1.5 us > > Compare Immediate 750 ns" > > > > From page 6 here: > > > > > http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF > > >
Re: Programming in 1946 - ENIAC's Birthday
> On Feb 15, 2021, at 7:23 AM, osi.superboard via cctalk > wrote: > > 75 years ago, February 15, 1946 > The ENIAC, presented to the public in 1946, is - depending on the definition > - the first programmable digital computer in the world. Its first programmers > were primarily women: so-called refrigerator ladies (seen here: Gloria Ruth > Gordon and Ester Gerston) spent hours flipping switches and swapping cable > connections - the first computer input devices - Not so much input devices as rather program storage devices. ENIAC wasn't a stored-program machine. And of course read-only program memories have a long history, going back to the Atanasoff-Berry digital computer years earlier, through the ROM of the Electrologica X1 and the Apollo Guidance Computer, to the deadstart panel toggle switch boot ROM of the CDC mainframes. paul
Re: Systems Concepts SC-4 computer
http://mnembler.com/ragooman/computers_mini_products.html You can see some info on the systems (gould SEL) concept line here, but looking at that PDF, systems concepts was something different. -Eric On Mon, Feb 15, 2021, 4:47 AM Lars Brinkhoff via cctalk < cctalk@classiccmp.org> wrote: > Anyone ever heard of the Systems Concepts SC-4 computer? > > "This is an two's-complement 18-bit machine, with 16 general registers > and a 16 level priority interrupt system. Its programming ascpects > are explained in great detail in the SC-4 Reference Manual, of which a > draft is enclosed. Below are times for some typical instructions. > > Add word on stack (not top word) to general register 1.5 us > Multiply general register by memory word 6.2 us > Jump 750 ns > Push and Jump 1.5 us > Compare Immediate 750 ns" > > From page 6 here: > > http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF >
RE: Programming in 1946 - ENIAC's Birthday
> -Original Message- > From: cctalk On Behalf Of osi.superboard > via cctalk > Sent: 15 February 2021 12:23 > To: cctalk@classiccmp.org > Subject: Programming in 1946 - ENIAC's Birthday > > 75 years ago, February 15, 1946 > The ENIAC, presented to the public in 1946, is - depending on the definition - > the first programmable digital computer in the world. Its first programmers > were primarily women: so-called refrigerator ladies (seen here: Gloria Ruth > Gordon and Ester Gerston) spent hours flipping switches and swapping cable > connections - the first computer input devices - to tell the programmable > digital computer what it has to do next. If believe that Tom Haigh, Mark Priestley, and Crispin Rope showed that in June? 1948 ENIAC ran the first "Modern" electronic computer program They used the banks of switches originally intended to store variable parameters to store the instructions so in effect the program was stored in a "prom" or "rom".. .. I would say the first "electronic programme". About a month later the "Baby" in Manchester ran a program from RAM... Once the machine was, I suppose "micro-coded" they seldom re-plugged it, but simply put the program into the switches. > > https://cdn1.vogel.de/unsafe/fit- > in/1000x0/images.vogel.de/vogelonline/bdb/1796600/1796642/original.jpg Dave G4UGM
Programming in 1946 - ENIAC's Birthday
75 years ago, February 15, 1946 The ENIAC, presented to the public in 1946, is - depending on the definition - the first programmable digital computer in the world. Its first programmers were primarily women: so-called refrigerator ladies (seen here: Gloria Ruth Gordon and Ester Gerston) spent hours flipping switches and swapping cable connections - the first computer input devices - to tell the programmable digital computer what it has to do next. https://cdn1.vogel.de/unsafe/fit-in/1000x0/images.vogel.de/vogelonline/bdb/1796600/1796642/original.jpg
Systems Concepts SC-4 computer
Anyone ever heard of the Systems Concepts SC-4 computer? "This is an two's-complement 18-bit machine, with 16 general registers and a 16 level priority interrupt system. Its programming ascpects are explained in great detail in the SC-4 Reference Manual, of which a draft is enclosed. Below are times for some typical instructions. Add word on stack (not top word) to general register 1.5 us Multiply general register by memory word 6.2 us Jump 750 ns Push and Jump 1.5 us Compare Immediate 750 ns" >From page 6 here: http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/141.graphics-system/Scan%203.PDF
