Jump to content

Recommended Posts

Good evening folks,

I've been researching the YM2151 chip and I have couple questions.

First, it appears this chip only has a digital output and I'm curious how the X16 is handling the digital to analog conversion.  From the docs I've read, Yamaha typically paired this with a YM3012, but I didn't know if that was how the X16 is doing it.

Second, I know one of the goals of the X16 is to use readily available parts but I'm having trouble sourcing this chip anywhere besides eBay. I'm just curious where folks are sourcing these chips.

--Luke

Share this post


Link to post
Share on other sites
Good evening folks,
I've been researching the YM2151 chip and I have couple questions.
First, it appears this chip only has a digital output and I'm curious how the X16 is handling the digital to analog conversion.  From the docs I've read, Yamaha typically paired this with a YM3012, but I didn't know if that was how the X16 is doing it.
Second, I know one of the goals of the X16 is to use readily available parts but I'm having trouble sourcing this chip anywhere besides eBay. I'm just curious where folks are sourcing these chips.
--Luke

These chips are readily available through our supply channels.

This chip was an exception because firstly it met our cost goals and secondly developing an open source FPGA core if the supply dries up isn’t a problem.

Yes it is paired with the YM3012.


Sent from my iPhone using Tapatalk
  • Like 4

Share this post


Link to post
Share on other sites
1 minute ago, Lorin Millsap said:


These chips are readily available through our supply channels.

This chip was an exception because firstly it met our cost goals and secondly developing an open source FPGA core if the supply dries up isn’t a problem.

Yes it is paired with the YM3012.


Sent from my iPhone using Tapatalk

Oh cool, thanks for the details and the quick response!

Share this post


Link to post
Share on other sites
On 1/14/2021 at 9:29 PM, Lorin Millsap said:

This chip was an exception because firstly it met our cost goals and secondly developing an open source FPGA core if the supply dries up isn’t a problem.

Is there a plan on how the FPGA would be implemented on the final board rev? On revisions 1 and 2, the YM chips socket right onto the board, but an FPGA solution would have to piggyback on both those sockets? Has any thought been given to that and/or using a stackable daughterboard (ala VERA) and just a pin header (or even just putting it on a card)? Or will that just be a future motherboard revision down the road?

It's been on my mind for days haha and I shouldn't worry about it that much given the availability of the chips, but was wondering if there were plans for this eventuality.

Share this post


Link to post
Share on other sites
1 hour ago, m00dawg said:

Is there a plan on how the FPGA would be implemented on the final board rev? On revisions 1 and 2, the YM chips socket right onto the board, but an FPGA solution would have to piggyback on both those sockets? Has any thought been given to that and/or using a stackable daughterboard (ala VERA) and just a pin header (or even just putting it on a card)? Or will that just be a future motherboard revision down the road?

I believe the idea is to use a beefier FPGA to run all (most?) of the chips... CPU, VERA, VIAs, YM, address decoding logic, the whole shebang. That would leave only RAM, ROM and perhaps some glue logic as separate physical chips.

Share this post


Link to post
Share on other sites
1 minute ago, Guybrush said:

I believe the idea is to use a beefier FPGA to run all (most?) of the chips... CPU, VERA, VIAs, YM, address decoding logic, the whole shebang. That would leave only RAM, ROM and perhaps some glue logic as separate physical chips.

That's for the "stage 2" motherboard I thought? And stage 3 is the Pi like design (which is likely to replace as many external chips with a single FPGA as possible for size and costs). The stage 1 board, I thought, was meant to be the most expandable/moddable with as many off the shelf chips as possible. Which means, today, real YM2151 chips because they're available. My wonder was if the final revision of the stage 1 board might account for the eventuality of needing an FPGA solution and making that compatible without having to do any hacks.

There's a lot of options potentially. Including I suppose not worrying about it for Stage 1 until it becomes a problem - in which case one might be able to come up with a Ms. Pac-Man style add on card that plugs into the existing sockets directly or via ribbon cables. Given the memory map of the YM2151 it sure seems like it could also be an expansion card (though that'd eat up a slot, require more modifications to the kernel, and might be more expensive). I rather like the idea of card myself though a VERA style riser that just connects via a pin header would make things nice and tidy too.

Curiosity killed the cat I guess 😉 I'm sure we'll find out eventually, though hoping the team does address this in a future update/video perhaps.

Share this post


Link to post
Share on other sites
2 hours ago, m00dawg said:

That's for the "stage 2" motherboard I thought? And stage 3 is the Pi like design (which is likely to replace as many external chips with a single FPGA as possible for size and costs). The stage 1 board, I thought, was meant to be the most expandable/moddable with as many off the shelf chips as possible. Which means, today, real YM2151 chips because they're available. My wonder was if the final revision of the stage 1 board might account for the eventuality of needing an FPGA solution and making that compatible without having to do any hacks.

There's a lot of options potentially. Including I suppose not worrying about it for Stage 1 until it becomes a problem - in which case one might be able to come up with a Ms. Pac-Man style add on card that plugs into the existing sockets directly or via ribbon cables. Given the memory map of the YM2151 it sure seems like it could also be an expansion card (though that'd eat up a slot, require more modifications to the kernel, and might be more expensive). I rather like the idea of card myself though a VERA style riser that just connects via a pin header would make things nice and tidy too.

Curiosity killed the cat I guess 😉 I'm sure we'll find out eventually, though hoping the team does address this in a future update/video perhaps.

That's the stage 3 that might include CPU and VIA cores (which are available under license from WDC) and all of the glue logic together with Vera in a single beefier FPGA, but the stage 2 is surface mount with cost reductions, which could include a CPLD/FPGA for the glue logic or a beefier FPGA to include it with Vera.

An FPGA might handle the YM2151 in either stage3 or both stage2 and 3, with the real stock for the through pin reference design.

 

Share this post


Link to post
Share on other sites

If the YM2151 becomes unavailable it would be replaced with an FPGA on a daughter card with pin headers to plug into a dip socket. But we are only crossing that bridge if it becomes necessary.


Sent from my iPhone using Tapatalk

  • Like 6

Share this post


Link to post
Share on other sites

I am trying to figure out how to use the YM 2151. I have looked at how @SlithyMatt does it in ChaseVault. I found that he uses the addresses $9FE0 for the register byte and $9FE1 as the data byte for communication with the YM 2151. However, in the official documentation, this area is denoted as "Future expansion"

https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#io-area

Are there any official sources or did the few people who have actually used the YM 2151 so far figure this out by themselves?

Edited by kliepatsch

Share this post


Link to post
Share on other sites

Although YM2151 support is in the emulator (if you go to line 112 of memory.c, you will see these addresses connected to the YM2151 emulation), it is not currently documented, and these addresses may change in the future. I am assuming that they will document the YM2151 addresses after they finish working on the next hardware revision.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Addresses will certainly change at least once the emulator starts being worked on again. I do worry as all the repos haven't been administered in some time. There's several PRs across the project and some of these would be really valuable. The emulator I might understand if it's not technically open source yet (though I think it is?) but the docs - I know there's one PR that provides the actual color swatches of the palette in line with the docs, and that would be SUPER helpful.

Not sure why the repos have seemingly been ignored by the team. I'm sure there's a reason for this but it does create some issues. We know, for instance, the kernal now has claim to a few zeropage addresses that are currently available in the emulator for instance, and we know from Kevin's last vid on the revision 2 board working that several addresses (FM included) will be changing.

Not trying to stoke any conspiracy theories here but Micheal Steil was doing tons of work on the project but hasn't made any changes since August so perhaps he may have gone onto other things and the team is busy working on the other stuff to have the time to circle back and work on the repos at the moment. That could make sense if the hardware design is still changing (better to go back and update the emulator once if there's limited resources than over and over again as the hardware changes)?

I do wish some of the PRs would be looked at though, as noted above, There's some good ones worthy of eval.

Share this post


Link to post
Share on other sites

Yeah- you can fork and build your own emulator an kernel but eventually there is going to be a Rom made for the real hardware....

Share this post


Link to post
Share on other sites
On 2/14/2021 at 2:27 AM, m00dawg said:

Not sure why the repos have seemingly been ignored by the team. I'm sure there's a reason for this but it does create some issues. We know, for instance, the kernal now has claim to a few zeropage addresses that are currently available in the emulator for instance, and we know from Kevin's last vid on the revision 2 board working that several addresses (FM included) will be changing.

A lot of work would have been put on hold during the period when the revised board was not able to boot. It would not be surprising if there is a lot of work going on behind the scenes as we speak. That makes it quite plausible that it is not an effective time investment to update the repos based on previous iterations of work in progress hardware and Kernel when the finalized design may appear to be in sight.

Given the track record so far of announcing things when there is something to announce, including announcing that they had hit some kind of hardware snag when they were NOT able to get the board to boot up, I prefer to imagine a period of silence as representing the garage door being shut but clanging sounds coming from inside.

Edited by BruceMcF
  • Like 2

Share this post


Link to post
Share on other sites
15 minutes ago, BruceMcF said:

A lot of work would have been put on hold during the period when the revised board was not able to boot. It would not be surprising if there is a lot of work going on behind the scenes as we speak. That makes it quite plausible that it is not an effective time investment to update the repos based on previous iterations of work in progress hardware and Kernel when the finalized design may appear to be in sight.

Given the track record so far of announcing things when there is something to announce, including announcing that they had hit some kind of hardware snag when they were NOT able to get the board to boot up, I prefer to imagine a period of silence as representing the garage door being shut but clanging sounds coming from inside.

Indeed those are good points and I agree with most of that. I do think at least the documentation PRs are well worth looking at and certainly if folks were looking at PRs, I would provide a few of my own (the section of the docs the mention the kernel routines, like CHROUT, could stand to be better formatted for example). I'd bet plenty of folks would be willing to contribute to those (and some have by way of some excellent external resources though these require knowing that they exist). There's a PR that adds nice color swatches for the built in palette for instance. That would be super convenient to have and I would really like to see that merged.

Share this post


Link to post
Share on other sites

I came here exactly because the official repo has been quiet for so long. I was thinking about updating the YM2151 support to move it to the base address and add read support to the emu, as well as adding its INIT routine to the system reset. I was wondering if there was any news here about why emu development seems to have stopped completely.

Share this post


Link to post
Share on other sites
1 hour ago, ZeroByte said:

I came here exactly because the official repo has been quiet for so long. I was thinking about updating the YM2151 support to move it to the base address and add read support to the emu, as well as adding its INIT routine to the system reset. I was wondering if there was any news here about why emu development seems to have stopped completely.

As far as anyone seems to know, Michael Steil is still part of the team, but may simply be busy with their day job and simply hasn't been able to keep up with the Github.

This comes, in part, from Mike Allison, who responded to a ping about this on the unofficial Discord a few days ago.

So... "patience, grasshopper".

Though I'll say I sure would love to help catch up the emulator on pull requests and features, and maybe catch up on some of the bugs from the actual emulator (and not the ROM). Of course, anyone can fork the emulator in GitHub, and the magic of Git is that (once you've learned how to do it, anyways), you can pull changelists from almost anywhere. Just keep in mind that there is only one official emulator repo, and it is the only repo that has been granted permission to host the X16's modified ROM files that are necessary for the emulator to do anything useful.

  • Like 3

Share this post


Link to post
Share on other sites
On 2/17/2021 at 5:30 PM, StephenHorn said:

As far as anyone seems to know, Michael Steil is still part of the team, but may simply be busy with their day job and simply hasn't been able to keep up with the Github.

This comes, in part, from Mike Allison, who responded to a ping about this on the unofficial Discord a few days ago.

So... "patience, grasshopper".

It would definitely be good to go ahead and start using the new address locations for things like the RAM/ROM banking and YM2151 base addresses in our X16 projects.

On the emu side, I've also felt like taking a stab at doing a VIA emulation that works for the clocks/IRQs. Lacking those made it difficult to debug my program back when I was helping Kevin with the 'hello world' tests for the YM2151 back on prototype 1.

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, ZeroByte said:

It would definitely be good to go ahead and start using the new address locations for things like the RAM/ROM banking and YM2151 base addresses in our X16 projects.

On the emu side, I've also felt like taking a stab at doing a VIA emulation that works for the clocks/IRQs. Lacking those made it difficult to debug my program back when I was helping Kevin with the 'hello world' tests for the YM2151 back on prototype 1.

Well, the nice part about the emulator's design is that it's really easy to move around memory-mapped I/O. There's no reason someone couldn't work on cycle-accurate VIA emulation for the current addresses, and then move it to the proper addresses later.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use