Jump to content

What is the Commander X8?


Recommended Posts

9 hours ago, BruceMcF said:

Are you referring to the CX16p. CX16c or CX16e?

The CX16p would have an actual 8bit processor, all ASIC through pin chips on the board. The CX16c, though we haven't seen a prototype yet, would have similar, except mostly surface mount and possibly a CPLD replacing the glue logic, and the VERA circuit on the board.

[+] If you don't see the appeal of that, this implies you aren't in the target audience for those. That's normal: nothing is attractive to everybody.

The CX16e, though we are even further from seeing a prototype, would give the ability to run much of the same software that can run on the CX16p (unless it requires the undefined whatevers that can't make the transition to FPGA), without forcing someone to muck about with something like a Mister system.

Ditto [+]

If the software ecosystem around the CX16 is attractive enough to make it worthwhile to develop a Mister simulator for it and for a reasonably large number of people to use that simulator, it would be due in part to the stable development target implied by the system reference design. Without the CX16p existing, there isn't the stable development target which might (bearing in mind that little in life is guaranteed) be the kernel for an attractive retro kind of software ecosystem, for chameleon systems to benefit from by simulating.

Bear in mind the genesis of the CX16 project is people asking The 8bit Guy for advice on what 8bit system to buy if they wanted to have some experience with that style of system, and his realization that there wasn't a classical system that he could recommend without reservation. It's not likely there is a lot of overlap between that core target audience and the typical Mister owner.

I said "X16e"; I'm not sure how that created confusion about which specific device I was referring to. Also, the most complex functionality of the CX16p is on Vera which is neither an ASIC nor a through-hole dip chip. I'm utterly confused about your CPLD comment: the CX16's glue logic should be replaced with an SPLD or EEPLD; and I am not aware of any CPLD on the market which could hope to replace an iCE40UP FPGA.

Have you ever mucked about with a Mister? "Forcing" makes it sound like much more of a chore than my real life experience suggests. "Worthwhile" seems to imply that a developing a CX16 Mister core would be a substantial amount of work. All of the Verilog except VERA would amount to a couple lazy summer weekends by a grad a student with nothing better to do.

That is why my specific question is what would the X16e provide that a DE-10 nano with an IO daughterboard could not. The only example I can glean from your response is "not having to muck with Mister" which is non-sensical. Mister is the most popular environment for the DE-10 nano, but it is not required nor was it even intended when Terasic made the device.  It seems to me that implementing the CX16e on a DE-10 nano would make more sense than developing a new FPGA platform design and also more sense for phase 2 of the CX16.

  • Like 1
Link to comment
Share on other sites

4 hours ago, Wavicle said:

[1] I said "X16e"; I'm not sure how that created confusion about which specific device I was referring to. ...

[2] Have you ever mucked about with a Mister? "Forcing" makes it sound like much more of a chore than my real life experience suggests. "Worthwhile" seems to imply that a developing a CX16 Mister core would be a substantial amount of work. All of the Verilog except VERA would amount to a couple lazy summer weekends by a grad a student with nothing better to do.

[3] That is why my specific question is what would the X16e provide that a DE-10 nano with an IO daughterboard could not. The only example I can glean from your response is "not having to muck with Mister" which is non-sensical. Mister is the most popular environment for the DE-10 nano, but it is not required nor was it even intended when Terasic made the device.  It seems to me that implementing the CX16e on a DE-10 nano would make more sense than developing a new FPGA platform design and also more sense for phase 2 of the CX16.

[1] Sorry, I didn't catch that when I read it the first time.

[2] But does your real life experience include having an interest in learning how to work with FPGAs, or is it the experience of learning how to work with a DE-10 nano as a chore to be got through in order to get to the part you are interested in? If it's the former, you wouldn't actually have had the experience of what climbing that learning curve is like for the latter.

[3] Your question wasn't why a new FPGA platform design makes more sense, it was what the CX16e would provide that a DE-10 with an IO daughterboard could not.

Obviously the DE-10 nano would have a higher retail price for delivering a complete system to the market, and the new FPGA design would have a lower price, so since the design target for "Phase 3" is to deliver a complete system at a lower price, the DE-10 nano approach could have been ruled out quite early.

Also it makes absolutely no sense for Phase2 of the project, which is targeting the segment of the audience who would like to have all of that lovely through hole ASIC on the board but can't justify the substantial cost of that kind of system, because rather than delivering as close to that as they can get at a lower cost price (and the reduction in board build price is not the only cost reduction, because the smaller board seems likely to be put into a smaller and less expensive case to form the complete system, which will then be less expensive to ship), it delivers almost as far from that as they can get short of just running the CX16 emulator on a PC.

Link to comment
Share on other sites

30 minutes ago, BruceMcF said:

[1] Sorry, I didn't catch that when I read it the first time.

[2] But does your real life experience include having an interest in learning how to work with FPGAs, or is it the experience of learning how to work with a DE-10 nano as a chore to be got through in order to get to the part you are interested in? If it's the former, you wouldn't actually have had the experience of what climbing that learning curve is like for the latter.

[3] Your question wasn't why a new FPGA platform design makes more sense, it was 1what the CX16e would provide that a DE-10 with an IO daughterboard could not.

Obviously the DE-10 nano would have a higher retail price for delivering a complete system to the market, and the new FPGA design would have a lower price, so since the design target for "Phase 3" is to deliver a complete system at a lower price, the DE-10 nano approach could have been ruled out quite early.

Also it makes absolutely no sense for Phase2 of the project, which is targeting the segment of the audience who would like to have all of that lovely through hole ASIC on the board but can't justify the substantial cost of that kind of system, because rather than delivering as close to that as they can get at a lower cost price (and the reduction in board build price is not the only cost reduction, because the smaller board seems likely to be put into a smaller and less expensive case to form the complete system, which will then be less expensive to ship), it delivers almost as far from that as they can get short of just running the CX16 emulator on a PC.

[2] If you only want to use the Mister+DE-10 Nano platform as a hardware emulation system, all you need to do is write a disk image to an SD card, insert the card, and turn the device on. It's all automated from there. What is the learning curve for running Win32 Disk Imager like, exactly? It sounds like you have no idea what working with the platform is like and have made a lot of incorrect assumptions.

[3] Yes, I know. Why are you stating what my question wasn't? I didn't change the question.

The DE-10 Nano is $135, which is more than the $100 target; and an IO daughterboard, if necessary, would be on top of that. What it gets you now is time to market. If the additional IO ports are not needed or the existing Mister IO board is adequate, the CX16e on DE-10 Nano can be ready to ship, albeit without a case, a week or two after the CX16 architecture is finalized and people can start using it before the first CX16p is out the door. It would be targeted at the same market segment as those who would be interested in the CX16e. Hence the way I stated my question.

Link to comment
Share on other sites

4 hours ago, Wavicle said:

[3] Yes, I know. Why are you stating what my question wasn't? I didn't change the question.

The DE-10 Nano is $135, which is more than the $100 target; and an IO daughterboard, if necessary, would be on top of that. What it gets you now is time to market. If the additional IO ports are not needed or the existing Mister IO board is adequate, the CX16e on DE-10 Nano can be ready to ship, albeit without a case, a week or two after the CX16 architecture is finalized and people can start using it before the first CX16p is out the door. It would be targeted at the same market segment as those who would be interested in the CX16e. Hence the way I stated my question.

The question of what the third phase gives that a DE-10 Nano cannot is a different issue than, quoting you, "It seems to me that implementing the CX16e on a DE-10 nano would make more sense". The implied question, "why wouldn't implementing the CX16e on a DE nano make more sense than a dedicated CX16e board built around an FPGA" is a quite distinct question.

Now it's "ready to ship, albeit without a case" beating the CX16p to market for no particular benefit to the project, but at the same time, "targeted at the same market segment as those who would be interested in the CX16e", who are people interested in a system in a case, although happy (or willing) to accept an FPGA board inside the case if it gets the system price down as low as possible.

It seems like you are equating the entire market for Phase3 with the entire audience for a CX16 core on a DE-10 Nano by assumption. Those are not automatically the same groups, even if there may be some degree of overlap.

How big the market for the third phase might be would be an open question, but whether or not it is enough to support that phase of the project is something that is answered by putting it out to crowdfunding.

It's also an open question whether there is a actual market for a CX16 core for a DE-10 Nano, or whether its like a lot of the "retro gaming" crowd that is happy to put all of their money into hardware because they rip off all of their software from pirate bay sites.

Link to comment
Share on other sites

1 hour ago, BruceMcF said:

The question of what the third phase gives that a DE-10 Nano cannot is a different issue than, quoting you, "It seems to me that implementing the CX16e on a DE-10 nano would make more sense". The implied question, "why wouldn't implementing the CX16e on a DE nano make more sense than a dedicated CX16e board built around an FPGA" is a quite distinct question.

Now it's "ready to ship, albeit without a case" beating the CX16p to market for no particular benefit to the project, but at the same time, "targeted at the same market segment as those who would be interested in the CX16e", who are people interested in a system in a case, although happy (or willing) to accept an FPGA board inside the case if it gets the system price down as low as possible.

It seems like you are equating the entire market for Phase3 with the entire audience for a CX16 core on a DE-10 Nano by assumption. Those are not automatically the same groups, even if there may be some degree of overlap.

How big the market for the third phase might be would be an open question, but whether or not it is enough to support that phase of the project is something that is answered by putting it out to crowdfunding.

It's also an open question whether there is a actual market for a CX16 core for a DE-10 Nano, or whether its like a lot of the "retro gaming" crowd that is happy to put all of their money into hardware because they rip off all of their software from pirate bay sites.

I don't know what it is about leveraging an existing FPGA platform that merits this sort of reaction, but this has become uncivil and I don't care to continue.

Link to comment
Share on other sites

"Also, the most complex functionality of the CX16p is on Vera which is neither an ASIC nor a through-hole dip chip."

Well .... actually pretty much all of the functionality of the CX16 is on Vera now. You're left with the RAM, ROM and CPU (maybe one of the sound chips, not sure).

An FPGA would have one huge advantage ; it wouldn't be limited to 8Mhz.

 

  • Like 1
Link to comment
Share on other sites

6 hours ago, paulscottrobson said:

"Also, the most complex functionality of the CX16p is on Vera which is neither an ASIC nor a through-hole dip chip."

Well .... actually pretty much all of the functionality of the CX16 is on Vera now. You're left with the RAM, ROM and CPU (maybe one of the sound chips, not sure).

An FPGA would have one huge advantage ; it wouldn't be limited to 8Mhz.

 

Don't forget about the 128KB of high speed pseudo-dual-ported RAM on that FPGA!

I believe I had posted in another forum that consolidating functionality to VERA made the project look like an over-engineered 8 bit controller for an FPGA device; it was losing its "8 bit feel" and spec wise was competitive with 16/32 bit computers of the day.

Link to comment
Share on other sites

7 hours ago, paulscottrobson said:

Well .... actually pretty much all of the functionality of the CX16 is on Vera now. You're left with the RAM, ROM and CPU (maybe one of the sound chips, not sure).

The 65C22 VIAs, any expansion cards, and the YM2151 (as you mentioned) are additional components of the system that are not part of VERA.

  • Like 2
Link to comment
Share on other sites

13 hours ago, Elektron72 said:

The 65C22 VIAs, any expansion cards, and the YM2151 (as you mentioned) are additional components of the system that are not part of VERA.

The VIAs are just used as control ports mostly as far as I can see. The other thing I'm not sure of is the PS/2 interface, which should be on Vera because of the way it operates.

Link to comment
Share on other sites

1 hour ago, paulscottrobson said:

The VIAs are just used as control ports mostly as far as I can see. The other thing I'm not sure of is the PS/2 interface, which should be on Vera because of the way it operates.

One of the VIA's seem to be mostly used for PS/2 and Gamepad input ... a few of the lines are the other one are used for that, but most if it is used to provide the User port.

Link to comment
Share on other sites

15 hours ago, Wavicle said:

Don't forget about the 128KB of high speed pseudo-dual-ported RAM on that FPGA!

I believe I had posted in another forum that consolidating functionality to VERA made the project look like an over-engineered 8 bit controller for an FPGA device; it was losing its "8 bit feel" and spec wise was competitive with 16/32 bit computers of the day.

Yes, the psuedo-video-RAM (though it is really truly dual ported) is very similar to the 80 column display on the C128 with indirect access to the Video Memory which is distinct from the main computer memory.

And similar to some of the Atari 8bits and to the C16 in having (most of) the audio functions and video functions consolidated into a single chip.

But VERA is far from the complex of coprocessor and blitter in the Amiga. Despite repeated calls from various corners in the last several years, the design team has stuck to their guns about VERA being a Video Chip rather than a Graphical Processing Unit.

Link to comment
Share on other sites

On 3/15/2021 at 7:30 AM, paulscottrobson said:

pretty much all of the functionality of the CX16 is on Vera now.

...and was before.  VERA is its own product too; I'd expect it to do lots of modern things.

I love the way it opens up a physical 65C02 system -- essentially doing all of the auxiliary bits from chips that can't be sourced reasonably.  I think it's just a fact of this millennium that it's like a turbojet bolted onto a dune buggy.  It's nice to have an embarrassment of riches!

 

Edited by rje
  • Like 1
Link to comment
Share on other sites

2 hours ago, picosecond said:

Those are logical ports, and maybe that is what Bruce meant by "truly dual-ported".  I inferred he was describing the internal construction of the FPGA RAM blocks.

Based on the logo on top of the FPGA (Lattice) and the QFN-48 pinout, I'm guessing that the FPGA is the ICE40UP5K-SG48I. It has 1Mbit of internal "SPRAM", which matches the VERA specs and from my reading of the datasheet is called "pseudo-dual-ported" because it has separate read and write ports. It is separate from the FPGA block RAM and as near as I can tell is not "truly dual-ported".

  • Like 1
Link to comment
Share on other sites

59 minutes ago, Wavicle said:

Based on the logo on top of the FPGA (Lattice) and the QFN-48 pinout, I'm guessing that the FPGA is the ICE40UP5K-SG48I.

Yup.  That matches my guess exactly.  I did not see anyone from the design team confirm this but I can't think of any other parts that match.

The 16Kx16 SPRAM has just one address port so I would call it single-port and leave it at that.  But that is picking nits.  I think we both agree that it is definitely not "truly dual-ported".  Hence the request for citations...

  • Like 1
Link to comment
Share on other sites

4 minutes ago, picosecond said:

Yup.  That matches my guess exactly.  I did not see anyone from the design team confirm this but I can't think of any other parts that match.

The 16Kx16 SPRAM has just one address port so I would call it single-port and leave it at that.  But that is picking nits.  I think we both agree that it is definitely not "truly dual-ported".  Hence the request for citations...

Upon re-reading the datasheet, you are correct. The block RAM can be pseudo-dual ported (section 3.1.5), not the SPRAM (which I should have known since it stands for "single port RAM").

  • Like 2
Link to comment
Share on other sites

7 hours ago, BruceMcF said:

[1] Yes, the psuedo-video-RAM (though it is really truly dual ported) is very similar to the 80 column display on the C128 with indirect access to the Video Memory which is distinct from the main computer memory.

[2] And similar to some of the Atari 8bits and to the C16 in having (most of) the audio functions and video functions consolidated into a single chip.

[3] But VERA is far from the complex of coprocessor and blitter in the Amiga. Despite repeated calls from various corners in the last several years, the design team has stuck to their guns about VERA being a Video Chip rather than a Graphical Processing Unit.

[1] Source? Is this referring to MMIO "ports"?

[2] As the kid who would be the first (and ultimately only) one on the block whose parents got him a Plus/4 instead of the C64 he wanted, I remember that the defining characteristic of those chips was that they sucked. 120 colors couldn't make up for the fact that it had no sprites and sad audio consisting of two channels of square waves. (Or one channel could be noise instead... yay?)

[3] The copper and blitter lived on Agnus, the DMA controller, not Denise, the video chip. Much of what the blitter was needed for (compositing rectangular graphics with transparency on top of a playfield) can be accomplished less expensively on CX16 using VERA's sprites and those won't steal CPU cycles while doing it. In no case could the Amigas of the 80s display 8 bit plane graphics or sprites that were more than 16 pixels wide (and I think limited to 4 colors, or 16 colors when grouped together). Hence why I say VERA is "competitive" with.

(Side note: since the "world's first" (Nvidia's phrasing) "graphical processing unit" (GeForce 256, 1999), that term has always referred to a chip that contains a pixel pipeline capable of doing, at a minimum, texture and lighting. Hardware bit blitters were common in mid and high end SVGA cards (e.g. ET4000/W32) from the early 90s and didn't use that moniker. I don't think anyone has been seriously asking for a texture or shader engine in VERA.)

  • Like 1
Link to comment
Share on other sites

7 hours ago, Wavicle said:

[1] Source? Is this referring to MMIO "ports"?

[2] As the kid who would be the first (and ultimately only) one on the block whose parents got him a Plus/4 instead of the C64 he wanted, I remember that the defining characteristic of those chips was that they sucked. 120 colors couldn't make up for the fact that it had no sprites and sad audio consisting of two channels of square waves. (Or one channel could be noise instead... yay?)

[3] The copper and blitter lived on Agnus, the DMA controller, not Denise, the video chip. Much of what the blitter was needed for (compositing rectangular graphics with transparency on top of a playfield) can be accomplished less expensively on CX16 using VERA's sprites and those won't steal CPU cycles while doing it. In no case could the Amigas of the 80s display 8 bit plane graphics or sprites that were more than 16 pixels wide (and I think limited to 4 colors, or 16 colors when grouped together). Hence why I say VERA is "competitive" with.

(Side note: since the "world's first" (Nvidia's phrasing) "graphical processing unit" (GeForce 256, 1999), that term has always referred to a chip that contains a pixel pipeline capable of doing, at a minimum, texture and lighting. Hardware bit blitters were common in mid and high end SVGA cards (e.g. ET4000/W32) from the early 90s and didn't use that moniker. I don't think anyone has been seriously asking for a texture or shader engine in VERA.)

 

7 hours ago, picosecond said:

Yup.  That matches my guess exactly.  I did not see anyone from the design team confirm this but I can't think of any other parts that match.

The 16Kx16 SPRAM has just one address port so I would call it single-port and leave it at that.  But that is picking nits.  I think we both agree that it is definitely not "truly dual-ported".  Hence the request for citations...

The only source is multiple mentions by a member of the design team, back in the morass of the FB site. Perhaps that was a holdover from the first generation design with the Gameduino, which used 32K(x9bits) of Block RAM rather than SPRAM, where Block RAM has a read port and a write port and can be synthesized to be fully dual ported if the data paths are half or less than the width of each of those ports (at least, I've seen that mentioned regarding the Xilinx and Altera families, I don't know about Lattice but IIRC the Gameduino was on an obsolete Xilinx FPGA).

If it's SPRAM, then I wouldn't imagine that synthesis is possible.

[2] The target is to be an 8bit "dream machine" so sprite and tile graphics with lots of sprites and 80 column text mode is a core design feature. Even if TED chips were available, they wouldn't have ticked that box. They just make the point that having sound and video on a single chip is something that was done in various 8bit systems. Having a VGA resolution rowbuffer display with sprites and tiles may make it "better" in the sense of designing sprite based games than something like the IBM CGA/VGA display cards, but those were designed for business applications and games were designed to work with them as best they could. I think the overview of the likely performance of the video system made it clear it has a serious claim to qualify for an 8bit "Dream Machine", but it falls well short of best in class against the 16/32bit systems.

So, tl;dr: if "like a 16/32bit system" means "like the best of the graphical oriented 16/32bit systems", I don't buy it, and if "like a 16/32bit" system means "overlapping the low end 16/32bit systems although focusing on the features relied on most heavily in 8bit systems", that's just a different way of phrasing "8bit Dream Machine".

[3] The point is that the processing is offloaded from the CPU, which is starting the technological evolution toward the GPU. Where in that evolution the term "GPU" is conventionally applied is a pure semantic quibble ... the best of the 16/32 video systems had already started down the path toward framebuffer oriented dedicated graphical processing and the CX16 video system steadfastly insists on relying on the 8bit CPU doing all of the processing.

 

Edited by BruceMcF
Link to comment
Share on other sites

55 minutes ago, BruceMcF said:

 

The only source is multiple mentions by a member of the design team, back in the morass of the FB site. Perhaps that was a holdover from the first generation design with the Gameduino, which used 32K(x9bits) of Block RAM rather than SPRAM, where Block RAM has a read port and a write port and can be synthesized to be fully dual ported if the data paths are half or less than the width of each of those ports (at least, in the Xilinx and Altera families, I don't know about Lattice but IIRC the Gameduino was on an obsolete Xilinx FPGA).

If it's SPRAM, then it would indeed have a single R/W port. Whether that can be synthesized as two read ports given a small enough data path, I wouldn't know, but I doubt it, and I presume that for bus register writes it couldn't share control in any event. I'm not going to tear out my hair waiting to find out whether it shares the port by waiting the read for the rowbuffer generator on a bus access (or bus write), or by fetching 16bits in alternate cycles and working on a byte per cycle.

[2] The target is to be an 8bit "dream machine" so sprite and tile graphics with lots of sprites and 80 column text mode is a core design feature. Even if TED chips were available, they wouldn't have ticked that box. They just make the point that having sound and video on a single chip is something that was done in various 8bit systems. Having a VGA resolution rowbuffer display with sprites and tiles may make it "better" in the sense of designing sprite based games than something like the IBM CGA/VGA display cards, but those was designed for business applications and games were designed to work with them as best they could. I think the overview of the likely performance of the video system made it clear it has a serious claim to qualify for an 8bit "Dream Machine", but it falls well short of best in class against the 16/32bit systems.

So, tl;dr: if "like a 16/32bit system" means "like the best of the graphical oriented 16/32bit systems", I don't buy it, and if "like a 16/32bit" system means "overlapping the low end 16/32bit systems although focusing on the features relied on most heavily in 8bit systems", that's just a different way of phrasing "8bit Dream Machine".

[3] The point is that the processing is offloaded from the CPU, which is starting the technological evolution toward the GPU. Where in that evolution the term "GPU" is conventionally applied is a pure semantic quibble ... the best of the 16/32 video systems had already started down the path toward framebuffer oriented dedicated graphical processing and the CX16 video system steadfastly insists on relying on the 8bit CPU doing all of the processing.

 

The SPRAM is a hard IP block fixed at 256Kx16 bits. I cannot say how VERA is implemented but based on my experience working with architectural designs of display silicon, that isn't how I would implement buffering lines for scanout.

When multiple features were combined into a single ASIC, it came at a cost; often a high cost. TED gave up the most important features that made VIC-II good at games; it was intended to be a business application video chip also. I'm not arguing CX16 would exceed best in class 16/32 bit systems in every metric; I think it would in some important metrics, but that is a useless argument to make without nailing down what systems count as "best of the graphical oriented 16/32bit systems". I think the Amiga 500 would count but then I'm also left wondering what the low end 16/32bit systems whose functionality is being overlapped are.

  • Like 1
Link to comment
Share on other sites

14 hours ago, Wavicle said:

The SPRAM is a hard IP block fixed at 256Kx16 bits. I cannot say how VERA is implemented but based on my experience working with architectural designs of display silicon, that isn't how I would implement buffering lines for scanout.

The Gameduino used BlockRAM for both the linebuffers and for the working RAM, when it is argued it is probably an FPGA with 1024bit SPRAM, I'd assumed that the rowbuffers are still BlockRAM and the SPRAM is providing much (or all) of the "Video" RAM space that is accessed via the data ports from the bus, which is why I as guessing that Vera would only be reading from the SPRAM when writing into the current target rowbuffer.

14 hours ago, Wavicle said:

... but then I'm also left wondering what the low end 16/32bit systems whose functionality is being overlapped are.

Whichever ones you had in mind when you argued that Vera was overlapping into the effective functionality of the video systems in 16/32bit systems.

Link to comment
Share on other sites

1 hour ago, BruceMcF said:

Whichever ones you had in mind when you argued that Vera was overlapping into the effective functionality of the video systems in 16/32bit systems.

By that definition Amiga, Atari ST, and Macintosh all have functionality that overlaps with and by some measures is exceeded by VERA. They are all therefore low end and my original statement:

On 3/15/2021 at 12:17 PM, Wavicle said:

spec wise was competitive with 16/32 bit computers of the day.

Would seems to hold. Not sure what this conversation is about anymore.

Link to comment
Share on other sites

6 minutes ago, Wavicle said:

By that definition Amiga, Atari ST, and Macintosh all have functionality that overlaps with and by some measures is exceeded by VERA. They are all therefore low end and my original statement:

Would seems to hold. Not sure what this conversation is about anymore.

Whether VERA ... or indeed any Video processor that meets the target for an "8bit dream machine" ... somehow stops the system "feeling like" an 8bit system because video systems in 8bit and 16bit systems were not big discrete steps but a continuum of different capabilities, so "an upgraded 8bit style video system" will necessarily overlap with some of the specs and features of 16bit systems back in the day: "... it was losing its '8 bit feel' and spec wise was competitive with 16/32 bit computers of the day."

The only clear divide I can see in that continuum are the systems that started the process of offloading video processing chores from the CPU, and Vera is on the 8bit side of that divide.

Link to comment
Share on other sites

2 hours ago, BruceMcF said:

Whether VERA ... or indeed any Video processor that meets the target for an "8bit dream machine" ... somehow stops the system "feeling like" an 8bit system because video systems in 8bit and 16bit systems were not big discrete steps but a continuum of different capabilities, so "an upgraded 8bit style video system" will necessarily overlap with some of the specs and features of 16bit systems back in the day: "... it was losing its '8 bit feel' and spec wise was competitive with 16/32 bit computers of the day."

The only clear divide I can see in that continuum are the systems that started the process of offloading video processing chores from the CPU, and Vera is on the 8bit side of that divide.

Well, VERA has sprites, which are definitely a chore but they're also hardly unusual for an 8-bit machine. When I think of video processing chores that really start to separate the 8-bit era, I mostly think of hardware-based affine transformations and the first steps into 3D arithmetic. Hardware blitting into bitmaps probably also counts, but I was a lot less aware of that particular feature while growing up. So as far as I'm concerned, the VERA is still on the 8-bit side of that delineation.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use