May 23, 2020
In 1983 my father acquired a computer for his lab, a clone of an 18-bit address PDP-11, called SM-4. At the outset, it had a ferrite core RAM of about 32KB, which clearly was inadequate. In a couple of years, he got a semiconductor RAM module of 128KB. It would be a great improvement, but it was unreliable. It was based on the KR565RU1 DRAM chip of rather poor quality. As the system ran, the DRAM warmed up and started to fail.
I helped Dad's underlings to fix it up. We would put a board on an extension so it hung outside of the chassis. Then we ran diagnostic tests. When the test failed, we administered just a drop of ethanol on the DRAM chips. If the test started to pass again, we knew the bad chip. I replaced a bunch of those by carefully cutting the legs off, then removing the legs one by one. I did not have a solder pump at the time, and it was safer to cut the bad chips off anyway. It was important not to damage the PCB.
IIRC, about 30% of the chips were bad. Of course, the same ratio among the spare ones were bad too. But eventually we prevailed and got the RAM module running well. It served until the SM-4 was decommissioned.
May 21, 2020
For a few short years, the backbone of computer networking in late USSR was Internet e-mail transmitted over UUCP. To hook MISS into it, I needed so-called "g protocol". It provided basic flow control over a modem link with sliding windows. The counters were in packets, not bytes like in TCP, and up to 8 packets could be outstanding at a time before acked.
To be frank, it was a hell on Earth. Or almost, because it was fun after all, like climbing the Everest.
To begin, merely programming a sliding window protocol challenged my prowess. There's a million of corner cases, all the ack numbers had to be tracked, modulo-8 arithmetic comparisons were confusing. I struggled with basic correctness.
But the hell arrived when I faced interoperability. Our first counterpart at Demos was a Xenix of some kind. Its uucp descended from the earliest AT&T originals. I more or less made my implementation talk with that. But one day, Demos switched us over to a VAX with BSD 4.1. That used an entirely different implementation, known as "pk". My code flat out didn't work with it, and it took a huge effort to fix it up. The final implementation that I had to support was UUPC, an MS-DOS program. By the time I had to talk to it, my code was tightened up considerably and UUPC only took some slight tweaks.
The amount of work it took to get g-protocol robust has framed my understanding of communicatio protocols for many years. It continues to amaze me that TCP even works at all, considering the diversity of networks that it must traverse, and above all the multitude of implementations. TCP is significantly more complex than g-protocol, even before we talk auxiliaries such as PMTU Discovery or extensions such as SACK. I didn't have to deal with sizing of the window and the Slow Start.
Unfortunately, they source code of my g-protocol implementation was lost when I changed jobs to MCST and didn't think to take it along.
 Aside of the g-protocol itself, I needed a few other things: a Hayes-compatible modem, and an ability to control it. It was not a trivial task to find hard currency in order to buy the 1200 baud modem, while working in a univirsity in a collapsing country. In addition, Mitra-225 cum ES-1011, as well as MISS had some trouble talking to the modem. The "channel" was barely capable of supporting full-dublex operations at 1200 baud with linked channel programs. Interrupts were expensive! The OS did not have any way to buffer input either. I ended writing a kernel driver that de-framed g-protocol and buffered 1 or 2 packets at a time. This allowed the userland to receive packets with MISS' equivalent of ioctl(2). All this was small potatoes, however.
 It was the famous kremvax.demos.su. My own node was r11740.phys.msu.su. R11 was yet another alias of Videoton's clone of Mitra, and 740 was the serial number of the CPU.
Next: Memoir 5.
May 20, 2020
My LSI-11 needed a console, attached over a current loop. I found a small Polish terminal that was suitable. Unfortunately, it was set to display KOI-7 encoding, and UNIX needed ASCII with lowercase letters. So, I set to re-program it. I opened the case, and the first surprise was that the case was made out of plywood. It was polished and painted from the outside, so I never suspected anything!
The firmware and the fonts were stored in a UV PROM. It was the kind of ROM that you needed to erase with ultraviolet light. Some people even erased them with direct sunlight. Through my connections, I found someone who had a programmer for it on the other side of town. Then, I read the ROM, found where the fonts were, and copied them. Then, I designed lowercase letters. I mapped them in a text file with asterisks, and then read that file with a simple program in C. The complete font is preserved in this picture (in an X bitmap, actually):
Once I packed the font back into the firmware, I went to the gentleman with the programmer and wrote it into the chip. The operation was a success, although ultimately led to nothing, even though the font had a last hurray later.
Next: Memoir 4.
May 19, 2020
My first PC was a Soviet LSI-11 compatible, based on a DVK-3 motherboard in an Electronika-60 chassis with a transformer-based power supply. It had 256KB of RAM. I managed to find a controller of MFM winchester and a Seagate ST-20 20MB hard drive. So, it was capable of running UNIX.
I went to Demos and got a distributive of their UNIX. It was based on v7, but with many features of BSD 2.9 grafted in. Unfortunately, the bootstrap procedure crashed on my machine.
I cannot remember how I did it, but I identified the problem: the DVK-3 CPU did not implement the MFPS instruction, but the kernel identified it as a certain model of PDP-11, and assumed that it had to have the MFPS. I might have used my low-level debugger for it.
By that time Demos already was phasing out the obsolete stuff and there was no chance to get a new distributive composed for a free-loader. In order to fix the crash, I went a long way. Using Mark Vengerov's C under MISS on ES-1011, I ported ld(1). Then, I used Vadim "avg" Antonov's portable assembler (it was an unbelievable luck that he wrote that in the first place; his objective was speed - it worked many times faster than original UNIX v7 assembler written in assembly). Finally, I literally ported K&R C under MISS, with the output into avg's assembler and the aforementioned ld(1). It turned out that the compiler was absolutely full of endian assumptions, and Mitra-225/ES-1011 was big-endian. I fixed them all. And finally, I used the toolchain that I built to cross-compile the DEMOS' bootstrap loader and kernel. Then, I wrote it to a distribution floppy.
It all worked in the end. Now that I'm writing all this, it boggles the mind that I was able to pull it off. I was too young to know what was impossible back then.
UNIX in 256KB sucked though. And it was entirely useless. I was very happy to replace it with an IBM PC in a year or two.
Next: Memoir 3.
May 17, 2020
Some time around 1988 I wanted to port UNIX to ES-1011, a hungarian clone of Mitra-225. It was a 16-bit+ mini with an accumulator-based instruction set, and unlike its contemporary PDP-11, it had no hardware-supported stack.
Our ES-1011 ran OS MISS, written by late Vladimir Butenko, including a C compiler by Mark Venguerov. Mark found it somewhat annoying implementing a stack. His prologue routine had 22 instructions and epilogue had something like 9. The K&R C also had an non-trivial prologue function, called '.jsav' IIRC. But it wasn't as bad as having a word in memory work as a stack pointer on Mitra/1011.
Because entering functions properly was so expensive, Mark made a decision not to make all functions recursive by default. Instead, those that needed to be recursive were marked with a reserved word "recursive". It was expected that not many were needed. The problem was how to find those that did and mark them. I didn't do that, but I think someone developed a program that searched for potential call loops (perhaps Ivan Bobrov or Sasha Ovsyankin did). Even so it was rather iffy to identify and tag recursion.
Before I started porting, I consulted with Vadim Antonov, who was basically King of Unix in USSR. His suggestion was to start with developing the ABI and calling convention. I don't remember if he pointed it out, or if I decided it myself, but Mark's explicit recursion was a non-starter. I began looking into the problem and had an idea.
Mitra-225 had an additional register, L, which was possible to read in userspace. I think it pointed at the word where the return address was saved. The instruction set had rarely used addressing modes with L as an index register. Also, a procedure return instruction set L as a side effect, as I recall. Either way, I decided to use L as a frame pointer. I found a less than obvious way to extract the return address and save it at L, by tricking the return instruction so it jumped into the body of the function instead of out of it, and that set L. The epilog was even smaller and I think it was basically RET. The code was compact and performant enough to allow all C functions to be recursive, as they should.
When I demonstrated the code to Mark, he looked at me for a long moment and said: "Where have you been before, Pete?"
By that time, he was busy with his 2nd C compiler, for 8086, and he never got back to retool the C for Mitra. And I burned out of porting UNIX for one reason or other. My diploma theses was porting MISS to PDP-11, ironically enough. So, nothing came out of my craftiness.
Next: Memoir 2.
Update: There's a manual for Mitra-15 floating on the Internet, so I used it to refresh my memory somewhat. The L register is loaded from a global "section table" upon a procedure call (CLS: Call Section). This hardware support and traditional use make a reason why nobody came upon the obvious. But the procedure return (RTS) is recursion-friendly: it loads the return address from L+0 and the L from L+2.
April 10, 2020
The pecan got planted in the autumn, but its leaves turned nasty brown and fell off, so I gave it up for dead. However, my wife detected flexibility in its stem (which has not yet upgraded to a trunk) and suggested that it may yet come back. And it did! Stupid dedicious trees!
I took pictures of it with dying leaves, but it didn't look good on the background of dead grass. In fact it was next to impossible to tell what one was looking at. So, this time I provided an artificial background.
March 23, 2020
In response to a viewer's question, what pistol caliber is set to follow the .40 S&W into the dustbin of history, Jon Patton of The Gun Collective suggested .380 ACP today. Quoting:
It will take a while, but I think with the rise of the 9, 380 will start to fade away like .32 ACP and the .25 ACP did.
Well, I think it's a very risky bet Jon is making. What we're having currently are two trends: what he calls "the rise of The Nine" and also the buying public refusing to listen to the gun elite, and continuing to prefer the .380.
The former trend expresses itself in new and cool guns not being offered in .380, only in 9mm. SIG P365 and Glock 43X are the main examples of this. There is no Glock 42X and never will be. Probably.
The latter trend has started in 2003, when Kel-Tec introduced P-3AT and continued until the present. The industry steadily introduced new products in .380, such as Ruger LCP (2008), Glock 42 (2014), Browning 1911-380 (2015), Ruger LCP II (2016), S&W M&P Shield 380EZ (2018), and SCCY CPX-3 (2019). Even Beretta, who stopped making Model 84 relented and re-started the production!
As the two trends battle it out, the fate of .380 hangs upon an introduction of a small gun with 10 or 11 round capacity. It must be well designed and be of high quality. And it likely needs to be made by a top-tier brand, and be striker fired (until the LCP II appeared, this last point was a must, but I'm not as sure anymore). If this gun does not appear before 2023 at the latest, .380 is finished. If it does appear, it's going to let .380 catch up with the 9 yet again.
Unfortunately, if SCCY take the frame of CPX-3 and drop DVG-1 firing system in, the result will not be enough. It has to be SIG, Glock, Ruger, S&W, or Walther. Chances of that happening are not great, but not zero.
I think in a large part a company making these decisions depends on new shooters. Many commenters seem to think that the key feature of .380 that enabled its raise is the small size of the guns. It may have been so, but with P365 existing, it no longer is a factor. However, the lower recoil still remains. The .380 allows to make a small gun that is comfortable to shoot for beginners. That is why 380EZ came to exist. If a shrewd executive agrees with this line of reasoning, anything is possible.
P.P.S. Remington RM380 was announced, delayed, and shipped in 2015.
P.P.P.S. I downloaded the 2019 Beretta catalogue, and the Series 80 Cheetah pistols are not in it. Apparently Beretta made one last production run of the Model 84 at the peak of the popularity of the .380 around 2015-2016, then canceled Cheetah again.
January 16, 2020
November 10, 2019
Not sure of this is something known in America, but I learned from the couple set from Tendai Senshi Sanred (Astro Fighter Sunred). When Vamp suddenly comes to visit, Sunred hides his half of the set, because he feels embarrassed to show such a proof of close relationship.
September 20, 2019
The pecan is growing and about ready to be planted.
Update: Pecan 3.
September 13, 2019
The above is called a "plumcot", and it is a hybird of plum and apricot. I think it makes way more sense than a cronut.
September 12, 2019
It's not going to be an exaggeration to say that the "B.Yu.Aleksandrov" brand milk cheese stick is one of the most amazing industrial foods I have ever eaten. It may beat the white Ferrero Raffaello. Unfortunately, the milk cheese requires refrigeration, so those wanting to taste one must find a Euro food store like Austin's BEM. It's not something I recommend ordering online.
September 11, 2019
This gun was made using a hand drill and pen knife, and it works perfectly.
September 10, 2019
These rolls have bacon strips between layers.
September 08, 2019
This is what my wife told me today. She wanted to cook some udon and wanted to know how. I saw "約1l", "湯の中へバラバラと", and "約10分", so I said with confidence: "Take 1 liter of water to boil per 1 bunch of udon, separate strands and throw it in there, then boil for 10 minutes. Then pour cold water on it."
But it wasn't all. A few minutes later, she asks, "Do I need to drain on a sieve or do I drown them in cold water in a pan?" Suddenly, it's an emergency. That stuff is already boiling, and all I see is: "ゆで上がりをザルに取り冷水で水洗いをして blah blah blah ください". There is no katakana "zaru" in a dictionary. There's no "torireisui" either! Well, reisui is cold water, so that makes sense. But I already know that cold water is used to anti-scald pasta, so it's not helping! The only thing that saved me is that IMI has a very broad search, and apparently "zaru" can also be "笊", which means a strainer. What a relief! Quickly I report that we throw udon on sieve first and all is good.
June 29, 2019
This one is not as upscale as Burgman, but still looks nice, especially if its rider is not too tall.
June 24, 2019
Although I know that it's a dumb idea, I find these high-end scooters irresistibly cute.
June 22, 2019
I am not a native English speaker and perhaps I'm quite wrong about this, but in my mind, a "pilot error" is an error that a pilot commits. He needs to press the top rudder, but he presses a bottom rudder — a deadly error. In case of Atlas 3591, the error is hitting the TOGA button. So, when my friend Kirill said that the crash of SU 1492 was caused by "pilot error", I was very tempted to deliver a lecture. Well, Kirill is more correct than journalist Mike Eckel when he blames lightning. Still, it's not an error that killed 40 passengers, it's a series of strange actions by the captain that followed his error. In a way, I want to draw a distinction between a pilot error and pilot incompetence.
Errors are abundant in pilot's life, but what matters is what happens after tthem. Just a week ago, I made an error following a takeoff from Big Spring, Texas: forgot to raise the gear. So, I detected an anomaly (the aerodynamic noise), identified a root cause (my error), and took a corrective action (lifted the nose sufficiently for the airspeed to decrease below Vlo and raised the gear).
Of course, incompetence prompts errors, sometimes dangerous ones. Worse, it results in errors in response to errors, thus contributing to an accident chain. So, I guess we can consider SU 1492 as a sequence of errors: let the airplane settle below the glideslope, keep the power on for too long, thus causing an overspeed at touchdown and a bounce, command a nose-down input that turns a bounce into a porpoise, forget that spoilers do not deploy automatically, fixate on sticking the landing instead of going around. But I think it is more productive to look at the episode as a whole, rather than decompose it into pilot errors. Maybe we can talk about deficient training and lax standards at Aeroflot instead.
June 21, 2019
I found a pecan growing naturally. I guess birds scatter those.
Update: pecan 2.
June 20, 2019
My better half added an exotic fruit in there. Feels like a mix between kiwi and asian pear.
25 queries taking 0.0446 seconds, 70 records returned.
Powered by Minx 1.1.6c-pink.