Keeping 'order' without RTC.

No, you are getting the two clocks confused. The RTC was a real clock which you could read and get from it the year month day hour minute second. It could be set up to set an interrupt on the second. The computer system clock was a set of interrupts from the crystal driving the cpu, which was and is designed to issue an interrupt once every 1/18 sec originally and now more frequently but had nothing but the interrupt. No time information. That was the duty of the interrupt routine which counted the interrupts and assignes a time to them.

However IIRC the MSDOS version of time and date was updated by the 18Hz timer interrupt (in fact it was usually programmable: I had it running over 1Khz on one project). It wasn't very accurate at all.

We were well into Win98 or so before NTP time became available on PCs and one could guarantee that a roomful of them were more or less marking files with the same timestamps.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll

[snip]

[snip]

I wondered how long it would be before we were told how the time was maintained on some ICL dinosaur or homebrewed system.

;-)

On Fri, 17 Apr 2015 17:56:20 +0100, mm0fmf declaimed the following:

Of course, back in those days, rebooting the mainframe was something seldom done, so time-setting was only really needed if the clock based on the system interrupt was drifting significantly vs the time of the users. I wouldn't be surprised if some computer rooms found it faster to change the wall clock than to reset the computer's idea of wall clock time.

The VAX date/time system used Modified Julian Day 0.0 as its epoch time.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

And the VAX clock chip wrapped at about 15 months, so it used a date from a system file to get the date part when starting up. As a result if a VAX hadn't been rebooted for somewhere in excess of 15 months, the date and time could be significantly wrong.

--
Alan Adams, from Northamptonshire 
alan@adamshome.org.uk 
http://www.nckc.org.uk/

In comp.sys.raspberry-pi message , Fri, 17 Apr 2015 01:54:03, William Unruh posted:

Not quite, I think. The interrupt routine only counted and tested for having reached, IIRC, hex 1800B0, at which it set a count of 0 and set a "tomorrow" flag. The standard routines for accessing date and time, if the flag had been set, first incremented a daycount and cleared the flag; then they translated the counts to Y M D or H M S C.

The effects of directly setting hex 1800B0 or more were mildly amusing.

--
 (c) John Stockton, nr London, UK.   E-mail, see Home Page.    Turnpike v6.05. 
 Website   - w. FAQish topics, links, acronyms 
 PAS EXE etc. :  - see in 00index.htm 
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

The Prime/Primos clock wrapped every 150 days or so; it was a 32-bit counter of 1/330'ths of a second.

I sent a bug report about this, but they just framed it and hung it in their reception area. This was in ca 1986, and reflects on the stability of the hardware and software of the times. Most hardware shops insisted on PMs taking the system down every 2-8 weeks.

-- mrr

-> Well I left after 6months and spent the next 5 years working on 68000s

-> on Macs/Ataris/Amigas etc. People use to think you were clever if you

-> programmed a 68000 in assembler. In reality it was so easy compared to a

-> 6502 or the like as you had all these registers and powerful addressing

-> modes to play with. Did the 68000's have a Multiply and Divide instruction? Trying to get back into 6502 programming, after forgetting it all for so many years, one of the hardest things to do is to write code without a MUL or DIV command, after having been exposed to the 80x86 series of processors.

Yes: All 68000s have both MUL and DIV. There are both signed and unsigned forms and all four (DIV, DIVS, MUL, MULS) can operate on 8, 16 or 32 bit operands.

The 6809 has a MUL but no DIV - and MUL is an 8 bit unsigned multiply giving a 16 bit result.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

Yes. I remember that, and using a DSP as a coprocessor to write 16 bit integer multiplies and some trig functions as well for a custom 6809 project. (digital storage scope).

That was when I finally realised that what was a scope with a processor, should have been a PC with a high speed sample and store A->D converter in it as a peripheral....and the digital age had really arrived.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll

...and that, with the arrival of the 68040 we really did have a mainframe on a chip.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

As you can tell I could only remember 4 out of 6! Wikipedia has it though:

A typical AST multifunction card of the mid-1980s would have an RS-232 serial port, a parallel printer port, a battery-backed clock/calendar (the original IBM PC did not have one), a game port, and 384 KB of DRAM (added to the 256 KB on the motherboard to reach the full complement of 640 KB) - marketed under the product name 'SixPakPlus'. so I guess the calendar app counted!

--
Bah, and indeed, Humbug

Yes, but ISTR for many simple cases you could do better with a hardcoded routine. The 68k didn't have a barrel shifter so the bigger the multiplier the more cycles it took.

; d0.w contains multiplicand

muls.w #10,d0 ; d0 := d0 * 10 (38*n cycles) ; ; or...

lsl.w #1,d0 ; d0 := d0 * 2 ( 6+2 cycles) move.w d0,d1 ; d1 := d0 ( 4 cycles) lsl.w #2,d0 ; d0 := d0 * 4 ( 6+4 cycles ) add.w d1,d0 ; d0 := d0 * 10 ( 8 cycles)

So the muls takes 38 * 2 = 76 cycles and the hardcoded takes 30 cycles.

I last wrote 68k assembler in 1994 so I had to look up those timings ;-) I have an original Motorola 68000 programmers card somewhere here from

1987 that has all the timings and flag operations. From the day when you actually programmed stuff not like now where you write some code and if it's too slow you tell the client to get a faster machine!

I hated 6502, just did. I did a lot of 6303 code (Hitachi 6800 with extended instruction set) and found that easy. I never did any 6809 code though and that had a nice looking instruction set for an 8 bit CPU.

We ask today's youth in job interviews if they can program in assembler and from the looks you get would think you were asking them to cure cancer. Well we ask people who claim C++ experience these questions, the Java programmers don't get an interview ;-)

That is correct.

How can a file become ? Only by being written, when the rPi's time is less than the time-mark of some other existing file/s. JB's idea of marking each written file with the next available , would achieve the effect. But using the Files' ID for this is problematic; besides apparently the rPi ; cp; wouldn't this 'keep order'?

Looking at the big-picture of the system: rPi + PC

1. RTC-ed:PC ==Puts dataFiles to => rPi, with RealTime stamps;
2. rPi uses the dataFiles and marks their use-status by marking-their- ID; depending on the RealTimeStage of their usage. eg. if power is cut while .ogg is playing, it becomes marked as z.ogg and if power is cut during the short prompt after playing, it becomes .ogx

So when rPi goes back to HQ/PC for , we need the old & new *.og* not to be mixed i.t.o. their time stamps.

PS. isn't the rPi an educational project? Who remembers: when UK brought out the mini-car, US advertisers spoke about a 'proper sizes car' [we can use a 2-ton V8 to go to the shop to buy 20 LuckyStrike, cos we've go the infinite frontier...then came toyota....]

WDYS?

Do step 1 with a method that doesn't copy timestamp and you should get the rPi's idea of the time which is always moving forward even if not close to real-time. So, say, for example use "scp" without "-p". Then files should time sequence in the order in which you copy them.

The software clock is not an RTC. It counts interrupts. Yes, you can decode that count to a wallclock time, but that extra step is an extra step for a true RTC.

I don't care what 1900 says, it's more than a century later and RTC has a meaning specific to computing.

I guess that maybe you don't realize that the "RTC" you think your OS maintains is really just a counter, and the the conversion to real time is done only upon request. It is a waste of time for the kernel to maintain the HHMMSSYYMMDD info that is "real time". If you believe that

1467829322 is a "real time", then your defintions are wrong.

On the other hand, the true RTC devices do maintain the "real time". You can ask it directly "what hour of the day is it?" because its API returns hour of the day. You don't have to get a 32 or 64 bit integer and break it down or even know what the epoch that counter is based on is. Yes, if you are calling ctime or other "real time" function, that's what you are implicitly asking (unless you have a true RTC and library interface to that.)

Agreed. It counts "seconds" (well after it has been calibrated) but those are at best "seconds since the machine has been turned on". To have it count useful seconds (eg seconds since Jan 1 1970) you need to feed it the Real Time at one of those seconds. Taht is the job of the Real Time Clock. Note that the Real Time Clock also counts seconds. Seconds since epoch is a perfectly good time, just as Julian day is That does not need to be broken down into years months days, hours minutes seconds and fractions to be real time.

Seconds since epoch IS a "real time" Seconds since the computer was switched on is not.

Actually intrnally it too just keeps count of seconds. There is a well defined algorithm to turn seconds since epoch into civil time. Your computer does it, that RTC does it.

Unless you fail to keep your leap seconds table up-to-date. Civil time is not linear.

Agreed. But there is still a well defined algorithm. The RTC is worse. As far as I know, it never takes leap seconds into account. Fortunately it is usually recalibrated on shutdown, so the system, which should take leap seconds into account ( although I am not sure Windows does) can reinitialise the RTC.

>