Posts by Neil Barnes 6265 publicly visible posts • joined 18 Apr 2007
Can't help feeling that an awful lot of people have been killed by rocks, basically, over the years.
OK, maybe not as efficiently, but even so... I'm assuming, just from energy transfer requirements, that this is a single-incoming at a time handling device? You'd need a bunch of them to handle a bunch of mortars, or a mortar firing fast enough to have more than one in the air at the time?
Than he does in real light... (sorry Lester!)
B&W on silver all the way for me: OM1 and 2 for 35mm, Mamiya 645 and Reflex Korelle for 120mm, and Micro Precision Press and home-made cameras for 4*5. Can't afford to feed anything bigger!
Loving the look of some of the vintage emulsions that were produced in the FSU until recently; no red sensitivity... develop in ID-11 or Rodinal or Caffenol (look it up!) and occasionally the older processes - there's all sorts of creativity out there if you look!
Can't argue though that digits are the way for quick images - just rather annoyed that Olympus have pulled out of the semi-pro market and no longer provide tools for my E400.
Yet my experience is the opposite: I have much the same experience and age, but the Nexus 7 I bought mostly gathers dust.
I've written a book over the last couple of months. I used a DSLR camera to take the required pictures (about 90 in the final book) and I typed in all the words on a keyboard. I used photo software to change the images. I used a proper typesetting program to put things in the right order and laid out properly. I used a laptop with a couple of internal drives and an extra external screen to keep an eye on what I was doing.
I never even *thought* of reaching for the Nexus to do it.
And the book is paper, too.
But is it then going to knock on the door and pretend I'm not in, and carry the parcel back to some inconvenient location for me to collect?
I reckon they'd be better off with bloody great ballistae; harder to hit in flight and much more fun for the delivery operatives.
A J Stiles, you are me and I claim my five pounds.
But then, I did work for them directly or indirectly for over thirty years; if you cut me in half it says 'BBC' through the middle.
Mind you, I'm not so sure of them since they started employing commercial execs who seem to think everything is a ratings war and all production should be outsourced.
Nonetheless: as you point out their charter is to deliver programmes to viewers/listeners. *Every* other broadcaster in the world is in the business of delivering eyeballs to advertisers. Long may they continue.
Hi Jake, no joy there though I did find a useful prom listing.
However, I had a brainstorm and once I stopped looking for specific 'S571 data I found this: http://ygg-it.tripod.com/id3.html which is a programmer for the '188 but critically includes the specific page from the TI book I was looking for; the used the same materials, voltages, and algorithms as the NatSemi part.
It seems that the part is available as NOS, so I'll probably bend an AVR in that direction rather that programming manually; his programmer only has to do 32 locations. Toggling a couple of thousand bits in is too far beyond IPLing, I fear.
But first, I'll glue an EEPROM on the back and see if it still works. Most of the other chips can be replaced with HC or LS TTL if necessary though I'd rather keep the originals; after all, I've had them thirty five years...
I'm trying to get a Sinclair MK14 up and running, and it turns out the PROMs don't contain quite what they should - looks like something's screwed the internal data selectors.
While it'd be easy to stick an eprom on the back with jumper wire, I'd rather use the original prom type if I can - but while I can find the data sheet scattered around the net my google-fu has failed me on the programming details.
If anyone can point me at the right place, I'd be really chuffed... perhaps an old Nat Semi paper TTL databook?
Thanks
of being not-quite-tupe'd from the Beeb to Siemens ten years ago. There was some complicated reason why TUPE didn't apply - might have been to do with the public funding of the Beeb and the fact that BBCT were already a wholly owned subsiduary - memory fades.
But to be fair it wasn't a *bad* experience - we sat at the same desks in the same office using the same computers and the same phones doing the same job we did before, and on one occasion where a serious accident would have triggered an earlier pay cut than the Beeb's T&Cs, Siemens were politely nudged and didn't quibble. Even the pension terms were the same as the Beeb's.
The mistake many of us made was to leave our pensions with the Beeb (on the grounds of eggs and baskets) which meant we over-fifties couldn't get the Beeb pension when Siemens made us redundant some years later. We did get the few grand that the Siemens pension had accrued by then, but we have to wait for the BBC one.
Surely I'm not the only person in the whole wide world who has his music filed by artist/album and often just wants to listen to an album, in its entirety, in the order that the artist originally intended?
Without having to set up a damn playlist?
No?
Oh well. Back to Exaile. Or even, $deity$ help us, mpg123.
Why the (http at least) internet protocol was not encrypted from day one, or at least as soon as usable encryption came along.
I wonder whether a public/private key system could be usable; each user talks to a server/website using a published-in-many-places website key and providing his own public key as part of the protocol.
Spot on, Mike.
Shortly after that, the sets got better but we still kept 50Hz timebase. The fun started when you wanted to insert an outside broadcast or another studio centre; the delays in the transmission circuits (curse that speed of light!) meant that you were guaranteed to be at least part of a line out and usually more.
So Natlock was invented, which allowed the whole of the BBC transmission chain to be moved from the precision main oscillators to whatever the outside broadcast truck could manage - by tweaking the master oscillator frequency to match the OB a few microseconds a minute. When they were synchronised, you could cut between local and remote sources without a jump or a frame roll - while the change in frequency was too slow to upset the domestic receiver PLLs. Fast Natlock was used if you had multiple OBs that you needed to change to quickly; that dropped one line per frame and then used the slow method when you had at least the same field.
Genlock was the same thing in reverse; you locked your local station to the network so that you could cut to the network through your vision mixer without a glitch, before running your local video.
Of course, this all went away when digits came along since you could maintain everything to a common oscillator and just use a suitably long digital delay (eight fields covered all the options) but of course you now had an audio delay to accommodate...
Not Dr Who, but vaguely related: when the first Shuttle was sitting on the stand I was working for BBC TV News. It turned out that we didn't have a system which could superimpose a running countdown onto the screen, along with all the holds that were happening - the usual super sources at the time were either a camera pointing at a black and white card, or the Riley machine which read paper tape and built letters using a diode look-up table.
Using a Tangerine single board computer, I knocked up a blocky character set (the resolution was, IIRC, 2*3 blocks in a 32*16 array, so 64 x and 48 y pixels), and a bit of machine code that could generate the countdown and change as required. We pointed a camera at it and zoomed to fit... and then the editors decided not to use it!
Bah!
While Python has much to recommend it, I am less than impressed by its insistence on flow control by white space, and its bizarre abilities to change types on the fly, e.g. returning more than one type from a routine.
It strikes me as difficult to prove e.g. a numerical analysis is correct if there are hidden type conversions going on.
caveat: I'm still learning Python. Perhaps there is stuff I haven't come across yet.
@AC 02:09 - can't, unfortunately - I'm constrained to three 16f chips in the range that although not qualified have been proven to work (at least, they fail in ways we can work around) at the very high temperatures we operate at. Failure is (a) embarrassing and (b) extremely expensive.
If the boss would let me, I'd be using some high-temp AVR chips.
I never saw a computer in school; the one (external) course in which it was even mentioned was training fro data entry, not programming and certainly not design.
When I did engineering training at the BBC, the only section on microprocessors was *after* the final exam, and was not well attended - though it did improve somewhat after that once the BBC realised there was life in those things. Though I had by that time taught myself the basics (6502, 8060, 8080, 8085, Z80, 6809, Basic, Forth), to the extent that when I was finally sent on a micro course I ended up as an assistant instructor.
And thirty-five years later I'm bit-banging SPI in machine code on a PIC with no sane instructions, no useful internals, and no bloody stack... the more things change, the more they stay the same!
p.s. 6502 is best!
Very kind of you, thanks, Chris.
As it happens (though you may not find this interesting) I've been a photographer for pushing fifty years; I've built my own cameras from 35mm to 4*5 and pinhole cameras up to 8*10. I use modern and vintage cameras and presented - at the invitation of the International Broadcasting Convention - on the subject of Victorian 3-d imaging technology.
I don't criticise his skills; I merely point out he's solving a solved problem. Kudos to the guy for doing it - but where is the innovation?
~Spartacus,
I'm not sure I agree. There's a difference between 'want' and 'put up with'. You're quite right; the difference is in how the question is asked - and equally, I'm aware that while I dislike adverts, at least some of the sites I use are reliant upon advertising for their existence.
The problem is probably not resolvable by rational thought - I almost wonder if the equation (conscious or not) for most people is 'I get something I don't really care about in exchange for adverts I don't really watch'. But there's a subtle brainwashing going on in that people are now conditioned to expect adverts with everything... and there's an equally obvious approach with so many new sites appearing with few or no adverts and gradually increasing the intrusiveness and quantity of them.
I can answer my question, too: I happen to be an administrator of a car owner's club forum which is paid for by club members. There are no adverts, and non-members are allowed almost free rein over the site; there are only a couple of sub-fora reserved for club members only.
The ratio of members to users is approximately 1:10...
Which says it all, really.
I guess I spent too many years working for the BBC.
That web users actually *want* adverts?
Not 'want' as in 'they're ok if they're just text boxes'.
Not 'want' as in 'I don't care, I have an ad blocker'.
Not 'want' as in 'I feel I should support the people who pay for the interwebs'.
Not 'want' as in 'Ooh, these adverts are targeted just at me'.
But actually, deep in their soul, ache to have their attention diverted and their precious time wasted, their ears and eyes sullied with attention grabbers, their social media and networking and news and technical sites polluted with crap that there is a chance in a thousand they might actually want to purchase?
Or do they just put up with it?
There is only one time I *ever* want to see an advert, and that's when I make an explicit search for an item or class thereof. Until then, I'll pay to keep sites free of adverts, or just use blockers. Life is too short.
And indeed the microphone being able to hear it - but what about the filters in the front end of the ADC? What about a back end stack on 'every' computing device that listens for and silently understands not just data but executable commands, completely invisible to the OS? So every BIOS ever made comes with this capability?
I can see how, if one had a voice activated browser, it might be possible to send a human-inaudible spoken command (for example, transmit above 20KHz and let the undersampling on the input ADC turn it back to expected audio frequencies - assuming it survives the anti-aliasing filters) and to then direct the browser to a drive-by attack site... but a generic attack as described?
Colour me sceptical.
is probably to do it Russian style, rather than US - traditional lumps of metal rather than very very high-tech composites; bimetalic strip thermostats rather than computers and ADCs.
Something you can fix with a big enough hammer, basically, rather than something that requires you to build a nano-scale fabrication system.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
