Boom computer

While I was reading about the Digi Comp II computer (more information), I thought I could make this kind of pinball-style logic with moving floors in Boom. I set myself a goal to make a similar computer with voodoo-dolls. Four days later, this is the result. Because I'm going away for 5 days first thing tomorrow, I'll upload my beta version.

I started with copying the registers and counting logic from the Digi Comp II, but made up all the surrounding flow and decision logic myself.

All consoles at the start area are interactive, and all use gunfire triggers. (could probably turn them into switches, because it was an old idea of having multiple action lines triggering at once (now replaced by separate program strips (look at the map to see what I mean)) but shooting is faster anyway)

Main problems are that the voodoo doll becomes stuck sometimes at a corner or slanted line, because of the infamous DOOM clipping logic. If that happens, then please let me know which vertex is causing the blocking so I can fix it. (it will always be a vertex touching a corner of the doodoo-doll bounding box).

Edit: here's the correct wad:
http://www.mediafire.com/?93a1417vxhfgtde

Some calculations can take a very long time (in the order of 20 minutes) so make good use of PrBoom's speed-up function.

The idea reminds me of this.

Added screenshots

Also reminds me of the minecraft computer I saw once. Cool stuff.

P.S. you use parenthesis like a programmer :P

So some day we may finally be able to use Doom to play Doom?

EDIT: Am I the only one who got a generic "inside a computer" level instead of what the pictures show when I downloaded the WAD?

TrueDude said:

EDIT: Am I the only one who got a generic "inside a computer" level instead of what the pictures show when I downloaded the WAD?

Same here. Either this is a hoax, or it's the wrong WAD.

DOES NOT WORK IN INTENDED SOURCE PORT.

The TEXTURE1/PNAMES appears to be based on Doom 1's, while the level is on MAP01, so PrBoom(+) chokes on it. You can play it with Doom 2's IWAD, if you load doom.wad with -file first, but the custom textures are broken under PrBoom anyway. I have a feeling that Zom-B uploaded the wrong wad. :P

TrueDude said:

So some day we may finally be able to use Doom to play Doom?

EDIT: Am I the only one who got a generic "inside a computer" level instead of what the pictures show when I downloaded the WAD?

WHOOPS, wrong wad uploaded. confusing names. computer.wad != calculator.wad

Here's the right one:

http://www.mediafire.com/?93a1417vxhfgtde

Figured it was but a matter of time before somebody figured out a full calculator inside DOOM. From there, the next step is a Turing-complete virtual machine ;)

Then, someday 50 years from now, people will be booting OSes inside DOOM levels.

Someone needs to port Terminal Doom into classic Doom.

Gez said:

Someone needs to port Terminal Doom into classic Doom.

Heh, although, the referenced mod "cheats" by including the game's native code as a DLL - it's not purely interpreted or virtualized ;)

Heh I figured my next step would be a programmable computer. It shouldn't be too difficult as I have experience in designing and building CPUs from scratch. It won't have floating point, smart pipelining or cache, though. For this to work, I just need to find a way to bring a single signal to multiple places, like in real electronics or the WireWorld cellular automata. I think I'll start out with a trigger line which releases multiple dolls, and work my way up from that.

It's really complex and all but er.. what does it do?

EDIT: Oh

Cool!

Zom-B said:

Heh I figured my next step would be a programmable computer. It shouldn't be too difficult as I have experience in designing and building CPUs from scratch. It won't have floating point, smart pipelining or cache, though. For this to work, I just need to find a way to bring a single signal to multiple places, like in real electronics or the WireWorld cellular automata. I think I'll start out with a trigger line which releases multiple dolls, and work my way up from that.

Ok I was semi-joking the first time, but now I really do want to see Doom run Doom.

TrueDude said:

Ok I was semi-joking the first time, but now I really do want to see Doom run Doom.

The "easiest" route would probably be to write a FPGA to "Boom logic map" converter, and use it on an FPGA programmed with that C to FPGA converter. I would love to see how inputs and outputs would be absracted though... and how many computrons you could get out an emulated CPU. Maybe a 1.000.000:1 slowdown? And how many bytes of actual memory would map to 1 byte of a simulated register or memory cell.

Even more interesting, how WAD data and other static data would be represented on a map and with what overhead ;-)

This is very cool. I'd never heard of the Digi Comp II though, now I want to buy one, or at least try to make one

Oh and a game in Doom sounds neat, but how would you do the display? On one hand we have an advantage over Minecraft guys in that we could make pixels of different colors with a bunch of 1 unit thick walls with different colors on them. But then there's the question of room over room.

DuckReconMajor said:

Oh and a game in Doom sounds neat, but how would you do the display?

Or more generally, how would you map inputs/outputs to the Boom logic (assuming plain Boom here, with no special extensions, and both the code and the data will have to reside entirely in map format, by simulating memory cells).

To answer that, think of how you would get Doom to run on an Altair 8800 (assuming that compiling the code and having the necessary RAM to store the code and the data would not be a problem): if you attach no special peripherals (not even a primitive video card, or a keyboard), then the only way to "play" would be to manipulate registers directly with the front-panel switches and "play" at the register/state level.

In Boom, I imagine you could simulate a raster display of some sort by building some sort of "video wall" or "video floor" with monochromatic textures/flats that change upon some event...that would be your video output. Of course, even for vanilla resolution, you would need a freaking huge number of sectors/openings, and the map would have a tremendously complex "wiring". To simulate video memory, you would need at least 64000 * 8 "memory cells", plus all the other memory you'd require for work RAM plus special "read only" memory cells that cannot be changed.

Now, since the Boom controls would actually control the actual (not the simulated) doomguy, you'd need to have some structure that works as a keyboard/gamepad, and which you activate by walking/shooting while observing the huge video monitor of DOOM in the distance, while an infernal landscape of weird machinery, voodoo dolls, conveyor belts, crushers, exploding barrels works tirelessly to make the simulation advance.

TL; DR: I think the major problem with those simulations is the speed at which events propagate and at which "logic gates", "registers" etc. can be made to change state. In the end it will be like playing Doom at a subatomic time scale, where you can literally see the signals being transmitted along wires and gates changing state.

Though with some minor source modding you could at least improve the situation over voodoo dolls.

The first thing to do is apply the ZDoom-style tweak which allows objects to move at nearly arbitrary high speeds.

The second thing to do is to reduce the voodoo doll to the minimum size that will, with this enhanced collision code, still properly clip. It's your "electron" so it needs to be small and fast ;)

Still, the speed of the simulation and the number of events caused even by the "game" sitting idle (but with the clock ticking and all the gizmos flipping states etc.) would be witnessed from an electron-eye type of view and would be perceived as extremely slow, as if you were some kind of little Maxwell Demon trapped inside a computer.

If you could interact with said "electrons", you could even cause glitches, e.g. by standing in their path or shooting them ;-)

In any case, I think designing something that complex is feasible, but only by using standardized prefabs like those e.g. used in VLSI design software (logic gates, transistors, whole memory cells etc.), making them as small as possible so that they can still function as intended and squeezing them on the surface allowed by a standard Doom map using a specialized editor (or even a tool that converts directly from VHDL or a similar design language), otherwise the complexity would be mind-boggling to design solely by hand.

The limited coordinate space of a Doom map could probably be hacked around by overlaying several layers of circuits (after all, overlapping vertexes , linedefs and sectors are possible, if you don't use a node builder that tries to compress/merge them), so a specialized node builder would be required as well. Of course, parts of the map with an overlaying mess of nodes/lines etc. should not be visualized/should be off-limits for the player, and of course such a map would NEVER have to be opened by a standard editor such as Doom Builder.

Edit: by using special design software, you could even design "components" that are sub-unitary in dimensions and have different manufacturing processes like real-life nm processes ;-)

I actually had a dream I was playing around with this. It was strange.

Prototype AND-gate with clock-input:

http://www.mediafire.com/?kwx79v8z8xmbdb5

I experimented a bit with an OR-gate and NOR-gate, and failed to make an NAND gate. Then I was thinking how difficult it would be to make even an XOR gate.

I started thinking from scratch again and thought that different types of signal might work.

The previous gate worked with clocked pulse logic. After a clock signal, a doll means 1 and no doll means 0.

I thought about how electronics work. A wire is either energized or not; there are no events. The next example uses toggle logic: A doll in one place means 1 and the same doll in another place means 0.

I created a prototype AND gate and realized something very useful: the order of the 1 and 0 locations does not matter, so I can easily construct OR, NAND and NOR gates by just swapping tags around.

http://www.mediafire.com/?l8vnwvlq4uazlw8

It is even faster than the previous logic style. In clocked pulse logic, when gates are chained, you need as much clock pulses as the longest chain of gates. In toggle logic, a change in input automatically cascades towards the end of the chain. (again, just like electronics)

Success!

I implemented an 8-bit adder using binary logic. This proves that all primitive digital gates (AND/OR/INVERT) and gates consisting of those (flip-flops, memory) can be implemented in Boom.

This opens the door to a real CPU in Boom.

http://www.mediafire.com/?9tacawcwcx52tcc

I designed a speed-optimized version of the Ripple-block carry look-ahead adder. This precalculates the carries in parallel so each digit doesn't have to wait for the previous digit (which would be very slow). For more information, see these links:

The design: http://i56.tinypic.com/2iqjuqd.png
Background information: http://www.aoki.ecei.tohoku.ac.jp/arith/mg/algorithm.html

Great! What you really need now, is some way to design complex circuits while using the map space efficiently (then again, it's not necessary for a map to be displayable to be functional as a logic circuit). E.g. something to translate VHDL to Boom circuits automatically.

Incidentally, wouldn't it be easier to implement asynchronous (non-clocked) logic with Boom? That would get rid of the need to propagate the clock everywhere.

Also...is there ANY chance for the clock and various logic events to actually toggle/propagate faster than once per game tic or faster than the game logic itself? Because a 35 Hz (or even a 200 Hz) CPU won't be much use, besides academics ;-) It must be like observing a computer with a microscope that also slows down the time scale incredibly :-p

It's already asynchronous.

And faster than once per game tic? What are you thinking? That's like asking to travel faster than light speed. A game tic is a single update in game state. There's no way to update things twice in a single update. And uncapped framerate doesn't help, that just interpolates the view between the previous and current state.

Even one update per tic is hard to reach (just like light speed is). With the current doll logic, the dolls need to be lifted over a ledge, then accelerated, then trigger a walk-over line. Each logic gate in my example has a propagation delay of 6 tics, and shoot buttons are 7 tics. So the entire duration of the adder is 7*6+7 = 49 tics. Assuming this is part of a larger CPU, and adding is the slowest operation, add some safety margin and overhead time and you have a 0.5Hz CPU.

My BOOM allows me to accelerate about 700 times before it tops out, which makes it a 350Hz CPU. The 'virtual machine' slowdown is about 2.4GHz/350Hz = about 7,000,000

Well, that still doesn't rule out that ONE DAY, there will be computers fast enough to run it ;-)

Assuming that you need about a 40 MHz CPU (assumping 1 CPU operation per clock, just like an i80486-class CPU), computationally wise, we'd need a computer that's about 80 million/350 times faster in purely serial problems than the best of the best available today. I doubt there exists even any modern supercomputer than could achieve that kind of speed on a purely serial problem that can't be parallelized (as is Doom's game logic).

BTW, have you came up with an estimate of how much data overhead is involved in order to store a bit of information, in the form of a logic gate inside a Doom map (or in the most efficient/convenient way possible with Boom's map format and game logic)?

That would also give us a size estimate of a WAD that stores WAD data encoded as "ROM gates" of some sort. But even is you can somehow indicate a bit with the simple presence/absence of a mapthing (and that's compatible with your logic gates), that still would mean storing up to 160 millions of them in a WAD, in order to represent e.g. the Doom II IWAD contents (assuming that you use no special extensions). Since a plain old Doom thing is 10 bytes on disk and the very least 152 bytes in RAM...do the math :-p

Maes said:

stuff

I know you want to create an optimized fork of Boom which strips everything unnecessary and only leaves in the functionality needed to create programs with this wad. Then you wouldn't need to waste unnecessary memory for thing data that's not needed and you could remove the 35 tick/second limit. :P

The EXTREEEEEME!!!11!! FPGA emulator of DOOM ? :-p

Yeah, that will give Altera & co. a run for their money ;-)

Dunno if this has been mentioned yet, but it might be worth looking at Wadc. It's a programming language/compiler that is useful for generating complex wads such as this.