Archive for the ‘inventions’ Category

Programs I want to write

Wednesday, July 16th, 2008

There are a lot of programs I want to write.

Which of these do you, my blog readers, think I should work on? Comment below to vote. I don't promise to abide by your decision, though.

There are also a number of projects I have wanted to work on in the past but which aren't currently inspiring me for various reasons:

  • Digger (plus Styx and Sopwith) - I now think that emulation rather than remastering is the best solution for these old games.
  • CRTC emulation and other MESS work - superceded by the Modular Emulator and NTSC decoder.

PAL version of demo machine

Wednesday, July 2nd, 2008

The demo machine described the other day could easily be generalized to PAL output. There are some complexities though. Because of the missing quarter cycle of the carrier frequency per line, the PAL signal for a still image repeats every 4 frames. This means that in order to do the same "extremely simple, highly standards-compliant demo" that was possible on the original demo machine for NTSC, we need 2.7Mb of sample data. Let's run with this and round up the PAL machine's memory to 4Mb - rather than making the PAL machine as similar as possible to the NTSC machine, we should take the opportunity to introduce some variety.

Similarly, the CPU clock speed for the PAL machine should be (exactly) 17.734475MHz.

Generating interesting standard PAL signals does have some complications that NTSC signals don't have. Because of the 25Hz offset, the colour carrier frequency starts at a different phase on each line, meaning that a sprite needs to have different sample data depending on its vertical position. I expect that most demos written for the machine would use one of three simplications of the PAL standard (as most if not all computers and consoles that generate PAL signals did):

  1. eliminate the 25Hz offset so that the colour carrier phase repeats every 4 lines
  2. use a whole number of subcarrier cycles per line (making the chroma patterns vertical)
  3. eliminate interlacing, doubling the frame rate at the expense of halving the vertical resolution

These simplifications change the horizontal and vertical retrace frequencies slightly from the standard 15.625KHz and 50Hz rates, but not so much that real hardware is likely to fail to display the intended image.

Demo machine

Monday, June 30th, 2008

If one were to design a computer specifically for the purpose of having Oldskool-style demos written for it, what would it be like?

I came up with a few requirements:

  • Oldskool "feel"
  • Attractive output: sampled sound and realistic looking (still) images can be achieved very easily
  • The more skilled the programmer, the better effects can be achieved - very great skill is required for the best effects
  • Hardware as simple as possible
  • Easy to emulate
  • Fun to program

To get that Oldskool feel but still allow realistic looking still images, I decided to base it around a composite NTSC signal. It turns out there is a standard for digital composite NTSC signals - SMPTE 244M, so I just picked the 8-bit version of that. The video hardware is about as simple as video hardware could possibly be - just an 8-bit DAC that repeatedly cycles through a consecutive region of memory and dumps the bytes to the output at a frequency of 14.318MHz (4 times the color carrier frequency). This is also the CPU clock speed (the CPU is in sync with the pixel clock).

Technically, a still image in this format that is fully NTSC compliant requires 955,500 bytes (933Kb) of memory (2 frames*910*525) because the color carrier phase alternates between frames. Given that the machine's memory size should be a power of 2 (so that we can map 32-bit addresses to physical addresses just by clearing the top bits) I decided to give it 1Mb (any more and it stops being so Oldskool). This doesn't necessarily mean that you need to use almost all the memory to store the framebuffer - by tweaking the burst/sync patterns you can get a 912*525 (468Kb) interlaced mode where you only need one frame, or a 912*262 (233Kb) non-interlaced mode (again with only frame), both of which should be compatible with any composite monitor. These have usable resolutions (including the overscan area) of about 720*480 and 720*240 respectively (with respective CGA-esque pixel aspect ratios of 5:6 and 5:12). So this gives a nice bit of flexibility to software with no extra hardware complexity.

One disadvantage of this setup is that it may be possible for software to damage some composite monitors by creating sync pulses too often. So one would probably want to use an emulator when testing/debugging programs! Also, scrolling is fiddly because you have to move the image data independently of the sync/burst pulses. There are block move instructions which can move 4 pixels per clock to help with this, though.

Audio is done in a very similar way to video - set the beginning and end of the region of memory and the hardware cycles through that memory range turning bytes into samples and putting them through a DAC. Another register is used to set the sample rate (I decided a fixed rate would be too inflexible).

Programs are just 1Mb memory images which are dumped into RAM. The first two words of RAM are the instruction pointer and the stack pointer, so execution starts at the address pointed to by the word at 0. I/O registers are also at the start of the memory region.

Most instructions are 1 cycle long (with the exception of instructions like the equivalents of "REP MOVSB" and "REP STOSB") to enable effects that require cycle counting to be done as easily as possible. Most instructions are 1 byte long (with the exception of instructions that have a 1-byte, 2-byte or 4-byte immediate argument). The CPU is 32-bit (to make addressing that 1Mb of memory easy). The architecture is stack machine based (kind of like Java) - I have a soft spot for such architectures because they're really easy to write decent compilers for (registers are helpful at the hardware level for making processors fast, but that isn't a particular concern here). Devolving the CPU has some ideas for generating a good instruction set.

Because of the cycle counting and simplicity requirements, there are no hardware interrupts - all timing must be done by cycle counting. This also means that there are no instructions whose purpose is to determine some value N and take O(N) time to do it - so no "REP SCASB" in this architecture. I don't think that is very useful for demos anyway, and it's a non-goal of this design to be suitable for general purpose computing tasks like searching and parsing.

It would be pretty easy to generalize this architecture to make a games machine - just have a register whose bits reflect the up/down status of controller buttons.

Now, while I'd like to believe that building such a machine would revitalize the Oldskool demo scene by providing a new focal point, I suspect a more realistic point of view is that because programming such a machine would be such a non-applicable skill, because the limitations of the machine constrain the possible effects, and because there would be none of the nostalgia inspired by actual Oldskool hardware, nobody would actually be interested. But it's still an interesting exercise!

Vocalsynth

Sunday, June 29th, 2008

A fun toy would be a musical instrument with a microphone that can detect and modify pitch in real time. So if you sing an A but play a B it will transpose your voice up a tone. I understand such things are common in modern recording studios but I'm not sure if they work in real time (besides which, I don't think it would be too difficult to create such a thing from scratch).

Better still would be if it was polyphonic, so you sing a note, play a chord and hear a trio.

Multiple scrollbars

Thursday, April 26th, 2007

Ever have a window which has so much text in it that the vertical scrollbar moves too coarsely to allow you to find the position you want? Like you have an entire dictionary loaded as a text file and you're trying to find the word "madrigal". You get to "machine" and (after some fiddling with the mouse) manage to move the scroller one pixel down only to find that you have overshot all the way to "magical". Then you have to scroll all the way back up to madrigal or go back to machine and scroll down. Either of which, depending on the size of the dictionary, may take quite some time. Most annoying.

Wouldn't it be good if, for long documents like this, you had two scrollbars side-by-side. These would work like the hour hand and minute hand on a clock. The rightmost one would set the position in the document coarsely and the leftmost one would be for fine-tuning it. Once you had got to the "early Ms" with the rightmost scrollbar you could quickly get to any nearby word with the leftmost one.

For best distribution of precision between the scrollbars, the region of the document corresponding to the entirety of the leftmost scrollbar (X) would be to the entirety of the document as the window would be to X (i.e. the pixel size of the two scrollers would be the same).

The scrollbars would be set up so that moving the scroller of the leftmost scrollbar one pixel scrolled the document by at most one line. If the document is too large, than a new scrollbar is added - particularly long documents might have 3 or even more scrollbars, each with the same virtual document size to virtual window size ratio.

Lensing editor

Wednesday, April 25th, 2007

One problem I'm always wrestling with while programming is how to see as much as possible of my program on screen at once. I tend to use a very high screen resolution (1600x1200 usually) and a very small font in my text editor (6x8) to see a large quantity of text at once. My coworkers despair that they can never read what's on my screen and say that I must have very good eyesight (I do at short distance - reading road signs while driving is another matter). But even 150 lines is not enough sometimes.

A while ago I had an idea for effectively increasing the number of lines even further. Vertically "compress" the lines that are further away from the cursor, while showing the closer lines at normal size. The further lines wouldn't be legible (unless the document is quite small) but you can see the overall "shape" of the document and easily navigate to different sections. The effect would be kind of like squashing the document vertically so that the whole thing fits on the screen and then looking at part of it with a horizontal bar magnifier centred on the cursor (although it would be a magnifier with an extended cross section so that even lines of text quite far away from the center were magnified a little bit, and there would be no obvious boundary between magnified and non-magnified text). Because of the similarity to a bar magnifier, and by analogy with the concept of a "folding editor" I call this idea the "lensing editor".

Sonic head tracking

Tuesday, April 24th, 2007

Here's an interesting idea I had a while ago. It involves using the microphone in a headset like this, a fixed set of speakers and a high-resolution sound card (like almost any modern sound card) to track the position of the head of the person wearing the headset.

The software works by sending sounds through the speakers and trying to pick them up through the microphone. Once it manages to synchronize the sent pulses with the received pulses it can calculate the exact delay from sending a pulse to receiving it. Part of this delay will be due to the hardware involved or the latencies in the operating system, but these delays should be fixed. The remainder of the time is caused by the finite speed of sound in the medium between the speaker and the microphone. To a fairly good approximation this speed will be constant (about 300m/s) so using the delay one can work out the distance between the microphone and the speaker. Do this for two speakers and you can triangulate the position to a circle in the plane normal to the line between the speakers. Two more speakers and you can determine the position of the user's head quite precisely, up to the resolution limit of the soundcard (most modern soundcards can do 192k samples/second, giving a positioning accuracy of about 1.6mm).

Why would you want to do this? Well, the position of the user's head is a particularly interesting datum because it can be used to move windows around giving a pseudo-3D view. Suppose you have two windows on the screen and one is partially covering another. Normally to see the hidden part of the lower window you have to use the mouse (or worse, the keyboard) to move the upper window or bring the lower window to the foreground. But with a pseudo-3D view each window has a "Z-position" in front of or behind the plane of the monitor. If the user's head moves left then the closer windows move right and the further windows move left, allowing you to "see around" the upper window by moving your head, just as you would do with real objects. I haven't tried it yet, but I think it would be quite effective, and a cheap way to make a user interface much more immersive. I thought of doing this years ago but with an infra-red gadget strapped to the forehead - it only recently occurred to me that this could be done less intrusively with the microphone that many people wear anyway for telephony purposes.

Road rage and body language

Saturday, April 14th, 2007

I think that most cases of road rage could be eliminated if cars could express body language. If it was possible to tell from a long way away that someone is in a hurry or a bad mood, people might stay out of their way. Conversely, if someone made a mistake while driving and their "oops" was clearly visible, people might be more likely to forgive them.

Perhaps future technology will make this possible - a couple of cameras mounted in the dashboard connected to a holographic display on the roof might just do the trick. Though by the time we have that technology hopefully cars will be driving themselves.

Inventing stuff in my sleep

Tuesday, November 1st, 2005

I was dreaming about how to improve the interface for a clock. The dream took the form of a conversation between two parts of my subconscious:
1: The ideal interface for a clock would be to not have one at all. It should be able to set itself from radio time signals.
2: But what about time zones and DST?
1: Well, it could have a built-in GPS and a database of time zones and locations.
2: Isn't that rather a lot of expensive hardware for a simple clock?
1: Well, we could have a microprocessor in the clock which controls everything from the display to the GPS - even the radio could be software based. By keeping the hardware simple and the complexity in the software, we can keep unit costs minimal.
2: Brilliant! Let's write up a business plan.

Then I woke up.

No screws

Thursday, June 23rd, 2005

Imagine what the world would be like if the screw thread hadn't been invented. (That's just an example - it could just as well be something else that is similarly obvious-with-hindsight and is in everyday use, but it was screwing in wall anchors the other day that made me think of it.) The screw thread isn't really used much in nature (as far as I know) apart from on a very small scale so it is kind of plausible that somewhere out there there could be an alien species at a similar level of technology to us who just never thought of the concept of screw threads. It could be that (even despite having invented all sorts of other things) their minds are built in just such a way that the concept would never occur to them without having seen it. Maybe that when faced with the problem of converting linear motion into rotary motion, they use some other device (like the rack and pinion) or just somehow evade the problem altogether (by using nails instead, for example).

Now let's turn this hypothetical thought on its head and wonder if there could be some similarly simple and useful concept that we have just never thought of, that some alien species uses every day for all sorts of purposes. Some device that would easily solve all sorts of problems that we solve in much more complicated ways, just because nobody ever thought of the easy way of doing it. I imagine that when we do eventually make contact with intelligent alien species, that there will be all sorts of such "oh why didn't we think of that" moments (possibly on both sides, especially if it's a mutual first-contact situation). Probabably nothing as simple as the screw thread, but potentially all sorts of slightly more obscure things. Just one reason why the SETI project could pay big dividends if it is ever successful.