On Thu, 29 Jun 2006, Don Y wrote: I was told a story about how the Thomas Guide people did this, naming an unremarkable alley in the LA area the "Mark and Brian Expressway" after a rather colorful pair of morning disk jockeys. Later when the city decided to redo street signs, they used the Thomas Guide and thus ordered and installed signs marking this particular alley. Many of these ripoffs were horridly bad, though interesting examples of beating on the thing until it works. For example, Donkey Kong running on Galaxian hardware. Nasty colors. Nasty sounds, but it plays more or less correctly. -- David Griffith dgriffi at cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?

Hi, Fred Cisin said: The British Ordnance survey and "A to Z" street maps certainly do this. I found one of their deliberate errors in the latest edition of our local area map. -- Cheers, Stan Barr stanb at dial.pipex.com The future was never like this!

On Fri, 30 Jun 2006, Stan Barr wrote: Although the OS at one time explicitly denied it, about 5 years ago, they used it to bust the British Automobile Association! (20 million pound out of court settlement, London Times 3/6/01) OS said the changes were not errors but "subtle and secret ways of detecting plagiarizing, rather like watermarks". NOTE: all errors in a MICROSOFT OS are NOT Mountweazels nor pseudata; they are REAL errors.

David Griffith wrote: [intentionally bogus streetnames] Ha! Leave it to the gummit to take the lazy way out! :-/ Even more amusing are some of the lengths counterfeiters went to in order to "appease" the anti-counterfeiting algorithms embedded in the runtimes! The important lesson here is never leave a go-nogo decision point in code that you intend to protect (too easy to find those and workaround them)

On 6/29/2006 at 9:02 PM Don Y wrote: a decided Rand McNally does that routinely. They create a few bogus towns or geographical markers to thwart copying. I've heard that some music publishers will also put in intentional typos (say, the wrong number of beats in a bar or a superfluous accidental) to brand their work. I like to do a similar thing with online forms that require your name and email. I create a throwaway email address and then make up a name and address. I'm still getting spam offering really great mortgage rates to someone called David Marquez in Juneau. But I never did get anything for Consuelo O'Brien of Barrow. I'm looking for Carl LaFong....that's Big C small a small r small l... Cheers, Chuck

A (mad) friend of mine adds extra middle initials whenever he has to give his name and address. He then uses them to prove how said details are being passed arrounf, IIRC, he proved that the UK Electoral Roll was being used for something it shouldn't be, and ended up taking some group to court over it (I forget the exact details). -tony

Jules Richardson wrote: Robotron. There's just no way to replace the "feel" of a fullsize upright with two joysticks -- *dragging* all that weight across the floor in a frenzied bout with The Brains... :> While I'd *love* having a cocktail, the play sensation just wouldn't be the same as the upright!

der Mouse wrote: [arcade pieces] Yeah, I had a Tempest upright but gave it to a neighbor when I left Chicagoland (they are phenomenally HEAVY! easier to move a refrigerator than a Tempest!!) In at least one game, the logo is "drawn" (algorithmically). A counterfeiter modified the drawing routine (since their title/logo is obviously different!) and learned that one of the counterfeiting checks was to make sure the "pen" ends up in the same place as the original logo left it! The trick to fighting counterfeiting is to make the actions that happen random when something is "incorrect". And, to design the code so that you never do explicit tests for "correct". Instead, you leave a computed/checksum value someplace... then magically use it in a computation (*expecting* it to be the correct value). So, if it is incorrect, some object might move in a nonlinear fashion. Or, might become invisible (e.g., the color map entries for the object get mangled). With these sorts of failures, the counterfeiter is hard pressed to notice them: "Hmmm... was the angle of incidence equal to the angle of relection when I bounced off that wall?" And, even harder to set up a breakpoint condition to check (since the problem may manifest itself differently next time you press GAME START) However, to a PLAYER of a counterfeited game, they QUICKLY learn that they are being screwed by the game. And, stop playing it. Operator (the guy who buys the games) sees drop in revenue and realizes game is crap. Vendor sees lower sales for next "90 day wonder". Unfortunately, this sort of "random failures" pattern is hard to leverage to other devices. Imagine yourself trying to defend (in court) a piece of code that deliberately screws up the normal operation of the product -- *if* that code screws up unexpectedly!! "And, could you please tell the court why you designed that algorithm to deliberately cause my client's pace maker to put out 300 stimuli per minute? ..." Finally, using that sort of an approach in a *desktop* market would also probably be fruitless -- since people seem to EXPECT desktop software to be buggy! :-(

der Mouse wrote: It is *very* hard to design these sorts of checks. First, you need to make sure that they are totally ineffectual while you are developing the "real" code. (you don't want to waste your time tracking down a bug that isn't really there!) Second, you need to make them hard to detect. Simple checksums during POST (etc.) take just a few minutes to find and patch around. Even continuously running checks are easy to spot unless they look like they are doing "real work" ("Gee, why is this piece of code just walking through memory...?") Third, they need to be subtle in how they affect the normal play of the game when they trigger -- if it is to noticeable, then it is too easy to see when they have kicked in. Just like adding arbitrary 3 second delays to failed login attempts, you want to make the counterfeiter have to invest a lot of time *deciding* if he has beat the check system or not. Fourth, when you "install them", you need to be "Ivory Soap Sure" that they work properly -- in a legitimate game as well as in a hacked game! All in a machine that is a fraction of a MIPS :> Unfortunately, there never was a good solution to this problem. Software hacks like these are labor intensive. And, in a market (at that time) where time to market was *critical*, "wasting" a week writing/debugging/installing them was expensive. Yet, hardware protection schemes were just as easy to beat (even easier in today's technology!). Some of the schemes that came along were quite imaginative. But, also quite costly to implement (for a machine that went to the end purchaser for < ~$2000). [IIRC, the vector engine in Tempest was pretty much "fully disclosed" in their documentation -- this wasn't the case in all machines (though Atari used LOTS of "custom chips" in their machines)]

der Mouse wrote: I think I mentioned it before, but I reverse-engineered the Asteroids Digital Vector Generator (FYI - Tempest uses an Analog Vector Generator instead). Ended up finding out what instruction opcode 0x0 *really* does - MAME's been mis-emulating that for years :) For those who actually care, it's a DRAW instruction with a scale factor of 512. It's really only good for drawing single pixels and very (and I mean *very*) short lines. The two Atari Vector Generators rank pretty high on my list of cool hacks. Some of the tricks used to squeeze additional I/O lines out of the 4-bit state machine PROM were pretty neat, and the circuitry itself was a pig to trace, even with the schematic. I've got a Verilog version that I need to look into programming into a CPLD to play with, but first I need to get my homebrew X-Y display working again... -- Phil. | Kitsune: Acorn RiscPC SA202 64M+6G ViewFinder philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 512M+100G http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G

Don Y wrote: Heh. I heard about some of the fun the Atari engineering team went through to get the AVG going. Apparently some undetermined parameters meant that only one type of capacitor worked properly in the AVG circuit. Anything else displayed severe non-linearity. There's a CRT clock around somewhere that has an onboard sine generator (might be two sine generators) that's used to generate "proper" curves. Personally, I like the sharp angles on the Atari vector font - the curves look a bit too.. well.. perfect :) I never really got into analog design. I can do simple opamp stuff (current sense amplifiers, basic add/subtract/multiply signal processing) but I've never designed a 200MHz oscilloscope front-end amplifier or anything like that. Electrohome? Oh yes. They made the G08 didn't they? The "pyromaniac's arcade monitor", allegedly prone to catch fire with very little provocation. I seem to recall an entry in one of the Atari vector FAQs that said something to the effect of "If you are the owner of one of these monitors, you should also be the owner of a very good electronics-grade fire extinguisher." So I've noticed. Something like ten microseconds per inch for the Wells-Gardner 6400, or 200uS to cover the whole screen. It would be neat to find one if it was. A couple of saw generators and an LM1881 should be enough for the scan signal generation. Sure, if it's not too much trouble. Thanks. -- Phil. | Kitsune: Acorn RiscPC SA202 64M+6G ViewFinder philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 512M+100G http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G

On 6/30/2006 at 1:06 PM Jules Richardson wrote: I recall something in one of the 70's electronics/computer mags about this. Probably something like Kilobaud or Microsystems. There's also a fairly ancient (1960s) paper on the subject on the web about drawing characters using LRC circuits. Which is the way the old CDC 6000 operator's consoles did it. Maximum text density in small characters was 64 colums by 64 rows (3 character sizes were possible). You could create special effects like intensify or blink by simply redisplaying or skipping a display cycle. No buffering at all--the more time you took to get through a display, the more flicker it had. The fewer charactrers on the screen, the brighter they were. Graphics mode, IIRC was 512x512, again, unbuffered. Cheers, Chuck

Roger Merchberger wrote: Actually, that wasn't the one I was thinking of, although it was one I'd seen before and forgotten about - so thanks for sharing! I'm thinking that something like that (though obviously not porn-based :-) would make a nice little self-contained display for our museum. PC + soundcard under the desk, nice old Tek 'scope running as a little scrolling message display with the museum name or something... I don't know, it's oddball enough to be quite eye-catching, but fairly trivial to implement. cheers Jules

Chuck Guzis wrote: Sound card sure seems easier! :> Build a WAV file and just have it "play" endlessly.

Philip Pemberton wrote: You don't care about the DC bias... the image will "self center". And, consider the persistence of most 'scopes... 20KHz would be more than adequate for a "sweep rate". The "problem" here is you can't easily change the "display".

der Mouse wrote: i thought the goal was to have very *little* (none) electronics -- since someone would have to design/build it... Actually, this will be VERY visible. I.e. try updating a raaster scan display without watching where the scan is currently. You end up with weird visual artifacts.

This is more in the way of idle curiosity, but does there exist schematics for the TZ07 tape drive anywhere? I've seen the maintenance manual online, but not the circuit diagrams. Cheers, Chuck

On Sunday 02 July 2006 02:49, you wrote: The problem is not the resistor values. You have the formula. R 2R ;^) It works for any value of R. it's equal value that counts. You are more likely suffering from non-equal voltage on each driver. The load is not the same for all bits,and any mismatch (high or low) will directly affect linearity. Buffering with a CMOS driver and using high value of R will help some. joe lang

Eh? The resistors in the ladder are R and 2*R, for some suitable value of R. The (maximum) output voltage depends on 2 things. Firstly the output voltage from the parallel port (and note, if those 8 output signals don't switch between the same voltages, you will get non-monotonicity as you observed). And secondly, the load you connect to the output. I would also think that the output impedance of the parallel port needs to be taken into account. And that may well be non-linear (which may make things difficult). Another cause of non-monotinicity is, of course, errors in the individual resistor values. Just out of curiousity, why do you want to use an R-2R ladder, rather than a single-chip DAC? Commercial vector displays that I've come across either used a DAC chip (Vectrex), a DAC module (DEC GT40), or a rather complicated circuit with tweakers for the top 6 bits (HP 1350). -tony

Ethan Dicks wrote: Can you make resistors out of ice? :-) Lack of power on the parallel port's a strange one - I always found it hard to believe that the implementors didn't forsee the use of the port as a general-purpose output port and provide it with a couple of power pins. It's not like there aren't several grounds available so that couple could have been given up for +5V pins. I used to power external gadgets from the PC keyboard port because I happened to have the right connectors to hand in order to tap power from there - that was at least portable until everywhere went to ps/2 type keyboards. One of my other machines just had one of the internal drive power connectors fed out of the back of the case though for a useful point to take power from. cheers J.

Ethan Dicks wrote: :-) I thought that pretty much all DACs are ladder-based internally anyway, just with far finer tolerances than the typical "bag 'o resistors" hack. In other words, by fine-tuning a homebrew ladder and using suitable buffering, you could probably get something pretty respectable running. I stumbled across a few pages on DACs and ADCs a while ago: http://www.allaboutcircuits.com/vol_4/chpt_13/1.html thinking about it, I wonder if the resistor packs often found in old equipment are any finer tolerance (or at least more closely matched) than using seperate resistors? If you have any scrap ones laying around it might be worth investigating. cheers Jules

zillions of years ago, when I was an undergrad, I did some work for the university geology department. They had a litle PDP-11 with dual floppies which ran RT-11. It had a nice ADC board from Data Transalation and a scope with D-to-A. The unit was originally designed to sample some sort of data and display the results on the scope. For a senior project I made a bridge and connected a strain gauge to the ADC and wrote code to sample the data over time, do some simple transformations and plot the data on the scope. The used it to measure particle size distributions in a slurry tube. All I rememeber is that everything had great documentation, the scope was an off the shelf o-scope and I was suprised that just controlling x, y, "z" (beam) I could plot numbers and dots on the screen and it looked pretty good. I don't remember but I suspect the cpu was just a little qbus 11/03 and everything was written in fortran. anyway, once done with the project I couldn't resist and wrote a spacewar game. It worked great and became very popular with the grad students. so popular that the dept head eventually hid all the disks with the program on it because nothing was going on except a spacewar tournament :-) my point is that I was suprised how well a little '11 could do with fortran code and a (I presume) a very linear ADC. The game ran ran well and was very fluid. wish i'd saved the source code... (but it wasn't very complex) I would guess that a simple parallel port adc on a PC could do very well displaying a reasonable number of dots on a scope with intensity control... not very impressive given what fpga's do now shading polygons, but fun none the less. -brad

Josh Dersch wrote: Always load X (for example) before Y. Then, insert an extra buffer between X's parallel port and the X D/AC. Clock BOTH D/AC's off of the Y "load" pulse. So, write to X doesn't alter the X D/AC *but* saves the output in X's "holding latch". Then, updating Y causes X's held value to fall into the X D/AC at the same time that Y's value is falling into the Y D/AC. Another problem you will encounter is handling big motions. The X or Y deflection amp will slew at it's rated bandwidth and allow X (or Y) to traverse the difference in values as quickly as possible. Meanwhile, the other channel is doing the same thing -- but for a different magnitude of change. So, you don;t necessarily get a straight line connecting the X0Y0 with X1Y1.

On Tuesday 04 July 2006 03:51 pm, Josh Dersch wrote: Or maybe using some outboard latches and those strobe pins on the port? Or something like that anyhow... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

On 7/3/2006 at 10:07 AM Jules Richardson wrote: a have Given the implementation of the port, I don't believe that any use beyond a printer port was foreseen at the time of product release. The implementation has some oddities about it, however (I'm talking about the original IBM PC device found on the parallel printer adapter and the monochrome display adapter). If one looks at the original IBM PC BIOS listing, the printer port is referred to in at least one spot as an 8255, which was not the way it was implemented--but perhaps that was the original plan. The fact that the output buffer on the original PC part (both on the parallel port printer adapter and on the MDA) are tristate (LS374), with the tristate enable tied to ground, essentially forcing the idea of unidirectionality (I know that it's possible to drive the data lines low externally by application of sufficient current, but it's hardly the way to run a railroad). It's also curious that the 6-bit latch (LS174) used for some of the handshaking pins has a free bit. I (and doubtless many others) found that it was a simple matter to lift the tristate enable line and tie it to the unused bit on the latch, giving full controllable bidirectional use of the port. It's interesting that the PS/2 version of the parallel port did exactly this; the bit used being identical in position and sense to the original parallel port hack (probably a coincidence). Regardless, it's pretty obvious that the "bidirectionality) of the parallel interface was intended for self-diagnostic use more than anything. If one needed +5, one could steal it by using a DC boost converter from an unused logic high output or from the keyboard connection or, in the case of later machines, a USB port. Cheers, Chuck

On 7/4/2006 at 11:31 AM Jules Richardson wrote: never full of That's unlikely--the expansion board set was mostly buffers and receivers that worked directly off the bus lines. IBM did offer a Data Acquistiion board, however. I just don't think they ever saw a need for generic parallel I/O, though (and I'm not 100% certain of this), the sample circuit for the prototype adapter involved driving an 8255. Cheers, Chuck

On the original IBM Printer Adapter PCB (although not on the MDA card, which included a printer port) and some clones, the OR/ pin of the '374 is linked to ground by a track that has a couple of adjancent vias. Another via nearby goes to the appropriate output of the '174. It's a simple matter to cut the first track between the vias and solder a jumper wire to link it to the via connected to thr '174. I am not sure if this is shown on the schematic or not. It's certainly very obvious if you look at the PCB. I once saw a clone multi-i/o card that cheated with this. There weren't enough pins on the ASIC to give the printer data port, so there was an external 374, inputs from the system data bus, outputs to the printer connector, and clock input from a pin on the ASIC. No buffer to read back the printer lines, though. No, there was another latch hidden inside the ASIC, which could be read back. It kept the BIOS routine happy, but didn't actually check the printer port was working correctly. A boost converter cannot increase power. So if you, say, double the voltage (e.g. from a TTL output sitting at about 2.5V up to 5V), you halve the available current (down to <1mA?). -tony

Philip Pemberton <philpem at dsl.pipex.com> wrote: Non-existent problems. I've been doing this since the 70's and AC-coupled scopes are just fine as long as you don't do any horribly baselined stuff. And with regards to rate and CPU speed, I never had any problem using CPU's that were realistically a tenth of a MIP or slower :-). If it's just a half-dozen letters then there's dozens of ways to implement it (some of them COMPLETELY ANALOG.) My favorite thing to put on a X-Y scope is in fact the output of an analog computer. See Paul Horowitz's Lorenz equation integrator for a wonderfully chaotic example: http://frank.harvard.edu/~paulh/misc/lorenz.html I built this, added some knobs to twiddle the parameters, and hooked it up to a 10" X-Y display and am very happy :-). Tim.

Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote: Ah, yes, to play search and replace myself the really correct URL is http://frank.harvard.ed/~paulh/misc/lorenz.htm I had to type that 4 times before I finally left the "l" off the end! The Lorenz equation is remarkable for it's conciseness. I recall that when I first learned about it (late 80's?) I was told that it was originally intended to model some sort of atmospheric or gas flow phenomena. As a practical matter you can get nearly the same chaotic behavior with less expensive circuits that have the right kind of nonlinearities. In my implementation the most expensive components were the ten-turn pots and the turn-counter knobs to set the parameters. I think MPY634's are $10 a pop, but that there are some AD parts that are equivalent and slightly cheaper. There are some even simpler circuits that produce chaotic behavior using just diodes and inductors and capacitors. One of these is often called "Chua's circuit" or "Chua's diode" if you want to go googling. I highly recommend it! Historically a lot of chaos research even in the 80's was in fact done with analog computers. It certainly is more fun to move wires around a plugboard and tweak knobs and see the result on the scope, as compared with editing computer code or point-and-drool with a mouse and then running it and then seeing the picture! Tim.

Tim Shoppa wrote: I did wonder how critical those components are - or rather, what the nature of it 'not working' is when bits of slightly lower tolerance are used. Will do! Later on we can make a 'proper' funded project out of this - it'd definitely be justified - but prior to launch and opening of the new museum we're probably pretty much stuck raiding bits from the junk box :-) If anyone has any circuits... We've got a nice Pace TR-48 analogue computer that I suspect would lend itself well to this (conveniently with a Tek 555 and a large XY display currently parked on top!) as well as a fairly large Solartron that could probably also do the job. Unfortunately we only have one person who knows anything about the analogue machines, and he doesn't get that much time to ever do anything with them :-( cheers Jules

Not sure if someone posted a pointer here to this yet... http://www.cathodecorner.com/sc100.html

Well, of course, since you want to get light all along the line, not just flick from point A to point B. The X-Y oscilloscope idea sounds cool. I'll have to take my asteroids game (which uses a Sun cg6, with "hardware" line-draw, to give a vector-game feel) and try to give it a sound-card output module. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

I knew a fellow who liked to "brand" his code by executing his name. Actually, it's pretty easy on x86 platforms; most uppercase alphas are simple 1-byte register ops. For example, "DERMOUSE" would translate to: INC SP INC BP PUSH DX DEC BP DEC DI PUSH BP PUSH BX INC BP The simple way to code this would be to follow this with a bit of "fixup" code: DEC BP ADD SP,5 INC DI But code of a bit more devious bent would actually set registers up with known values before the name and then check their values to make sure that the "name" code has been executed. I once remember hacking some game that did just this. Drove me nuts when the execution path veered off into what I thought was data. Cheers, Chuck

On 6/29/2006 at 11:39 PM Don Y wrote: That's actually very common; in particular, stuff like: CALL SHOW_MESSAGE DB "Any old blather here",0 The nice part of this sort of thing is that you don't need the calling code to load the address of the string to be displayed in a register. Saves a few bytes here and there. Cheers, Chuck

I see... So then I get remembered as somebody who puts out inaccurate information... This seems similar to those disgusting CD copy-protection scheems, which one pundit in the UK has likened to splashing paint over the Old Masters in art galleries so that they won't be stolen. Yes, I've heard that too. Adding extra allies, etc. Great if you're trying to find the 'third turning on the left' or something ;-( -tony

On Thu, 29 Jun 2006, Evan Koblentz wrote: Be sure to keep us informed as to what what sort of mess you make with them. -- David Griffith dgriffi at cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?