Commander X16

52 minutes ago, Geehaf said:

I wonder if it's worth considering the x16 with a full FPGA implementation like the X8? Not sure what it would mean for the YM chip but perhaps there is already FPGA for that too. It would allow for complete "firmware" upgrades in the future and could simplify the overall design. Not sure if it would help reduce manufacturing costs. Yes, my idea is a little radical I know, especially with all the work and time spent so far on the hybrid FPGA / non FPGA chips approach. ?

10 minutes ago, BruceMcF said:

It's not all that radical, since it's part the original plan. That is the "phase 3", also known as "X16e".



The market for the X16p/X16c exists because of people who WANT the "authentic" ASIC parts. So the X16e is not "instead of" the X16p or X16c, but a lower cost alternative to those boards.



Putting all of it except for a RAM chip inside an FPGA was the plan for the lowest cost member of the family. To do that, it has to be a larger FPGA than the one that is used for Vera in the X16p.



The point of the X8 is that it's not perfectly compatible with the CX16, but it fits in the same FPGA that Vera uses and doesn't need any external RAM, so it would be about half the price of the X16e. So if the X16e costs $90 for the board, the X8 would cost $45 for the board.

1 hour ago, BruceMcF said:

Putting all of it except for a RAM chip inside an FPGA was the plan for the lowest cost member of the family. To do that, it has to be a larger FPGA than the one that is used for Vera in the X16p. AFAIU from the Foenix256 project, an FPGA core for the YM2151 exists, so it seems like it wouldn't be a serious issue including it.

34 minutes ago, paulscottrobson said:

I was wondering about the PCM audio. With 64k of VRAM and a slowest speed of 12khz, that's quite large samples outside very short SFX.

3 hours ago, BruceMcF said:

So a reset system can be simply some form of switch that connects the FPGA CS_rom to a ~10kohm external pull up.



So there is a simpler system, which is to just generate ONE external select from the undecoded CS_rom and CS_SD. The CS_rom is just an informative input to the decoder, the CS_rom from the FPGA is connected straight to the serial ROM CS. The CS_SD and CS_EXT are %01 and %11 respectively. %00 and %10 then both actually select CS_rom, so there is no SPI bus contention despite CS_rom and CS_SD no longer being decoded.



So I will just look at the options if there is no extra pin available ... if there is, the options proliferate.



1. If there is no extra pin, I2C only approach:

• 
  CS_rom and CS_SD are brought out decoded
  


• 
  There is an internal setting which switches the two UART pins to I2C
  

2. If there is no extra pin, UART centric approach:

• 
  CS_rom and CS_SD are brought out undecoded and decoded externally, to CS_rom, CS_SD and CS_EXT, the CS_rom line is also connected through the FPGA hard reset switch to a reset pull-up resister and AND'd with the decoded CS_rom line.
  


• 
  %11 is brought out as CS_EXT.
  


• 
  The UART is left alone, to provide a built in serial port connection.
  

3. If there is no extra pin, I2C centric approach:

• 
  CS_rom and CS_SD are brought out undecoded and decoded externally, to CS_rom, CS_SD and CS_EXT, the CS_rom line is also connected through the FPGA hard reset switch to a reset pull-up resister and AND'd with the decoded CS_rom line.
  


• 
  %11 is brought out as CS_EXT.
  


• 
  There is an internal setting which switches the two UART pins to I2C
  

If there is no extra pin, and if there are the logic resources to support the I2C, my preference would be the third. SPI is convenient to breadboard. If there was a desire to have multiple SPI parts on a single hat, an I2C 8bit GPIO expander could generate the extra selects. And of course, if there is a desire to have multiple I2C parts on a single hat, they just need to have unique I2C addresses. It also means less of an issue if the I2C cannot support HS mode, since the External SPI bus supports 12.5Mbps.



Now, if the "extra pin" is really there, the simplest external expansion is to put it out low when the two CS bits are high. That avoids any extra build cost of the external circuitry, and provides a "normal operation" "all deselected" state at %00.



 



 

8 hours ago, Wavicle said:

 



I'm not quite sure that I follow. I looked at the pin-to-port mapping file tonight; pin 16 (SPI_SS) is mapped to the flash_ssel_n port so the same wire used to select the flash component on the SPI bus during configuration is also used for reading flash ROM (presumably where KERNAL lives and is loaded by the bootloader). Whatever external circuit you have in mind must keep the expected behavior at that time. Also, it looks like pin 34 (IOT_44B) is mapped to the unconnected exp3 port. According to the design as it stood at the end of last year, there was one unused IO pin.

1 hour ago, KnightFire said:

I'm all in to tossing $5us in the donation hat.  Don't forget that Kickstarter also sticks their fingers in the pie.  So I'd prefer a direct donation method, and avoid having to buy a t-shirt/cup/pen/pin/cap - but would consider a Commander X16 case badge purchase.



The keyboard, does it have PETSCII on the keycaps?  It's probably too late to inquire, but why wasn't a USB model chosen and then a USB to PS/2 adapter used to connect with the X16?  I'd buy such a PETSCII keyboard even if I just had it to use with Vice on an RPi.



I'm biting my tongue on the X8, if it was tweaked wouldn't it just be the Phase-3 X16?



- -



The Opinionated Stay-at-home Dad



 

1 hour ago, Shauny said:

A kickstarter would be a legitimate way of moving the project forward, the aims/goals and company structure are out in the open  I wouldn't be in favor of direct donations, I think it would be very sinister if they go down that route.