|
Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment. |
|
Thread Tools |
15th Jan 2017, 3:06 am | #1 |
Dekatron
Join Date: Nov 2003
Location: Heckmondwike, West Yorkshire, UK.
Posts: 9,643
|
They don't come much more Vintage than this
|
15th Jan 2017, 10:47 am | #2 |
Heptode
Join Date: Feb 2010
Location: Duffort, Gers, France
Posts: 714
|
Re: They don't come much more Vintage than this
I once had an interesting chat with someone who programmed computers in the early days. There were no high-level languages, not even assembler. They had to program directly in machine code. Debugging must have been almost impossible.
__________________
Stuart The golden age is always yesterday - Asa Briggs |
15th Jan 2017, 11:07 am | #3 |
Dekatron
Join Date: Feb 2005
Location: West Cumbria (CA13), UK
Posts: 6,130
|
Re: They don't come much more Vintage than this
The big problem with programming directly in machine code is that if code needs to be moved, any address references need to reflect this.
When writing machine code patches for existing object code, there was the additional problem of trying to fit the new code over the code it was replacing. Fortunately, I only ever had to make very minor alterations by this method.
__________________
Mending is better than Ending (cf Brave New World by Aldous Huxley) |
15th Jan 2017, 12:04 pm | #4 |
Pentode
Join Date: Nov 2015
Location: Maidstone, Kent, UK.
Posts: 131
|
Re: They don't come much more Vintage than this
Ah but...the thought process and discipline using machine code ensured a very efficient program usually needing only a few hundred bytes rather than the megabytes even the simplest of functions seem to need today. The worst part was preparing paper tape with a uni-punch....!
|
15th Jan 2017, 1:18 pm | #5 |
Nonode
Join Date: Mar 2010
Location: Dukinfield, Cheshire, UK.
Posts: 2,038
|
Re: They don't come much more Vintage than this
Brilliant! I have a book 'Electronic Brains' by Mike Hally which deals with the early machines which were built for the military (usually ballistic calculators etc) and the early university machines. It's fascinating, as is another book which charts the development of LEO, the Lyons machine. I could read this stuff all day.
__________________
Andy G1HBE. |
15th Jan 2017, 4:01 pm | #6 | |
Nonode
Join Date: Aug 2010
Location: Resolven, Wales; and Bristol, England
Posts: 2,614
|
Re: They don't come much more Vintage than this
Quote:
And then there was the problem of squeezing it all into 16k of EPROM, we sometimes used 32k but that was frowned upon, memory was very expensive.
__________________
Richard Index: recursive loop: see recursive loop |
|
15th Jan 2017, 6:31 pm | #7 | |
Dekatron
Join Date: Feb 2005
Location: West Cumbria (CA13), UK
Posts: 6,130
|
Re: They don't come much more Vintage than this
Quote:
__________________
Mending is better than Ending (cf Brave New World by Aldous Huxley) |
|
15th Jan 2017, 7:51 pm | #8 |
Guest
Posts: n/a
|
Re: They don't come much more Vintage than this
My very first programme was written in Cecil https://en.wikipedia.org/wiki/CESIL running over a teletype link via a (very slow) modem to an IBM 360 in Cambridge. Such joy when it worked!
|
15th Jan 2017, 9:03 pm | #9 |
Hexode
Join Date: Dec 2012
Location: Carmarthen, Carmarthenshire, UK.
Posts: 268
|
Re: They don't come much more Vintage than this
I know it's new fangled compared, but I started programming by going on a course after having been an operator for a while. We started with COBOL, but I enjoyed IBM assembler and even better - ICL PLAN. Multiplying two long numbers required "double length aritmatic" (or even adding if I remember correctly). Like most people over a certain age, I don't like VB and Java etc.
Stuart.
__________________
Half my stuff is junk - luckily, my wife doesn't know which half! |
15th Jan 2017, 10:54 pm | #10 | |
Dekatron
Join Date: May 2008
Location: Derby, UK.
Posts: 7,735
|
Re: They don't come much more Vintage than this
Quote:
Suppose you need the constant 3 in your program. On the Z-80, the byte 03h corresponds to the opcode for LD [BC], A. If you happen already to have the instruction LD [BC], A in your program somewhere, then you can use the address of that instruction as the address of the operand, and it will fetch that three, rather than deliberately populating a separate memory location with 03h and then pointing to that address. Admittedly, since the Z-80 includes an immediate addressing mode (where the next byte is the operand itself, as opposed to using the next two bytes to indicate the address where the operand is to be found) this particular technique is less useful. An instruction to read a byte from a fixed location, such as LD A, [$4C2B] requires three bytes (and also the desired value in the pointed-to location, here $4C2B; making a total of four bytes if that value has to be populated specially) whereas an immediate-mode load such as LD A, $03 requires only two bytes and fewer clock cycles, since it already has the wanted value without the need to do another memory access. But this technique was certainly used on some early architectures without an immediate addressing mode. If you need to set the accumulator to all zeros, the obvious LD A, $00 is two bytes; but EOR A, A is one byte (and fewer cycles). And then there are situations where a little inside knowledge of the machine state lets you get away with something -- for instance, storing a temporary value somewhere that will get stomped on later but not until you have already used it; such as just below the stack pointer, where it will be overwritten by the next PUSH or subroutine CALL instruction, or over a system variable which will not get updated until some other event has happened, such as a keystroke or the start of a new video scanline. An assembler would also reserve separate space for all variables; when in practice, you might have finished using one before you stored anything in another. Yet one more common optimisation you can do by hand on the Z-80 and the 6502 is to use a two-byte relative jump (which happens only to be available as a conditional instruction), if you know in advance that the processor state will always be favourable (e.g., a SUBtract or DECrease instruction will always leave the carry flag set if it produced a positive value), as opposed to a three-byte unconditional absolute jump. It might seem crazy today, when you can run interpretated languages on a Raspberry Pi; but there was a time when all this made sense, because every byte and every clock cycle mattered.
__________________
If I have seen further than others, it is because I was standing on a pile of failed experiments. |
|
16th Jan 2017, 1:18 am | #11 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: They don't come much more Vintage than this
I'm with Dave Moll, slightly mystified in the sense that as far as I know you can perform any explicit machine code manouvre you need to in assembly language, since each single line of pure assembly language generates one absolute machine code instruction.
For example Quote:
Those of us who had very early 'computer' systems (ie, MK14) had little choice other than to enter code in machine language, but when we did, we ourselves were only doing what software assemblers later did for us: translating human-readable assembly language mnemonics into the corresponding machine code. There is an undeniable degree of pleasure to be had from being able to write in actual machine code (I'm very fond of Z80 in particular and can remember quite a few of the opcodes even now) but I wouldn't want to go back to the bad old days of having to shuffle code around by hand and recalculate all the jump offsets / addresses affected whenever a few bytes have had to be inserted into some code. |
|
16th Jan 2017, 11:03 am | #12 | |
Octode
Join Date: Jan 2003
Location: Ware, Herts. UK.
Posts: 1,082
|
Re: They don't come much more Vintage than this
Quote:
JR xx with the opcode 18H in the first byte and 2s complement offset in the second. I too am mystified about the statement that programming in assembly language is somehow less efficient than programming in machine code. If they felt so inclined, the assembly language programmer could employ any of the tricks stated above. John Last edited by jjl; 16th Jan 2017 at 11:10 am. |
|
16th Jan 2017, 11:36 am | #13 | |
Nonode
Join Date: Aug 2010
Location: Resolven, Wales; and Bristol, England
Posts: 2,614
|
Re: They don't come much more Vintage than this
Quote:
I still have my Rodney Zaks book on the shelf!
__________________
Richard Index: recursive loop: see recursive loop |
|
16th Jan 2017, 12:01 pm | #14 |
Heptode
Join Date: Dec 2014
Location: Lincoln, Lincolnshire, UK.
Posts: 583
|
Re: They don't come much more Vintage than this
I must admit that I began by learning machine code (on 6500 series, Z80 and 6800 series) and except for hand assembly did not really use an assembler. As such when I first looked at progressing to what should have been an easier way I did not get on with it. I could remember the op codes without problem after a while so preferred to use machine code as I visualised the operation of registers etc which is something that tends to get more remote the higher the level of programming language. It made things easier when I came to build my, designed by me, development system for my college course project (6802 based).
With the fixed position in memory of code, as others have said, relative addressing will sort. It depends somewhat on the capability of the monitor(basic system) program. I think this is one of the reasons 'com' files got replaced by 'exe' as this enables the file header to be in a different place to the program itself, just containing a reference jump to the program. I have not been too involved too much of late, although I notice from the manual of the Arduino controller chips that things have got somewhat more complex than the 6502 etc. That said, unless there is reference to a changed hardware function, things can be built up from basic instructions. With my system I spent many a hour contemplating virtual processors with my own machine language and even programmed the system up to work parallel processing although it was a little unstable (maybe all the pushing and pulling off the stack at each change of thread was the issue as it is easy to forget something - even these days when I do it in far higher level language) |
16th Jan 2017, 1:28 pm | #15 |
Rest in Peace
Join Date: Sep 2008
Location: Solihull, West Midlands, UK.
Posts: 4,872
|
Re: They don't come much more Vintage than this
I too am puzzled by the claim that assembler is somehow less efficient than machine code. This could only be true if the assembler sometimes tried to do something other than what is given in the source code e.g. an attempted optimisation which turns out to be unhelpful. Most assemblers don't do this, and any competent assembler which did should be able to have this facility switched off.
The big advantage of writing in assembler is that you can write maintainable code. Very little code survives for long without needing modification, for debugging or enhancement. Assembler can contain comments and symbolic names. If you want to save data space by re-using it, you can do this by just giving several names to one location - but then be careful that the different uses do not overlap under any circumstances! If you really want to use opcodes as data then you can. Any competent assembler programmer will be able to read and patch machine code too. Then ensure that the patch gets put into the source code and commented!! |
17th Jan 2017, 9:54 am | #16 | |
Hexode
Join Date: Apr 2006
Location: Medway towns, Kent, UK.
Posts: 271
|
Re: They don't come much more Vintage than this
Quote:
__________________
"Oh yes I love television, all those wiggly lines"! |
|
17th Jan 2017, 10:42 am | #17 |
Dekatron
Join Date: Nov 2010
Location: Oxford, UK.
Posts: 4,996
|
Re: They don't come much more Vintage than this
My first programming was at Southampton U in 1974. They had an ICL mainframe, and I produced stacks of punched cards for programs I had written in Fortran and Algol. If you wanted more than 16k of core you had to have written permission from your supervisor (there was a maximum of 32k).
Rather later in 1979 I was writing optical design programs in BASIC to run on the Electronics department Modcomp, and later ported them into probably the first RM desktop. Two 8" floppy drives, one for the operating system and one for program and data. In my first job in 1981 it was my task first thing to boot the PDP8. Several key entries got it to recognise the punched tape reader, which got it to recognise the washing machine size hard drive - and then the machine finally woke up. I finally threw in the towel when object oriented programming came in in its various guises. My poor 1970's brain could not cope with that. But I never formally programmed in assembler, although I did a bit just for fun in the early 80's. |
17th Jan 2017, 7:35 pm | #18 |
Dekatron
Join Date: Jun 2015
Location: Biggin Hill, London, UK.
Posts: 5,224
|
Re: They don't come much more Vintage than this
By coincidence I am working on a late-ish PDP8 machine (PDP8/e) at the moment. So far I am doing battle to get the processor box mounted in the rack. Repairin the electronics, if it needs it, doesn't bother me at all.
I have the 'boot matrix' board in mine. A diode matrix ROM (I am not joking) that acts like the front panel amd loads the paper tape bootstrap into core. Means that starting up involves putting the loader tape into the reader and flipping one switch. I am wondering what the 'washing machine size hard drive' was. PDP8 systems didn't generaly have large hard drives. The most common one (at least on later models) was the RK05, which is a single 6U rack unit taking a 14" disk cartridge which slides in through a door on the front. The cartridges were nicknamed 'pizzas' and the drives 'pizza ovens for obvious reasons. I can't understand this modern very high level programming either. I'm a hardware guy. I think in terms of gates and flip-flops. Machine code is fine. Microcode (one level below machine code) is even better (and yes I have written microcode both in assembler and binary). I've never formally done any of it though (I failed computer studies O-level the only O-level I did fail). |
18th Jan 2017, 8:49 am | #19 |
Heptode
Join Date: Feb 2010
Location: Duffort, Gers, France
Posts: 714
|
Re: They don't come much more Vintage than this
Possibly a magnetic drum memory?
__________________
Stuart The golden age is always yesterday - Asa Briggs |
18th Jan 2017, 1:36 pm | #20 |
Rest in Peace
Join Date: Sep 2008
Location: Solihull, West Midlands, UK.
Posts: 4,872
|
Re: They don't come much more Vintage than this
For quite a few years I used RK05s on various PDP-11s. I didn't know they were available for PDP-8 too. The 11/40 was booted by toggling a few opcodes in via the front panel switches. That somehow caused a jump to a boot ROM which knew about the RK05.
|