Jump to content
IGNORED

YMari - OPL3 Cartridge by Tori / Yogi


Matej

Recommended Posts

yamari_logo.jpg

 

On MSX2 they have Moonsound with OPL4. And Atari developer from Poland (Tori/AtariArea site) has made OPL3 cartridge... Similar FM was inside Atari Arcade System too! So what about StereoPOKEY+OPL3 as ??? We can make some carts. ..

 

More infos here:

https://translate.google.sk/translate?sl=pl&tl=en&js=y&prev=_t&hl=sk&ie=UTF-8&u=http%3A%2F%2Fraven1.magix.net%2Fyamari%2Fyamari.html&edit-text&act=url

 

Wiki:

https://en.wikipedia.org/wiki/Yamaha_YMF262

 

What is OPL3?

Its good old soundchip from Soundblaster16. Do you remember DOOM music from MSDOS?

 

There is beautiful PC MSDOS tracker named Adlibtracker2:

http://www.adlibtracker.net/

 

YOUTUBE

 

OPL3 is ideal for MIDI playback too!!!

 

And you will say now. Thats not ATARI! But ATARI used similar YAMAHA chip in ATARI ARCADE SYSTEM boards (Marble Madness). Or there is 7800XM module using FM chip too! So it is ATARI!

 

Good is that songs are small like 8kb. So no samples... Ideal for Demos, Games, Trackers...

18 channels FM + 4 or 8 Pokey that will be ultimate sound setup...

 

Yogi has made little PCB tuning, here is OSHpark

https://oshpark.com/shared_projects/opUPvV4U

 

15USD for PCB + 3euro for OPL3+DAC so whole cart can be 30USD max.

Not bad for 18 channels stereo sound...

Edited by Matej
  • Like 6
Link to comment
Share on other sites

Hi Matej, here is a BOM for the BRD. Before ANYONE orders a run, please consider the Stereo jack, I don't know what the Part number is for the board's part. It needs to be low profile, to fit in a cart case, so will have to search for a suitable jack and likely edit the brd file. So IF you can't wait please make sure you can source a jack to fit the existing footprint! If anyone has a preference as far as the jack, let me know and I'll change it.

YAMari v2 BOM.txt

 

Just to let people know, I'm also re-working the design for an internal XEL M-PBI YAMari device. Currently, have gone thru the schema and added some XEL related changes. Also planning the board to be thru-hole, aside from the Yamaha parts, so the layout will take a little longer :)

 

Yogi

  • Like 2
Link to comment
Share on other sites

T0ri's project does not include a driver :( he did post a couple .bas test files though. My hope is if the HW is available to interested coders it will aid development. 'If you build it, they will come'

The MIDIbox.org FM synth project should be helpful in driver development, it's based on a 8bit PIC. Somewhat 'Apples and Oranges' but may be helpful understanding the OPL resisters.

Yogi

Link to comment
Share on other sites

Never less interesting but....and no....me not coding tracker ;).

DOSbox DRO v2 dumps to start with. Native A8 tracker is not the first step. There is a C64 OPL2 player http://csdb.dk/release/?id=119462 and https://github.com/lgblgblgb/c64-sfx-cartridge-player/wiki and 4MAT has a FM+SID player http://www.lemon64.com/forum/viewtopic.php?t=54715&sid=b4663430ba2dcb41e90797494a807090 and http://csdb.dk/release/?id=147615&show=summary#summary , so it's not a far stretch for an Atari player. OPL3 is really just two OPL2s on the same die and better timing wise.

Yogi

Link to comment
Share on other sites

Heaven is good coder! :) We dont need tracker! We need adlib player :D.

I know personally Adlibtracker 2 coder SubZ3ro.

I think best will be to have AT2 module player for Atari...

Like RMT player is... Will write to Him.

Download here:

http://www.adlibtracker.net/downloads.php

There is win32 version too with opl3 emulation!

I know few OPL3 musicians. When there will be Adlibtracker2 player

than there will be music.

Tracker on A800 will be best to have. But lets be realistic for start.

Dan!L from C64 scene knows ADT2 tracker very good too!

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

Hello friends, I am too sleepy but:

 

Here is that OPL2 adlib player for C64 SFX expander...
http://csdb.dk/release/?id=119462

GIThub
https://github.com/lgblgblgb/c64-sfx-ca … layer/wiki

Author:
http://lgb.hu/

Re-pasting from email -> LGB/C64 opl2 player author:

part1:
Hi,

Nothing mystical about my *extremely* stupid player too much, and the source code is open since years, so no problem at all to grab it smile.png You can find it here:

https://github.com/lgblgblgb/c64-sfx-cartridge-player

The only issue can be, that since it's GPL, if you use it, or part of it, your work must be open source + GPL too, etc, but IANAL ;-P

Well, it sounds an interesting project (yours), but I am not so much a great help here, since I've never even used Atari (unfortunately, but I would love to have one) - but if you speak about 8 bit Atari computers, the CPU is still 65xx class, so maybe some other differences on the hardware should be learnt (Ehmm, I am over-optimistic enough here?). There are several minor points with my "player":

* in its core, it's really two STAs smile.png selecting the register number, and write it .... all the other part is the DRO file format "reader", which is simple enough, since it's basically a register dump like file format (of DOSBOX). Thus it's very easy to write a player like this, it's more a challenge if some wants to play a "decent" tracker like format ...
* this source is OLD, AFAIK does not even compile with modern ca65 as it should be (as it would create its own BASIC SYS stub for C64, some modification is needed)
* it cannot "load" anything, the DRO is INCBIN'ed ....
* really, this is good for demonstration only, eg, a DRO file format is also not so nice, as very large file sizes, etc etc
* I've already started a project for C64 (with the same hardware) to be able to play S3Ms instead, well, at least ones with "AdLib instruments" only. that is the mentioned "tracker like format" player, which is probably more close to have a sane player than this DRO thinggy ... Surely, other formats can be found as a good candidate for playing on OPL2/OPL3 not only "S3M with AdLib instruments only".

Some technical background: back in the time when I wrote that, I only read the "Adlib programming FAQ for PCs". There is 388h and 389h (if I remember correctly) ports for selecing OPL2 register, and read/write that register. Other than that there is a timing constraint to wait some time before write/read again. Also, the layout of the actual internal registers of the OPL chip. Then I thought, if SFX Sound Expander cartridge has some kind of similar chip, these theories can be used without _any_ change _but_ the I/O port of course (which is PC notion). And indeed, that seems to work, as expected. So it's just that ...

Sorry for the long mail, maybe too much information already smile.png But if you have question just ask ... I can't tell I have too much time recently for coding as well, but at least for writing insane mails, well, it seems I do ;-D

part2:
One additional note: I have the yet unfinished work to play S3M "with AdLib instruments only" on C64 + SFX expander cartridge. That code would be able to play S3M directly (ie, on-the fly "interpretation" of the so called "packed pattern format" since ScreamTracker for real decompresses it first, but it uses way too much memory in that way for my taste). However since it's not ready yet to do _anything_ it is not released yet. Also I find myself a bit dumb for implementing stuffs like "commands" in the patterns, but we will see ...

  • Like 2
Link to comment
Share on other sites

Support for s3m mods would be awesome, hope that comes to pass. I wonder if DOSbox (I.E the DOSbox Mega build with AT ][ configured) can output a DRO when AT][ is playing a song?

 

I also contacted 4mat over at CM.org, about his player. The posted player, @ http://csdb.dk/release/?id=147615&show=summary#summary, supports XM note/channel import via a converter (incbin the converter's output file into the C64 player source before assembling) and is modular. There is a basic instrument editor also, so that will help.

 

In the DL zip is a pretty nice PDF doc to explain the sources. Of course the sources will have to be ported to Atari system, but it's 6502 asm so should be doable without too much grief :) The OPL3 has two sets of OPL2 registers (4 HW addresses) so the player will have to account for the extra channels but once the basic player works with OPL2 music, expanding to OPL3 should be straight forward.

 

Been working on the XEL version schema, YAMari XEL.pdf

Included a lot of headers/jumper blocks to allow max configuration options. Also added a lot of filter caps, as per the MBHP OPL3 module http://ucapps.de/mbhp/mbhp_opl3.pdf. So it's kind of a blend of t0ri's project and the MIDIbox board. The design could also be used with other systems as a OPL3 sound board. Anyway, will be starting the brd layout now :)

Yogi

  • Like 3
Link to comment
Share on other sites

Been working on the XEL version schema, attachicon.gifYAMari XEL.pdf

Included a lot of headers/jumper blocks to allow max configuration options. Also added a lot of filter caps, as per the MBHP OPL3 module http://ucapps.de/mbhp/mbhp_opl3.pdf. So it's kind of a blend of t0ri's project and the MIDIbox board. The design could also be used with other systems as a OPL3 sound board. Anyway, will be starting the brd layout now :)

Yogi

Cool project!

 

Not that it will affect what you are doing, but what is shown as /CSYN (Buffered CSYNC) will probably get reassigned as HALT in the final MPBI spec, and /CSYN moved off to it's own header to allow direct connection to the RGB-THRU. Having HALT on the MPBI seems more useful.

 

- Michael

  • Like 2
Link to comment
Share on other sites

Cool project!

 

Not that it will affect what you are doing, but what is shown as /CSYN (Buffered CSYNC) will probably get reassigned as HALT in the final MPBI spec, and /CSYN moved off to it's own header to allow direct connection to the RGB-THRU. Having HALT on the MPBI seems more useful.

 

- Michael

Thanks. '/CSYN' only passes thru from header to header; just shortened the name to fit in my label frame :) HALT will fit better ;)

The OPL board only uses the basic buss signals so as long as those don't change, we're good.

Yogi

Link to comment
Share on other sites

Thanks. '/CSYN' only passes thru from header to header; just shortened the name to fit in my label frame :) HALT will fit better ;)

The OPL board only uses the basic buss signals so as long as those don't change, we're good.

Yogi

 

I had to shorten some of the names myself for the silkscreen legend on the board, so I also used the same abbreviations on the schematics, but where it wasn't perfectly clear I added a note showing the complete name.

 

Actually /HLT is what I'm going to use, and is similar to how it was designated on the U1MB except I'm prefacing it with '/' to denote that it has active low logic. So /CSYNC has been moved to a 2 pin header which allows the signal to be tied into the RGB video output connector if using a VBXE (not needed by Sophia). It is a buffered logic level version originating at the GTIA, and being passed through a spare 74HCT08 AND gate.

 

So here's how things stand now.

 

BzMBung.png

I'm locking this in, so this will be the standard for MPBI.

 

So I saw you are taking advantage of the Stereo inputs on your project :thumbsup: I put those there thinking that it'd be nice to have an XEL controlled MP3 player plug-in. It would be nice if you could add an audio mixer to your project with one set of inputs tied into the pass-thru port, that way if I ever do make what I have in mind it could easily co-exist with your board. Or I guess I could do that on my end as well... just depends upon who goes first in the chain.

 

- Michael

  • Like 2
Link to comment
Share on other sites

 

I had to shorten some of the names myself for the silkscreen legend on the board, so I also used the same abbreviations on the schematics, but where it wasn't perfectly clear I added a note showing the complete name.

 

Actually /HLT is what I'm going to use, and is similar to how it was designated on the U1MB except I'm prefacing it with '/' to denote that it has active low logic. So /CSYNC has been moved to a 2 pin header which allows the signal to be tied into the RGB video output connector if using a VBXE (not needed by Sophia). It is a buffered logic level version originating at the GTIA, and being passed through a spare 74HCT08 AND gate.

 

So here's how things stand now.

 

BzMBung.png

I'm locking this in, so this will be the standard for MPBI.

 

So I saw you are taking advantage of the Stereo inputs on your project :thumbsup: I put those there thinking that it'd be nice to have an XEL controlled MP3 player plug-in. It would be nice if you could add an audio mixer to your project with one set of inputs tied into the pass-thru port, that way if I ever do make what I have in mind it could easily co-exist with your board. Or I guess I could do that on my end as well... just depends upon who goes first in the chain.

 

- Michael

Good info, I'll change the label :)

 

I put in a 2x3 header for the Audio with the intent of dual use. The header can be jumpered to route audio into the XEL mixer Or can be used as two 1x3 headers to route aud off and back on to the board/into the XEL. My thoughts are that many that want to produce music will want control over the levels of each channel so would want separate outs for each channel.

 

IF R-IN and L-IN connected direct to the mixer sum nodes, at the base of Q3 and Q4, then each external audio source could couple to the mixer with 100Ks. Maybe even removing C10 and C13 and each source adds them to the M-PBI connection. In essence R-IN and L-IN by-passing the RN SIPs and become an extension to the mixer sum.

Yogi

  • Like 2
Link to comment
Share on other sites

Good info, I'll change the label :)

 

I put in a 2x3 header for the Audio with the intent of dual use. The header can be jumpered to route audio into the XEL mixer Or can be used as two 1x3 headers to route aud off and back on to the board/into the XEL. My thoughts are that many that want to produce music will want control over the levels of each channel so would want separate outs for each channel.

 

IF R-IN and L-IN connected direct to the mixer sum nodes, at the base of Q3 and Q4, then each external audio source could couple to the mixer with 100Ks. Maybe even removing C10 and C13 and each source adds them to the M-PBI connection. In essence R-IN and L-IN by-passing the RN SIPs and become an extension to the mixer sum.

Yogi

 

Good idea on making those summing inputs :thumbsup: ;)

 

- Michael

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...