UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 15th Jan 2017, 3:06 am   #1
AC/HL
Dekatron
 
AC/HL's Avatar
 
Join Date: Nov 2003
Location: Heckmondwike, West Yorkshire, UK.
Posts: 9,636
Default They don't come much more Vintage than this

http://www.bbc.co.uk/news/technology-38103893
AC/HL is offline  
Old 15th Jan 2017, 10:47 am   #2
bluepilot
Heptode
 
Join Date: Feb 2010
Location: Duffort, Gers, France
Posts: 713
Default 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
bluepilot is offline  
Old 15th Jan 2017, 11:07 am   #3
Dave Moll
Dekatron
 
Dave Moll's Avatar
 
Join Date: Feb 2005
Location: West Cumbria (CA13), UK
Posts: 6,113
Default 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)
Dave Moll is offline  
Old 15th Jan 2017, 12:04 pm   #4
Orakle42
Pentode
 
Join Date: Nov 2015
Location: Maidstone, Kent, UK.
Posts: 131
Default 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....!
Orakle42 is offline  
Old 15th Jan 2017, 1:18 pm   #5
Andrew2
Nonode
 
Andrew2's Avatar
 
Join Date: Mar 2010
Location: Dukinfield, Cheshire, UK.
Posts: 2,032
Default 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.
Andrew2 is offline  
Old 15th Jan 2017, 4:01 pm   #6
mole42uk
Nonode
 
mole42uk's Avatar
 
Join Date: Aug 2010
Location: Resolfen, Wales; and Bristol, England
Posts: 2,587
Default Re: They don't come much more Vintage than this

Quote:
Originally Posted by bluepilot View Post
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.
We used machine code exclusively when programming early Z-80 based coin-in-the-slot video games. There was no assembler that used code efficiently enough to make the games fast enough on a 1MHz processor. It was a choice to gain every last bit of speed - we even selected the op codes in a routine to use the minimum number of clock cycles.

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
mole42uk is offline  
Old 15th Jan 2017, 6:31 pm   #7
Dave Moll
Dekatron
 
Dave Moll's Avatar
 
Join Date: Feb 2005
Location: West Cumbria (CA13), UK
Posts: 6,113
Default Re: They don't come much more Vintage than this

Quote:
Originally Posted by mole42uk View Post
We used machine code exclusively when programming early Z-80 based coin-in-the-slot video games. There was no assembler that used code efficiently enough to make the games fast enough on a 1MHz processor. It was a choice to gain every last bit of speed - we even selected the op codes in a routine to use the minimum number of clock cycles.
I'm a little puzzled by this, as my experience of writing in assembler, albeit on rather different machines, was that the assembler was creating exactly the same code as coding directly in machine code - but simplifying things by using instruction names and symbolic addresses rather than their numerical equivalents. My assembler routines were therefore every bit (no pun unintended) as efficient to run as code poked in directly in hexadecimal, but without needing to know exact addresses or offsets for referencing data or jump destinations. I have always seen this as the distinction between assembler and high-level compiled languages - don't even mention interpreted code (nasty inefficient stuff for running on machines with lots of redundant capacity).
__________________
Mending is better than Ending (cf Brave New World by Aldous Huxley)
Dave Moll is offline  
Old 15th Jan 2017, 7:51 pm   #8
Guest
Guest
 
Posts: n/a
Default 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!
 
Old 15th Jan 2017, 9:03 pm   #9
Kala_12
Hexode
 
Join Date: Dec 2012
Location: Carmarthen, Carmarthenshire, UK.
Posts: 268
Default 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!
Kala_12 is offline  
Old 15th Jan 2017, 10:54 pm   #10
julie_m
Dekatron
 
Join Date: May 2008
Location: Derby, UK.
Posts: 7,735
Default Re: They don't come much more Vintage than this

Quote:
Originally Posted by Dave Moll View Post
I'm a little puzzled by this, as my experience of writing in assembler, albeit on rather different machines, was that the assembler was creating exactly the same code as coding directly in machine code - but simplifying things by using instruction names and symbolic addresses rather than their numerical equivalents.
Yes, but your fancy assembler probably was using separate numeric constants .....

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.
julie_m is offline  
Old 16th Jan 2017, 1:18 am   #11
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,471
Default 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:
Originally Posted by julie_m View Post
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.
The allocation of memory space to variables is entirely under the control of the programmer in assembly language. Conventionally, loop counters and so on tend to be given meaningful names and so individual addresses are reserved for them, true, but it would be simple to give a variable a name like GeneralPurpose1 and re-use it 'locally' in several different places. The onus then falls on the programmer to make sure that no two independent program entities (such as a main loop and an interrupt routine) try to use it at the same time, but it is perfectly possible to exercise that level of control in assembly language.

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.
SiriusHardware is online now  
Old 16th Jan 2017, 11:03 am   #12
jjl
Octode
 
jjl's Avatar
 
Join Date: Jan 2003
Location: Ware, Herts. UK.
Posts: 1,082
Default Re: They don't come much more Vintage than this

Quote:
Originally Posted by julie_m View Post
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.
No need to do this on the Z80 as it has a 2 byte unconditional relative jump instruction i.e.

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.
jjl is offline  
Old 16th Jan 2017, 11:36 am   #13
mole42uk
Nonode
 
mole42uk's Avatar
 
Join Date: Aug 2010
Location: Resolfen, Wales; and Bristol, England
Posts: 2,587
Default Re: They don't come much more Vintage than this

Quote:
Originally Posted by jjl View Post
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.
It was 40 years ago now and my memory isn't what it was, but we would use machine code rather than assembler on the Z-80 because we could always use less memory and because we could select op codes that used fewer clock cycles, both of which were important considerations. Possibly the assembler available to us at the time didn't allow us to do one or both of these things. I don't remember any irritation about programming in machine code, my feeling now is that we had some satisfaction in making code as efficient as possible

I still have my Rodney Zaks book on the shelf!
__________________
Richard

Index:
recursive loop: see recursive loop
mole42uk is offline  
Old 16th Jan 2017, 12:01 pm   #14
ionburn
Heptode
 
ionburn's Avatar
 
Join Date: Dec 2014
Location: Lincoln, Lincolnshire, UK.
Posts: 583
Default 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)
ionburn is offline  
Old 16th Jan 2017, 1:28 pm   #15
G8HQP Dave
Rest in Peace
 
Join Date: Sep 2008
Location: Solihull, West Midlands, UK.
Posts: 4,872
Default 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!!
G8HQP Dave is offline  
Old 17th Jan 2017, 9:54 am   #16
bobsterkent
Hexode
 
bobsterkent's Avatar
 
Join Date: Apr 2006
Location: Medway towns, Kent, UK.
Posts: 271
Default Re: They don't come much more Vintage than this

Quote:
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!
I too first learned computing in CECIL, I was lucky to be selected to do 'computer programming' as a CSE at school, in 1978. The general consensus was 'why you doing that? you won't ever see a computer'!
__________________
"Oh yes I love television, all those wiggly lines"!
bobsterkent is offline  
Old 17th Jan 2017, 10:42 am   #17
Craig Sawyers
Dekatron
 
Craig Sawyers's Avatar
 
Join Date: Nov 2010
Location: Oxford, UK.
Posts: 4,919
Default 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.
Craig Sawyers is online now  
Old 17th Jan 2017, 7:35 pm   #18
TonyDuell
Dekatron
 
Join Date: Jun 2015
Location: Biggin Hill, London, UK.
Posts: 5,180
Default 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).
TonyDuell is offline  
Old 18th Jan 2017, 8:49 am   #19
bluepilot
Heptode
 
Join Date: Feb 2010
Location: Duffort, Gers, France
Posts: 713
Default Re: They don't come much more Vintage than this

Quote:
Originally Posted by TonyDuell View Post
I am wondering what the 'washing machine size hard drive' was.
Possibly a magnetic drum memory?
__________________
Stuart

The golden age is always yesterday - Asa Briggs
bluepilot is offline  
Old 18th Jan 2017, 1:36 pm   #20
G8HQP Dave
Rest in Peace
 
Join Date: Sep 2008
Location: Solihull, West Midlands, UK.
Posts: 4,872
Default 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.
G8HQP Dave is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 10:17 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.