- COFF - www.tuhs.org

by Nemo Nusquam

I am currently reading "Memoirs of a Computer Pioneer" by Maurice Wilkes, MIT press. The following text from p. 145 may amuse readers. [p. 145] By June 1949 people had begun to realize that it was not so easy to get a program right as had at one time appeared. I well remember then this realization first came on me with full force. The EDSAC was on the top floor of the building and the tape-punching and editing equipment one floor below [...]. I was trying to get working my first non-trivial program, which was one for the numerical integration of Airy's differential equation. It was on one of my journeys between the EDSAC room and the punching equipment that "hesitating at the angles of stairs" the realization came over me with full force that a good part of the remainder of my life was going to spent in finding errors in my own programs. N.

4 years, 4 months

2
1
0 0

Re: [COFF] [TUHS] cut, paste, join, etc.

by Peter Jeremy

=> COFF since it's left Unix history behind. On 2021-Feb-16 21:08:15 -0700, Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> wrote: >I like SQLite and Berkeley DB in that they don't require a full RDBMS >running. Instead, an application can load what it needs and access the >DB itself. I also like SQLite and use it quite a lot. It is a full RDBMS, it just runs inside the client instead of being a separate backend server. (BDB is a straight key:value store). >I don't remember how many files SQLite uses to store a DB. One file. I often ship SQLite DB files between systems for various reasons and agree that the "one file" is much easier that a typical RDBMS. -- Peter Jeremy

4 years, 4 months

3
2
0 0

Re: [COFF] [TUHS] cut, paste, join, etc. (Grant Taylor)

by Rudi Blom

I've been maintaining a customer's application which uses C-ISAM as database interface on SCOUNIX, TRU64 and HP-UX. Simple and above all in 'C' ! As wiki says "IBM still recommends the use of the Informix Standard Engine for embedded applications" https://en.wikipedia.org/wiki/IBM_Informix_C-ISAM Mind you, the page hasn't seen significant changes since 2006 :-) Of course not having C-ISAM as a shared library can make executables a bit big unless included in a custom made shared library which I never really tried on SCOUNIX, but did on the newer UNIXes. A diskette used on SCOUNIX for certain offline salvage actions just isn't 'spacious' enough. Cheers, uncle rubl . >From: Grant Taylor <gtaylor(a)tnetconsulting.net> >To: coff(a)minnie.tuhs.org >Cc: >Bcc: >Date: Sat, 20 Feb 2021 10:23:35 -0700 >Subject: Re: [COFF] [TUHS] cut, paste, join, etc. >On 2/18/21 12:32 AM, Peter Jeremy via COFF wrote: >>I also like SQLite and use it quite a lot. It is a full RDBMS, it just runs inside the client >>instead of being a separate backend server. (BDB is a straight key:value store). > >Fair enough. > >I was referring to an external and independent daemon with it's own needs for care & >feeding. >. >>One file. I often ship SQLite DB files between systems for various reasons and agree >>that the "one file" is much easier that a typical RDBMS. > >*nod* > >-- >Grant. . . . >unix || die -- The more I learn the better I understand I know nothing.

4 years, 4 months

1
0
0 0

Fwd: [TUHS] nothing to do with unix, everything to do with history

by Dan Cross

The COFF folks may have a bead on this if no one on TUHS does. ---------- Forwarded message --------- From: ron minnich <rminnich(a)gmail.com> Date: Wed, Feb 10, 2021, 9:33 AM Subject: [TUHS] nothing to do with unix, everything to do with history To: TUHS main list <tuhs(a)minnie.tuhs.org> There's so much experience here, I thought someone might know: "Our goal is to develop an emulator for the Burroughs B6700 system. We need help to find a complete release of MCP software for the Burroughs B6700. If you have old magnetic tapes (magtapes) in any format, or computer printer listings of software or micro-fiche, micro-film, punched-card decks for any Burroughs B6000 or Burroughs B7000 systems we would like to hear from you. Email nw(a)retroComputingTasmania.com"

4 years, 4 months

1
0
0 0

Re: [COFF] [TUHS] Typing tutors

by Michael Parson

<moving to coff, less unix heritage content here> On 2021-02-07 23:29, Doug McIntyre wrote: > On Sun, Feb 07, 2021 at 04:32:56PM -0500, Nemo Nusquam wrote: >> My Sun UNIX layout keyboards (and mice) work quite well with my Macs. >> I share your sentiments. > > Most of the bespoke mechanical keyboard makers will offer a dipswitch > for what happens to the left of the A, and with an option to print the > right value there, my keyboards work quite well the right way. I've been using the CODE[0] keyboard with 'clear' switches for the past few years and have been very happy with it. Has the dipswitches for swapping around CTRL/CAPS and the meta/Alt, probably others as well. When I don't have hardware solutions to this, most modern OSes let you remap keys in software. Being a gnu screen user, CTRL & A being right next too each other makes life easier. I've used enough keyboards over the years that didn't even have an ESC key (Mac Plus, the Commodore 64, the keyboard on my Samsung tablet, probably a few others), that I got in the habit of using CTRL-[ to generate an ESC and still do that most of the time rather than reaching for the ESC up there in the corner. > I did use the Sun Type5 USB Unix layout for quite some years, but I > always found it a but mushy, and liked it better switching back to > mechanical keyboards with the proper layout. Before I got this keyboard, I used a Sun Type 7 keyboard (USB with the UNIX layout). It had the CTRL and ESC keys in the "right" places (as noted above, ESC location doesn't bother me as much), but yeah, they're mushy, and big. Much happier with the mechanical keyboard for my daily driver. I've been eyeballing the TEX Shinobi[1], a mechanical keyboard with the ThinkPad type TrackPoint, cut down on reasons for my fingers to leave the keyboard even more. -- Michael Parson Pflugerville, TX [0] http://codekeyboards.com/ [1] https://tex.com.tw/products/shinobi?variant=16969884106842

4 years, 4 months

1
0
0 0

Re: [COFF] Architectures -- was [TUHS] 68k prototypes & microcode (Clem Cole)

by Rudi Blom

I have to agree with Clem here. Mind you I still mourn the demise of Alpha and even Itanium but then I never had to pay for those systems. I only make sure they run properly so the customer can enjoy their applications. My 32-1/2 cents (inflation adjusted). Take care and stay as healthy as some of my 25 year old servers :-) Cheers, uncle rubl >From: Clem Cole <clemc(a)ccc.com> >To: Larry McVoy <lm(a)mcvoy.com> >Cc: COFF <coff(a)minnie.tuhs.org> >Bcc: >Date: Fri, 5 Feb 2021 09:36:20 -0500 >Subject: Re: [COFF] Architectures -- was [TUHS] 68k prototypes & microcode <snip> >BTW: Once again we 100% agree on the architecture part of the discussion. And frankly >pre-386 days, I could not think how anyone would come up with it. As computer >architecture it is terrible, how did so many smart people come up with such? It defies >everything we are taught about 'good' computer architectural design. But .... after all of >the issues with the ISA's of Vax and the x86/INTEL*64 vs. Alpha --- is how I came to the >conclusion, architecture does not matter nearly as much as economics and we need to >get over it and stop whining. Or in Christensen's view, a new growing market is often >made from a product that has technically not as good as the one in the original >mainstream market but has some value to the new group of people. <snip> -- The more I learn the better I understand I know nothing.

4 years, 5 months

1
1
0 0

Re: [COFF] Architectures -- was [TUHS] 68k prototypes & microcode

by Clem Cole

Moved to COFF - and I should prefix this note with a strongly worded -- these are my own views and do not necessarily follow my employers (and often have not, as some of you know that have worked with me in the past). On Wed, Feb 3, 2021 at 8:34 PM Larry McVoy <lm(a)mcvoy.com> wrote: > The x86 stuff is about as far away from PDP-11 as you can get. Required > to know it, but so unpleasant. > BTW: Once again we 100% agree *on the architecture part of* *the discussion*. And frankly pre-386 days, I could not think how anyone would come up with it. As computer architecture it is terrible, how did so many smart people come up with such? It defies everything we are taught about 'good' computer architectural design. But .... after all of the issues with the ISA's of Vax and the x86/INTEL*64 *vs.* Alpha --- is how I came to the conclusion, *architecture does not matter nearly as much as economics and we need to get over it and stop whining. * Or in Christensen's view, a new growing market is often made from a product that has technically not as good as the one in the original mainstream market but has some value to the new group of people. x86 (and in particular once the 386 added linear 32 bit addressing), even though DOS/Windows sucked compared to SunOS (or whatever), the job (work) that the users needed to do was performed to the customer's satisfaction *and for a lot less.* The ISVs could run their codes there and >>they<< sell more copies of their code which is what they care about. The end-users, really just care about getting a job done. What was worse was at the time, it was the ISV's keep their own prices higher on the 'high-value platform' - which makes the cost of those platforms ever higher. During the Unix wars, this fact was a huge issue. The same piece of SW for a Masscomp would cause 5-10 more than a Sun -- why we were considered a minicomputer and Sun was a workstation. Same 10MHz 68000 inside (we had a better compiler so we ran 20% faster). This was because the ISV's classified Masscomp's competition was considered the Vax 8600; not Sun and Apollo -- sigh. In the end, the combination of x86 and MSFT did it to Sun. For example, my college roommates (who were trained on the first $100K architecture/drawing 3D systems developed at CMU on PDP-11/Unix and Triple Drip Graphic's Wonder) Wintel running a 'boxed' AutoCAD was way more economical than a Sun box with a custom architecture package -- economics won, even though the solution was technically not as good. Another form of the same issue did you ever try to write a technical >>publication<< with Word (not a letter or a memo) -- it sucks -- The pro's liked FrameMaker and other 'authoring tools' (hey I think even Latex and Troff are -- much ' better' for the author) -- but Frame costs way more and Word, so what do the publishers want -- ugh Word DOC format [ask Steinhart about this issue, he lived it a year ago]. In the case of the Arm, Intel #$%^'ed 101-15 yrs ago up when Jobs said he wanted a $20 processor for what would become the iPhone and our execs told him to take a hike (we were making too much money with high margin Window's) boxes. At the time, Arm was 'not as good' - but it had two properties Jobs cared about (better power - although at the time Arm was actually not much better than the laptop x86s, but Apple got Samsung to make/sell parts at less than $20 -- i.e. economics). Again, I'm not a college professor. I'm an engineer that builds real computer systems that sometimes people (even ones like the folks that read this list) want to/have wanted buy. As much as I like to use sold architecture principle to guide things, the difference is I know be careful. Economics is really the higher bit. What the VAX engineers at DEC or the current INTEL*64 folks (like myself) was/is not what some of the same engineers did with Alpha -- today, we have to try to figure out how to make the current product continue to be economically attractive [hence the bazillion new instructions that folks like Paul W in the compiler team figure out how to exploit, so the ISV's codes run better and can sell more copies and we sell more chips to our customers to sell to end users]. But like Jobs's, DEC management got caught up in the high margin game, and ignored the low end (I left Compaq after I managed to build the $1K Alpha which management blew off -- it could be sold at 45% margins like the Alpha TurboLaser or 4x00 series). Funny, one of the last things I had proposed at Masscomp in the early 80s before I went to Stellar, was a low-end system (also < $1K) and Masscomp management wanted to part of it -- it would have meant competing with Sun and eventually the PC. FWIW: Intel >>does<< know how to make a $20 SOC, but the margins will suck. The question is what will management want to? I really don't know. So far, we have liked the server chip margins (don't forget Intel made more $s last year than it ever has - even in the pandemic). I feel a little like Dr Seuss' 'Onceler' in the Lorax story ... if Arm can go upscale from the phone platform who knows what will happen - Bell's Law predicts Arm displaces INTEL*64: “Approximately every decade a new computer class forms as a new “minimal” computer either through using fewer components or use of a small fractional part of the state-of-the-art chips.” FWIW: Bell basically has claimed a technical point, based on Christenson's observation; the 'lessor' technology will displace the 'better one.' Or as I say it, sophisticated architecture always losses to better economics.

4 years, 5 months

5
4
0 0

Re: [COFF] [TUHS] AT&T 3B1 - Emulation available

by Peter Jeremy

On 2021-Feb-03 09:58:37 -0500, Clem Cole <clemc(a)ccc.com> wrote: >but the original released (distributed - MC68000) part was binned at 8 and >10 There was also a 4MHz version. I had one in my MEX68KECB but I'm not sure if they were ever sold separately. ISTR I got the impression that it was a different (early) mask or microcode variant because some of the interface timings weren't consistent with the 8/10 MHz versions (something like one of the bus timings was a clock-cycle slower). >as were the later versions with the updated paging microcode called the >MC68010 a year later. When the 68020 was released Moto got the speeds up >to 16Mhz and later 20. By the '040 I think they were running at 50MHz I also really liked the M68k architecture. Unfortunately, as with the M6800, Motorola lost out to Intel's inferior excuse for an architecture. Moving more off-topic, M68k got RISC-ified as the ColdFire MCF5206. That seemed (to me) to combine the feel of the M68k with the clock/power gains from RISC. Unfortunately, it didn't take off. -- Peter Jeremy

4 years, 5 months

2
1
0 0

Re: [COFF] [TUHS] 68k prototypes & microcode

by Peter Jeremy

On 2021-Feb-03 17:33:56 -0800, Larry McVoy <lm(a)mcvoy.com> wrote: >The x86 stuff is about as far away from PDP-11 as you can get. Required >to know it, but so unpleasant. Warts upon warts upon warts. The complete opposite of orthogonal. >I have to admit that I haven't looked at ARM assembler, the M1 is making >me rethink that. Anyone have an opinion on where ARM lies in the pleasant >to unpleasant scale? I haven't spent enough time with ARM assembler to form an opinion but there are a number of interesting interviews with the designers on YT: * A set of videos by Sophie Wilson (original designer) starting at https://www.youtube.com/watch?v=jhwwrSaHdh8 * A history of ARM by Dave Jaggar (redesigner) at https://www.youtube.com/watch?v=_6sh097Dk5k If you don't want to pony up for a M1, there are a wide range of ARM SBCs that you could experiment with. -- Peter Jeremy

4 years, 5 months

1
0
0 0

Re: [COFF] [TUHS] 68k prototypes & microcode

by Larry McVoy

On Fri, Feb 05, 2021 at 01:16:08PM +1100, Dave Horsfall wrote: > [ Directing to COFF, where it likely belongs ] > > On Thu, 4 Feb 2021, Arthur Krewat wrote: > > >>-- Dave, wondering whether anyone has ever used every VAX instruction > > > >Or every VMS call, for that matter. ;) > > Urk... I stayed away from VMS as much as possible (I had a network of > PDP-11s to play with), although I did do a device driver course; dunno why. Me too, though I did use Eunice, it was a lonely place, it did not let me see who was on VMS. I was the only one. A far cry from BSD where wall went to everyone and talk got you a screen where you talked.

4 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF