[gp2000]

You could choose that the memory accesses be at any bit size from 1 to 32 with both unsigned and sign-extended register loads. In fact, I think you got to pick two sizes and for most normal operation you'd choose 16 and 32 bits. There were some load/store operations that always operated at 8 bits so you'd get the usual complement of data sizes. Pretty useful feature for something that was intended to be a graphics processor. I've also seen the different bit sizes used for fast and simple Huffman decoding in gzip decompression.

The auto-increment/decrement addressing modes were aware of the bit size. Thus you could have polymorphic subroutines where the same code could be used to sum an array of bytes, words, 13 bit quantities or whatever size word you wanted (up to 32 bits).

Since the processor had built-in circuitry to help drive graphics displays it took a high input frequency of something like 40 or 50 MHz and actually divided that down to run the processor at around 10 MHz or so. The opposite of what we're used to now and made the darn things look scary (well, scarier) from an emulation programmer's perspective.

The memory interface was designed to work with shift-register VRAM. The idea there being that the VRAM chips had a built-in shift register 512 pixels wide. The display circuitry would make use of it by having each line from the frame buffer dumped into the shift register as the raster was moving down the screen. And then the shift register would clock out the pixels as the raster moved across each line.

During VBLANK (when the video circuitry is waiting for the raster to return to the top of the screen) you could use special instructions to load and store the shift register which would be as fast as any load/store operation. The entire frame buffer could be filled very quickly with any repetitive pattern or erased entirely by copying some fixed line to all the others.

Lotta cool stuff in that beast.

[waynecochran]

Yes and then the TMS34020 came out which had a trapezoid fill instruction. Essentially you would partition your polygon into trapezoids; For each trapezoid you would load the appropriate registers ... the slopes of the edges used 16.16 fixed point numbers. I remember how much you could do with fixed point arithmetic.. very few programmers even know how program using fixed point anymore. A very useful lost art.

There was also a built in Bressenhsm line drawing instruction.

Then there was the TMS34082 floating point coprocessor. I essentially wrote a primitive OpenGL'ish pipeline API. That was fun.

Wow... I really wish a general purpose processor like this made it into the PC. The best stuff doesn't always win in the marketplace.

[pjmlp]

Last time I used fixed point arithmetic was for a J2ME game targeted at the Sharp GX20, for a game competition sponsored by Vodafone.