On 13 Mar, 22:29, "Peter Corser" wrote:
The half minute timing accuracy was down to the programme (sequence)
machines stepping every half minute. The timetables on the machines ran in
half-minute time (from 0300 to 0300 the next day) with 0 at midday - half
minute time was the most you could do within the limits of a computer
integer (8 bit - +/-32767 IIRC).

8 bit would give you +-127, 16 bit is needed for 32767

The Central Line computer control ran internally to quarter minute timings,
but the Timetable software used in developing and printing of the published
timetables (and also the computer control timetables) could only cope with
half minute resolution.

From noon until 3AM needs a signed integer capable of storing upto
1800 values for a half minute resolution, 3600 for quarter minute. 12
bits would do -2048 to +2047, capable of half minute, but not third or
quarter. 12 bits is 3, 4 bit words.

Nowadays of course 64bit time_t is the way to go, although I think
some libraries do 128 bit, which is a little extreme, although some
may say it doesn't go far enough. I think* a 256 bit time_t would be
capable of representing any measurable point in time, and then some.

*
seconds in creation (50 billion years): -- (86400*365.25*50000000000)
Measurable Units of time (plank time) in a second -- 1/(3.3 x 10^-44)
Measurable Units of time in creation (a*b)
~ 4.8 * 10^61
ln(4.8 * 10^61)/ln(2) == 205

"Paul Weaver" wrote in message
roups.com...
On 13 Mar, 22:29, "Peter Corser" wrote:
The half minute timing accuracy was down to the programme (sequence)
machines stepping every half minute. The timetables on the machines ran
in
half-minute time (from 0300 to 0300 the next day) with 0 at midday - half
minute time was the most you could do within the limits of a computer
integer (8 bit - +/-32767 IIRC).

8 bit would give you +-127, 16 bit is needed for 32767

The Central Line computer control ran internally to quarter minute
timings,
but the Timetable software used in developing and printing of the
published
timetables (and also the computer control timetables) could only cope
with
half minute resolution.

From noon until 3AM needs a signed integer capable of storing upto
1800 values for a half minute resolution, 3600 for quarter minute. 12
bits would do -2048 to +2047, capable of half minute, but not third or
quarter. 12 bits is 3, 4 bit words.

Nowadays of course 64bit time_t is the way to go, although I think
some libraries do 128 bit, which is a little extreme, although some
may say it doesn't go far enough. I think* a 256 bit time_t would be
capable of representing any measurable point in time, and then some.

*
seconds in creation (50 billion years): -- (86400*365.25*50000000000)
Measurable Units of time (plank time) in a second -- 1/(3.3 x 10^-44)
Measurable Units of time in creation (a*b)
~ 4.8 * 10^61
ln(4.8 * 10^61)/ln(2) == 205

Paul

Thanx for corrections - my memory was slightly befuddled & confused! It's a
long time since I did programme machine design for the original Heathrow
extension!

Programme machines (correctly known as sequence machines in most cases)
stepped in 30 second granularity. The whole system ran in two second time.
It is the two second time which requires the 16-bit width.

Bearing in mind that this system was designed in a railway signalling
pre-computer age using some relays and an individually designed set of
controls accomplished with electronic cards reducing the bit width was
always a necessity. The sequence machines ran on the plastic pianola roll
with mechanical fingers principle.

As an aside you may be aware that the train running numbers (set numbers)
shown in the time table were the direct digital equivalent of a hex number -
477 digital was stored as 477 hex and 477 was the highest number normally
used (there was also nothing between x78 and x99) which also saved bits (ot
sequence machine fingers).

Peter
--
Peter & Elizabeth Corser
Leighton Buzzard, UK



----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On Wed, 14 Mar 2007 09:41:39 -0000, Peter Corser wrote:

As an aside you may be aware that the train running numbers (set numbers)
shown in the time table were the direct digital equivalent of a hex number -
477 digital was stored as 477 hex and 477 was the highest number normally
used (there was also nothing between x78 and x99) which also saved bits (ot
sequence machine fingers).

ITYM octal rather than hex...

"Peter Corser" wrote in message
...
....
As an aside you may be aware that the train running numbers (set numbers)
shown in the time table were the direct digital equivalent of a hex
number - 477 digital was stored as 477 hex and 477 was the highest number
normally used (there was also nothing between x78 and x99) which also
saved bits (ot sequence machine fingers).

You may mean octal, not hex?
--
David Biddulph

"David Biddulph" groups [at] biddulph.org.uk wrote in message
...
"Peter Corser" wrote in message
...
...
As an aside you may be aware that the train running numbers (set numbers)
shown in the time table were the direct digital equivalent of a hex
number - 477 digital was stored as 477 hex and 477 was the highest number
normally used (there was also nothing between x78 and x99) which also
saved bits (ot sequence machine fingers).

You may mean octal, not hex?
--
David Biddulph

David

Oh Dear - brain still not in gear! Yes.

Peter
--
Peter & Elizabeth Corser
Leighton Buzzard, UK



----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

In article , Peter Corser
writes
As an aside you may be aware that the train running numbers (set numbers)
shown in the time table were the direct digital equivalent of a hex number -
477 digital was stored as 477 hex and 477 was the highest number normally
used (there was also nothing between x78 and x99) which also saved bits (ot
sequence machine fingers).

Actually, I think you'll find that numbers on programme machine
controlled lines only went up to 377 - there were 8 bits for train
number.

The PM data I've seen wasn't organised by 8-bit byte, but simply had a
number of bits for each field. I thought that there were 6 minute bits,
5 hour bits, and a half-minute bit, but I could be misremembering here.

--
Clive D.W. Feather | Home:
Tel: +44 20 8495 6138 (work) | Web: http://www.davros.org
Fax: +44 870 051 9937 | Work:
Please reply to the Reply-To address, which is:

"Clive D. W. Feather" wrote in message
...
In article , Peter Corser
writes
As an aside you may be aware that the train running numbers (set numbers)
shown in the time table were the direct digital equivalent of a hex
number -
477 digital was stored as 477 hex and 477 was the highest number normally
used (there was also nothing between x78 and x99) which also saved bits
(ot
sequence machine fingers).

Actually, I think you'll find that numbers on programme machine controlled
lines only went up to 377 - there were 8 bits for train number.

The PM data I've seen wasn't organised by 8-bit byte, but simply had a
number of bits for each field. I thought that there were 6 minute bits, 5
hour bits, and a half-minute bit, but I could be misremembering here.

--
Clive D.W. Feather | Home:
Tel: +44 20 8495 6138 (work) | Web: http://www.davros.org
Fax: +44 870 051 9937 | Work:
Please reply to the Reply-To address, which is:

Clive

You are right on the 4xx series numbers - some lines did have them for empty
trains, etc. but not on PM controlled lines.

The train numbers were octal (what's the correct term fo 2 bits giving
0-3?), but displayed as decimal using the same numerals, so 377 would be 8
bits overall.

It was 2 second time I was thinking about with the byte format. Your bit
numbering for the half minute time held on the machine seems familiar. I
think my brain is definitely getting addled - it's a long time since I
actuall did PM design (original Heathrow Extension), computer control system
with PM monitoring (Cobourg Street), LUL style computer control (Met,
Jubilee & Bakerloo) and Central Line. I think things have got a little
confused and blended with time!

Even when LUL had moved to computer control there was a tendency to to
define data structures using bit masks on the data - the GEC (later GPT)
4xxx series central control computers had their own data laid out like this.
I remember that the date information internally within the machine was based
on 0 in 1972 (I think Jan 1st) and included a year field which counted up -
this was a 6 bit field. We all thought that 5 bits would probably have been
enough!

Peter
--
Peter & Elizabeth Corser
Leighton Buzzard, UK




----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

On Thu, 15 Mar 2007 11:21:57 -0000, Peter Corser wrote:

The train numbers were octal (what's the correct term fo 2 bits giving
0-3?),

Quaternary.

In article , Clive D. W. Feather
writes
Actually, I think you'll find that numbers on programme machine
controlled lines only went up to 377 - there were 8 bits for train
number.

The PM data I've seen wasn't organised by 8-bit byte, but simply had a
number of bits for each field. I thought that there were 6 minute bits,
5 hour bits, and a half-minute bit, but I could be misremembering here.

Reading through an IRSE booklet, it shows 8 bits for train number (hence
000 to 377). Some machines had a 5 bit "time to next event" field,
giving times from 0.5 to 15.5 minutes. Others had an 11 bit time field
(4 hour, 6 minute, plus half-minute). The timer device recorded time in
the form day (0 to 15), am/pm, hour (4 bits), minutes (6 bits), and
half-minute, with the last 11 bits being compared against the 11 bits on
the punched roll.

--
Clive D.W. Feather | Home:
Tel: +44 20 8495 6138 (work) | Web: http://www.davros.org
Fax: +44 870 051 9937 | Work:
Please reply to the Reply-To address, which is: