Just watched today's video on writing a new CPL program. New CPL source code Complied, Assembled, Linked and ran, great job team. This time last year we just started working on getting the Diag PROM Bd to run the diag, tests, what a year. To the RUclips viewers keep in mind when the Warrrex-Centurion was designed in the 1970's by a small team of people in Richardson, TX. This computer put food on the table and paid the bills for 100's of families for over 10 years. Regards, Ken R.
I grew up in Plano, which is just north of Richardson, from 1976. I remember that area as having a lot of interesting computer tech. There was a supercomputer company there too, and I think that's the one started by Feynman's son. Later this would be the "Telecom Corridor" and it was more about switches and other telecom tech. This is close to where Texas Instruments is located, too.
Interesting to hear. But the name “CPL” makes me twitch a bit, because back in the 1960s it was the name of a British effort to put together a rival to IBM’s PL/I. The name stood for either “Combined Programming Language” or “Cambridge Plus London”, being the names of the two Universities involved in the effort. The full language as originally conceived was never implemented. But a cut-down version, intended for bootstrapping the full compiler, was put into use and achieved some popularity on various computers as a low-level systems programming language. It was called “BCPL”, which stood for either “Bootstrap CPL” or “Basic CPL”. Some folks at Bell Labs got hold of this, and saw it had some promise for implementing an operating system they were working on. They created their own, even more cut-down version, which they called “B”. This was then developed further, with the addition of types and structures (which the original BCPL did not have), into another language, called “C”. And the rest, as they say, is history.
Ken, thank you so much for all your help! We couldn't have gotten anywhere near this far if it hadn't been for your unbelievably good memory and excellent hardware repair skills!
It’s amazing what you all managed to do in so little time from this non-functional, long-forgotten, entirely proprietary undocumented technology. You managed to preserve this knowledge and demonstrate it in all its 8bit glory. Amazing !!!!
So, the O/S is still under copywrite and they don't want to make it freely available. Fair call ..after all they wrote it. What about a hobbyist license? People sling a collective 10$ and they get a license to go play with it. Money gets donated to ..what ever the majority of the still living/interested copywrite owners decree? For 10$ for a hobbyist project ..who wouldn't sling some cash at it all? I certainly would.
No joke, I maintain a very old computer accounting software at work (mid 80s, I think?) and I’m incredibly lucky they saved the original manuals, and that the one guy who wrote the program is still alive. Unfortunately the manuals are covered in cigarette smoke, but at least they’re there!
The real exciting parts of these old multiuser systems is how they handle simultaneous access to files and databases. When you can run two or more programs that are heavily updating a huge file and the file doesn't get trashed, *that's* when you realize that someone worked very hard on the part of the OS that delegates file access to users.
You know, *nix systems have an editor of a similar type to Kompoz, called "ed". I believe it was the first editor for Unix. Maybe it's not as bad, but it too makes vi look easy.
@@fllthdcrb "ed" standing for "line editor". It filled the same purpose as compose, but even more stripped back. There was never a UI version of ed, so you always had to rely on the terminal to maintain information Was developed in the era *before* CRTs and inspired a compose-like version called "ex" with actual UI features (like a text buffer wow). And said ex was further developed so you could edit the buffer directly in a visual manner, creating "vi". Can even use ex-mode in Vim today
yeah its funny how when it was unveiled vi was a tremendous advance in user friendliness, but it was also criticized for being wasteful. Terminals and connections were extremely slow and often paper-based so the terseness of interactive programs output was highly valued
This reminds me a little bit of my first C programming attempts on an Atari 520st. I had only one floppy drive. The C compiler from Digital Research was on ~10 floppy disk. You had to put the source code on a separate floppy disk and then switch between the compiler disks (the compiler would tell you which disk to insert) and the source code disk. If you inserted the wrong disk you had to start all over again. On compiler run took about 15 minutes.
I used to program on the C64 using "Power C"... Although it came on 4 disks instead of 10 on your Atari, it required swapping disks up to 10 or 15 times even to compile one file of only 2-3KB, and it took the better of 10 minutes... It also lacked many useful header/libraries so you'd have to write nearly everything yourself. I would assume that your experience on the Atari was meant to be used with a hard drive, but the C64 never even had support for one of those back then, so you had no other options...
In 1989/1990 I had an Amstrad PCW something or other, that I used for writing my projects and doing a bit of PASCAL programming. It only had a single floppy, and wasn't multi-tasking, so had to reboot each time I switched between the editor and the compiler. During a programming session I got overly familiar with quitting without writing; which didn't end well when I switched back to a word processing session.
Man, I felt that 31:44. That's a common sentiment when trying to be productive in janky old programming environments. Thank you for going to the effort of demonstrating this machine doing work.
I REALLY enjoyed this video! Your difficulty reminds me of all the frustration I experienced while learning to program 6502 ASM code on my Apple IIe as a teenager back in the 80s. Congratulations on your progress!
Thank you so much! Programming is difficult no matter what language, but a confusing editor can really make it something that'll push your patience to the max, haha.
@@UsagiElectric BUT ... regardless of how awkward, confusing and rudimentary an interactive editor is, those of us who began programming on punch cards still really appreciate it. Or think about programming on a remote computer through a dial up connection at 300 baud. Or on a teletype terminal that lists the program by printing on paper. In the mid-70's programmers at big companies used terminals for IBM mainframes that were enhanced Selectric typewriters.
I remember actually writing COBOL code onto coding sheets and having them sent away to be entered by operators and compile errors come back the next day. That was in the 1980. Absolutely bonkers. That was British Rail, an old, publicly owned company full of time wasters. I still have no clue what the system was about, and I never got anything useful done there. So ridiculous.
I learned IBM 360 assembly language on punch cards in the late 70's. It was running on a Burroughs 6800 mainframe with a simulator program. You only got 2 compiles per day.
Shaking my head at how you do string assignments! Even 40 years ago this machine was clearly way behind the state of the art. On a PDP-11 under RSTS at that time I was using a full screen editor to create programs in the excellent 'Basic Plus' language. You could still be somewhat productive using those tools today !
This is not to throw shade at the Centurion dev team. They probably only had 2-3 developers for this entire system which as Ken says paid hundreds of mortgages of people during the 70s and 80s.
Ah takes me back to the late 1970s when I was working with a Signetics 2650 8- bit CPU and had nothing more than the 1Kbyte PIPBUG monitor rom as system firmware. All programs had to be written in assembler and then converted to hex codes for keyed entry (ie: hand-assembled). So much work but such a buzz when even the simplest program was debugged and working. Kids today.... 🙂
It’s incredible to be able to see these old tools in action and imagine how people worked back then. The learning curve and the tediousness are such it makes me hard to imagine how they were convinced to put so much money and time into this and get productivity gains.
Programming for the machine was certainly an exercise in mental fortitude, but I think once you got the hang of the editor, it would be a lot easier. However, from an end-user perspective, a lot of the applications are incredibly user friendly and very well written! One thing I didn't touch on in this video (but will in the next), is that writing an executable in CPL is only half of the job. The Centurion actually makes use of an in-depth scripting language called JCL (Job Control Language), and a lot of things like printing to the screen, getting input from the user, making conditional choices, etc. are all handled by JCL, with the script calling the executable only at the end once it's gotten all the necessary information saved in the appropriate places. JCL is even more obtuse and difficult to follow than CPL, but the two together are incredibly powerful!
You definately are! :) Imagine the carpal tunnel and other sores in your hands you'd get after a day of coding with Kompoz on this ancient beast... The lack of an easy command line history in modern shells also sounds painful...
Beautiful video, thank you for that trip down memory lane. When I was a just.starting.out programmer working for ACT in the Milan office, writing the Linkage Editor for the Olivetti A7 minicomputer, 1973, we used coding sheets. That’s right. We wrote out each line of code on a formatted sheet of paper. We could then walk through the proposed code - called it a “code walk-through” and discover various stupid errors. After a number of expresso stops - the coffee was brought up from the bar on the ground floor, in little individual thermos containers - the code could be entered into the machine and since we were good … it often worked first time. That was the most important lesson of coding once upon a time. Go slow, step by step, think it through, and catch mistakes before they occur. Became a mantra of Deming … rework is harder than doing it right the first time. Thank you so much !
Oh wow. I have a ZX Spectrum and Commodore 64. This is PROPER retro, having a mini/mainframe in your workroom and coding like this. Loved seeing it. I started my career on an ICL-ME29 as a Computer Operator running Cobol job streams (if I remember rightly) which moved onto Unix after a couple of year. Great seeing this old kit put to use, and the memory/CPU 'restrictions' showed how much can be gotten through it.
I just had a flashback. In late 80s, I took a computer course in a local college. I was a new EE graduate and I remember I kept swearing at the designers who didn't have any logic for very basic commands. As we said then the commands came from their butt. I left the course the same night. I'm glad the mini computers died in '90s.
I just wanted to express my heartfelt gratitude for all the hard work you put into restoring vintage computer systems. Your expertise as an electronic engineer is truly impressive and your dedication to the craft is admirable. You are a person of great quality and I have no doubt that your contributions to the field will continue to make a positive impact. I hope that this new year brings you all the success and happiness you deserve. Wishing you a happy 2023!
I swear the youtube algorythm is dumber everyday, I litterally searched "1980s coding" several times the last few months and this channel NEVER came up
Congratulations! You are now a programmer! You experienced the total panic of failure, and with a tweak, the thrill of success! Computers are fun like that. After hours of looking at a core dump in COBOL or emulating your app for iPhone, you FINALLY find the bug, and squish it!!! Welcome to The Brotherhood!
Wow, I really enjoyed myself watching this! I'm fairly new to the programming scene and just got my new job as a software engineer. Even though our text editors are so much better today, it amazes me to see how difficult CPL can be just to edit in its environment! You did an awesome job debugging your code. Congrats on making it all work!
As a pascal native programmer i really understsnd the efforts, the suffering but also the joy wen the compiled propgram works. I think it may be very interesting to go trought the machine code to really understand the steps the CPU does during the execution
This was actually day two of filming too! The first day of filming it all feel apart about midway through and I had to come back in to the emulator and spend some time sussing things out. In the end I couldn't use any of the footage from day one, so seeing it actually print the right answer was properly exciting! I believe we could get the full compiled assembly from one of the temp files, but the we still don't actually have a full grasp on the entire ISA, though we're getting a lot closer. It would definitely be interesting to see how the assembly achieves the same thing, but I would also definitely need someone to walk me through it first, haha.
@@KameraShy It evolved. I learnt Pascal at school, being initially designed as an educational language. Then I got my first computer (after using the Intel SDK85, a 6502 kit and an Acorn Atom), a massive 2 drive CP/M beast that came with full Pascal MT+ compiler. Then there was MSDOS and Turbo Pascal, which evolved into Borland Pascal. It is still very much alive as Delphi (Embracadero) and I use it every day to write and maintain the windows configuration software that come with our products.
@@KameraShy Down another branch, Niklaus Wirth after designing Pascal, designed Modula(-2) and then designed Oberon, which is not only a programming language, but also an OS (which he has also designed a RISC chip to run on.)
@@AMcAFaves Down _another_ another branch, Anders Hejlsberg, the guy who created Turbo Pascal, has been at Microsoft for some time, where he created C#.
Suddenly found your channel. I just love it. It’s my whole history of computing . From where you need 32 Amps for a processor to an iPhone. What a journey ! Just love the noise of the fans behind you. I so miss that. All the cooling coming up through the floor. What a pleasure :-) Programming was programming. Oh one of our Integraph pdp11/70 wouldn’t boot. I had to slap the 8.5 inch floppy for it to boot.such fun
Happy New Year and congratulations on your first successful program on the Centurion! Your efforts and frustration remind me of my programming days back in the mid to late 1970's! Brought back a whole load of memories! 😀
Thank you, and Happy New Year to you and yours as well! Y'all were proper programmers back in the day. The necessity to keep the full structure of your program in your head and work from there is something that I'm glad I experienced but certainly not envious of, haha.
@@UsagiElectric 1) If you are going to use a system designed from tape use , better get a tape unit for the machine... 2) For programming I was always taught to write down (pen and paper) what I was going to get typed into the machine - this should help get your structure / " ; etc correct as you can (or get someone else) to step through it and spot errors. Of course you need to check for typos still. 3) It is always worth copying your first saved file to a "backup / ver0.00 " file that you can bring back if you edit the working programme and find you have lost something" (3a the use these days of "undo" as a command or whatever in "apps", is that poss on the likes of these 8 bit systems ?
Lockpicking lawyer would be proud of you. Btw you can disassemble the lock and file a working key from a blank. Or just get the whole lock to a locksmith, and he'll give you a working key from his collection.
@@KameraShy I think the overall theme is to keep everything intact and original, so just getting a key for the lock would mean everything stays genuine. If he can rake it open in one second, that shouldn't be too hard.
Excellent video! This is a milestone! You're right. 90% of the problem is the editor. CPL appears to be influenced by Fortran, but most likely very streamlined for ease of compile. Around that same time, I was working at Control Data Corp with a language called TAC BB2, which I really liked. It was a full featured "Business BASIC". Very easy to use, no hassles with compiling and all those compiler directives. Notably, it lacked floating point math, so all money transactions were done in pennies, and when you printed out, you structured the print with a decimal point. To me, the lack of floating point was not a deficiency. I like that. It avoided rounding errors. All good wishes for 2023.
Don't forget there were at least a couple of computer lines designed specifically to run BASIC, one from HP and the other better known one from Wang. There is at least one video of an HP 250 running- it's a timesharing BASIC system integrated into a small desk with a tiny console monitor, based on the architecture of the HP 9835.
@@lawrencedoliveiro9104 - unless you have a language that supports some kind of infinite precision (which would require an infinite amount of memory) you will always get rounding errors.
Interesting. Since this was intended to be an accounting machine for small business languages such as Fortran and standard Basic were intended for other purposes. COBOL would have been too heavy. PL/I was used in a few shops for business programming but never caught on. It may also have been too much for the Centurion.
Man! That thing is stacked - and a 5MHz CPU too! Had to laugh, I thought you were going to have to hotwire that thing when you said you'd no key - but then to see you actually 'Pick' the lock - priceless. Excellent work dude!
This is a very interesting series, i've never used these kinds of machines, and I find it really informative and exciting. Kudos to all who put in effort to make this happen.
That text editor makes VI look positively user-friendly! And I can see why there was so much demand for BASIC to be ported to different machines back in the day. It's a shame there wasn't a BASIC for the Centurion, that would've made life a lot easier! But I guess it makes sense that a business computer wouldn't need it, since the majority of those computers would just be running one custom made program that all the terminals would access.
I've been in computer programming for 34 years and written code in BASIC to assembly and many languages in between. This video makes me appreciate how rough programmers before me had it. Some of you who hate VIM should be glad you don't have to use Kompoze.
Hadn't heard the name "CPL" spoken for many years - unless I'm getting my wires crossed, it was the foundation that a Z80 development system ran on top of that I once used. And now I know what the letters mean. Thankfully my mission was the Intel assembly code we used it to develop and not dealing with actual CPL, it's native editor or inner workings. Still, my co-workers and I had our share of struggles very similar to what you just went through. I really appreciate how you have fun with this older stuff and you mostly refrain from reminding your audience how dated the technology is - no reminder needed. Your exacerbation and finally triumph was a pretty frequent and common shared experience back then!
LOL, how we used to do things :-) I used work on the Phoenix drives you mentioned attached to Wang 2200 systems, and they were great when they worked, but boy, did they seem to crash a lot! That smell and that awful screeching noise still haunt my nightmares! After a head crash there was the fun of replacing the heads, then getting the damned things aligned. Oh the joys of being mini-computer maintainence engineer! Great video! BTW, at around 21:15 the text on the screen shows strings being declared using " ' STRING ' ", but your voice-over and what you type are in the format ' " STRING " '.
THIS... THIS is where the idea of Computer Programmers being "High Priests" of the machine came from. Look at all the esoteric crazy non-intuitive things you had to do just to write a simple math problem! Thank god we've come so far. Of course, by the 1976 there were the big 3 microcomputers each running BASIC that you could have done the same thing on at home just as fast (ok maybe not AS fast given interpreted BASIC vs compiled code) and a LOT easier!
22:53 - I saw that END LOP - now I know what kind of Usagi is writing tthat program! :) 28:26 Always make a backup! KOMPOZ looks a lot like EDLIN on the old CP/M machines. It probably lets you read in multiple lines from the input tape, work with them in RAM, and then write them out in a bunch. What most programmers did was work mostly with modules that would fit in memory, suck them in at one go, edit them, and then write them out. (Of course, a programmer would boost the amount of user memory available for the edit session. That's why programmers did so much of their work outside business hours on these machines.)
ED, the UNIX ed text editor is the base editor. EDLIN is a Q/Dos alternative, that MS copied in MS DOS too, we all call them ED ! i only wrote routines to export data on Digital system, good tool !
@@lucasrem Yeah, saying EDLIN was a brain fault, it's been a long time. I meant CP/M's ED. It was very different from ED on Unix, which was a lot more convenient. Once they became available, I'd use either RED (Ed Reams's small-C screen editor) or MINCE (Mince Is Not Complete EMACS).
Oh my gawd, a shiver just went down my spine. My first home computer was an Altair 8800 (still have it) but my first business computer was a Centurion by Warrex. Seems to be that same configuration. Same line printer. We switched out printers at some point and I got to take the printer home with me. Also added a tape backup at one point but I had nothing but trouble with it. Programming in CPL was a drudge but they eventually added conditional looping and it allowed me to change my programming style. Eventually I was laid off for economy reasons but got to keep the printer, now lost to history when I had to give up my house.
Wow, this is nostalgia for me, reliving my young programming days again. You are the best! Happy New Year and I wish you good health and lots of retrocode.
It'd be interesting to see the centurion run the Mandelbrot benchmark written by Matt Heffernan to see how it stacks up against 80s 8 bit home systems and also James Sharman's homemade pipelined 8 bit CPU.
Can you imagine not having a CRT to do all this? Instead imagine the frustration of keying into IBM punch cards (with ALL the errors), submitting your stack of cards, and getting a printout the following day. Somehow, that's how we got the Apollo Guidance Computer to get to the Moon and back again.
@@Mueller3D I learned programming that way! It makes you think about the algorithm you want to use and the way that is best coded in the used language, before blindly entering sourcecode and hit "compile&run" until it compiles without syntax errors and appears to run OK. The chance of bugs is decreased doing it that way.
Well actually.... Punching cards AND correcting errors, was not that hard. And always make sure to take a pen and draw a fat line diagonally across your card stack. Ask me how I know.
I was gonna say that substituting a new punch card for one with a different line of code would seem easier. Not like the hardware would eat your cards prior to the place where you made the change. And yes I’ve heard horror stories about dropping a stack of cards. Life is full of trade offs. Must be why in these modern times we’ve got nothing better to do than argue over where to put your curly braces in C/C++ and how many spaces (or just use tabs) etc. etc. 🔥
Boy was that interesting! Watching you go through the torture of editing the program made me appreciate the genius of line numbers in timesharing BASIC in replacing errors. How far we've come in 40 years!
Yea, as someone with a one-line 24-character display, I could really appreciate the use of line numbers to specify where to put a new line or targeting a line to be edited.
i could only imagine his reaction if one of the errors lead to another bad chip somewhere. its good to see this thing doing something thats not an included function, great work.
This seems like a very efficient system. I can't believe that editor didn't require you to acknowledge the disk every 60 seconds and retype everything if you missed an acknowledgement, or that the compiler didn't require you to manually patch the executable for operation at a fixed memory address. At this rate of progress we'll soon have kids operating computers!
It's weird how much it can raise ones heart rate to just watch compiling on RUclips, even with a knowledge that the program will most likely run and function properly by the end of the video.
DUDE - you need to write a FORTH system for this computer. That will open up true multitasking and modern control of the hardware so you can add peripherals. It's pretty much a cookbook procedure to implement a FORTH system when you know the details of the CPU and memory map. Great funny video. Reminds me of struggling with XEDIT only much worse :)
It was so exciting watching the Centurion running code. I really enjoyed this video. Congratulations on the progress and I can't wait to see more developments. Happy New Year!
You certainly have balls of steel! The OS looks a lot like M/PM... It's incredible how people wrote serious systems in these "business" computers in the 70's, 80''s... I remember writing a Pert/CPM program in a TRS-80 and guys using it to control projects with 200-300 activities as the company did not have enough money to pay for IBM Projacs.... These small computers really changed the computing landscape!
Fun blast from the past -- reminded me of writing lots of code for machines like this. From a programmer-of-those-times perspective, your reactions to the kludgy text editor were amusing and deja vu clench-worthy. In our day, we desk-checked our code and made every effort to avoid using the compiler as a debugging tool! The early ASYNC/ASCII character-cell CRTs were effectively paper-free teletypes and nearly useless as text-editing devices (though we wrote lots of code on them), and until the DEC VT-100 came along, there were no standards for full-screen operations, which created a market for word processing and enabled such wonders as in-line editing, etc in the ASCII world. For large projects, some of us continued to rely on unit record devices like card readers
Reminds me of FORTRAN programming on a Perkin Elmer back in the early '90s...the line editor wasn't great, but once you got the hang of it, became perfectly usable....ahh...the days of the 20 minute compiles...hit go, get up and go make another cup of coffee and chat with the co-workers, those were the days.
It was very good how you remembered the obtuse shell commands to operate the compiler and editor. Yes before there were graphics, text based systems were all there were in 1980s. It was like PDP-10, PDP-11 and VAX/VMS which I used at University of Queensland in Australia.
I came across the centurion playlist two days ago when I took a little break from studying for my upcoming exams... let's just say I haven't learned a thing about organic chemistry in the past 48 hours. Thank you for your excellent work, both in terms of the videos and the repair itself!
That editor makes me appreciate vim, as a casual Linux user. I wrote a program in FORTRAN about a year ago just for fun... the experience was very similar to this!
This reminds me sooo much of trying to type in a program from a magazine to a Commodore 64 back in the day. I knew NOTHING about code at the time, so if I had an error, I was screwed! Loving your content lately!!!
Awesome work. As your interaction with the Centurion transitions from getting the hardware running to working at the terminal for long periods, I'd recommend moving the terminal away from the chassis onto a bench. That's how the system would have been used back in the day: you sit at the terminal when it's at desk-height, and the noisy components in the chassis aren't wearing away at your eardrums.
Cool to watch your video, bringing back memories of the days without fancy IDE's and just simple line editors. As a programming teacher one small remark about your program however (cannot help it!): I suggest it is clearer to check if CNT is smaller than 1000 (as stated in the exercise) instead of checking CNT is smaller or equal to 999 (in which you made an implicit thinking step). I really liked the video, and subscribed to your channel!
I also would have programmed it your way as I was taught, thought his was was odd and wondered if there was a reason technical to the Centurion why he did it that way.
@@KameraShy Good point. Maybe the language only has a 'less than or equal' operator, and not a 'less than' operator. For a moment I considered that it had something to do with the maximum integer size together with binary coded decimal representation, but that is unlikely since the answer that is printed at the end is > 1000!
Great video. And I get that the point is not to get the correct answer but to test a program on that device. I just want to point out that of all the Euler problems, the one chosen is really not brute-force friendly. The multiple of 3 are 3,6,9,...,996,999 their sum is obviously 3x(1+2+3+...+333) = 3 x 334 x 333 / 2 = 166,833 The multiple of 5 are 5,10,...,990,995 their sum is obviously 5x(1+2+3+...+199) = 5 x 200 x 199 / 2 = 99,500 we can sum those two values except the multiple of 15 are been counting twice so we have to subtract it once The multiple of 15 are 15,30,...,975,990 their sum is obviously 15x(1+2+3+...+66) = 15 x 67 x 66 / 2 = 33,165 the answer is 166,833 + 99,500 - 33,165 = 233,168 as the computer rightful answered
Way back in the '80s when I had to load my assembler for the Z80 in the ZX Spectrum, it would take 15 minutes to load the assembler from tape, and a split second to crash it. So, you can guess, I did not write too much of that on the ZX Spectrum. Therefore, I had to do a lot of READING to ensure I did not do something that would anger the assembler and crash it. You learn to appease the beast and keep it calm! I preferred to use Spectrum Basic, which was much better, very powerful, just slower. I wrote a full-page word processor in a week and it worked, but you would press a button and wait for the whole screen to update, so I changed a few parameters, and limited it to 3 lines. This is why I called it a periscope editor, although it was easy to use, powerful, and it allowed me to save documents to tape, load it from tape, and print it to a dot-matric printer. Later, I wanted to print it a bit more "normal" instead of the blocky text, so I would send a code to switch the printer to NLQ (Near-letter quality), which is a feature the printer supported. This was all in the manual that came with the printer, so again I had to READ the manual to be able to do this. Boy, those were the days! Thanks for taking me back there to those almost-pioneer days.
The instructions to the compiler at the start of the program are painful but I do appreciate that they are kept with the program and don't need to be remembered and input on the command-line each time the compiler is invoked. About the program itself, the syntax is, well, archaic, but that shouldn't be a surprise, considering. However, archaic or not, one thing that this era of programming lacked was blank lines, every line of code followed the other without any breathing space between them. Coding then was like writing books without paragraphs. UPDATE: It seems the final source code does in fact contain blank lines, but this may simply be because it was written recently by people that know better.
I have been dipping my toe a bit into a few older machines and I do appreciate the effort needed to get them running to the level that you can write a program on them. Today it's a lot easier, but I also think that we have lost some really neat and nice solutions on the way as well.
Yep, as an old timer who first learned to program in the 1970's, that was painful. Lol! All that typing. I recall a co-worker who typed those header blurb's so fast it just sounded like one big splat sound with a very short pause between the next blurb, so as not to overload the keyboard buffer. So you know you gotta find a port for Colossal Cave or Adventure to put on your machine next, right? I think that was practically standard on those machines in that day.
You could do a compromise where the progress indicator is updated only when one of the conditions for the add subroutine is satisfied. This would slow the program down less and fulfill the purpose just as well IMO.
It has been SO MUCH FUN watching you work on this machine! A labor of love and a true contribution to creating a resilient history of these super cool old machines. KUDOS! 👍😁
The mistakes had to make the payoff all the more worth it to know that you wrote new code for a 40-year-old proprietary system that nobody has programmed for in years! I do also hope you covered the bunny's ears for the things that were no doubt said in that "more than a minute" right before you discovered the error. I shared in that hurt. I've been there many times. Thanks for sharing your progress and your pain and have a HAPPY NEWEAR! (Yes, that is a dumb Hellorld joke--I'll see myself out now...)
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Just watched today's video on writing a new CPL program. New CPL source code Complied, Assembled, Linked and ran, great job team. This time last year we just started working on getting the Diag PROM Bd to run the diag, tests, what a year. To the RUclips viewers keep in mind when the Warrrex-Centurion was designed in the 1970's by a small team of people in Richardson, TX. This computer put food on the table and paid the bills for 100's of families for over 10 years. Regards, Ken R.
I grew up in Plano, which is just north of Richardson, from 1976. I remember that area as having a lot of interesting computer tech. There was a supercomputer company there too, and I think that's the one started by Feynman's son. Later this would be the "Telecom Corridor" and it was more about switches and other telecom tech. This is close to where Texas Instruments is located, too.
Interesting to hear. But the name “CPL” makes me twitch a bit, because back in the 1960s it was the name of a British effort to put together a rival to IBM’s PL/I. The name stood for either “Combined Programming Language” or “Cambridge Plus London”, being the names of the two Universities involved in the effort.
The full language as originally conceived was never implemented. But a cut-down version, intended for bootstrapping the full compiler, was put into use and achieved some popularity on various computers as a low-level systems programming language. It was called “BCPL”, which stood for either “Bootstrap CPL” or “Basic CPL”.
Some folks at Bell Labs got hold of this, and saw it had some promise for implementing an operating system they were working on. They created their own, even more cut-down version, which they called “B”. This was then developed further, with the addition of types and structures (which the original BCPL did not have), into another language, called “C”.
And the rest, as they say, is history.
Ken, thank you so much for all your help!
We couldn't have gotten anywhere near this far if it hadn't been for your unbelievably good memory and excellent hardware repair skills!
It’s amazing what you all managed to do in so little time from this non-functional, long-forgotten, entirely proprietary undocumented technology.
You managed to preserve this knowledge and demonstrate it in all its 8bit glory.
Amazing !!!!
So, the O/S is still under copywrite and they don't want to make it freely available. Fair call ..after all they wrote it. What about a hobbyist license? People sling a collective 10$ and they get a license to go play with it. Money gets donated to ..what ever the majority of the still living/interested copywrite owners decree? For 10$ for a hobbyist project ..who wouldn't sling some cash at it all? I certainly would.
the guy who saved that manual deserves a badge of some kind. so much info like that just disappeared
No joke, I maintain a very old computer accounting software at work (mid 80s, I think?) and I’m incredibly lucky they saved the original manuals, and that the one guy who wrote the program is still alive. Unfortunately the manuals are covered in cigarette smoke, but at least they’re there!
@@the48thronin97 Cool story, but maybe you should think about scanning the manual (with OCR).
@@the48thronin97 time to do some migration
The real exciting parts of these old multiuser systems is how they handle simultaneous access to files and databases. When you can run two or more programs that are heavily updating a huge file and the file doesn't get trashed, *that's* when you realize that someone worked very hard on the part of the OS that delegates file access to users.
yep, DOS absolutely couldn't do that at all, you would need novell or something
@@monad_tcp4
Astonishing, I never thought I'd see an editor that makes vi look easy, or at least intuitive. Great job, Kompoz!
You know, *nix systems have an editor of a similar type to Kompoz, called "ed". I believe it was the first editor for Unix. Maybe it's not as bad, but it too makes vi look easy.
@@fllthdcrb "ed" standing for "line editor". It filled the same purpose as compose, but even more stripped back. There was never a UI version of ed, so you always had to rely on the terminal to maintain information
Was developed in the era *before* CRTs and inspired a compose-like version called "ex" with actual UI features (like a text buffer wow). And said ex was further developed so you could edit the buffer directly in a visual manner, creating "vi". Can even use ex-mode in Vim today
Egad! I recall using "ed" to edit data files on a PDP in 1982-84. It was abysmal - I just not realize it at the time.
yeah its funny how when it was unveiled vi was a tremendous advance in user friendliness, but it was also criticized for being wasteful. Terminals and connections were extremely slow and often paper-based so the terseness of interactive programs output was highly valued
the 'ex' syntax is often used in vi. That is what you do when you enter : command, like :q! is how to exit the vi and also how to exit the ex.
This reminds me a little bit of my first C programming attempts on an Atari 520st. I had only one floppy drive. The C compiler from Digital Research was on ~10 floppy disk. You had to put the source code on a separate floppy disk and then switch between the compiler disks (the compiler would tell you which disk to insert) and the source code disk. If you inserted the wrong disk you had to start all over again. On compiler run took about 15 minutes.
I used to program on the C64 using "Power C"...
Although it came on 4 disks instead of 10 on your Atari, it required swapping disks up to 10 or 15 times even to compile one file of only 2-3KB, and it took the better of 10 minutes...
It also lacked many useful header/libraries so you'd have to write nearly everything yourself.
I would assume that your experience on the Atari was meant to be used with a hard drive, but the C64 never even had support for one of those back then, so you had no other options...
In 1989/1990 I had an Amstrad PCW something or other, that I used for writing my projects and doing a bit of PASCAL programming. It only had a single floppy, and wasn't multi-tasking, so had to reboot each time I switched between the editor and the compiler. During a programming session I got overly familiar with quitting without writing; which didn't end well when I switched back to a word processing session.
Man, I felt that 31:44. That's a common sentiment when trying to be productive in janky old programming environments. Thank you for going to the effort of demonstrating this machine doing work.
Me too! Made me actually LOL because I've been there. I bet most of us watching this have been there too.
I REALLY enjoyed this video! Your difficulty reminds me of all the frustration I experienced while learning to program 6502 ASM code on my Apple IIe as a teenager back in the 80s. Congratulations on your progress!
Thank you so much!
Programming is difficult no matter what language, but a confusing editor can really make it something that'll push your patience to the max, haha.
Those were the days!
@@UsagiElectric BUT ... regardless of how awkward, confusing and rudimentary an interactive editor is, those of us who began programming on punch cards still really appreciate it. Or think about programming on a remote computer through a dial up connection at 300 baud. Or on a teletype terminal that lists the program by printing on paper. In the mid-70's programmers at big companies used terminals for IBM mainframes that were enhanced Selectric typewriters.
I remember actually writing COBOL code onto coding sheets and having them sent away to be entered by operators and compile errors come back the next day.
That was in the 1980. Absolutely bonkers. That was British Rail, an old, publicly owned company full of time wasters.
I still have no clue what the system was about, and I never got anything useful done there. So ridiculous.
I learned IBM 360 assembly language on punch cards in the late 70's. It was running on a Burroughs 6800 mainframe with a simulator program. You only got 2 compiles per day.
Shaking my head at how you do string assignments! Even 40 years ago this machine was clearly way behind the state of the art. On a PDP-11 under RSTS at that time I was using a full screen editor to create programs in the excellent 'Basic Plus' language. You could still be somewhat productive using those tools today !
Yeah, that was an amazing editor on the VT100 ... Really hard work if your terminal isn't cursor addressable though.
@@edgeeffect the VT100 was cursor addressable. Once the TPU editor came out editing was easy.
Before that the edit program was all typed commands.
This is not to throw shade at the Centurion dev team. They probably only had 2-3 developers for this entire system which as Ken says paid hundreds of mortgages of people during the 70s and 80s.
@@TesterAnimal1 edt worked quite well with the VT100. Even teco would work in a screen mode.
Ah takes me back to the late 1970s when I was working with a Signetics 2650 8- bit CPU and had nothing more than the 1Kbyte PIPBUG monitor rom as system firmware. All programs had to be written in assembler and then converted to hex codes for keyed entry (ie: hand-assembled). So much work but such a buzz when even the simplest program was debugged and working. Kids today.... 🙂
Well done! You brought back nightmares of my college days. But they were good nightmares.
It’s incredible to be able to see these old tools in action and imagine how people worked back then. The learning curve and the tediousness are such it makes me hard to imagine how they were convinced to put so much money and time into this and get productivity gains.
I don't think it is that hard to learn. It is more boring. You need to make lots of unnecessary steps.
Programming for the machine was certainly an exercise in mental fortitude, but I think once you got the hang of the editor, it would be a lot easier. However, from an end-user perspective, a lot of the applications are incredibly user friendly and very well written!
One thing I didn't touch on in this video (but will in the next), is that writing an executable in CPL is only half of the job. The Centurion actually makes use of an in-depth scripting language called JCL (Job Control Language), and a lot of things like printing to the screen, getting input from the user, making conditional choices, etc. are all handled by JCL, with the script calling the executable only at the end once it's gotten all the necessary information saved in the appropriate places.
JCL is even more obtuse and difficult to follow than CPL, but the two together are incredibly powerful!
How glad I am to have a modern programming language and a modern IDE for coding! Great video about ancient coding!
You definately are! :)
Imagine the carpal tunnel and other sores in your hands you'd get after a day of coding with Kompoz on this ancient beast...
The lack of an easy command line history in modern shells also sounds painful...
Beautiful video, thank you for that trip down memory lane. When I was a just.starting.out programmer working for ACT in the Milan office, writing the Linkage Editor for the Olivetti A7 minicomputer, 1973, we used coding sheets. That’s right. We wrote out each line of code on a formatted sheet of paper. We could then walk through the proposed code - called it a “code walk-through” and discover various stupid errors. After a number of expresso stops - the coffee was brought up from the bar on the ground floor, in little individual thermos containers - the code could be entered into the machine and since we were good … it often worked first time. That was the most important lesson of coding once upon a time. Go slow, step by step, think it through, and catch mistakes before they occur. Became a mantra of Deming … rework is harder than doing it right the first time. Thank you so much !
Oh wow. I have a ZX Spectrum and Commodore 64. This is PROPER retro, having a mini/mainframe in your workroom and coding like this. Loved seeing it. I started my career on an ICL-ME29 as a Computer Operator running Cobol job streams (if I remember rightly) which moved onto Unix after a couple of year. Great seeing this old kit put to use, and the memory/CPU 'restrictions' showed how much can be gotten through it.
The palpable excitement Dave expresses when he gets things working in this video is really heartwarming. :D
I love that you still have to pick the lock every time you want to turn the system on
I just had a flashback. In late 80s, I took a computer course in a local college. I was a new EE graduate and I remember I kept swearing at the designers who didn't have any logic for very basic commands. As we said then the commands came from their butt. I left the course the same night. I'm glad the mini computers died in '90s.
I just wanted to express my heartfelt gratitude for all the hard work you put into restoring vintage computer systems. Your expertise as an electronic engineer is truly impressive and your dedication to the craft is admirable. You are a person of great quality and I have no doubt that your contributions to the field will continue to make a positive impact.
I hope that this new year brings you all the success and happiness you deserve. Wishing you a happy 2023!
I swear the youtube algorythm is dumber everyday, I litterally searched "1980s coding" several times the last few months and this channel NEVER came up
Congratulations! You are now a programmer! You experienced the total panic of failure, and with a tweak, the thrill of success! Computers are fun like that. After hours of looking at a core dump in COBOL or emulating your app for iPhone, you FINALLY find the bug, and squish it!!! Welcome to The Brotherhood!
That is is really good demonstration on how things use to be in the 70’s when it came to programming minis and mainframes
Wow, I really enjoyed myself watching this! I'm fairly new to the programming scene and just got my new job as a software engineer. Even though our text editors are so much better today, it amazes me to see how difficult CPL can be just to edit in its environment! You did an awesome job debugging your code. Congrats on making it all work!
Lukily, editors have much improved since then ;-D
Yyaaaayy, love this. I learned assembly, Cobol and more in 1980 and this is just totally memory lane :-)
"30 minutes of head-scratching later..." Classic programming experience 🤣
As a pascal native programmer i really understsnd the efforts, the suffering but also the joy wen the compiled propgram works. I think it may be very interesting to go trought the machine code to really understand the steps the CPU does during the execution
This was actually day two of filming too! The first day of filming it all feel apart about midway through and I had to come back in to the emulator and spend some time sussing things out. In the end I couldn't use any of the footage from day one, so seeing it actually print the right answer was properly exciting!
I believe we could get the full compiled assembly from one of the temp files, but the we still don't actually have a full grasp on the entire ISA, though we're getting a lot closer. It would definitely be interesting to see how the assembly achieves the same thing, but I would also definitely need someone to walk me through it first, haha.
Wasn't Pascal the wave of the future? What happened to it?
@@KameraShy It evolved. I learnt Pascal at school, being initially designed as an educational language. Then I got my first computer (after using the Intel SDK85, a 6502 kit and an Acorn Atom), a massive 2 drive CP/M beast that came with full Pascal MT+ compiler. Then there was MSDOS and Turbo Pascal, which evolved into Borland Pascal. It is still very much alive as Delphi (Embracadero) and I use it every day to write and maintain the windows configuration software that come with our products.
@@KameraShy Down another branch, Niklaus Wirth after designing Pascal, designed Modula(-2) and then designed Oberon, which is not only a programming language, but also an OS (which he has also designed a RISC chip to run on.)
@@AMcAFaves Down _another_ another branch, Anders Hejlsberg, the guy who created Turbo Pascal, has been at Microsoft for some time, where he created C#.
I just love it when you get all excited and happy 🤩
I appreciate that you always show us at the end that these projects are being properly supervised.
Suddenly found your channel. I just love it. It’s my whole history of computing . From where you need 32 Amps for a processor to an iPhone. What a journey !
Just love the noise of the fans behind you. I so miss that. All the cooling coming up through the floor. What a pleasure :-) Programming was programming. Oh one of our Integraph pdp11/70 wouldn’t boot. I had to slap the 8.5 inch floppy for it to boot.such fun
Enjoying your videos from Japan. Since 2023 is the year of the Usagi in Japan,🐇 May you continue to make great strides. (Like a rabbit jumping)
Vintage computers AND a bit of Lock Picking Lawyer! Love it!
Happy New Year and congratulations on your first successful program on the Centurion! Your efforts and frustration remind me of my programming days back in the mid to late 1970's! Brought back a whole load of memories! 😀
Thank you, and Happy New Year to you and yours as well!
Y'all were proper programmers back in the day. The necessity to keep the full structure of your program in your head and work from there is something that I'm glad I experienced but certainly not envious of, haha.
@@UsagiElectric 1) If you are going to use a system designed from tape use , better get a tape unit for the machine... 2) For programming I was always taught to write down (pen and paper) what I was going to get typed into the machine - this should help get your structure / " ; etc correct as you can (or get someone else) to step through it and spot errors. Of course you need to check for typos still. 3) It is always worth copying your first saved file to a "backup / ver0.00 " file that you can bring back if you edit the working programme and find you have lost something" (3a the use these days of "undo" as a command or whatever in "apps", is that poss on the likes of these 8 bit systems ?
Lockpicking lawyer would be proud of you. Btw you can disassemble the lock and file a working key from a blank. Or just get the whole lock to a locksmith, and he'll give you a working key from his collection.
Or just swap a toggle switch.
Or gut the lock
@@KameraShy I think the overall theme is to keep everything intact and original, so just getting a key for the lock would mean everything stays genuine. If he can rake it open in one second, that shouldn't be too hard.
This video brought back a lot of memories. I loved it at the time but I would never want to go back to that. I'm spoiled rotten now. Thank you
Excellent video! This is a milestone! You're right. 90% of the problem is the editor. CPL appears to be influenced by Fortran, but most likely very streamlined for ease of compile. Around that same time, I was working at Control Data Corp with a language called TAC BB2, which I really liked. It was a full featured "Business BASIC". Very easy to use, no hassles with compiling and all those compiler directives. Notably, it lacked floating point math, so all money transactions were done in pennies, and when you printed out, you structured the print with a decimal point. To me, the lack of floating point was not a deficiency. I like that. It avoided rounding errors. All good wishes for 2023.
Don't forget there were at least a couple of computer lines designed specifically to run BASIC, one from HP and the other better known one from Wang. There is at least one video of an HP 250 running- it's a timesharing BASIC system integrated into a small desk with a tiny console monitor, based on the architecture of the HP 9835.
So how did you avoid rounding errors in interest calculations?
@@lawrencedoliveiro9104 - unless you have a language that supports some kind of infinite precision (which would require an infinite amount of memory) you will always get rounding errors.
Interesting. Since this was intended to be an accounting machine for small business languages such as Fortran and standard Basic were intended for other purposes. COBOL would have been too heavy. PL/I was used in a few shops for business programming but never caught on. It may also have been too much for the Centurion.
Man! That thing is stacked - and a 5MHz CPU too! Had to laugh, I thought you were going to have to hotwire that thing when you said you'd no key - but then to see you actually 'Pick' the lock - priceless. Excellent work dude!
This is a very interesting series, i've never used these kinds of machines, and I find it really informative and exciting.
Kudos to all who put in effort to make this happen.
LPL would be so proud of ya for picking the lock like a boss with that wave rake.
Goodness, I felt each one of those errors in my soul. Good for you for figuring this all out.
That text editor makes VI look positively user-friendly! And I can see why there was so much demand for BASIC to be ported to different machines back in the day. It's a shame there wasn't a BASIC for the Centurion, that would've made life a lot easier! But I guess it makes sense that a business computer wouldn't need it, since the majority of those computers would just be running one custom made program that all the terminals would access.
VI is user friendly - compared to edlin, lined, TECO or any similar line based block editors of the time.
There’s nothing wrong with vi(1) 😊
I've been in computer programming for 34 years and written code in BASIC to assembly and many languages in between. This video makes me appreciate how rough programmers before me had it. Some of you who hate VIM should be glad you don't have to use Kompoze.
Hadn't heard the name "CPL" spoken for many years - unless I'm getting my wires crossed, it was the foundation that a Z80 development system ran on top of that I once used. And now I know what the letters mean. Thankfully my mission was the Intel assembly code we used it to develop and not dealing with actual CPL, it's native editor or inner workings. Still, my co-workers and I had our share of struggles very similar to what you just went through. I really appreciate how you have fun with this older stuff and you mostly refrain from reminding your audience how dated the technology is - no reminder needed. Your exacerbation and finally triumph was a pretty frequent and common shared experience back then!
LOL, how we used to do things :-) I used work on the Phoenix drives you mentioned attached to Wang 2200 systems, and they were great when they worked, but boy, did they seem to crash a lot! That smell and that awful screeching noise still haunt my nightmares! After a head crash there was the fun of replacing the heads, then getting the damned things aligned. Oh the joys of being mini-computer maintainence engineer!
Great video! BTW, at around 21:15 the text on the screen shows strings being declared using " ' STRING ' ", but your voice-over and what you type are in the format ' " STRING " '.
Ahah! I should have waited for the end of the video, LOL ;-)
It is so satisfying to write on those older keyboards. One must respect those old first programmers. wow
THIS... THIS is where the idea of Computer Programmers being "High Priests" of the machine came from. Look at all the esoteric crazy non-intuitive things you had to do just to write a simple math problem! Thank god we've come so far. Of course, by the 1976 there were the big 3 microcomputers each running BASIC that you could have done the same thing on at home just as fast (ok maybe not AS fast given interpreted BASIC vs compiled code) and a LOT easier!
It is more like 1977 when that happened... and a lot happened in a year in those days.
Love the 'dance for joy' when the program finally compiles and gives an answer. I remember doing many of those learning programming.
You opened some very old memories. Lots of head banging. I loved the video.
22:53 - I saw that END LOP - now I know what kind of Usagi is writing tthat program! :)
28:26 Always make a backup!
KOMPOZ looks a lot like EDLIN on the old CP/M machines. It probably lets you read in multiple lines from the input tape, work with them in RAM, and then write them out in a bunch. What most programmers did was work mostly with modules that would fit in memory, suck them in at one go, edit them, and then write them out. (Of course, a programmer would boost the amount of user memory available for the edit session. That's why programmers did so much of their work outside business hours on these machines.)
On CP/M, I would always use WordStar in non document mode to avoid the horrors of line editors.
True programmer still do their Windows coding with EDLIN!😉
ED, the UNIX ed text editor is the base editor.
EDLIN is a Q/Dos alternative, that MS copied in MS DOS too, we all call them ED !
i only wrote routines to export data on Digital system, good tool !
@@lucasrem Yeah, saying EDLIN was a brain fault, it's been a long time. I meant CP/M's ED. It was very different from ED on Unix, which was a lot more convenient. Once they became available, I'd use either RED (Ed Reams's small-C screen editor) or MINCE (Mince Is Not Complete EMACS).
@@lucasrem There was also VI, and then later on VIM
Kidding aside: super-kudos for solving an Euler challenge on the Centurion.
I spent my time 30 years ago making a progress bar where the “>” went across the screen. Oh how time flies. You did brilliant 35:37
Oh my gawd, a shiver just went down my spine. My first home computer was an Altair 8800 (still have it) but my first business computer was a Centurion by Warrex. Seems to be that same configuration. Same line printer. We switched out printers at some point and I got to take the printer home with me. Also added a tape backup at one point but I had nothing but trouble with it.
Programming in CPL was a drudge but they eventually added conditional looping and it allowed me to change my programming style.
Eventually I was laid off for economy reasons but got to keep the printer, now lost to history when I had to give up my house.
Wow, this is nostalgia for me, reliving my young programming days again. You are the best! Happy New Year and I wish you good health and lots of retrocode.
I'm glad someone is working on a basic text editor. That makes all the difference in the world.
It'd be interesting to see the centurion run the Mandelbrot benchmark written by Matt Heffernan to see how it stacks up against 80s 8 bit home systems and also James Sharman's homemade pipelined 8 bit CPU.
+1, totally agree
Sure but are *you* going to type that in using that terrible editor?
I'd actually do this with both assembly and CPL, like the benchmarks
@@Vanders456 Writing from a modern PC to a floppy maybe?
@@Vanders456 porting nano might be necessary first.
Can you imagine not having a CRT to do all this? Instead imagine the frustration of keying into IBM punch cards (with ALL the errors), submitting your stack of cards, and getting a printout the following day. Somehow, that's how we got the Apollo Guidance Computer to get to the Moon and back again.
Well, the nice thing about punch cards is that they typically don't just disappear into the ether like bits in RAM can 🙂
@@Mueller3D I learned programming that way! It makes you think about the algorithm you want to use and the way that is best coded in the used language, before blindly entering sourcecode and hit "compile&run" until it compiles without syntax errors and appears to run OK.
The chance of bugs is decreased doing it that way.
@@Mueller3D You sure get a mess if you drop your punch cards though.
Well actually.... Punching cards AND correcting errors, was not that hard.
And always make sure to take a pen and draw a fat line diagonally across your card stack. Ask me how I know.
I was gonna say that substituting a new punch card for one with a different line of code would seem easier. Not like the hardware would eat your cards prior to the place where you made the change.
And yes I’ve heard horror stories about dropping a stack of cards. Life is full of trade offs. Must be why in these modern times we’ve got nothing better to do than argue over where to put your curly braces in C/C++ and how many spaces (or just use tabs) etc. etc. 🔥
Will watch it this night! I LOVE YOUR Minicomputer videos! 🥰
Man, congratulations. You got a lot more patience than I will ever have.
Congrats on getting your program to run. Now all you need is for someone to port TECO to the Centurion. :)!
Boy was that interesting! Watching you go through the torture of editing the program made me appreciate the genius of line numbers in timesharing BASIC in replacing errors. How far we've come in 40 years!
Yea, as someone with a one-line 24-character display, I could really appreciate the use of line numbers to specify where to put a new line or targeting a line to be edited.
i could only imagine his reaction if one of the errors lead to another bad chip somewhere.
its good to see this thing doing something thats not an included function, great work.
This seems like a very efficient system. I can't believe that editor didn't require you to acknowledge the disk every 60 seconds and retype everything if you missed an acknowledgement, or that the compiler didn't require you to manually patch the executable for operation at a fixed memory address. At this rate of progress we'll soon have kids operating computers!
It's weird how much it can raise ones heart rate to just watch compiling on RUclips, even with a knowledge that the program will most likely run and function properly by the end of the video.
I'm getting serious COBOL flashbacks watching this.... my eye is twitching... UGH... the IDIOTIC way we did things back in the 70's...
Ha ha ha. Oh I hated COBOL in the day.
I have to use COBOL still, it’s insane.
@@DrHughJohnson yeah I’d be finding another job!
I don't think I ever managed to actually compile in COBOL. I switched to Pascal which I still write to this day for my job.
Complies Only By Odd Luck. According to my father that was the feeling, he was very happy to be rid of it.
DUDE - you need to write a FORTH system for this computer. That will open up true multitasking and modern control of the hardware so you can add peripherals. It's pretty much a cookbook procedure to implement a FORTH system when you know the details of the CPU and memory map. Great funny video. Reminds me of struggling with XEDIT only much worse :)
Wow, when you consider what shape the system was in originally, this is really some achievement. Well done.
It was so exciting watching the Centurion running code. I really enjoyed this video. Congratulations on the progress and I can't wait to see more developments. Happy New Year!
You certainly have balls of steel! The OS looks a lot like M/PM... It's incredible how people wrote serious systems in these "business" computers in the 70's, 80''s... I remember writing a Pert/CPM program in a TRS-80 and guys using it to control projects with 200-300 activities as the company did not have enough money to pay for IBM Projacs.... These small computers really changed the computing landscape!
Oh my god, I've been watching since the first few videos.
Keep up the good work!
Man what a cool channel. Also I died laughing when you pulled out the lockpicking tools to turn this thing on.
Takes me back more years than I care to remember, and my first efforts at programming. 👍
This video is such an accurate display of what programming is like :-D
Fun blast from the past -- reminded me of writing lots of code for machines like this. From a programmer-of-those-times perspective, your reactions to the kludgy text editor were amusing and deja vu clench-worthy. In our day, we desk-checked our code and made every effort to avoid using the compiler as a debugging tool! The early ASYNC/ASCII character-cell CRTs were effectively paper-free teletypes and nearly useless as text-editing devices (though we wrote lots of code on them), and until the DEC VT-100 came along, there were no standards for full-screen operations, which created a market for word processing and enabled such wonders as in-line editing, etc in the ASCII world. For large projects, some of us continued to rely on unit record devices like card readers
Watching you use kompoz makes me glad we have tools such as vi these days.
Nice work, this is a beautiful computer. Just look at 15:48 - the keyboard is lovely. Well done!
Reminds me of FORTRAN programming on a Perkin Elmer back in the early '90s...the line editor wasn't great, but once you got the hang of it, became perfectly usable....ahh...the days of the 20 minute compiles...hit go, get up and go make another cup of coffee and chat with the co-workers, those were the days.
It was very good how you remembered the obtuse shell commands to operate the compiler and editor. Yes before there were graphics, text based systems were all there were in 1980s. It was like PDP-10, PDP-11 and VAX/VMS which I used at University of Queensland in Australia.
I came across the centurion playlist two days ago when I took a little break from studying for my upcoming exams... let's just say I haven't learned a thing about organic chemistry in the past 48 hours.
Thank you for your excellent work, both in terms of the videos and the repair itself!
I'd been growing impatient waiting for a new video on the Centurion. Always an interesting topic.
After having watched the whole video, I think you need someone to write a port of vi for the Centurion.
Thank you for a 36 minute summary of my entire career.
Oh my gosh...I'm getting the shakes remembering how challenging it was to program even the most basic programs in the early '80s! Well done!
That editor makes me appreciate vim, as a casual Linux user.
I wrote a program in FORTRAN about a year ago just for fun... the experience was very similar to this!
This reminds me sooo much of trying to type in a program from a magazine to a Commodore 64 back in the day. I knew NOTHING about code at the time, so if I had an error, I was screwed! Loving your content lately!!!
At least editing programs was easier on the C64!
Awesome work.
As your interaction with the Centurion transitions from getting the hardware running to working at the terminal for long periods, I'd recommend moving the terminal away from the chassis onto a bench. That's how the system would have been used back in the day: you sit at the terminal when it's at desk-height, and the noisy components in the chassis aren't wearing away at your eardrums.
And with a bit of luck, you might be able to use the Centurion terminal with the PDP-11. Two birds, one stone.
Screen and characters are so beautiful!!
What a great tutorial for all the Centurion user out there!
Cool to watch your video, bringing back memories of the days without fancy IDE's and just simple line editors. As a programming teacher one small remark about your program however (cannot help it!): I suggest it is clearer to check if CNT is smaller than 1000 (as stated in the exercise) instead of checking CNT is smaller or equal to 999 (in which you made an implicit thinking step).
I really liked the video, and subscribed to your channel!
I also would have programmed it your way as I was taught, thought his was was odd and wondered if there was a reason technical to the Centurion why he did it that way.
@@KameraShy Good point. Maybe the language only has a 'less than or equal' operator, and not a 'less than' operator. For a moment I considered that it had something to do with the maximum integer size together with binary coded decimal representation, but that is unlikely since the answer that is printed at the end is > 1000!
Great video. And I get that the point is not to get the correct answer but to test a program on that device. I just want to point out that of all the Euler problems, the one chosen is really not brute-force friendly.
The multiple of 3 are 3,6,9,...,996,999 their sum is obviously 3x(1+2+3+...+333) = 3 x 334 x 333 / 2 = 166,833
The multiple of 5 are 5,10,...,990,995 their sum is obviously 5x(1+2+3+...+199) = 5 x 200 x 199 / 2 = 99,500
we can sum those two values except the multiple of 15 are been counting twice so we have to subtract it once
The multiple of 15 are 15,30,...,975,990 their sum is obviously 15x(1+2+3+...+66) = 15 x 67 x 66 / 2 = 33,165
the answer is 166,833 + 99,500 - 33,165 = 233,168 as the computer rightful answered
Way back in the '80s when I had to load my assembler for the Z80 in the ZX Spectrum, it would take 15 minutes to load the assembler from tape, and a split second to crash it.
So, you can guess, I did not write too much of that on the ZX Spectrum.
Therefore, I had to do a lot of READING to ensure I did not do something that would anger the assembler and crash it.
You learn to appease the beast and keep it calm!
I preferred to use Spectrum Basic, which was much better, very powerful, just slower.
I wrote a full-page word processor in a week and it worked, but you would press a button and wait for the whole screen to update, so I changed a few parameters, and limited it to 3 lines.
This is why I called it a periscope editor, although it was easy to use, powerful, and it allowed me to save documents to tape, load it from tape, and print it to a dot-matric printer.
Later, I wanted to print it a bit more "normal" instead of the blocky text, so I would send a code to switch the printer to NLQ (Near-letter quality), which is a feature the printer supported.
This was all in the manual that came with the printer, so again I had to READ the manual to be able to do this.
Boy, those were the days!
Thanks for taking me back there to those almost-pioneer days.
Brings back so many memories! I was the only undergrad at university that had the key code to the PDP11-23 "lab"
That is amazing that the company that made the computer made the OS and programing language.
The instructions to the compiler at the start of the program are painful but I do appreciate that they are kept with the program and don't need to be remembered and input on the command-line each time the compiler is invoked.
About the program itself, the syntax is, well, archaic, but that shouldn't be a surprise, considering.
However, archaic or not, one thing that this era of programming lacked was blank lines, every line of code followed the other without any breathing space between them. Coding then was like writing books without paragraphs.
UPDATE: It seems the final source code does in fact contain blank lines, but this may simply be because it was written recently by people that know better.
Omg, such a blast from the past. I started on Minicomuters and terminals ...
So enjoyable this video. So relatable from times gone by. I could have watched this in real time to share your pain!
I have been dipping my toe a bit into a few older machines and I do appreciate the effort needed to get them running to the level that you can write a program on them.
Today it's a lot easier, but I also think that we have lost some really neat and nice solutions on the way as well.
Yep, as an old timer who first learned to program in the 1970's, that was painful. Lol! All that typing. I recall a co-worker who typed those header blurb's so fast it just sounded like one big splat sound with a very short pause between the next blurb, so as not to overload the keyboard buffer. So you know you gotta find a port for Colossal Cave or Adventure to put on your machine next, right? I think that was practically standard on those machines in that day.
For comparison this program, written in Fortran 77 and run on my PDP11/73 takes 2.45 secs with progress indicator and 0.61 secs without indicator.
You could do a compromise where the progress indicator is updated only when one of the conditions for the add subroutine is satisfied. This would slow the program down less and fulfill the purpose just as well IMO.
I truly remember this enjoyment. It’s palpable.
It has been SO MUCH FUN watching you work on this machine! A labor of love and a true contribution to creating a resilient history of these super cool old machines. KUDOS! 👍😁
Watching now makes my insides twist and squirm. Coding on the PDP 8 at the time was exciting.
The mistakes had to make the payoff all the more worth it to know that you wrote new code for a 40-year-old proprietary system that nobody has programmed for in years! I do also hope you covered the bunny's ears for the things that were no doubt said in that "more than a minute" right before you discovered the error. I shared in that hurt. I've been there many times. Thanks for sharing your progress and your pain and have a HAPPY NEWEAR! (Yes, that is a dumb Hellorld joke--I'll see myself out now...)
15:07 I jokingly said "Outer Planets Alliance" in my head right before you said the same thing lmfao I can't even right now. xD