Jump to content

Change of product direction, good and bad news!


What should we do?  

392 members have voted

  1. 1. Should we release the Commander X8?

    • Yes, it should replace Phase-3. It's good enough.
    • Yes, but you should still offer a Phase-3 Commander X16 eventually too.
    • No, don't release the X8, stick with the original plan.
  2. 2. Should we still make a Phase-2 product?

    • Yes, Phase-2 is what I want
    • No, skip and go straight to Phase-3
  3. 3. For the X16 Phase-1, do you prefer a kit or a somewhat more expensive pre-assembled board?



Recommended Posts

8 minutes ago, BruceMcF said:

I said "I hope someone" because there's no way on this green earth that it would be me. If xForth development goes well in my time off this fall after getting back to the US, I might seriously consider putting in signed fixed point. Though come to think of it, maybe 24.8 rather than 16.16.

Chuck Moore would approve. I think he does all his floating point maths in fixed point integer.

  • Like 1
Link to comment
Share on other sites

1 hour ago, paulscottrobson said:

Chuck Moore would approve. I think he does all his floating point maths in fixed point integer.

He also did his "matrix of forth processors" chip with 20bit cells, saying it made doubles largely uneccesary, and fixed point on a power of two on a byte boundary makes it especielly parsimonious, which was his favorite virtue.

Link to comment
Share on other sites

1 hour ago, paulscottrobson said:

I haven't seen it. I would be interested to know what the pins are used for. USB in, Audio out (D/A ladder ?), Video out of some sort , SD Card interface.

I think making it cheap opens up a whole new vista, and adding your serial RAM chip opens it up even more.  If 8 bit Dave does release the X8 I hope they spend a little bit of time tweaking the design. An option or a slightly larger port and you could use VRAM as an extended memory like A000-BFFF is now if you weren't using all of it.

But then I never bought the authenticity argument. I still don't really, as a learning experience. I don't buy the whole thing educationally, not that there mightn't be a use for it, but the old Microsoft BASIC is just unusable for that. I was teaching programming nearly 40 years ago and it was antiquated then.

I don't know what all of the original Vera pins are, but all of them except the system bus interface would still be used.

SPI is a serial bus, with master in / slave out, master out / slave in, and serial clock going to all devices, but each device has its own select line and it only reacts to the serial clock if its select is pulled low.

It is already used for the SD card, and for the serial flashROM. So two selects already come out. They can be brought without decoding and use an external decoder. So %11 selects a serial shift register. Write a byte to it with one bit low, you have set the external select. %00 then makes that select active. %10 and %01 select the SD card and serial ROM like before.

A simple block header and you can plug an expansion card on top, and basically any serial interfaced chip that can be made to work with SPI can be put on that card. At the quantities they'd be making them, a dual 2>4 decoder, a serial shift register, a pin block header and an eight resister block would each be less than $0.50. So for less than $2 added to the bill of materials ... maybe $+5 to the final price ... $40-$55 instead of $35-$50 ... suddenly plugging an expansion card on top is possible.

As far as data storage, the X8 "videoram" access is already pretty handy ... instead of (W),Y and increment W+1 on page crossing, $0400,Y and increment the page address register on page crossing. At that price, I'm OK with keeping the code inside 62K - size of the Kernel.

As far as Basic v2 and education, the exact amount of Basic v2 used should be the minimum required to set the system up to autostart the real system. It's like BAT with Dos computers ... nobody was "taught in" BAT, except the poor unfortunates who had to write the batch files for users at a company.

 

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

16 hours ago, BruceMcF said:

I don't know what all of the original Vera pins are, but all of them except the system bus interface would still be used.

SPI is a serial bus, with master in / slave out, master out / slave in, and serial clock going to all devices, but each device has its own select line and it only reacts to the serial clock if its select is pulled low.

It is already used for the SD card, and for the serial flashROM. So two selects already come out. They can be brought without decoding and use an external decoder. So %11 selects a serial shift register. Write a byte to it with one bit low, you have set the external select. %00 then makes that select active. %10 and %01 select the SD card and serial ROM like before.

A simple block header and you can plug an expansion card on top, and basically any serial interfaced chip that can be made to work with SPI can be put on that card. At the quantities they'd be making them, a dual 2>4 decoder, a serial shift register, a pin block header and an eight resister block would each be less than $0.50. So for less than $2 added to the bill of materials ... maybe $+5 to the final price ... $40-$55 instead of $35-$50 ... suddenly plugging an expansion card on top is possible.

As far as data storage, the X8 "videoram" access is already pretty handy ... instead of (W),Y and increment W+1 on page crossing, $0400,Y and increment the page address register on page crossing. At that price, I'm OK with keeping the code inside 62K - size of the Kernel.

As far as Basic v2 and education, the exact amount of Basic v2 used should be the minimum required to set the system up to autostart the real system. It's like BAT with Dos computers ... nobody was "taught in" BAT, except the poor unfortunates who had to write the batch files for users at a company.

 

The SPI flash is also used to configure the FPGA during reset, a sequence which is driven by either a hardware state machine or embedded microcontroller. If the CS pin for SPI flash goes low, that component must start responding or the FPGA will fail to configure itself properly. You could use an SR latch connected to the SD's CS (set) and reset (reset) to drive a multiplexer select, but that's adding even more external hardware.

I'd consider repurposing the the debug UART as I2C and plug a board with an I2C to UART chip into it when a serial connection is needed for debugging (e.g. MaxLinear XR20M1280IL32-F). If I2C isn't fast enough and enough extra pins are available, that IC can also be configured to communicate over SPI.

  • Like 1
Link to comment
Share on other sites

4 hours ago, Wavicle said:

The SPI flash is also used to configure the FPGA during reset, a sequence which is driven by either a hardware state machine or embedded microcontroller. If the CS pin for SPI flash goes low, that component must start responding or the FPGA will fail to configure itself properly. You could use an SR latch connected to the SD's CS (set) and reset (reset) to drive a multiplexer select, but that's adding even more external hardware.

A hardware state machine or embedded microcontroller inside the FPGA, or outside? Below, I am presuming inside, since if outside, it would go through an AND with the CS_flash line from the FPGA and there would be no change.

With the external decode, if the the FPGA puts out %01 on those pins, then the CS pin for the SPI flash WILL go low.

If the build is logic resource bound, that is more logic to have the FPGA reset state machine drive CS_flash low AND CS_SD high, independent of the simulated register state (or, during FPGA reconfiguration, existence!) versus the status quo where it only drives CS_flash low and that is nothing but an AND.

It's also less logic to have it not decode the state of CS_flash and CS_SD from the two setting bits in the register.

But the logic is likely not in the same place.

So ... well, if it builds, it builds, if it doesn't, back to the drawing board.

Then there is the mystery pin. If it is available (at least when none of the three are decoded) and CS2, CS1 and CS_flash=CS0 are taken out, then you can have three external selects with a single three to eight decoder: CS_SD=%001, CS_EXT1=%011, CS_EXT2=%101, CS_EXT3=111. With CS_flash directly to the flash and decoded %xx0 not connected, the CS_flash select effectively over-rides the SD and External selects, with no FPGA logic required. That's a single glue logic, pull up resisters and a pin block header. And the pin block header is smaller, to boot ... +3.3V, GND, SCLK, MOSI, MISO, CS_EXT1, CS_EXT2, CS_EXT3 ... 1x8 long/wide.

On the debug serial port, how usable is the debug serial port as-is, if operated from the X8?

If it's an I2C bus master, and the I2C bus being mishandled is why you need to debug, I don't know enough about I2C and what would likely be already built into the fpga dedicated serial module to know if that is problematic. If that works, heck, just add that to the block pin header and make it 10 long. I2C_1, I2C_2, +3.3V ... or for a more stable base for a hat, a four block pin header with I2C and power, and a six block pin header with just SPI, on parallel edges.

I don't know enough about I2C to know if this is what you were proposing or it it's feasible, but if for debugging purposes, the UART/I2C bridge is connecting with the X8 acting as an I2C peripheral, that's a really appealing change, since then doing the same thing without the UART means the X8 can be plugged straight into the X16 I2C bus.

 

 

Edited by BruceMcF
Link to comment
Share on other sites

On 8/26/2021 at 9:29 PM, BruceMcF said:

... a Kernel that implements the Commodore Kernel interface would likely need a development team, since by their nature their first impression would be that they were built on Commodore IP that Cloanto claims, and they would have to document that they are "clean code".

Mega65 has a repo started for this, and a defined process to ensure IP is not violated.  I was excited to see this, even though it’s not a priority. An open source KERNAL ... seems to have a lot of appeal.

 

https://github.com/MEGA65/open-roms

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

23 minutes ago, rje said:

Mega65 has a repo started for this, and a defined process to ensure IP is not violated.  I was excited to see this, even though it’s not a priority. An open source KERNAL ... seems to have a lot of appeal.

https://github.com/MEGA65/open-roms

Yes. However, implementing the Kernel interface would be even easier than producing a KERNAL rom image that is compatible with the bulk of C64 games and applications, so a project with the less ambitious goal could take what they have so far and likely complete it substantially faster.

  • Like 1
Link to comment
Share on other sites

12 hours ago, BruceMcF said:

A hardware state machine or embedded microcontroller inside the FPGA, or outside? Below, I am presuming inside, since if outside, it would go through an AND with the CS_flash line from the FPGA and there would be no change.

With the external decode, if the the FPGA puts out %01 on those pins, then the CS pin for the SPI flash WILL go low.

If the build is logic resource bound, that is more logic to have the FPGA reset state machine drive CS_flash low AND CS_SD high, independent of the simulated register state (or, during FPGA reconfiguration, existence!) versus the status quo where it only drives CS_flash low and that is nothing but an AND.

The SPI master configuration process is documented in the iCE40 Programming & Configuration technote (TN 2001) section 9.4. The SPI_SS pin is expected to have an ~10kohm external pull up which is how the SPI master configuration mode is selected. Once the mode select is detected, the FPGA will assert SPI_SS and begin downloading the design configuration from the SPI flash. It's an automatic process that begins after POR or regular CRESET_B rising edge transition and cannot be modified. Whatever mechanism you plan to use for multiple SPI chip select lines, that pin must still function as expected during that critical time period.

12 hours ago, BruceMcF said:

On the debug serial port, how usable is the debug serial port as-is, if operated from the X8?

If it's an I2C bus master, and the I2C bus being mishandled is why you need to debug, I don't know enough about I2C and what would likely be already built into the fpga dedicated serial module to know if that is problematic. If that works, heck, just add that to the block pin header and make it 10 long. I2C_1, I2C_2, +3.3V ... or for a more stable base for a hat, a four block pin header with I2C and power, and a six block pin header with just SPI, on parallel edges.

I don't know enough about I2C to know if this is what you were proposing or it it's feasible, but if for debugging purposes, the UART/I2C bridge is connecting with the X8 acting as an I2C peripheral, that's a really appealing change, since then doing the same thing without the UART means the X8 can be plugged straight into the X16 I2C bus.

Again, keeping in mind I'm basing this on Verilog code posted 8 months ago and I'm not an authoritative source --

The debug serial port as implemented is driven from a UART design that is in Verilog and not a hard IP block in the FPGA. I'm not sure that making the X8 an I2C slave makes sense, but in any case the component I mentioned does not operate as an I2C master. I'm not aware of any such component that does.

Link to comment
Share on other sites

9 hours ago, Wavicle said:

The SPI master configuration process is documented in the iCE40 Programming & Configuration technote (TN 2001) section 9.4. The SPI_SS pin is expected to have an ~10kohm external pull up which is how the SPI master configuration mode is selected. Once the mode select is detected, the FPGA will assert SPI_SS and begin downloading the design configuration from the SPI flash. It's an automatic process that begins after POR or regular CRESET_B rising edge transition and cannot be modified. Whatever mechanism you plan to use for multiple SPI chip select lines, that pin must still function as expected during that critical time period.

Again, keeping in mind I'm basing this on Verilog code posted 8 months ago and I'm not an authoritative source --

The debug serial port as implemented is driven from a UART design that is in Verilog and not a hard IP block in the FPGA. I'm not sure that making the X8 an I2C slave makes sense, but in any case the component I mentioned does not operate as an I2C master. I'm not aware of any such component that does.

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.

 

 

Edited by BruceMcF
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Edited by BruceMcF
  • Like 3
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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.

Edited by BruceMcF
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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.

Edited by BruceMcF
Link to comment
Share on other sites

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

 

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

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. 

Edited by Calculon
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

David,

I have been quietly following this project for a while now, and I'd like to offer a couple of observations which you will not like, and a couple of solutions which I suspect you will also not like.

1. This project has turned into a camel (horse designed by a committee). Too many people pulling in different directions.

2. It's getting held up by individuals stuck on issues. No offence to these people who are giving up huge amounts of time and effort whenever they can, but it is happening.

solutions:

1. This is your vision, your baby. Take back control of the project. Decide what it is you want, define it. Publish a specification.

2. Open source the entire project. You have a massive group of very talented people here, Hardware and software designers. Yes, I know you have licencing issues such as BASIC. Dump it! Its only basic interpreter and a clean version can be written from scratch with the skills here. But unless its open source it won't happen. Hardware and software bugs will also vanish quickly will so many eyes on it. With open PCB artwork available folks can build their own computers, sourcing components themselves. With so much real hardware available firmware development will accelerate.

See, I knew you wouldn't like it. (:-)

I do fear though, that if things continue as now, the whole project could falter.

  • Like 1
Link to comment
Share on other sites

6 hours ago, KnightFire said:

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 would be happy enough if I could buy just the keycaps.  I have a keyboard I can use them with.  Decent MX switch type ten keyless keyboards can be had for cheap.  

  • Like 1
Link to comment
Share on other sites

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

From what they've said, the standard keyboard will have PETSCII on the keycaps, and will be a dual mode keyboard, so it will come with one of those passive adapters to plug into USB as well.

The deluxe keyboard, already available, is the same ... it has to ship with a slightly older version of the firmware for that keyboard, because the newest version no longer supports dual mode functioning. (Some people got the impression those are general purpose PS/2 to USB adapters, rather than the keyboard being dual-mode.)

The PS/2 is not because that's easier to find for the keyboard, but because PS/2 is easier to support with 8bit systems ... its predecessor, the AT keyboard was originally, after all, read by an 8bit microcontroller inside the IBM-AT.

Edited by BruceMcF
  • Confused 1
Link to comment
Share on other sites

I'm honestly willing to pay the money for something pre-assembled. As for waiting, I'd only hold out for Phase 3 if there's a minor benifit to that like a slightly faster CPU. Otherwise I'm getting this machine to see what the community creates on it. Given the special hardware tricks aboard, that should prove interesting to the extreme!

Link to comment
Share on other sites

5 hours ago, Woofy said:

David,

I have been quietly following this project for a while now, and I'd like to offer a couple of observations which you will not like, and a couple of solutions which I suspect you will also not like.

1. This project has turned into a camel (horse designed by a committee). Too many people pulling in different directions.

2. It's getting held up by individuals stuck on issues. No offence to these people who are giving up huge amounts of time and effort whenever they can, but it is happening.

solutions:

1. This is your vision, your baby. Take back control of the project. Decide what it is you want, define it. Publish a specification.

2. Open source the entire project. You have a massive group of very talented people here, Hardware and software designers. Yes, I know you have licencing issues such as BASIC. Dump it! Its only basic interpreter and a clean version can be written from scratch with the skills here. But unless its open source it won't happen. Hardware and software bugs will also vanish quickly will so many eyes on it. With open PCB artwork available folks can build their own computers, sourcing components themselves. With so much real hardware available firmware development will accelerate.

See, I knew you wouldn't like it. (:-)

I do fear though, that if things continue as now, the whole project could falter.

I'm honestly obliged to agree that what exists should be tightened up. The goal here is an 8-bit machine made from all still-produced parts. Between that, and getting past the licensing, this becomes a community machine if the code exists for people to work from.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Please review our Terms of Use