Your kids' chances of becoming programmers? ZERO Almost overnight in the early 1980s, hordes of British kids embraced programming, as did many adults, delivering the most IT-literate workforce in the world. It was a big reason why the nosediving economy of the '70s and '80s didn’t crash and burn. Well, that or Thatcherism, you choose. Why BASIC? In the early 1970s and early …
As opposed to the 6502 where you could basically treat the first 256 bytes of memory as registers, it had hidden instructions (see http://www.ataripreservation.org/websites/freddy.offenga/illopc31.txt) and could perform memory to memory moves at least as fast as the Z80.
I programmed both at assembler level and generally prefered the 6502. The 6809 was better and the 68000 made them both look like complete crap.
This post has been deleted by its author
Woah there! It was just a light-hearted nostalgic post.
No need to take if personally! It's not a competition! Those days were over 25 years ago (and my beloved Z80 ZX spectrum won! woooohooo! Mwwwwahahaha)
Incidently, I also did 6502 assembler (I used it to hack the school econet system), but seeing as it didn't power the speccy.... :-)
What made Page 0 really special on the 6502 was the ability to treat any pair of bytes as a vector, and jump using a 2 byte instruction (one for the op code, the other for the address in page 0) to anywhere in the systems address space very quickly. Because this was used extensively in the BBC Micro OS for almost all OS calls (see the Advanced BBC Micro User Guide), it mean that you could intercept the OS call and do something else instead (it was called re-vectoring).
I used this many times. For example, in Econet 1.2, all file I/O (but not loading programs) across the network was done a byte at a time (very slow, and crippled the network, which only ran at around 200Kb/s anyway). I wrote a piece of intercept code which would re-vector OSREAD and OSWRITE so that they would buffer the file a page (256 bytes) at a time (IIRC I hijacked the cassette file system and serial buffers to hold the code and the buffered page), which sped things up hugely. Could only do one file at a time, but would handle random access files correctly.
When used with the Acorn ISO Pascal ROMs, it sped up compiling a program from disk from a couple of minutes to seconds, and meant that it was possible for a whole class to be working in our 16 seat BBC Micro lab at the same time.
Talking about ISO Pascal, which came on 2 ROMs, I also re-vectored the Switch ROM vector (can't remember it's name) so that I could load the editor and runtime ROM into sideways RAM, edit the Pascal program, issue a compile command (which would switch to the compiler ROM), and have it overwrite the editor/runtme ROM image with the compiler ROM image, compile the code, and then switch back after the compile was finished. Great fun! Infringing on Copyright, of course, but meant that I could work in Pascal on my BEEB that did not have the ROMs installed!
The problem with may of the complex instructions on the Z80 was that they took so many T-states to execute. This meant that on paper, a 4MHz Z80 looked like it should outperform a 2MHz 6502, but as the average Z80 instruction took 3.5 T-states, a 6502 clocked at half the speed, with an average of 1.5 T-states per instruction could run more instructions in the same time.
This meant that with careful programming, it was often possible to get functionally identical code running faster on the 6502 than on a Z80. It was horses for courses, of course, but many of the sorts of things that these processors would be running would be integer, simple data handling or block memory problems that did not need the more powerful instruction set of the Z80 anyway. I've commented on this with a worked example before here
But this comes back to the crux of the article. In order to get the best out of the machines back then, it was necessary to know the instruction set very well. And this is what is missing in today's programmers.
A 6502 couldn't average 1.5 T-states per instruction - it was guaranteed to only access memory every other tick of the clock, so there were always at least two ticks between instructions.
In theory, this meant you could have two 6502s accessing memory alternately for an early dual CPU system. I think at least one system did, but this was a trick the main micros missed.
In order to get the best out of the machines back then, it was necessary to know the instruction set very well.
And It was indeed possible by a single person to know that instruction set very well. The entire documentation for the Z80 instruction set was a slim book, from memory, about 80 pages. The complete hardware documentation was, again from memory, 250 pages. Fat, but one did not have to read the whole thing only the first part on IRQ's and the 1-2 peripheral's one would use.
Now, on a modern CPU, just the section on how to configure the memory controller is the size of those to books together and you have to read all that crap + the errata's to get that sucker to boot!
Yes, a 4MHz Z80 and a 2MHz 6502 were roughly on an equal footing. But at the time, in the home machines, the 6502 and family were clocking in at less than 1MHz, so they turned out with about half the grunt of the Z80-based machines at 3.5-4MHz.
Although Sinclair blew its advantage by sticking one of the slowest BASIC interpreters ever on its ROMs...
LDIR? Nah mate, you wanna chuck the stack pointer around and use POP and PUSH to shift 16 bytes at a time. Waaaay faster on a Z80, and leaves a 6502 standing still. Just make sure SP is back where it should be before an interrupt occurs...
Huh? What did I just type? Damn, channelling Joffa again. Lucky I've got that exorcist on speed dial...
EIEIO on the 6502? You jest. It's the PowerPC "Enforce Instruction Execution In Order" opcode. It *might* go back as far as IBM's 801 processor, or more likely the original POWER ISA, but no further. The first time you're liable to have come across this unless you were doing low level AIX development on IBM hardware is when the first PowerPC Macs came out in 1994. About ten years after the 6502 was commonplace.
"EIEIO on the 6502? You jest. It's the PowerPC "Enforce Instruction Execution In Order" opcode."
Hmm, my memory is failing.
The mnemonic expands to the same wording, but I've definitely not done any assembly code on PowerPC (not done any at all for at least 15 years tbh,) so it must have existed on an earlier platform. It could have been 68000 I suppose.
Indeed. I used mine from when I got it (second hand) in 86, until I moved to the states 10 years ago. used DRS to run all my businesses, had the floppy, boxes of tapes, and even went to the last dragon store (above a shop in Valetta, Malta) in the early 90s to pick up more stuff.
Heady days...
>> There were almost no books on programming, I worked out most of the syntax of DEC BASIC from the error messages.
I think that I still have a 1975 DECsystem-10 Basic manual in my garage ... can I send you a copy?
But more seriously, my early programming experience at school from 1973 was learning Algol-60 from an ICL Manual and using the formal Algol-60 Revised Report (in BNF) as bedtime reading. Weekly job turn round from the local technical college using mark-sense punch cards, eventually graduating to using the sixth-form 'Wednesday Sports afternoon' to visit the college to use their proper punch card machine and get a couple of jobs run each week.
Sad isn't it?
But more seriously, my early programming experience at school from 1973 was learning Algol-60 from an ICL Manual and using the formal Algol-60 Revised Report (in BNF) as bedtime reading.
May be an apochryphal story but I recollect hearing that the original Algol-60 compiler developers used a parser generator which generated the progam parsing code from the BNF description .... and initially it had a single error message which simply stated "Not a valid Algol-60 program"
My school had an Elliott 803 (with expanded memory, floating-point unit etc. etc.) and Algol60.
I remember a couple of the Algol error messages, and the OP got one of them (not a valid Algo60 program). Another amusing one was "Program too large or complex to be compiled at all'
I tried to write an Algol program specifically to generate that error message but I never quite succeeded.
original Algol-60 compiler developers used a parser generator
Sure, why not? That's the way Yacc worked (and Bison still does). For a while there parser generators were all the rage (perhaps inspiring the quip "I'd rather write programs to write programs than write programs" by Dick Stiles). It seemed to me at the time that compiler design/implementation was the way of the future, so I wrote a 6502 assembler in first year in college and a full compiler for a Pascal-like language a couple of years later (in Yacc, and using Zortech C's linker and maths library for the runtime part). The compiler was less than 1,500 lines of code/comments thanks to Yacc and being able to piggy-back on the Zortech linker and runtime libraries.
Never got a job where my compiler skills were even remotely relevant, but it taught me a lot and I still find it quite interesting. So much so that I've recently been re-reading parts of the Dragon book and my old assembler/compiler code. For fun.
No - I think that you're right. I was taught at Manchester by a Dr Lindsey in the mid 80s who was a complete Algol bigot. He forced us to use Algol-68 (the pain, the pain). He used to proudly tell us that the whole Algol 68 language could be validated using the BNF parser and so it was impossible to write incorrect programs. What is didn't say was that it was pretty well impossible to write any programs at all the syntax was so convoluted.
Still have the Algol 60 "Days and Dates" program which calculates what day a particular date fell on. Wrote it in 1965. Mind you, I did work at a place that had a computer we ops could use when there was nothing to run on night shift.
But seriously, CompSci students can't write programs? Could be that language compilers are not so readily available, or are not so cheap these days. I stopped buying Visual Basic when MS wrapped it up in a big package, Visual Studio, that was nothing to do with what I wanted.
Even in my 50s I wasn't at all impressed with the CompSci graduates I worked with as they seemed to know little about software engineering, nor the reasons why we had to develop it in the first place. Prof Dijkstra, Michael Jackson, James Martin, and other legendary figures are completely unknown to them. Also such historic events as "the software crisis" that led to the foundation of software engineering as a serious profession in the first place.
No, sadly it's only about cushy well paid careers and big fat pay checks for minimum effort.
>No, sadly it's only about cushy well paid careers and big fat pay checks for minimum effort.
Be careful painting with that broad brush. I have seen Baby Boomer coders that even after many decades weren't worth a shit and have also left nothing but a lifetime of spaghetti code behind every job they hopped after a few years.
This post has been deleted by its author
The reference implementation of the C compiler costs £0 including full Source Code.
Exactly! I doubt that there are any current languages for which you can't get a free compiler. Many of them offer a free IDE. In the Java world, it's a battle between four or five IDEs that are either entirely free or offer a free version. I think Microsoft offer some sort of .NET freebie. If you're truly perverse and you search hard enough I bet you can even get COBOL free.
This post has been deleted by its author
But seriously, CompSci students can't write programs? Could be that language compilers are not so readily available, or are not so cheap these days.
No. Python is available for free on Windows and Linux systems alike. http://www.python.org/download . Python is a perfect first language: well-structured, lots of libraries, and interpreted.
Most people are no longer interested. Sad but true. I don't feel it's just programming. rather, that the whole state school system is broken, and now exists to crush all inquisitiveness and initiative out of kids so that they can become drooling compliant consumers. Exams no longer require thought or understanding, just regurgitation of memorized texts.
Obviously I don't know what you are going to put in the second article yet but I refute the title - it has been true for the last two decades but look at the new National Curriculum which has Real Computer Science and Programming at every level from KS1 up.
Actually it's not even completely true now - there are kids out there who have found their own way into C++ games development, ObjC/Java mobile apps or Raspberry Pi Python hacking. I've met them in schools and have had some as work experience - every bit as keen to learn the deep stuff as we were in 1980.
This kind of "ain't like the good old days" 80's nostalgia is all well and good but it's getting old hat. What's needed now is a concerted positive effort from education and us in industry to fix it. Schools are crying out for help - Google "STEM Ambassador" or just go and talk to your local school's head of ICT who is probably panicking right now. Learn some Greenfoot (Java) and Scratch (drag-and-drop) and get out there!
"This kind of "ain't like the good old days" 80's nostalgia is all well and good but it's getting old hat" - the problem these days is twofold:
Firstly, the entry barrier is a lot higher for someone with almost zero knowledge. Back in the 80s, you switched on your machine, the BASIC prompt would come up and off you went, usually with something like:
10 PRINT "Hello World!"
20 GOTO 10
RUN
... which would work, leaving you thinking "yeah!", encouraging further experimentation. Whereas now (assuming you have a bog-standard Windows PC from a high street outlet), you need to hook up to the web, and download and install your programming tools - so there's scope for things to go wrong before you've even written a line of code (remember, I'm assuming near zero experience)! Very discouraging, and bound to put a lot of people off...
Secondly - as I've mentioned elsewhere - is what the fledgling programmer can achieve versus their expectations. Back in the 80s, games were all blocky graphics and bleepy sound - once you had mastered cursor positioning and printing special characters in different colours, it didn't feel like a huge leap to make. Whereas now, kids are brought up on a diet of Call of Duty and Grand Theft Auto, so they expect to be able to make similar - and then stop when they realise just how much work is involved.
I'm not saying that all are put off - but it's certainly a lot more difficult these days.
"Firstly, the entry barrier is a lot higher for someone with almost zero knowledge. Back in the 80s, you switched on your machine, the BASIC prompt would come up and off you went, usually with something like:
10 PRINT "Hello World!"
20 GOTO 10
RUN"
That's a very good point. Although in UNIX land you have shell scripting available by default - but the barrier for entry there is UNIX rarely come with a quickstart guide telling you how to write your first shell script so your point still stands (unfortunately).
VBScript is available by default in Windows too (though there's no GOTO in VBScript, so your 2 liner becomes a 3 liner, with a Do or While loop around the wscript.echo "Hello World!" statement)
What you can't easily do with VBScript at the command line that you could do with BASIC 25 years ago is move the cursor around the screen (though you can run your script in a web page if you want to write your own version of Snake).
It's not that bad - programming tasks may still be appealing to kids. It really depends.
Some good examples: Forth computer in Minecraft, Colobot, Mindstorms. Sufficiently easy, starting to yield sense of achievement right away, and yet allow to get a hang of algorithmic thinking. After that, it's quite likely that next Christmas wish is going to be an Arduino or Raspberry.
But yes, abundance of ready-made things has taken its toll. If there's an app for everything, why bother?
> Firstly, the entry barrier is a lot higher for someone with almost zero knowledge.
LOL NO!
One word: Documentation. And: Actually getting your hand on a machine. With a screen. And some software. And maybe an assembler
In 80s: FARK OFF, KIDDO.
Now: PLENTY, WHERE YOU YOU WANNA START?
Really, considering the "barrier of entry" today to be higher is like pining for the good old pre-capitalistic times were man and beast lived happily together and you died from a toothache at 30.
"Don't you DARE downvote me, fracking kids. I have burnt through more keyboards than you have had anniversaries.
I upvoted you, but of course you know that a comment like that is like a red rag to a bull with those downvoters!
Yes, documentation is much better these days - In the early 90's, I basically taught myself Unix using the man pages. These seemed brilliant to me - all the information I'd require readily at hand.
However, I'm actually quite glad I didn't have access to more information - back then, if I got stuck, I'd have to work it out - now you just Google it!
"Now get off my fracking lawn!"
Sigh, those energy companies will do anything these days to find new sources of natural gas! :-)
I still use scripting tools reminiscent of BASIC in order to write simple programs to do things that aren't already pre-packaged for me in some higher level language with a nice shiny happy GUI. I also automate non-GUI tools in order to deal with tasks more effectively than I would be able to in a GUI.
In some ways, the allegedly new and better suffers from the same old problems. Except now there's shiny graphics to distract you from the problem. We try to convince ourselves that things a "different and better" when quite often they are mostly just prettier.
Also, GUIs are often not recognized as such just because they aren't pretty enough.
In the old days...
"I want to learn programming! Ah, I see. BASIC is the language. There's also this thing called machine language that I might look at. Let's get stuck in."
In the new days...
"I want to learn programming! Ah... OK, what do I use? There's Basic, C, C++, C#, Java, Perl, Python, Go, Dalvik, Objective C, Lisp... How do I choose?"
[@davtom, choice of language]
That's easy - Java in Greenfoot (www.greenfoot.org). Not a perfect first contact language maybe (Python probably shares that with BASIC in terms of PRINT 2+2, and LOGO was hard to beat) but teaching good concepts and more importantly, a brilliant mini-IDE with a sprite-based world to make games in and a wealth of teaching materials and support forums. And it's free and runs on anything. Next question?
(it would be interesting to know how many people whinging about access being too hard and capability too limited have ever even heard of Greenfoot, or have seen kids playing with it)
Okay, getting hold of a machine was a bit more of a chore, I'll give you that. But documentation? Really?
Like I said, when I started programming, I started off with my "How to write programs" Usborne book and just switched on my computer and typed in the first listing which - due to its simplicity - worked, as did many of the others, regardless of the fact that the book in question was for BBC BASIC and I was using an Amstrad CPC.
Yes, when I got a bit more advanced, things got trickier. But by that time, I was well and truely into it, and had no fear of trawling through my manuals and trying a few random things to see what worked.
But now - wade through documentation, try and make sense of all the buzzwords, eventually download and install programming software, make sure you have the latest version, fire it up and figure out how to get started... how much longer does it take than just "switch on and go"? The longer it takes to get a result, the less likely something is to appeal.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
