Change of product direction, good and bad news!

[BruceMcF]

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

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

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.

[Geehaf]

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.

Thanks for clarification and further details. Appreciate it.

[paulscottrobson]

 

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.

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.

[BruceMcF]

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.

In the X8? Yeah, especially since the buffer is 4KB and the reload alert is at 1KB remaining, there's not a lot a room for a lot of actual samples.

If it's a repeating waveform, loaded two copies of 1KB and then reloaded with 1KB when there's 1KB left, that's still 1KB storage per instrument per frequency. You wouldn't have many notes available if it was something like a bass guitar or marimba (thinking of instruments with more complex waveforms). It seems like it might be workable for Tri-toms or snare drum, where you only need to store 1 or 3 waveforms.

[Wavicle]

 

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.



 



 

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.

[BruceMcF]

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.

Yes, I was assuming that the FPGA reset CS_rom and the X8 CS_rom are the same pin.

If there is an unused I/O pin and the resources, %01 decodes to CS_rom, %10 decodes to CS_SD, and %11 decodes to CS_EXT, which is the unused pin, and CS_EXT goes to the block pin header.

If there is not an unused I/O pin and/or the resources it needs, the two bits go out to the pins as simple outputs, CS_rom is connected directly to the serial rom, and also as d0 to an external 2>4 decoder, the current CS_SD pin provides d1 for the decoder, the pulldown on %10 is the CS_SD line, the pulldown on %11 is the CS_EXT line.

In the second case, neither other SPI select line is low when CS_rom is low, so no attached device contends for MISO when the serial rom is driving it. That's why it uses a decoder rather than simply NAND of the two lines to generate CS_EXT.

Independently of that, a setting to select I2C for the two pins providing the UART, if feasible. If not, a setting to use the two pins providing UART as two general purpose outputs.

[KnightFire]

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 X16e?

- -

The Opinionated Stay-at-home Dad

 

[Calculon]

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



 

The keyboard does have PETSCII on the keys. As for why not USB, my guess is it would increase the cost of the keyboard to support both signaling types. 

[Shauny]

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.

[Scott Robison]

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.

I appreciate why you feel that way, but I personally trust David. It's not like a kickstarter guarantees results either as I've observed multiple times. https://www.slashgear.com/superscreen-kickstarter-fails-takes-2-5m-down-the-drain-11549706/

Now, if David were some guy who's never released a product, that would be another issue. Yes, hardware is different than software, but just having a certain level of influence and prestige in the community is a big deal for something like this, even if it isn't a guarantee.

But again, I understand why you feel that way. I've started kicking into David's patreon to try to show support (your mileage may vary). I would donate some amount of money to help push the project forward (the exact amount would impact my decision making process, of course). And I'd pre-order on a kickstarter today (again, depending on the amount). $10 is a no brainer to me. $100 is doable depending on the details of the donation / kickstarter plan. $1000 isn't in my budget. There are a wide range of degrees of "hell yeah" and "hell no" between the extremes.

Everyone has to decide what they want and what they can afford. My only real "criticism" is the "sinister" label. I think the money I lost on superscreen was done in a sinister way, and so far David has given me no reason to think his motives are sinister.