Re: 9 track tapes and block sizes
On Fri, Oct 2, 2020, 9:37 PM Chuck Guzis wrote: > On 10/2/20 8:08 PM, Warner Losh wrote: > > > > > > On Fri, Oct 2, 2020, 8:38 PM Chuck Guzis via cctech > > mailto:cct...@classiccmp.org>> wrote: > > > > In fact, is there any standard for floppy disk metadata container > files? > > > > I'm not aware of any. > > > > > > Teledisk? > > > > > Heh, but no--there's no way to include a photo and other supporting > metadata--just a few lines of commentary. > Oh, that kind of meta data. Derp.i was thinking track, sector number, head info... Warner >
Re: 9 track tapes and block sizes
On 10/2/20 8:08 PM, Warner Losh wrote: > > > On Fri, Oct 2, 2020, 8:38 PM Chuck Guzis via cctech > mailto:cct...@classiccmp.org>> wrote: > > In fact, is there any standard for floppy disk metadata container files? > > I'm not aware of any. > > > Teledisk? > Heh, but no--there's no way to include a photo and other supporting metadata--just a few lines of commentary. --Chuck
Re: PSA to SparcBook 2 Users
Yea I received a Sparcbook 2 and saw this damage knock some SMD components off the entire OTHER SIDE of the board from the leaky cap. Got it going again with cleaning and repair work though. I had a SB3 fail in its power supply module due to shorted tantrums on the output side of the supply which cooked the coil and switching driver chip. Luckily most of these components were available from digikey at the time and I rebuilt that entire supply rail and the system came up OK. -Connor K On 9/22/2020 14:45, null via cctalk wrote: No, this applies only to Tadpole Series 2 and potentially Series 1 machines (although I have not observed the latter) Series 3(/3000) are completely different internally. Your SB3000 is safe- at least from this failure mode. On Sep 22, 2020, at 11:02, Alan Perry via cctalk wrote: You flush electronics with Indian Pale Ale? Too many TLAs. This isn't a problem on the model of SparcBook you sold me, is it? On 9/22/20 10:53 AM, Ian Finder via cctalk wrote: There is a 1000uf 10v cap on the main logic board just above the Bt display controller. It is leaking... a lot. (4/4 samples so far) Go replace it, flush the area and scrub the with 99.9% IPA.
Re: 9 track tapes and block sizes
On 10/2/20 1:42 PM, Eric Smith wrote: > On Fri, Oct 2, 2020 at 1:27 PM Chuck Guzis via cctalk > mailto:cctalk@classiccmp.org>> wrote: > > Actually, they're neither. I append the metadata after the EOI marker > on mine. Doesn't seem to bother the emulators. > > > Some programs (but probably very few) that use various so-called .tap > files assume that they can seek to the EOF (of the container file) and > read records backwards (supported by lengths being at both ends of > blocks in the container). Tacking metadata on the end breaks that. I'm > not criticizing, mind you. It's just something that people may need to > be aware of. Metadata records tacked on after the EOI marker are appended with the appropriate preamble-postamble length indicators, so this doesn't break the scheme (much). --Chuck
Re: 9 track tapes and block sizes
On 10/2/20 1:42 PM, Eric Smith via cctalk wrote: Of course, that scheme breaks programs that use tape images but don't expect enormous or "negative" record lengths. Those would already be broken with Bob's use of large negative numbers for physical end of tape and 'bad block is here' (you don't get to know how big that bad block was, so that is hell with tapes with variable-length records, grumble..) But for all the people who get clean reads off their tapes, none of this is an issue. I wish I was so lucky.
Re: 9 track tapes and block sizes
On Fri, Oct 2, 2020 at 1:27 PM Chuck Guzis via cctalk wrote: > Actually, they're neither. I append the metadata after the EOI marker > on mine. Doesn't seem to bother the emulators. > Some programs (but probably very few) that use various so-called .tap files assume that they can seek to the EOF (of the container file) and read records backwards (supported by lengths being at both ends of blocks in the container). Tacking metadata on the end breaks that. I'm not criticizing, mind you. It's just something that people may need to be aware of. The .tap file formats are horrible. Originally there was at least the virtue of simplicity, but because they've diverged we don't even have that. Al wrote: > Bordynuik's at least had some provisions for reporting a bad block, > as I'm sure yours does. > Aeons ago when I was doing stuff with tape images, I made a proposal for representing bad blocks of either known or unknown length. I don't know whether anything other than some of my own unpublished code adopted that particular proposal. IIRC, I proposed using a record length of 0x to designate any kind of "metadata" record, with the real length of the metadata record in the next word in on both ends (to still support backwards reading), and the third word at the beginning only being a tag of what kind of metadata it was, etc. Of course, that scheme breaks programs that use tape images but don't expect enormous or "negative" record lengths. I contributed to the morass by still calling my files .tap files.
Re: 9 track tapes and block sizes
On 10/2/20 12:26 PM, Chuck Guzis via cctalk wrote: This is basically the problem with all of the container file formats that I've seen. They seem to think that the data alone is sufficient to describe an object. Quite often, a simple paper label is more informative than a bunch of bits the joys of tacking bags onto legacy container formats .tpc begat Wilson .tap which begat Supnik .tap and Bordynuik .tap none of which can be identified without heuristics during reading Bordynuik's at least had some provisions for reporting a bad block, as I'm sure yours does.
Re: 9 track tapes and block sizes
On 10/2/20 11:51 AM, Paul Koning wrote: > > >> On Oct 2, 2020, at 1:46 PM, Chuck Guzis via cctalk >> wrote: >> >> On 10/1/20 11:40 PM, Warner Losh via cctalk wrote: >>> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk >>> wrote: >>> I have never figured out why Bob Supnik defined the magnetic tape containers (TAP files) with the one byte padding for odd length records. This seems very odd (pun intended). :-) Even on a machine which couldn't write 32 bit numbers (the record lenght) on odd boundaries you could write the 32 bit number as 4 individual bytes. Does anyone know the reason? >> >> On the .TAP files that I provide to customers, I ignore the 16-bit >> granularity and supply odd-length records as appropriate. > > You can certainly create tape container files like that, but those are not > TAP format. Instead, they are E11 format. You should call them by their > proper name. Actually, they're neither. I append the metadata after the EOI marker on mine. Doesn't seem to bother the emulators. This is basically the problem with all of the container file formats that I've seen. They seem to think that the data alone is sufficient to describe an object. Quite often, a simple paper label is more informative than a bunch of bits--indeed, it may represent the Rosetta Stone when it comes down to figuring out what's what. Even the diagnostic options are very weak. For example, on many platforms, it's possible to identify which (vertical) frames contain parity or other errors. There's no option for reporting this level of detail in any of the container files that I've seen. I append a log of the reading process as part of the metadata. Similarly, I've handled tapes where the density changes between files. Where to report this? Most container files don't even make a provision for reporting parity (NRZI tapes). On 7 track, the encoding schemes between even and odd parity can be quite different. --Chuck
Re: Old Terminals
On Oct 2, 2020, at 12:01 PM, John Many Jars via cctalk wrote: > > I've always had a weakness for terminals. > > I have a question, are all those RJ-11 style keyboards interchangeable? No, virtually every manufacturer had its own signaling and protocols, and in a lot of cases individual *models* have their own signaling and protocols. You can probably find help fixing your ICL M8 here, it should be repairable. — Chris
Old Terminals
I've always had a weakness for terminals. I have a question, are all those RJ-11 style keyboards interchangeable? I have an ICL M8 with a bad key... it's only the scroll lock... but still. There is so little information about these things that I've been able to find...
Re: 9 track tapes and block sizes
> On Oct 2, 2020, at 1:46 PM, Chuck Guzis via cctalk > wrote: > > On 10/1/20 11:40 PM, Warner Losh via cctalk wrote: >> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk >> wrote: >> >>> I have never figured out why Bob Supnik defined the magnetic tape >>> containers (TAP files) with the one byte padding for odd length records. >>> This seems very odd (pun intended). :-) >>> Even on a machine which couldn't write 32 bit numbers (the record lenght) >>> on odd boundaries you could write the 32 bit number as 4 individual bytes. >>> Does anyone know the reason? > > On the .TAP files that I provide to customers, I ignore the 16-bit > granularity and supply odd-length records as appropriate. You can certainly create tape container files like that, but those are not TAP format. Instead, they are E11 format. You should call them by their proper name. paul
Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
On Fri, 2 Oct 2020 at 19:20, Noel Chiappa via cctalk wrote: > > (For those are are not familiar with Mini-Unix and LSX, they are both V6 Unix > variants lobotomized to run on PDP-11's without memory management: Aha! Like this? https://hackaday.com/2018/06/03/its-unix-on-a-microcontroller/ http://www.jcwolfram.de/projekte/mxe11_en/main.php -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: 9 track tapes and block sizes
On 10/1/20 11:40 PM, Warner Losh via cctalk wrote: > On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk > wrote: > >> I have never figured out why Bob Supnik defined the magnetic tape >> containers (TAP files) with the one byte padding for odd length records. >> This seems very odd (pun intended). :-) >> Even on a machine which couldn't write 32 bit numbers (the record lenght) >> on odd boundaries you could write the 32 bit number as 4 individual bytes. >> Does anyone know the reason? On the .TAP files that I provide to customers, I ignore the 16-bit granularity and supply odd-length records as appropriate. My own take is that the original was intended for DEC 16/32 bit hardware. There are other systems that make it impossible to write an odd-length record. More interesting are the 36-bit systems writing 7 track tapes (e.g. Univac 1100), where a tape record has to be a multiple of 18 bits/3 "bytes" long. An ANSI label record, for example, is 81 "bytes". Similar situations exist for 9 track tapes written on nominally 6-bit systems. --Chuck
Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
> From: Liam Proven > for my continuing education: what's a "Mini-Unix binary"? Two possible meanings; a system image for a Mini-Unix system (buildable under V6 with the standard V6 tool-chain of C-compiler/assembler/linker), and user command binaries (buildable with the C-compiler/assembler, but needing a special Mini-Unix linker - written in C, and compilable/runnable under V6). I've done both in my recent Mini-Unix work. (For those are are not familiar with Mini-Unix and LSX, they are both V6 Unix variants lobotomized to run on PDP-11's without memory management: -11/05's, etc. I'm currently working on getting Mini-Unix to run on an -11/03; not a major change, but not a model supported 'out of the box'. LSX is more heavily cut down, so it will run on even smaller systems - I seem to recollect 20KB or so - but that's not that useful nowadays, with semi-conductor memory being fairly common.) Noel
Re: ancient 5" SMD message
On 10/2/20 8:17 AM, Zane Healy wrote: There is a name from the past. That’s a good question Al, when was the last time anyone heard from Dave? kinda grasping at straws at this point Eric Smith has been looking for info on the SMD Elite drives for over 10 years. The non-SCSI Elite series were only around from 89-92 I was interested in them as the smallest physical example of an IPI interfaced drive. IPI didn't make much sense after SCSI-2 came out. Probably the biggest user of the IPI interface was IBM midrange machines (S36-AS400) The Sun IPI Elite drives are really cheap on eBay, and are being incorrectly advertised as SCSI.
Re: ancient 5" SMD message
There is a name from the past. That’s a good question Al, when was the last time anyone heard from Dave? Zane > On Oct 1, 2020, at 6:41 PM, Al Kossow via cctalk > wrote: > > > > 5.25" SMD drives > > > From: David C. Jenner > Date: Tue Jun 24 19:28:00 2003 > > I have complete docs (User's Manual and Reference Manual, both > very long) for both of the Seagate drives (the manuals cover > both). And a stock of the 1.2GB drives, including power supply > and cables. And QD33 Qbus adapters. I'll be glad to entertain > offers for these offline, especially trades for PDP-11 equipment. > > Dave > > --- > > wonder if > > - he is still on the list > - still has the manuals
Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives
I'm sorry Paul, I didn't know you were talking about the carry circuit or I'd have replied. I don't recall where I saw the circuit described but with relay contacts, the carry was basically as fast as the sum was created. It was kind of a parallel operation. It didn't require different relay coils to actuate to pass the carry to the next relay stage. It was all just contacts for the carry to propagate. The reason I said it wasn't much use in today's circuits is that you can only series transistors to 3 or4 transistors before things slow down to much compared with driving an inverter. It has a lot to do with the non-zero resistance and the hidden charge stored between two transistors that are turned off. The worst case happens when the entire stack of transistors tries to turn on at the same time. Relay contacts themselves pass data in less than a micro second while relay opening and closing takes milliseconds. Designing with relays takes a different thinking. With NO and NC contacts, each coil can be thought of as a buffer or an inverter at the same time. Stacking contacts has almost no delay. One also needs to swap thinking positive and negative logic going through the circuit if it has any complexity, for if a coil is or isn't driven. Dwight From: Paul Koning Sent: Thursday, October 1, 2020 2:03 PM To: dwight ; General Discussion: On-Topic Posts Cc: osi.superboard Subject: Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives > On Oct 1, 2020, at 1:20 PM, dwight via cctech wrote: > > It is going to need a lot of contact cleaning. > The one thing I like is the carry design the Zuse used. Really fast for > relays but not of much use for solid state. > Dwight Where did you find that? I looked through the document that was posted and I don't see that detail in it. paul
Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
On Thu, 1 Oct 2020 at 00:58, Noel Chiappa via cctalk wrote: > > No, it looks like it uses a different fie-system layout. > > Besides; there's not much point: the big adantage of using V6 is that one can > use the V6 tool-chain to prepare Mini-Unix binaries; XV6 wouldn't allow > that. If all one wants to do is get files in or out, there's already a program > (compilable with gcc, that uses Standard I/O) to read files out of a V6 > filesystem. If there was any good need, it could be extended to write > (although that would be non-trivial). Ah, OK. Sorry for the noise, then. May I ask, for my continuing education: what's a "Mini-Unix binary"? -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives
On 2/10/20 10:20 am, Brent Hilpert via cctech wrote:
> I'm not sure how unique this is to Zuse however.
> The raw design presented in the Radio-Electronics/Edmund Berkeley Simon
> articles of 1949/50 presents this scheme,
> although more complex (unoptimised) in the contact logic.
> This is post-Zuse of course, but it's a question and investigation as to how
> the design may have gotten from Zuse to the US/Berkeley in those years.
> That is, I wonder if it's a design that was arrived at independently in
> multiple places, or did it all derive from Zuse.
Charles Babbage designed a carry generate/propagate mechanism
("anticipating carriage") for the Analytical Engine which works in much
the same manner, though of course mechanically and in Base 10.
If the wheel rotated past 9 it set a lever which (later) triggered carry
on the next higher wheel. If the wheel was sitting at 9, an interposer
meant that any carry in would be transferred to the next higher wheel
(as well as rotating the wheel to 0.)
This is in contrast to the ripple carry mechanism on the Difference
Engine, which he knew restricted the speed.
I don't know when his designs were publicised but I doubt they had any
influence on Zuse and others of that era.
> When I was figuring-out/recreating the design of 'Simon' some years ago, I
> optimised the RE/Simon adder design down considerably.
> That's written up here, in the ALU/adder section:
> http://madrona.ca/e/simon/imp.html
> The schematic there presents the idea.
> Some years later I ran across the Zuse design and found I was one
> optimisation short of Zuse
> (IIRC, one more contact could be optimised out and it would match the Zuse
> design).
> I've been long meaning to add the Zuse circuit into that page to present the
> further optimisation.
Please do! Perhaps you could phrase a description in terms of generate
(A.B) and propagate (A+B)
--
Lawrence Wilkinson lawrence at ljw.me.uk
The IBM 360/30 page http://www.ljw.me.uk/ibm360
RE: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives
> -Original Message- > From: cctalk On Behalf Of K. Krause via > cctalk > Sent: 02 October 2020 08:54 > To: General Discussion: On-Topic Posts > Subject: Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the > archives > > > > On 01.10.20 23:38, Eric Smith via cctalk wrote:It is going to need a lot of > contact cleaning. > >> The one thing I like is the carry design the Zuse used. Really fast > >> for relays but not of much use for solid state. > >> > > Where is that circuit described? > The circuit is described in Konrad Zuses life memories. There is an english > translation available from the Springer publishing house. > Zuse used it's own logic symbols, which he named "abstrakte > Schaltgliedlogik", "abstract gating logic", because this logic could be > applied to > both, the full mecanical Z1 and the later relais machines. > I found this carry logic built with transistors in a book from the early 1960. > The author named it: killburn adder. It uses a chain of single transistors. That would be Tom Kilburn from Manchester who worked on many computers there. > > You can find a demonstration of the Zuse-adder on: > http://computermuseum.informatik.uni-stuttgart.de/virtuell/z1_adder.mp4 > (sorry, it's in german only :-( ) > > Klemens Dave
Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives
On 01.10.20 23:38, Eric Smith via cctalk wrote:It is going to need a lot of contact cleaning. The one thing I like is the carry design the Zuse used. Really fast for relays but not of much use for solid state. Where is that circuit described? The circuit is described in Konrad Zuses life memories. There is an english translation available from the Springer publishing house. Zuse used it's own logic symbols, which he named "abstrakte Schaltgliedlogik", "abstract gating logic", because this logic could be applied to both, the full mecanical Z1 and the later relais machines. I found this carry logic built with transistors in a book from the early 1960. The author named it: killburn adder. It uses a chain of single transistors. You can find a demonstration of the Zuse-adder on: http://computermuseum.informatik.uni-stuttgart.de/virtuell/z1_adder.mp4 (sorry, it's in german only :-( ) Klemens
Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives
On 2020-Oct-01, at 2:03 PM, Paul Koning via cctalk wrote: >> On Oct 1, 2020, at 1:20 PM, dwight via cctech wrote: >> >> It is going to need a lot of contact cleaning. >> The one thing I like is the carry design the Zuse used. Really fast for >> relays but not of much use for solid state. >> Dwight > > Where did you find that? I looked through the document that was posted and I > don't see that detail in it. On 2020-Oct-01, at 2:38 PM, Eric Smith via cctalk wrote: > Where is that circuit described? Try a search for "zuse adder", although I haven't gone through the results to see which one provides a 'good' explanation, but it looks like there are explanations out there. If I may, and in the following I hope I'm not conflating things, as it was some years ago I looked at this stuff: The idea is that a set of relays are energized in accordance with the state of the bits of the two operands. This can occur in parallel so is fast (one relay-unit-delay). Contact logic of those relays produces the sum, carry and not-carry for each bit, and the carries are wired sequentially through the contact logic of all bits. There are no intervening relays, and no relay energization is dependant upon a preceding relay in the bit sequence. Thus the entire sum and final carry are available immediately (at electric speed) after the one relay-unit-delay. No mechanical-speed ripple carry. If you try to do this with relays in a more 'obvious' manner you end up with a mechanical ripple delay down the bits. I'm not sure how unique this is to Zuse however. The raw design presented in the Radio-Electronics/Edmund Berkeley Simon articles of 1949/50 presents this scheme, although more complex (unoptimised) in the contact logic. This is post-Zuse of course, but it's a question and investigation as to how the design may have gotten from Zuse to the US/Berkeley in those years. That is, I wonder if it's a design that was arrived at independently in multiple places, or did it all derive from Zuse. When I was figuring-out/recreating the design of 'Simon' some years ago, I optimised the RE/Simon adder design down considerably. That's written up here, in the ALU/adder section: http://madrona.ca/e/simon/imp.html The schematic there presents the idea. Some years later I ran across the Zuse design and found I was one optimisation short of Zuse (IIRC, one more contact could be optimised out and it would match the Zuse design). I've been long meaning to add the Zuse circuit into that page to present the further optimisation.
Re: Datasheet / Info for Motorola SC5330 IC?
On Wed, Sep 30, 2020 at 7:48 PM Bob Rosenbloom via cctalk < cctalk@classiccmp.org> wrote: > On 9/30/2020 3:40 PM, Josh Dersch via cctalk wrote: > > On Wed, Sep 30, 2020 at 2:41 PM Gavin Scott via cctalk < > > cctalk@classiccmp.org> wrote: > > > >> Josh wrote: > >>> https://1drv.ms/u/s!Aqb36sqnCIfMpIVXm5draSrWHGMzJg > >> Would these potentially be the sense amp / comparators for the core? I > >> wonder if they were anything like: > >> > >> https://datasheetspdf.com/pdf-file/1092342/Motorola/MC1711L/1 > >> > >> which might have a similar application and take +15 and -7 on L > >> package pins 11 and 4 respectively with ground on pin 12. > >> > >> Being another Motorola design from what looks like a similar time > >> period, I wonder if there could be a similarity in pinouts by some > >> chance? > >> > > It's not an MC1711L based on that pinout. (But I suspect as you do that > > it's part of the sense amp for the core). In particular Pin 1 of the IC > is > > connected to what I believe to be +15V. (It's also hard to tell what > pin 1 > > is, since there's no orientation marker on these... ) Ground is pin > 10. I > > suspect -15V is pin 7. > > > > - Josh > That pinout sounds like the Motorola MC1440 sense amp though the > voltages are different. > Thanks, Bob! That does seem to be the same pinout, at least for the power/ground. I think I've managed to convince myself of the correct pinout for the power connector on this thing. I have a suitable supply and connector on their way... - Josh > Bob > > -- > Vintage computers and electronics > www.dvq.com > www.tekmuseum.com > www.decmuseum.org > >
Re: 9 track tapes and block sizes
On 10/1/20 11:40 PM, Warner Losh wrote:
>
>
> On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk
> mailto:cctalk@classiccmp.org>> wrote:
>
> I have never figured out why Bob Supnik defined the magnetic tape
> containers (TAP files) with the one byte padding for odd length
> records.
> This seems very odd (pun intended). :-)
>
My theory is that this was a time when the controller interface (either
to the tape unit or to the host or both) was 16 bits wide.
>
> Even on a machine which couldn't write 32 bit numbers (the record
> lenght)
> on odd boundaries you could write the 32 bit number as 4
> individual bytes.
> Does anyone know the reason?
>
>
> RMS did this too if nothing else, it was in the water at Digital.
> But it would have been faster to access than unaligned buffers...
Recently, Al forwarded me a tape image from Chuck Guzis. It was claimed
to be a NOS 1.4 tape, and that's what it turned out to be. However, it
was one of those tapes that requires new code in my tools to read
smoothly. While I routinely see tapes with a single padding byte, this
one had many cases requiring two padding bytes, and some requiring
three! Thus this tape image is not SIMH-compliant. Also, most NOS files
had their own ANSI labels; the files were mostly just text programs
without their own names, so the ANSI labels helped, but this is unusual
for NOS.
Summary:
73 HDR1 labels encountered. +++
73 EOF1/EOV1 labels encountered. +++
29 single-padded blocks +++.
406 double-padded blocks +++.
24 triple-padded blocks +++.
--
Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com
Nature abhors straight antennas, clean lenses, and empty storage.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
Card-sorting, Joel. -Crow on solitaire
Re: 9 track tapes and block sizes
On Fri, Oct 2, 2020, 12:05 AM Tom Hunter via cctalk
wrote:
> I have never figured out why Bob Supnik defined the magnetic tape
> containers (TAP files) with the one byte padding for odd length records.
> This seems very odd (pun intended). :-)
> Even on a machine which couldn't write 32 bit numbers (the record lenght)
> on odd boundaries you could write the 32 bit number as 4 individual bytes.
> Does anyone know the reason?
>
RMS did this too if nothing else, it was in the water at Digital. But
it would have been faster to access than unaligned buffers...
Warner
Cheers
> Tom Hunter
>
> On Fri, Sep 18, 2020 at 9:17 AM Jeff Woolsey via cctech <
> cct...@classiccmp.org> wrote:
>
> > > Acoustically, the best tapes were the short-record "stranger" tapes.
> > > All sorts of interesting noise. I could tell from across the room when
> > > someone was running the tape section of the Navy audit tests for COBOL
> > > just by the sounds.
> > >
> > MALET was also pretty good, reading and writing a bunch of blocks that
> > were one frame longer or shorter than the last. Loud rising or falling
> > tone in the noisy computer room.
> >
> > --
> > Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com
> > Nature abhors straight antennas, clean lenses, and empty storage.
> > "Delete! Delete! OK!" -Dr. Bronner on disk space management
> > Card-sorting, Joel. -Crow on solitaire
> >
> >
>
Sun SPARCstation LX boot from CDROM?
Dear Tom, Does your Sun workstation is functional and read QIC -150 cartridge? I have some old 3M 6150 cartridges that was created by Sun Sparc workstation in 2000. One those cartridges, I have some my personal files I like to get them. If you can you read those cartridges, I can pay some money for you? Chen Tsay
Re: 9 track tapes and block sizes
I have never figured out why Bob Supnik defined the magnetic tape
containers (TAP files) with the one byte padding for odd length records.
This seems very odd (pun intended). :-)
Even on a machine which couldn't write 32 bit numbers (the record lenght)
on odd boundaries you could write the 32 bit number as 4 individual bytes.
Does anyone know the reason?
Cheers
Tom Hunter
On Fri, Sep 18, 2020 at 9:17 AM Jeff Woolsey via cctech <
cct...@classiccmp.org> wrote:
> > Acoustically, the best tapes were the short-record "stranger" tapes.
> > All sorts of interesting noise. I could tell from across the room when
> > someone was running the tape section of the Navy audit tests for COBOL
> > just by the sounds.
> >
> MALET was also pretty good, reading and writing a bunch of blocks that
> were one frame longer or shorter than the last. Loud rising or falling
> tone in the noisy computer room.
>
> --
> Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com
> Nature abhors straight antennas, clean lenses, and empty storage.
> "Delete! Delete! OK!" -Dr. Bronner on disk space management
> Card-sorting, Joel. -Crow on solitaire
>
>
Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives
On Thu, Oct 1, 2020 at 11:54 AM dwight via cctech wrote: > It is going to need a lot of contact cleaning. > The one thing I like is the carry design the Zuse used. Really fast for > relays but not of much use for solid state. > Where is that circuit described?
Re: Zuse Z4 - Oldest Surviving Computer in the World - Lost in the archives
> On Oct 1, 2020, at 1:20 PM, dwight via cctech wrote: > > It is going to need a lot of contact cleaning. > The one thing I like is the carry design the Zuse used. Really fast for > relays but not of much use for solid state. > Dwight Where did you find that? I looked through the document that was posted and I don't see that detail in it. paul
