Commander X16

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.

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.

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...

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.

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...

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.



 

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.

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.

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.

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

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

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.

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.