Feeds

Huge PDP-11 in a lorry: How I drove computers into schools

Mobile technology, the mainframe way

SANS - Survey on application security programs

This Old Box Computers in classrooms are so common today, we may forget this was once inconceivably difficult. Computers were very expensive and so large they needed a huge truck to transport them. Nearly 35 years ago, I worked on an ambitious but ill-fated project to bring a minicomputer to rural Iowa schools, a classroom on wheels.

This old box

In the autumn of 1977, I was a sophomore at the University of Iowa. I’d had access to the university's computers for the past six years, under their initiative to teach computer science to students as young as 12. I had recently built a SOL-20 microcomputer from a kit, was enrolled in CS classes, and worked part-time as a junior programmer for the university.

I usually worked on experimental educational projects, and one day I was offered an exceptional project. The university had another initiative, to bring Computer Assisted Instruction (CAI) to schools across Iowa. In the late 1970s, even a simple 300 baud modem was exotic equipment, and computers in schools were unheard of. There was an active CAI program on campus, but it was impractical to bring teachers from across the state to the computer facilities. So the university would bring the computers to the schools.

The Mobile Instructional Classroom, as it was called, would put a DEC PDP-11 minicomputer and 16 terminals into a massive semi trailer and drive it to schools throughout Iowa.

It was a very ambitious setup – especially as the trailer had expanding wings to double the room size. I suggested to the project director that since schools already had classrooms, it would be easier and cheaper to buy some inexpensive microcomputers and install them in a spare classroom or the teacher's lounge.

The project's thrilling brochure

I suggested a newly released computer called the Apple II. My idea was immediately dismissed. The director insisted that Apple computers were only suitable for playing Pong and Breakout, they were incapable of "serious" computing. So I suggested something more "serious", an IMSAI or even a SOL. The director insisted that since they had already purchased the trailer and ordered the PDP-11, they were committed to the project as designed.

Writing software the old-fashioned way: with printouts

The project's software content was intended to help teachers recognise learning disabilities like dyslexia, and give them ongoing education and improved teaching certification.

The software originally ran on an IBM 1500 Instructional System, designed exclusively for CAI courses and written in a unique language, Coursewriter. But the IBM 1500 was obsolete and was decommissioned.

The last act of decommissioning was to print out all the programs, resulting in a stack of green-bar paper about 6 feet tall. My job was to learn that dead language, then rewrite the software in BASIC so it would run on the PDP-11. The framework was simple, the courses presented a section of instructional text, some multiple choice questions and a scoring system.

So, I found myself the senior programmer on the project. I helped write some of the new BASIC software, experimenting on my SOL at home. I borrowed a Carterphone 300 baud acoustic coupler modem from the project and wired it up to my SOL so I could write code from home.

The framework was designed so typists that were untrained in programming could read the content from the printout and type the BASIC code around it without having to understand how it worked.

This is where the troubles began

The PDP-11 hadn't shipped yet. So we wrote the software in an ANSI-compatible version of BASIC on a CDC Cyber mainframe. A dozen typists were hired, and put to work on dumb terminals in the computer science building.

The software was written in using a primitive line editor, a word processor that only showed one line at a time. The results were predictably disastrous. There were so many typos and errors, it took more time to fix their code than it would to just write it all by myself. So I did.

I had my SOL and a modem so I could work at home, but the typists only worked an hour or two each day. I was supposed to work in the office, but that would just make me available to fix everyone's bugs. So I started taking an inch or two of paper off the printout stack home with me, spending late nights typing it in.

The director didn't seem to notice the stack getting shorter, or the stored files getting larger. He would question me about why I was never in the office, but my time cards showed so many hours of overtime. I showed him my file storage, he couldn't believe I was doing more work than the rest of the team. Over the next few months, I coded about 90 per cent of the project by myself.

Your laptop? Show me your car park-top

Throughout the cold winter months, we wrote the code and tested it on the Cyber mainframe, consistently falling behind the director's optimistic schedule. Cyber BASIC was compatible with the DEC. I thought it was clever that we'd used an ASCII system

instead of the university's IBM/360, which used their proprietary (and incompatible) EBCDIC. That would have been a problem. But nobody noticed that we had no way to move the software from the Cyber to the PDP-11. The director planned on dumping the code to a DEC disk pack, but the format was incompatible with the Cyber. Eventually we found a contractor that had a DEC and a CDC computer on the same network, and could convert our tapes. But these unexpected delays were putting the project behind schedule.

SANS - Survey on application security programs

More from The Register

next story
Samsung Galaxy S5 fingerprint scanner hacked in just 4 DAYS
Sammy's newbie cooked slower than iPhone, also costs more to build
Leaked pics show EMBIGGENED iPhone 6 screen
Fat-fingered fanbois rejoice over Chinternet snaps
Oh no, Joe: WinPhone users already griping over 8.1 mega-update
Hang on. Which bit of Developer Preview don't you understand?
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Rounded corners? Pah! Amazon's '3D phone has eye-tracking tech'
Now THAT'S what we call a proper new feature
Leaked photos may indicate slimmer next-generation iPad
Will iPad Air evolve into iPad Helium?
Feast your PUNY eyes on highest resolution phone display EVER
Too much pixel dust for your strained eyeballs to handle
Zucker punched: Google gobbles Facebook-wooed Titan Aerospace
Up, up and away in my beautiful balloon flying broadband-bot
US mobile firms cave on kill switch, agree to install anti-theft code
Slow and kludgy rollout will protect corporate profits
prev story

Whitepapers

Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Top three mobile application threats
Learn about three of the top mobile application security threats facing businesses today and recommendations on how to mitigate the risk.
Combat fraud and increase customer satisfaction
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.