Asteroids - we don't need no stinkin' microprocessor! - Page 1
Forum section: electronics / projects

author: GK
author_rank: Super Contributor
timestamp: February 10, 2018, 03:39:54 pm
content: OK, this thread is a fresh start/continuation of some discussion in my fifty thousand post Pong thread. I really need another project like I need a hole in the head, so progress and updates won't be lightening fast.The aim here (I actually have it all conceptually figured out on paper) is to build a derivative of the classic arcade game using discrete logic and analogue circuitry. Here is where I am at as of this evenings effort. In order to keep things sane, however, I have decided to allow myself to use parallel EEPROM devices. There is much complex function generation required in order to trace the various objects out onto the oscilloscope screen (rotating space ships, tumbling asteroids, alpha numeric characters, etc) in addition to the sin/cos functions for the rotation of vectors. The ability to use look-up tables stored in EEPROM for what effectively is arbitrary waveform generation simplifies things a great deal.So far I have completed the function generation circuitry to trace out the spaceship, the radian-counting sin/cos function generator for the vector rotation of said spaceship under player-control and the actual (multiplier based) analogue vector rotation/matrix circuitry.The next part to be built is the spaceships thrust/velocity/inertia and X/Y-movement integrators. Once these are built I will be able to fly the spaceship around the screen in the pointed direction by simply pressing a "thrust button".However this is all I have time to post this evening (actually it's morning already). Circuitry and technical details will begin to follow maybe in day or two. For now just a video and a picture:

author: Wimberleytech
author_rank: Super Contributor
timestamp: February 10, 2018, 04:03:03 pm
content: You are nuts! But, I bow to you.

author: John Heath
author_rank: Frequent Contributor
timestamp: February 10, 2018, 04:39:59 pm
content: I could use a 1 G byte SD card made from discrete transistors. It should easily fit on a 1000 by 1000 foot board if left in your more than capable hands. You are the best. It brings to mind the old man and the sea. "man is not made for defeat"

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 10, 2018, 05:10:32 pm
content: Hmm, EEPROMs for tables -- I presume they'll immediately be driving DACs, so as to keep everything else analog? I suppose you considered using a sine wave (plus timer and S&H) for the same operation; too finicky?Certainly a lot of opportunities to "optimize" things. Objects could be sequential, allocated by index; each indexed bin points, by address (via mux), to drawing circuitry specific to each shape; the X-Y waveform goes through a transform block to do rotation and translation; there are (analog, S&H) registers tracking position, velocity, angle and so on; and, Idunno, a huge mux connecting these together? So much of which could be done with logic counters, muxes and such, or implemented again with plain old transistors. Sequencing can be timed-event driven, synchronous, or sequential; with implications for transistor count either way.Looking forward to seeing your choices on this one.Tim

author: Bud
author_rank: Super Contributor
timestamp: February 10, 2018, 05:19:40 pm
content: With the double negation used your Subject does not make sense. Unless you need a stinking micro processor.

author: John Heath
author_rank: Frequent Contributor
timestamp: February 10, 2018, 05:39:32 pm
content: Quote from: Bud on February 10, 2018, 05:19:40 pmI think the intended quote was " we don't need no stinking micro" I suspect the t in "not" was not supposed to be there.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 10, 2018, 05:55:48 pm
content: Alternately, there's the old paraphrasing,Yes, we have no microprocessors...Tim

author: John Heath
author_rank: Frequent Contributor
timestamp: February 10, 2018, 06:35:37 pm
content: Quote from: T3sl4co1l on February 10, 2018, 05:10:32 pmThis is a nice direction to take it. Just read it off a ROM. Technically this is a look up table not a micro so it is not cheating. I am going to tap this puppy one tiny step to right which is flirting ever closer to cheating but technically it is not as a ROM state machine is not a microprocessor. With this I declare 2 bits of the said ROM output to reserved for 4 states of the system with 4 different look up tables. If anyone wishes to say I cheated by putting in a micro my answer is no it is not a micro rather a quad ROM state machine which when boiled down is just 4 look up tables in said ROM. Clearly a ROM look up table is not a micro. I rest my case.

author: bitseeker
author_rank: Super Contributor
timestamp: February 10, 2018, 06:47:41 pm
content: Quote from: GK on February 10, 2018, 03:39:54 pmWon't be lightning fast he says and then has a button-controlled spaceship on a scope screen the day after posting about the concept. Way to go, GK!

author: CatalinaWOW
author_rank: Super Contributor
timestamp: February 11, 2018, 02:28:56 am
content: I'm a bit fuzzy on this, but I believe the original version of Asteroids that I saw (long before the arcade games) was implemented on an analog computer. So you might look into doing it with op amps and multipliers. That original version had a very limited number of "asteroids" and each "asteroid" could only break into a limited number of fragments so the number of function blocks wouldn't be totally out of line.

author: BrianHG
author_rank: Super Contributor
timestamp: February 11, 2018, 02:36:20 am
content: It wouldn't have looked the same, or had full functionality, but I'm surprised you didn't go for my idea of an all transistor version. You would have brought down the house.However, no microcontroller, this will still be unbelievable & with an eprom, you can create the real sophisticated outlined shapes of the objects.If you are doing a video version, with a little intelligence, you only need 1 single eprom and single binary counter and single CMOS analog mux switch to make your video raster, sync/color burst & locations and active video area with optional score board background. This one I have done before back in 1989, though, you need to write a little program to generate the raster pattern to be burned on the eprom.If you don't have access to tools to do this and you know some simple BASIC, I can point you to where you can make your own tool for generating the eprom bit-pattern you like.

author: james_s
author_rank: Super Contributor
timestamp: February 11, 2018, 04:39:53 am
content: Yeah Asteroids on a raster monitor is terrible, I've tried it on MAME and it's a feeble shadow of the real deal, not even worth playing. On the original vector monitor it's an amazing game, virtually perfect.

author: BrianHG
author_rank: Super Contributor
timestamp: February 11, 2018, 05:43:23 am
content: Well, for a vector based version, it should be possible with 1 good sized 16 bit eprom and a few reset-able binary counters + 2 bank resistor dac on the eprom output for x&y. This would create all of your objects on the playfield and the z will be either the max count or min count on one of those counters. Object positioning can either be done in analog like the oscilloscope pong game, or, counter -2- dac based. This might be build-able on bread-boards since GK has gone to ICs.Don't misunderstand me, I am not saying by any means that this will be easy. It will still be a hell of a project.

author: BrianHG
author_rank: Super Contributor
timestamp: February 11, 2018, 05:49:40 am
content: Quote from: james_s on February 11, 2018, 04:39:53 amI've tried the mame version as well. When I set mame to render the vectors at 1600x1200, with oversampling at 120hz on my CRT, it does actually look good, though you need a killer PC to render a vector emulated game in mame like this. Anything less in resolution, or over-sampled vectors disabled or lower frame-rate sucks. The only missing aspect is the monochrome phosphor and the huge size of the original arcade game.

author: GK
author_rank: Super Contributor
timestamp: February 11, 2018, 09:15:57 am
content: Quote from: John Heath on February 10, 2018, 05:39:32 pmOops, 2 am typo. Fixed.

author: GK
author_rank: Super Contributor
timestamp: February 11, 2018, 09:34:43 am
content: Quote from: BrianHG on February 11, 2018, 05:43:23 amUnfortunately that won't work for practical collision detection reasons. The X&Y signals for any two objects that you wish to detect collisions between must be available simultaneously.Also, collision detection must not be restricted to that which is being multiplexed to the screen (otherwise objects that appear to collide due to the persistence of vision will not reliably collide electronically) and the object multiplexer cannot change its terminal count depending on the number of objects being displayed, as that would cause the displayed intensity of all objects to vary inversely to the number of objects displayed. I've decided on a 5-bit X/Y MUX for a maximum of 32 separate displayed objects. If only five objects are displayed at any given instant, just for example, then for the remaining 27 effective time slots the CRT beam will just remain cut-off. Each individual objects will always be drawn to the screen at a 1/32 duty cycle (actually in reality slightly less due to a necessary beam blanking interval between objects).

author: bson
author_rank: Unknown
timestamp: February 11, 2018, 12:39:06 pm
content: This is fairly similar to the original arcade game; it used a state machine and ROMs containing the shapes in the form of parameters (think microcode) and state transitions. This was on a graphics board completely separate from the main game software. To add a shape the logic board just added an entry with coordinates and an angle, and the vector board handled everything else. The game had nothing resembling a frame buffer - everything from digits to text was rendered this way. I remember being awestruck when I saw the service manual sometime in the late 80s... It's available online and makes for an interesting read:https://www.arcade-museum.com/manuals-videogames/A/AstDlx-Cabaret-sp.pdf(I also had access to a privately owned game and spent quite a lot of time scoping it out to follow the schematics.)

author: james_s
author_rank: Super Contributor
timestamp: February 11, 2018, 09:59:46 pm
content: Quote from: BrianHG on February 11, 2018, 05:49:40 amYou just don't get anywhere close to the dynamic range you can get with a real vector monitor. On a real Asteroids game the missiles are searingly bright, they look like magnesium flares flying across the screen. There's no way you can do that with a raster display.

author: BrianHG
author_rank: Super Contributor
timestamp: February 12, 2018, 05:27:06 am
content: Quote from: GK on February 11, 2018, 09:34:43 amOk, I am unaware of your collision detect strategy so I cant comment much. The purpose of the 1 eprom was to hold say 32 objects, with a 128x128 programmable resolution, 2 bit function bits, IE, (reset animation counter, bypass collision detection) by say 5bit (31 segments in each object like an asteroid, + 1 blanked) geometric contours. (10 address's so far) say another 9 address for each making 512 animation steps of each object. IE rotation & explosion. Fits in a 8mb eprom (512kx16bit, or 2 4mb 8bit eproms). You would enable/disable each object at will as you cycle through the 32 objects. All objects are centered but added to 32 analog X/Y oscillators which stores the position and vector for each object and, in my design, it would have been a 2D window comparator matrix between these analog oscillators which created the collision matrix decoder, or, a limited 2D comparator matrix with analog mux inputs just driven by the spare eprom 2 bits data out.You would only enable/disable any one of the 32 playfield objects, but, always count through them whether enabled or not maintaining that uniform brightness.Note that the in the original Asteroids, there was a bit of play at the edge of the asteroids where the bullets would go right through without hitting. Also, the bullets were super bright compared to other objects.1 eprom, a few individual loadable counters. The rest is analog jfet opamps and comparators. This doesn't count sound.

author: james_s
author_rank: Super Contributor
timestamp: February 12, 2018, 05:30:43 am
content: The original Asteroids didn't have any sort of hardware collision detection, it had a 6502 CPU and the collision detection was handled entirely in software.

author: BrianHG
author_rank: Super Contributor
timestamp: February 12, 2018, 05:35:04 am
content: Quote from: james_s on February 12, 2018, 05:30:43 amYes, but it wasn't super accurate, or for some reason, the bullets would go through sharp edges on the asteroids, or, these edges could go through a corner of your ship without killing you.Also, GK's design doesn't have a CPU, most likely it will be half analog computer, or, I hope it's part analog with that slick motion you can generate that way. How would you do it without a cpu?

author: BrianHG
author_rank: Super Contributor
timestamp: February 12, 2018, 07:05:17 am
content: Quote from: BrianHG on February 12, 2018, 05:27:06 amActually, the objects in asteroids are a tiny fraction of the screen. 64x64 pixels should be plentiful leaving you with 4 function bits. Even 32x32 with 6 function bits would be plenty as the raster versions of asteroids is only 8x8 sprite for the ship, 16x16 for the large asteroids.

author: BrianHG
author_rank: Super Contributor
timestamp: February 12, 2018, 07:16:36 am
content: Cheap public domain remake in FreeBasic just to wet appetite:https://www.freebasic.net/forum/viewtopic.php?t=16066Zipfile -> Windows executable is already compiled and included as well as source codehttp://games.freebasic.net/startdownload.php?file=A/Asteroids_vincent.zip&gameID=148

author: Henrik_V
author_rank: Regular Contributor
timestamp: February 12, 2018, 12:25:30 pm
content: And there are FPGA Asteroids version for vector/scope display ...but the controller less version.. whowHow about restricting the fuel and add an analog meter?

author: GK
author_rank: Super Contributor
timestamp: March 03, 2018, 02:28:30 pm
content: OK, I have the spaceship flying around now. In the next video I will be firing missiles.Simplified block diagram:

author: ebastler
author_rank: Super Contributor
timestamp: March 03, 2018, 02:49:17 pm
content: Quote from: GK on March 03, 2018, 02:28:30 pmAmazing! But you didn't get the Asteroids game physics quite right. In the original game (and in real physics, in free space) the rotation is decoupled from the lateral motion: You can rotate your spaceship around its center, but the lateral motion will continue unchanged.To change the lateral motion, you need to give thrust -- which, of, course, always acts in the direction the spaceship is currently pointed at, and gradually accelerates the spaceship in that direction. In contrast, your spaceship seems to behave more like a car on solid ground?

author: GK
author_rank: Super Contributor
timestamp: March 03, 2018, 03:22:13 pm
content: Quote from: ebastler on March 03, 2018, 02:49:17 pmNo, I just had the thrust button held down the whole time while rotating. When thrusting the spaceship will move forward, which is always in the direction it is pointing. When the thrust button is released (see the block diagram) the sine/cosine DACs for the velocity vectoring are latched/held and thus decoupled from the ships rotation - whilst decelerating to a stop as the velocity integrator ramps down to zero the spaceship will continue to travel in the same direction regardless of the rotation.Getting a more realistic movement akin to the original game is now just a matter of adjusting the constants that determine the thrusting acceleration rate, maximum speed and deceleration. At the moment the maximum (terminal) speed is too slow and the deceleration time constant too short.I will have to make the terminal speed much faster, so that thrusting will only be manageable in short bursts, and the deceleration time constant much longer.

author: beenosam
author_rank: Regular Contributor
timestamp: March 03, 2018, 03:23:16 pm
content: This is cool. But the amount of time doing this would probably have my in tears when I mis-wired something

author: ebastler
author_rank: Super Contributor
timestamp: March 03, 2018, 03:39:17 pm
content: Quote from: GK on March 03, 2018, 03:22:13 pmAh, I see!I'll definitely stay tuned to see how your project develops. I always thought the Atari arcade circuit was primordial, with its discrete TTL vector generator. (And I built myself a little cabinet to put the circuit board on display,www.e-basteln.de/asteroids.) But you are taking this to a different level!

author: BrianHG
author_rank: Super Contributor
timestamp: March 03, 2018, 07:32:20 pm
content: How Sweet.....

author: GK
author_rank: Super Contributor
timestamp: March 04, 2018, 12:47:12 am
content: Quote from: ebastler on March 03, 2018, 03:39:17 pmOK, your objection wasn't actually wrong in that while actually thrusting the spaceship moved while "steering" as if was on invisible rails without any, lets say, "slip". So, not really realistic. This kept me up in bed last night past 4am......The problem was with how I was integrating the velocity variable for the horizontal and vertical positioning. I was only singly integrating.For a simulation true to real world physical motion double integration is required. However double integration is problematic as only a brief hit of the thrust button would send the spaceship off into oblivion, moving away forever (actually only until the op-amp outputs hit the rails). The solution is to add the effect of friction, which is done just by putting a resistor in parallel with the capacitor in one of the integrators of the doublet. This will ensure that when the thrust button is released and the output of the velocity integrator ramps back down to zero, the spaceship motion will follow, decelerating to a rest. This morning I experimented by adding a pair of additional H and V position integrators in series with the existing ones, having the same time constant, but a fixed gain of unity courtesy of the "friction" resistor.Here is the initial result. In this video I am just holding the thrust button down the whole time 'till just short of the very end. The terminal speed is still ~10 times too slow as I haven't adjusted those constants yet. The end goal will be to make the terminal speed very fast so that the spaceship, like in the original game, can only be maneuvered by thrusting in short bursts (otherwise you'll just zoom off the screen at light speed and crash into something).http://youtu.be/VJcyBNloGqM

author: james_s
author_rank: Super Contributor
timestamp: March 04, 2018, 12:57:17 am
content: That's really quite amazing. I worry that this sort of analog design is becoming a lost art, these days everyone just throws a microcontroller at the problem without even considering other approaches.

author: NiHaoMike
author_rank: Super Contributor
timestamp: March 04, 2018, 01:10:01 am
content: Quote from: GK on March 04, 2018, 12:47:12 amIn reality, with virtually no air resistance, the friction will be virtually zero, although that would make the game very hard to play. I suppose a switch to select "realistic physics" might still be nice to have just to show what would really happen.

author: GK
author_rank: Super Contributor
timestamp: March 04, 2018, 01:22:42 am
content: Quote from: NiHaoMike on March 04, 2018, 01:10:01 amSure, without some heavy simulated friction the game would be practically unplayable as the spaceship would never stop moving or decelerate. You would have to add another control button for reverse thrust or something. Also a brain fart in the above quote - "gravity resistor" should read "friction resistor" (corrected my prior post).

author: james_s
author_rank: Super Contributor
timestamp: March 04, 2018, 01:25:45 am
content: Quote from: NiHaoMike on March 04, 2018, 01:10:01 amThat is the balance between a simulation and a game. Early in my career I was involved in the video game industry and I can remember there was a delicate balance between realism and "arcade-y" games. If you made a game too realistic most people found it was way too hard and not much fun. Driving games in particular, without the G-forces, peripheral vision and other cues it's hard to get a sense of speed. An accurate model of a high performance sports car will seem to handle terrible, then you look at the speedometer and realize you tried to take a corner at 150mph.

author: bitseeker
author_rank: Super Contributor
timestamp: March 04, 2018, 01:31:11 am
content: The movement looks a lot more like what I remember. Good stuff, GK!

author: BrianHG
author_rank: Super Contributor
timestamp: March 04, 2018, 03:22:41 am
content: Actually, playback your video at 2x speed and it looks perfect!Or, I bet if you shrunk the space ship size by 4, easy enough to do in analog, your current speed will look perfect, as well as the playfield area looking much more spaced out.

author: bitseeker
author_rank: Super Contributor
timestamp: March 04, 2018, 03:47:50 am
content: spaced out

author: ebastler
author_rank: Super Contributor
timestamp: March 04, 2018, 08:12:36 am
content: Quote from: GK on March 04, 2018, 12:47:12 amThat looks great! Can't wait to see this taking further shape, with asteroids and shots added!Do you have plans how you want to assemble and present the electronics eventually? The whole circuit should really be in a large picture frame or similar, to show off the all-discrete design. Amazing!

author: bitseeker
author_rank: Super Contributor
timestamp: March 05, 2018, 02:10:02 am
content: I'd imagine it'd go into a shadow-box-like display case similar to what GK did for the discrete transistor Pong he made. Looks really cool.

author: kizmit99
author_rank: Regular Contributor
timestamp: March 05, 2018, 03:28:51 pm
content: This is looking pretty incredible!One minor point I noticed though is that the ship is rotating around its nose; in the original game (I'm pretty sure) the ship rotated "in place" (around the midpoint of it's body).

author: BrianHG
author_rank: Super Contributor
timestamp: March 06, 2018, 10:21:09 pm
content: Quote from: kizmit99 on March 05, 2018, 03:28:51 pmIf it simplifies things for the firing of bullets, I could easily live with that. You also wont really notice it when he shrinks the ship to a size on the scope more to scale similar to the arcade game.I wonder if GK has a 25-30 inch scope display like the arcade game screens.

author: GK
author_rank: Super Contributor
timestamp: March 06, 2018, 10:43:46 pm
content: Actually the ships axis for rotation is in the dead centre. Watch the last few seconds of the last video where the ship is rotating while stationary. It's just the realistic inertia in the change of direction while thrusting forward that makes it rotate in a wide arc. Think of a car sliding around doing donuts.

author: kizmit99
author_rank: Regular Contributor
timestamp: March 07, 2018, 12:25:11 am
content: Quote from: GK on March 06, 2018, 10:43:46 pmOk, right around second 40 in the video I can see where it does appear to rotate around the 'correct' point. I noticed around second 25 that it seemed like there wasn't any thrust, but it was rotating around the nose. I guess that was just an illusion. Carry on...Looking forward to seeing this progress.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 07, 2018, 12:43:32 am
content: Quote from: BrianHG on March 06, 2018, 10:21:09 pmI have a 21":Well, if I want to waste a screen that is much more useful on the PC. Obviously a bad hack -- doubly raster scanned, a VGA output watching a sampled (digital) scope. Basically why digital scopes are just about useless on X-Y.Tim

author: BrianHG
author_rank: Super Contributor
timestamp: March 07, 2018, 12:45:26 am
content: More than 2 sizes existed.Cant seem to find a photo of the stand up table top version which had the largest CRT in it. They were rare, but, the quality of vector drawing on such a large monochrome CRT made the image refinement obviously look like a 2k or 4k res image. For the time , it roasted any picture you can get on any home or commercial PC by a land slide.

author: sokoloff
author_rank: Super Contributor
timestamp: March 07, 2018, 01:23:11 am
content: Quote from: james_s on March 04, 2018, 01:25:45 amSmall world. I was a tech lead at a game company that did realistic driving simulation games (Indycar Racing, NASCAR Racing, and Grand Prix Legends; the very talented team who started iRacing came from there as pedigree) and I created the "arcade mode" and "burnout mode" for the Sony PlayStation version and we also offered that mode in Nascar 2 for the PC.You're spot on that what makes a simulation realistic and what makes a driving game fun for the masses are as different as chalk and cheese...

author: sokoloff
author_rank: Super Contributor
timestamp: March 07, 2018, 01:31:22 am
content: On the Asteroids topic, this is simply incredible to me as just a programmer and a poor Arduino digital hack.Hats off!

author: NiHaoMike
author_rank: Super Contributor
timestamp: March 07, 2018, 01:48:46 am
content: I wonder if anyone has looked into digitizing the signals and then using a FPGA to generate a video signal. Could be a good option for those who don't want to hunt down a vector CRT (that is bigger than an old scope) or convert a regular CRT into one.Another idea I can think of is to bounce a laser off some piezo actuators. The hard part would be finding actuators with a sufficiently flat frequency response.

author: james_s
author_rank: Super Contributor
timestamp: March 07, 2018, 04:36:20 am
content: Yes, people have digitized vector images to display on a raster monitor, but then what's the point of starting with a vector engine? Just build it around a raster display to begin with.

author: ebastler
author_rank: Super Contributor
timestamp: March 07, 2018, 04:59:22 am
content: Quote from: NiHaoMike on March 07, 2018, 01:48:46 amNo, sorry; that just wont look right. If you have ever seen the glowing shots on a real Asteroids vector monitor, you won't accept any substitute ;-) They crank the beam up to full brightness, and let it dwell in place a bit longer, for a really nice glow effect. You cant get those intensity dynamics on a raster monitor, where the beam always moves at a constant pace.

author: james_s
author_rank: Super Contributor
timestamp: March 07, 2018, 05:48:29 pm
content: Yeah the original Asteroids (I have one) makes incredible use of the vector monitor. No other display technology before or since can manage that sort of dynamic range. Many other vector games are less demanding of the display, but there is still something unique about the look. If you want to run one on a raster display though it's easier to just use an emulator rather than starting with vector hardware.