Vectrex
-
At the time, I was fascinated by the 9900 chip (the CPU, not the 9918 graphics chip), having all 'registers' in memory. At an interrupt, you could swap context completely simply update the "Workspace Pointer" to another complete register set. The bad thing was of course that register operations were no faster than memory operations, so all things considered, the chip was terribly slow. But interrupt handling was terribly fast! Sometimes, when I dig up memories of those quite different solutions that were ditched, I can't help but wondering: What if someone took up the ideas today and modernized them? A 9900 model 2022 would of course be a 32 or 64 bit chip, and I assume it would be built with a caching mechanism for the register blocks. Maybe, for some application areas were super fast interrupt handling was essential, and "unlimited" number of threads was a valuable property, that idea of just setting a pointer to the appropriate register block might have some merit! (I have worked on a machine with something resembling it: Interrupts were prioritized into 16 levels; a high level could suspend a lower one. Each level had its own physical register set. The first instruction of the interrupt handler started executing 900 ns after the arrival of the interrupt signal, which was rather impressive in the mid 1970s, when these small 16 bit minis (PDP-11 class) where developed and sold.)
Yes, I remember it well. I learned assembly for the TMS9900, and I recall that the architecture of the TI-99/4A was such that the video RAM was separate from the CPU RAM. In order to write to video RAM, the CPU had to set certain memory locations and then perform several NOP instructions to allow the video processor time to read the values that were just written. This led to extremely poor graphics speed, and in my view was just a dumb design.
The difficult we do right away... ...the impossible takes slightly longer.
-
CodeWraith wrote:
I will probably take a TMS9918 instead
Was that the chip used inside the TI-99/4A home computer?
The difficult we do right away... ...the impossible takes slightly longer.
Yes, that's the one. The selection of suitable graphics chips that are still available in some way unfortunately is not very large.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Yes, I remember it well. I learned assembly for the TMS9900, and I recall that the architecture of the TI-99/4A was such that the video RAM was separate from the CPU RAM. In order to write to video RAM, the CPU had to set certain memory locations and then perform several NOP instructions to allow the video processor time to read the values that were just written. This led to extremely poor graphics speed, and in my view was just a dumb design.
The difficult we do right away... ...the impossible takes slightly longer.
I don't expect anyone picking up a 30-40 year old architecture to feel obliged to carry forward any or every specific detail in the old design. Like the example you give: That seems to be something we can leave behind. The important thing is if there are forgotten solutions that might be more viable today than they were when they were left. Even though 99/4A had a poor video RAM interface, still the idea of a register block pointer to memory may be far more realistic today than forty years ago. As far as I remember, at the time of TI-99 cache memory was completely unknown in the microprocessor world (and for some years to come). I am not stating as a fact that cache makes the register block pointer idea a good one, but it might change the situation so that in some context where fast interrupt handling and thousands of threads is essential and far more important than beating x64 on number crunching. Whenever I tell my 'hope' that Intel would reconsider the ideas behind the 432, to make a truly object oriented processor, someone instantly jumps up: Forget it! The 432 was limited to 8 Ki objects - that is completely useless today! ... So why not make a 432 model 2022 with 4 Gi objects, then? But, I hear you cry, the 432 objects could be of max 4 Ki bytes! (if my memory is correct - don't quote me on that limit) ... So why not let the 432 model 2022 have object up to 4 Gi bytes? The same thing here: Even though there may be bad partial solution that you don't want to pick up, don't let that keep you from reconsidering other partial solution that might be much better.
-
At least I find it fun to read about. Yet I doubt that I would be spending many hours playin games on that machine :-) A small side remark: I looked around a few Wikipedia pages - some are of a strange kind, such as List of commercial failures in video games [^], which lists the Vectrex among 32 other gaming hardware failures, and also lists 27 gaming software failures. I mean: How did we survive in the old days, without Wikipedia to provide such absolutely essential information? :-) Another remark: Referring to 6809 as 'a relative of 6502' ... well ... Sure, they were both marketed as 8-bitters. Just like 8086 and MC68K were 'relatives', as they both were 16-bitters, at least externally. (68K had several 32-bit features, and 6809 had a number of 16-bit features.) But who cares about such details, 40 years later? (For those who remember the CPU wars of the 1980s, essentially between x86 and 68K: That is one of my prime examples to illustrate that sometimes, the best one does not win. But that is another discussion.)
-
At least I find it fun to read about. Yet I doubt that I would be spending many hours playin games on that machine :-) A small side remark: I looked around a few Wikipedia pages - some are of a strange kind, such as List of commercial failures in video games [^], which lists the Vectrex among 32 other gaming hardware failures, and also lists 27 gaming software failures. I mean: How did we survive in the old days, without Wikipedia to provide such absolutely essential information? :-) Another remark: Referring to 6809 as 'a relative of 6502' ... well ... Sure, they were both marketed as 8-bitters. Just like 8086 and MC68K were 'relatives', as they both were 16-bitters, at least externally. (68K had several 32-bit features, and 6809 had a number of 16-bit features.) But who cares about such details, 40 years later? (For those who remember the CPU wars of the 1980s, essentially between x86 and 68K: That is one of my prime examples to illustrate that sometimes, the best one does not win. But that is another discussion.)
refarding that failures list, for me meeting high expectations is not same failure. never released to market is likly the story of 100 to 1 products never released. Pippin, 64dd, sega cd, 32x. oh we only sold 9 million, boo, we wanted a billion: Sega Saturn, Dreamcast, VirtualBoy, WiiU, I saw enough in the world, but still marketcap expectations: ngage, ps vita. yeah, the paragraph is enough to explain its dislike: ps classic. for any others, if the companies broke even, well guess what, stop being greedy.
-
I bought one of these off eBay for nostalgia's sake: Vectrex - Wikipedia[^] It's really cool and it uses a relative of the Motorola 6502. But the weirdest thing about it is that it has only 1K of RAM! Imagine being tasked to write a video game that doesn't use more than 1K of RAM! The sound effects are in league with the Apple ][. A single voice driving a single small speaker. Does anyone else like to collect vintage computing devices?
The difficult we do right away... ...the impossible takes slightly longer.
-
I bought one of these off eBay for nostalgia's sake: Vectrex - Wikipedia[^] It's really cool and it uses a relative of the Motorola 6502. But the weirdest thing about it is that it has only 1K of RAM! Imagine being tasked to write a video game that doesn't use more than 1K of RAM! The sound effects are in league with the Apple ][. A single voice driving a single small speaker. Does anyone else like to collect vintage computing devices?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote: Does anyone else like to collect vintage computing devices? I kept my Commodore 64, my Commodore Pet 2001 with the chiclet keyboard, my Franklin Ace 2000 (Apple IIe clone), and an assortment of green screen and color Wyse terminals for many years. I think it was after my 2nd child was born, and we needed the space, that I finally sold them off. I wouldn't mind having my Pet back. I think that one was my favorite. ---------- Money makes the world go round ... but documentation moves the money.
-
I bought one of these off eBay for nostalgia's sake: Vectrex - Wikipedia[^] It's really cool and it uses a relative of the Motorola 6502. But the weirdest thing about it is that it has only 1K of RAM! Imagine being tasked to write a video game that doesn't use more than 1K of RAM! The sound effects are in league with the Apple ][. A single voice driving a single small speaker. Does anyone else like to collect vintage computing devices?
The difficult we do right away... ...the impossible takes slightly longer.
-
Richard Andrew x64 wrote:
Reminds me of the golden age of home computers.
You mean bronze age of computers. Today is the golden age. You can go down to the store and pick up a perfectly useable one for less than $500 that will handle some pretty impressive games that would have been utterly impossible back then, even if you shoveled out over $10,000. Or a million dollars, for that matter. I remember doing FEA in college, and the computation took hours to days. Now it is pretty much instantaneous. God, I don't miss those old 386's. Bootups in minutes...
Our Forgotten Astronomy | Object Oriented Programming with C++
I think the the early 1980s was more "Cambrian Explosion". A massive diversification of computers, most of which died out after the dominant species took hold.
-
At the time, I was fascinated by the 9900 chip (the CPU, not the 9918 graphics chip), having all 'registers' in memory. At an interrupt, you could swap context completely simply update the "Workspace Pointer" to another complete register set. The bad thing was of course that register operations were no faster than memory operations, so all things considered, the chip was terribly slow. But interrupt handling was terribly fast! Sometimes, when I dig up memories of those quite different solutions that were ditched, I can't help but wondering: What if someone took up the ideas today and modernized them? A 9900 model 2022 would of course be a 32 or 64 bit chip, and I assume it would be built with a caching mechanism for the register blocks. Maybe, for some application areas were super fast interrupt handling was essential, and "unlimited" number of threads was a valuable property, that idea of just setting a pointer to the appropriate register block might have some merit! (I have worked on a machine with something resembling it: Interrupts were prioritized into 16 levels; a high level could suspend a lower one. Each level had its own physical register set. The first instruction of the interrupt handler started executing 900 ns after the arrival of the interrupt signal, which was rather impressive in the mid 1970s, when these small 16 bit minis (PDP-11 class) where developed and sold.)
I also had a fascination with the TI 9900 chip. Loved that register concept. I don't collect vintage computers, but I have my TI99/4A in it's original box, with some of the original paperwork, and many cassettes of old basic and assembler programs. I haven't turned it on for 20 years. I think I tossed my TI cassette player, but I still have it's box. So, no collecting vintage hardware, but one piece that I can't seem to let go.
