Commander X16

TomXP411 wrote: ↑Tue Apr 11, 2023 7:51 am Ewww. No. SPi consumes too much CPU time to be useful.

Given the timed FIFO queue of that chip, bit banged SPI seems like it would be workable ... indeed, that's kind of why they provide the timed FIFO queue, so that the timing of writing to the chip is not closely tied to the timing of the execution of the actual register changes ... but hardware assisted would be better.

It might be possible to fake SPI using the bit shifters and the handshake clock, but that just increases the complexity level for programmers.

The complexity for programmers seems like it would be the same either way, load device number, JSR SPI_SELECT, load output byte, JSR SPI_OUT, JSR SPI_IN and store input byte, or load output byte, JSR SPI_BYTE, store the return byte, and then when done talking to the SPI device, JSR SPI_DESELECT.

At this point, I'm thinking an RP2040 or FPGA is a better choice.

When an RP2040 is used to emulate a chip is when I'm checking out, but I've said previously, my first preference is to include a YM2151 socket and put an FPGA simulator board in it if real YM2151's can't be found. That way if a Developer Board owner gets their hands on a YM2151 and corresponding DAC, they can just pop out the FPGA simulator board, pop the YM2151 in, and pick up where they left off.

TomXP411 wrote: ↑Tue Apr 11, 2023 11:10 pm

GTR3QQ wrote: ↑Tue Apr 11, 2023 5:32 pm

TomXP411 wrote: ↑Tue Apr 11, 2023 7:51 am Ewww. No. SPi consumes too much CPU time to be useful.

It might be possible to fake SPI using the bit shifters and the handshake clock, but that just increases the complexity level for programmers. At this point, I'm thinking an RP2040 or FPGA is a better choice.

Hold on? there was a previous attempt to get the chip from Shenzhen? how did it go?

I don't think anyone here has attempted to get it from Shenzen. We've all looked at parts suppliers, like Mouser and such. Those chips are not available through any of those distributers.

I left message on YAMAHA LSI website, asking whether the chip EOLed or not and their recommended dealer. Hope they will contact.

BruceRMcF wrote: ↑Tue Apr 11, 2023 11:15 pm

TomXP411 wrote: ↑Tue Apr 11, 2023 7:51 am Ewww. No. SPi consumes too much CPU time to be useful.

Given the timed FIFO queue of that chip, bit banged SPI seems like it would be workable ... indeed, that's kind of why they provide the timed FIFO queue, so that the timing of writing to the chip is not closely tied to the timing of the execution of the actual register changes ... but hardware assisted would be better

I'm saying that video games need every clock cycle they can get, and SPI is just not efficient.

It takes 2 instructions to write a byte on the CPU bus, or It takes at least 3 instructions to write a single bit via SPI... but probably more, since the unused lines on VIA #1 can't be written to in the most efficient manner possible. In the end, it takes roughly 20 instructions to write a single byte to SPI, compared to 2 instructions to move a byte using LDA/STA.

20 instructions at 4-5 cycles per instruction, updating 4-7 voices at a time... that's a lot of time spent servicing the audio queue - IMO too much time when the system also has to handle all the visuals and physics involved in a video game.

TomXP411 wrote: ↑Wed Apr 12, 2023 3:33 am

BruceRMcF wrote: ↑Tue Apr 11, 2023 11:15 pm

TomXP411 wrote: ↑Tue Apr 11, 2023 7:51 am Ewww. No. SPi consumes too much CPU time to be useful.

Given the timed FIFO queue of that chip, bit banged SPI seems like it would be workable ... indeed, that's kind of why they provide the timed FIFO queue, so that the timing of writing to the chip is not closely tied to the timing of the execution of the actual register changes ... but hardware assisted would be better

I'm saying that video games need every clock cycle they can get, and SPI is just not efficient.

It takes 2 instructions to write a byte on the CPU bus, or It takes at least 3 instructions to write a single bit via SPI... but probably more, since the unused lines on VIA #1 can't be written to in the most efficient manner possible. In the end, it takes roughly 20 instructions to write a single byte to SPI, compared to 2 instructions to move a byte using LDA/STA.

20 instructions at 4-5 cycles per instruction, updating 4-7 voices at a time... that's a lot of time spent servicing the audio queue - IMO too much time when the system also has to handle all the visuals and physics involved in a video game.

That would be the comparison if it was the same amount of information that needed to be sent during game play. IIUC, there's a lot more that can be set up to have the YMF825 run a process without intervention than with a OPM generation chip.

But that's also one of the reasons I am not enthusiastic about the YMF825 as a replacement for the OPM ... the OPM is not nearly as much an "Audio Generation Processor" as the YMF825 is. In my mind, setting up an ADSR envelope which is triggered at the specific time that the CPU writes a register is one thing ... setting up a script of note or sound effects to play in sequence when a trigger gets to the front of the FIFO queue and then it's time arrives is something else.

With four operators and eight waveforms, it seems like it should be able to generate whatever sound an OPM can generate or any sound an OPL2 can generate ... but it wouldn't really be the 8bit style of doing it.

BruceRMcF wrote: ↑Tue Apr 11, 2023 11:15 pm ...my first preference is to include a YM2151 socket and put an FPGA simulator board in it if real YM2151's can't be found. That way if a Developer Board owner gets their hands on a YM2151 and corresponding DAC, they can just pop out the FPGA simulator board, pop the YM2151 in, and pick up where they left off.

I agree. The devs have had the YM2151 in mind all along, the board is designed for it, the software is written. It is much better to emulate it on a daughter board until a source can be found, if indeed it can be found. No changes to hardware or software would be required. Much better than trying to change design specs at this stage.

No. Though I'm sure it's a great chip.

1) the design will never stabilise to production if people keep adding features and changing stuff. Given the existence of 100PCBs one should really be in feature freeze unless absolutely necessary

2) one should not really be adding specialist chips that aren't either reproducible reasonably easily (6502/6522) and are not very common or have equivalents. So if the FPGA in Vera stops being available it should be possible to port it to a different one. If new 6502/6522's cease to be available there already exist several FPGA core equivalents.

3) There is usually an issue of comparative power. If you have all bells and whistles chips a 65C02 at 8Mhz is going to struggle to service them all.

I just got 3 quotes from the gal, they all seem fine, lead time usually around 1-2 weeks, mostly shipping time.
22cents avg. lowest one calling for 20.9 cents.
Currently have 2k in stock ready to go.
Shipping costs 45USD, can request a lower priced freight company.
And he's getting more quotes.
But I also got an email from Kenji Iwamoto at Yamaha electronic devices division, sadly it's confidential, so I'll interpret it.
The chip EOLed due to reasons, and no longer promoted to any one.

paulscottrobson wrote: ↑Wed Apr 12, 2023 8:46 am No. Though I'm sure it's a great chip.

1) the design will never stabilise to production if people keep adding features and changing stuff. Given the existence of 100PCBs one should really be in feature freeze unless absolutely necessary

2) one should not really be adding specialist chips that aren't either reproducible reasonably easily (6502/6522) and are not very common or have equivalents. So if the FPGA in Vera stops being available it should be possible to port it to a different one. If new 6502/6522's cease to be available there already exist several FPGA core equivalents.

3) There is usually an issue of comparative power. If you have all bells and whistles chips a 65C02 at 8Mhz is going to struggle to service them all.

I don't think it's adding any feature that is none existence, it's just a better duel OPL3 card that 8 bit guy showed.
This chip is mostly used for opl3 compatibility, no worries if supplies dried up just use opl3 of fpga opl3.

Ed Minchau wrote: ↑Wed Apr 12, 2023 5:45 am

BruceRMcF wrote: ↑Tue Apr 11, 2023 11:15 pm ...my first preference is to include a YM2151 socket and put an FPGA simulator board in it if real YM2151's can't be found. That way if a Developer Board owner gets their hands on a YM2151 and corresponding DAC, they can just pop out the FPGA simulator board, pop the YM2151 in, and pick up where they left off.

I agree. The devs have had the YM2151 in mind all along, the board is designed for it, the software is written. It is much better to emulate it on a daughter board until a source can be found, if indeed it can be found. No changes to hardware or software would be required. Much better than trying to change design specs at this stage.

Of course, if chips can be found. This should be 'Last resort v2', just a better opl3 after all.

GTR3QQ wrote: ↑Wed Apr 12, 2023 9:07 am I don't think it's adding any feature that is none existence, it's just a better duel OPL3 card that 8 bit guy showed.

This chip is mostly used for opl3 compatibility, no worries if supplies dried up just use opl3 of fpga opl3.

It's not "just a better", because of the different way that it is designed to be used. The most effective way to integrate it is to add the 65xx bus CPLD SPI bus master, but it's still a risk to be more laggy getting an immediate, unpredictable response when writing through the bottleneck of the cost-reduced serial bus interface. It's a chip design more focused on repeatedly running its script to play the annoying song when the toy is shaken, and not the chip designed to go "pewww" as soon as its register is written, at random, unpredictable intervals because it depends on varying game logic.

The most critical, however, is that it is EOL at Yamaha, so it's just kicking the can down the road as far as the availability issue, but without the safety net of the availability of a working FPGA workalike core, because due to the parallel bus addressed chips being the ones that are sometimes dead in systems people are trying to bring back to life, the focus of development of the FPGA cores is going to be on the parallel bussed chips.

The EOL news means even the OPL3 board should look to replacing the OPL3 with an FPGA workalike core if the OPL3 stocks run low.

If I ever get an opportunity to work on hardware on the X16 CP/M card project, I'm still going to be looking to get some, because it'd make a great sound chip for its SPI focused I/O.