6 ms·

There's another TI processor that never really took off despite its usage in arcade consoles at the time. The TMS340 http://en.m.wikipedia.org/wiki/TMS34010 htt

There's another TI processor that never really took off despite its usage in arcade consoles at the time. The TMS340 http://en.m.wikipedia.org/wiki/TMS34010 http://en.m.wikipedia.org/wiki/TMS34010) series. 32bit in 1987. I assume it was just out of the price range of 8bit and 16bit machines. It was used in Mortal Kombat and NBA Jam games I believe.

karmakaze 11y ago
I remember those (coincidentally 68020/2) back when I was working at Eicon's graphics group (now Eicon Networks). Ended up just using M68Ks with blitters for PostScript and HP PCL interpreters. In the end the HP version even lost the blitter chip and I had to write bitblt.s
- kjs3 11y ago
  How did you implement your blitter?
  - karmakaze 11y ago
    I can't remember all the details now. The main interpreter was MS C with CodeView in text mode was awesome. The routines were 68k assembly with pixel write modes, optimized character blt, and there was a scale-up routine. The only reason the sw implementation came close to hw was that the hw had quite a bit of setup which is quite a bit of overhead for small patterns which were typical (e.g. patterned horizontal rules).
kjs3 11y ago
My opinion only, but I did at the time work for a company that created a TMS34010 product. It didn't take off because, frankly, it sucked. It was very expensive, relative to competing products, made worse by requiring lots of expensive VRAM memory (for both code and data memory) for decent performance. Memory bus was 16-bit, so if you were trying to do, say, 8-bit graphics, you could only grab 2 pixels per clock (~150ns-200ns depending on speed step). It was integer math only. I recall the C compiler was pretty buggy as well. There was a follow-on TMS34020 chip that was faster and had an FPU coprocessor and better 3D, but it was still prohibitively expensive to deliver product, and by then there were a boatload of competitors that were beating it on both performance and price.

karmakaze 11y ago

I remember those (coincidentally 68020/2) back when I was working at Eicon's graphics group (now Eicon Networks). Ended up just using M68Ks with blitters for PostScript and HP PCL interpreters. In the end the HP version even lost the blitter chip and I had to write bitblt.s

kjs3 11y ago
How did you implement your blitter?
- karmakaze 11y ago
  I can't remember all the details now. The main interpreter was MS C with CodeView in text mode was awesome. The routines were 68k assembly with pixel write modes, optimized character blt, and there was a scale-up routine. The only reason the sw implementation came close to hw was that the hw had quite a bit of setup which is quite a bit of overhead for small patterns which were typical (e.g. patterned horizontal rules).

kjs3 11y ago

My opinion only, but I did at the time work for a company that created a TMS34010 product. It didn't take off because, frankly, it sucked. It was very expensive, relative to competing products, made worse by requiring lots of expensive VRAM memory (for both code and data memory) for decent performance. Memory bus was 16-bit, so if you were trying to do, say, 8-bit graphics, you could only grab 2 pixels per clock (~150ns-200ns depending on speed step). It was integer math only. I recall the C compiler was pretty buggy as well. There was a follow-on TMS34020 chip that was faster and had an FPU coprocessor and better 3D, but it was still prohibitively expensive to deliver product, and by then there were a boatload of competitors that were beating it on both performance and price.