Ethan Dicks wrote: So what is wrong with a 8 bit cpu since a 68000 is overkill. BGmicro has surplus 512k x 8 flash $1.00 each if need cheap memory but they have real HD's for $21.50 each. Now my question is" are you designing a new interface or emulating a old one". Ben. Personaly I have hard time dealing with a CPU on a i/o card that is more powerfull than the PDP.

Alright all you tech heads, dust off your grade school prayers and say a few for the Shuttle astronauts. No time like the present to show some respect. John A. news: Columbia lost 16min before landing at ~40+mi. altitude

David Holland wrote: OK, for you Brits with SkyDigital, Sky News are covering the story live. For the American readers of this list, FOX News are covering the story. Info on www.sky.com/news and www.foxnews.com. Later. -- Phil. philpem(a)dsl.pipex.com http://www.philpem.dsl.pipex.com/

At 20:38 01/02/2003, you wrote: Although that sounds somewhat implausible (how would ABC know, when no-one else does?), I wouldn't be entirely surprised if it was the case. Incidentally, does anyone know if Columbia had been updated to the latest flight s/w & h/w? I know there was work on-going to do this, but I've no knowledge of what stage they'd got to. It seems to me that maybe a little complacency might have set in. Maybe they've landed slightly damaged orbiters before, with no ill effects. Certainly the post-Challenger analysis was that safety procedures were less rigorous than they ought to have been. There've been nearly a hundred flights since then (or is it slightly more, I forget), maybe - just maybe - someone made a wrong call based on the fact "it's always worked before". The trouble is, even if they'd aborted the landing (before the Shuttle left ISS presumably), what then? I do feel for the astronaut's families, and in almost equal measure for the future of humanity in space. We have *got* to find a better way of getting in and out of the gravity well. -- Cheers, Ade. Be where it's at, B-Racing! http://b-racing.com

At 23:02 01/02/2003, you wrote: Fair enough. The BBC rather poingiantly (sp?) recorded the last words of Columbia as "Roger...erm..."; so it looks like they didn't get much warning of an imminent problem. You can't compile ADA to run on Windows... -- Cheers, Ade. Be where it's at, B-Racing! http://b-racing.com

At 00:24 02/02/2003, you wrote: Ah yes, GNAT. Runs in a DOS box, doesn't it? Now you mention it, I do recall GNAT having some windows capabilities, but they were fairly feeble IIRC. Even the example windows prog crashes a lot - again, IIRC. The trouble being, of course, that almost everything *is* platform specific. That's not a criticism of Ada per se; most "portable" code suffers on different platforms, especially when windowing environments are in use. Mind you, when Linux and X become the defacto industry standard which every machine runs, portability issues will be largely a thing of the past... I hope. I think the last time I seriously looked at Ada was in about '95, I forget what level of the language we had. It ran on VMS (on that Vax 8800 I mentioned earlier). I looked at GNAT about 2-3 years ago, but couldn't remember enough about Ada to make even a simple program compile. An OS written in Ada? Any idea what it was called? -- Cheers, Ade. Be where it's at, B-Racing! http://b-racing.com

That is most assuredly false.

Based on the press briefing: What hit the tiles appeared to be only insulation. The tiles are brittle, but a chunk of insulation shouldn't have damaged them. Based purely on sensors failure sequences the failure APPEARED to progress explained by alternate damage to the wiring harnesses. So APPEARED is highly stressed. There has been more substantial tile damage in the past that has not created this problem on reentry. The failure did occur during the highest heating point in the landing cycle. Crew did not report a loss of control, nor any vehicle originated sensor anomalies (ground reported the failures back to the shuttle, who was in the process of acknowledging when contact was lost). NASA stresses that while it's easy to make the insulation hit look like the smoking gun, rarely in a system as complex as the shuttle is something so cut and dried. There is no mechanism for inspecting the bottom side of the shuttle, nor ANY method for inflight repairs. When they lost the drogue chute door a few missions ago, they said that "remote observation" yielded no clues. Very vague, but I presume they had the SRO turn a bird on the shuttles rear. However, the lighting was unlikely to be ideal, and camera angle may have played a part. As a result of the lack of success with remote observation last time, they elected not to do it this time, either. And the tiles are black, so it would be hard to discern any detail. Exhaustive analysis was done based on the crew films of the external tank and the ground cameras. They're pretty convinced there is no hardware in the chunk of insulation that hit. That's about it, for now. In the press briefing, too many idiotic reporters were asking the same questions. And the one woman that asked the smart question that I had been wondering about was glossed over. That being were any SRO assets focused on the shuttle during re-entry. I realize that the pan speed of the cameras may be slow, but the widefield views still have a lot of detail. The other question that was never asked is what intrinsically explosive gases or fluids run through the wing area. Hydrazine? Hydrogen? Any O2 tanks in the wing? Could one of them have ruptured or sparked off and blown away part of the wing? --John

The relative speed of the chunk of insulation to the wing at the time of impact surely couldn't have been anywhere near that fast.

There was some jackass radio broadcaster here (WRKO 680 in Boston) that was speculating it could have been a virus placed in space shuttle computers by terrorists causing it to explode on re-entry. -Chandra

Chandra Bajpai wrote: And how many virus authors would be able to get the guidance computer's *schematics* in the first place? Without a simulator (or a real machine) and a copy of the schematics, trying to write a virus like that would be damn near impossible IMO. And yet the general (technophobe) population of Boston may well have believed him... Idiots like that shouldn't be allowed to broadcast anything, period. Later. -- Phil. philpem(a)dsl.pipex.com http://www.philpem.dsl.pipex.com/

Lady take them to her breast, and shepherd them home... Strange thing: at 9am US CST, my wife and I were in the car going to pick up the keys to our new house, when our favorite oldies station played the original version of "Major Tom." My wife called my attention to the song, and, of course, the digital clock's right above the radio. We hadn't yet heard anything about Columbia, and the air caster didn't say anything about it, but I did feel an odd [definitely *not* nostalgic] shiver as it played... Ed San Antonio, Tx, USA ----- Original Message ----- From: "John Allain" <allain(a)panix.com> To: <cctalk(a)classiccmp.org> Sent: Saturday, February 01, 2003 08:43 AM Subject: Columbia

Bob Shannon wrote: I keep forgeting about the last feature. However getting back to the original question about the PDP without I/O, a console I/O is mandatory for use of a PDP-8.Not having a 8 I can't tell however if the standard serial I/O had a option for RS232 output. Here with the proper software a old PC would be handy to emulate a TTY. Ben.

--- ben franchuk <bfranchuk(a)jetnet.ab.ca> wrote: Nothing, but as I said, I have the skills and the tools. OTOH, hooking a 16-bit data bus to a 12-bit bus is a little easier than hooking an 8-bit bus to a 12-bit bus (having worked on a VAXBI product with a 68010 - that was a nightmare - 16 bits to 32 bits... can rant about that one for a while if you have the time ;-) Perhaps a little bit of both. If I were going to emulate a DF-32, that could be done in battery-backed SRAM - 32K words per unit, 4 units per CPU. Trivial. The original logic was implemented in R-series logic. It wouldn't be hard to do it all in TTL, just a bunch of work. The actual storage technology isn't the issue; the presentation to the PDP-8 is. The advantage of emulating old hardware is compatibility with existing drivers. The advantage of creating new hardware is freedom from ancient and typically arbitrary constraints. The disadvantage is a) writing the drivers (a one-time problem) and b) getting the new drivers onto an old system (a one-time-per-CPU problem). The SBC-6120 solves these problems by a) having had OS/8 drivers already written and b) having enough smarts in the monitor to stuff a disk image down the console serial line. Doing this for a real PDP-8/i would not be as painless. Having a "real" processor on the peripheral card might help mitigate these problems (i.e., partition, format and populate the "disk" via the embedded CPU, then all you need is a bootstrap from the -8/i side and off you go). That's another issue... the -8/i has no ROM. Some of the older devices had extremely short bootstraps (the RK8E is the shortest I know of - one or two words). I would hate to have to toggle in a 100-instruction boot everytime I corrupted memory. That points to emulation of existing devices being a good thing. Why? We used to sell them all the time. When COMBOARDs sold in bunches like grapes (c. 1982-1984), they frequently went into PDP-11s running RSTS because we could hang a line printer (LA-180 or larger) directly off our card and have print jobs coming back from the IBM come in the serial port and out the parallel port, never pestering the RSTS print queues. Folks *loved* that. The CPU on the COMBOARD is an 8MHz 68000 - _roughly_ equivalent to the CPU in the VAX-11/750 (~.6 VUPs) and quite a bit faster than most PDP-11s of its day (not sure about the 11/70) There is a period SCSI card for OMNIBUS PDP-8s - it has a 6809 processor on it to relieve the PDP-8 of the nitty-gritty details of how SCSI works. Same idea, slightly newer peripheral hardware. -ethan

ben franchuk wrote: But, remember, that 8k is 12 bits wide!