Roland Perry <roland@perry.uk> wrote:
> In message <ufr6l8$29k5a$1@dont-email.me>, at 08:59:20 on Sat, 7 Oct
> 2023, Sam Wilson <ukr@dummy.wislons.fastmail.co.uk> remarked:
>
>>> I arrived in LHR T2 this afternoon. There were no queues for the ePassport
>>> gates, which as usual worked quickly and efficiently (faster than a human
>>> officer). And, of course, these gates serve UK, EU and a number of other
>>> countries, such as the US, Canada, Australia, South Korea, etc.
>>>
>>> As an aside, leaving Copenhagen airport, all passports were checked by
>>> human officers. The Schengen queue was much longer than the 'All passports'
>>> queue.
>>>
>>>>>> To do the decryption, yes. Although the ICAO flowchart for checking a machine
>>>>>> readable document suggests doing a blacklist check on the full data read from
>>>>>> the MRZ first, and only after that has passed do you read the biometric and do
>>>>>> a second check. Not sure why to be honest, but presumably something to do with
>>>>>> detecting (or making harder) counterfeits.
>>>>>
>>>>> We hope they aren't using a 1MHz Z80 for all this.
>>>>
>>>> Well yes, we are all rather assuming you didn't design the solution.
>>>
>>> Indeed!
>>
>> Be fair; by the time the CPC 464 came out a Z80B at 4 MHz, which is what it
>> had, was really pretty pedestrian.
>
> The 1MHz above is a typo, I was misremembering the earlier 6800 (1MHz)
> machines, while contemporaneous 6502 home computers were C64 (6502
> 0.985MHz) BBC Micro (6502 2MHz) and Sinclair Spectrum (Z80 3.5MHz). The
> CPC's BASIC was faster than any of those.
>
> Other candidates for the project would have been an Apple II clone
> (6502, 1.023MHz) or MSX (Z80, 3.6MHz)
>
> Competitors which failed were the Oric (6502 1MHz) Elan (Z80 4MHz)
> Newbrain (Z80 4MHz) Camputers Lynx (Z80 4MHZ) TRS-80 MC10 (6803,
> 0.89Mhz), and the successful SEGA console was Z80 3.58MHz.
>
> So I think that the CPC was at least towards the top of the class.

It was in the middle of the bunch at the time it came out. IIUC neither it
nor its successors ever got a speed upgrade, unless the later video chips
improved the screen performance - it remained a 4 MHz processor. In fact I
made a factual mistake above - the CPC used a Z80A, the 4 MHz part, rather
than the Z80B which ran at 6 MHz. There was also a Z80H which ran at 8
MHz.

I don’t seem to be able to track down BASIC benchmarks from 30+ years ago
so I can’t comment on the veracity of that claim, though I’m surprised the
BBC BASIC wasn’t faster.

> In reality, because all these machines shared RAM between the processor
> and the Video Controller chip, the processor chip was doomed to run at
> the same clock speed as the video controller required, to generate a
> standards compliant PAL or NTSC signal.

The BBC managed to double that speed by using faster memory chips. It was
also possible to use separate video RAM, but that would have inflated the
costs considerably and not necessarily improved performance significantly.

> I suspect many of the numbers listed above are rounding errors (3.5MHz,
> 3.58MHz and 3.6MHz doubtless being the exact same architecture for
> example).

Almost certainly. In one of my jobs we ran the processors at 2.4576 MHz.
The crystals were designed for serial line baud rate generation by simple
division.

Sam

--
The entity formerly known as Sam.Wilson@ed.ac.uk
Spit the dummy to reply

On Sat, 21 Oct 2023 20:33:17 +0100, Roland Perry <roland@perry.uk> wrote:

>In message <ufpf2r$1l1mt$5@dont-email.me>, at 17:10:51 on Fri, 6 Oct
>2023, Recliner <recliner.usenet@gmail.com> remarked:
>>Clank <clank75@googlemail.com> wrote:
>>> On 6 Oct 2023 at 7:14:44 PM EEST, "Roland Perry" <roland@perry.uk> wrote:
>>>
>>>> In message <ufobfm$1e7je$1@dont-email.me>, at 07:03:18 on Fri, 6 Oct
>>>> 2023, Clank <clank75@googlemail.com> remarked:
>>>>> On 5 Oct 2023 at 9:42:06 PM EEST, "Roland Perry" <roland@perry.uk> wrote:
>>>>>
>>>>>> In message <ufm8lm$ub5f$1@dont-email.me>, at 12:03:02 on Thu, 5 Oct
>>>>>> 2023, Clank <clank75@googlemail.com> remarked:
>>>>>>> On 4 Oct 2023 at 7:06:08 PM EEST, "Tweed" <usenet.tweed@gmail.com> wrote:
>>>>>>>
>>>>>>>> Roland Perry <roland@perry.uk> wrote:
>>>>>>>>> In message <ufj0t6$1ffp$1@dont-email.me>, at 08:32:06 on Wed, 4 Oct
>>>>>>>>> 2023, Bob <bob@domain.com> remarked:
>>>>>>>>>> On 04.10.23 05:24, Matthew Geier wrote:
>>>>>>>>>>> On 1/10/23 11:40, Clive Page wrote:
>>>>>>>>>>>
>>>>>>>>>>>> their servers. Meanwhile those using pay-by-phone play about with
>>>>>>>>>>>> them, entering their PIN code or getting their fingerprint
>>>>>>>>>>>> recognised, then getting the right page shown on the screen, and
>>>>>>>>>>>> then operating the barrier. This is nearly always several
>>>>>>>>>>>> seconds slower.
>>>>>>>>>>>>
>>>>>>>>>>> Apple phones and many Android phones DO NOT NEED TO BE UNLOCKED to
>>>>>>>>>>> use Oyster terminals.
>>>>>>>>>
>>>>>>>>>>> Apple phones don't need to be even turned on if express pay is
>>>>>>>>>>> properly setup.
>>>>>>>>>
>>>>>>>>>>> People mostly do not need to fumble with unlocking phones and
>>>>>>>>>>> selecting apps, all that is needed to to bring the phone near the
>>>>>>>>>>> reader pad.
>>>>>>>>>
>>>>>>>>>>> I went through many Oyster gates just waving my Pixel6A at
>>>>>>>>>>> readers. I tend to unlock my phone before doing so, as
>>>>>>>>>>>Android only allows a limited number of 'tap to pay with out
>>>>>>>>>>> requiring an unlock. What number of transactions this is is
>>>>>>>>>>> (as it appears to vary by region/bank), so I've got into
>>>>>>>>>>>the habit of unlocking the phone (by finger print) as I
>>>>>>>>>>>approach the gates. And I have two fingers registered to
>>>>>>>>>>> either hand.
>>>>>>>>>>
>>>>>>>>>> Personally I haven't set up the PAYG on LU without unlock on
>>>>>>>>>>my phone, but due to the ergonomics of the phone and the
>>>>>>>>>>streamlined way of activating apple pay (double-press the side
>>>>>>>>>> I can do that one handed without looking except to show my
>>>>>>>>>> unlock the phone, in significantly less time than it would
>>>>>>>>>>take to find a paper ticket
>>>>>>>>>
>>>>>>>>> Where on earth are you hiding them so successfully?
>>>>>>>>>
>>>>>>>>>> and orient it correctly for the ticket barrier. If I have a ticket
>>>>>>>>>> that's a QR code there's a bit more effort to find it, but generally
>>>>>>>>>> comparable with the time involved in making use of a paper-printed QR
>>>>>>>>>> code.
>>>>>>>>>
>>>>>>>>> I've been flying with Ryanair recently, but I suppose it
>>>>>>>>>applies to all airlines. To open the gates into the security
>>>>>>>>>queuing area you have to put your boarding card onto a window,
>>>>>>>>>for it to read a barcode. For some reason this takes them several seconds.
>>>>>>>>>
>>>>>>>>> It's the same with electronic passport gates, the delay while they
>>>>>>>>> read the passport (it's just a small rfid chip and should take
>>>>>>>>> milliseconds) before they start to align a camera to your head
>>>>>>>>> height, is preposterous.
>>>>>>>>
>>>>>>>> Don’t the gates have to read out the image stored on the chip?
>>>>>>>> That’s what the gate’s camera compares against, not a central
>>>>>>>> database of images. (UK gate wouldn’t have access to non UK
>>>>>>>> passport holder database images). Every ePassport gate I’ve ever
>>>>>>>> used abroad is equally slow. Some Dutch ones even try to draw your
>>>>>>>> fingers into the mechanism if you aren’t careful.
>>>>>>>
>>>>>>> The gates have to scan and OCR the information printed on the
>>>>>>>passport page.
>>>>>>
>>>>>> Which is thoughtfully printed in an OCR-friendly not. Not rocket
>>>>>> science.
>>>>>
>>>>> And yet it still needs to be scanned, using decade-old hardware,
>>>>
>>>> The gates are virtually brand new.
>>>
>>> The virtually brand new gates work quickly in my experience, certainly not
>>> 'preposterously' slowly.
>>
>>I arrived in LHR T2 this afternoon. There were no queues for the ePassport
>>gates, which as usual worked quickly and efficiently (faster than a human
>>officer).
>
>My observations recently are that they gates are no faster than an
>averagely awake human officer. Any advantage arising from the
>potentially shorter queue.

The early e-gates used to be much slower than human passport officers, but you still gained because there were a lot
more of them in use than manned desks. The latest machines, which you won't have encountered, are now faster than human
officers, but it's true that the main gain remains the much larger number of in-use machines.