Checking interest for DalSoRi version 2

Page 7/12
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12

By sd_snatcher

Prophet (2992)

sd_snatcher's picture

13-02-2017, 23:15

JunSoft wrote:

What I can tell you at this moment, is that I will make a DalSoRi v2 with following specifications:

OPL4 (YMF278B)
YRW801M sample ROM
4MB sample RAM (upgraded from v1)
128KB (or more) BIOS ROM (new from v1)
8KB (or more) BIOS RAM (new from v1)

Audio DAC, Headphone amplifier, 3.5" phone jack
Switch to disable BIOS ROM/RAM (new from v1)
Konami-size (fit into Overrich case)

I'll really miss the ADPCM feature and an SFX processor (may be other than the YSS225), but what can I do? I'm sure it will be a great sound cartridge anyway. It will still be the OPL4 cartridge with most features. Smile

Quote:

Yeah, No ADPCM. Well, what for ones who want MSX-AUDIO functionality?
I think this needs more discussions. Exactly what parts of MSX-AUDIO functionalities are need, is not determined yet.
I also must determine the approach to implement the functions. So I need evaluation period more.

I hope this means a DalSori v3 with even more features. Wink

Quote:

If there is anything I missed, let me know.

Here go my thoughts, please consider them as constructive remarks:

1) Configuration register

I have some slight modification to suggest for this register:

67xxH: configuration register (default: 2)
[0] - enable FM I/O port map to C0H-C3H
[1] - enable FM I/O port map to C4H-C7H
[2] - reserved (must write 0)
[3] - reserved (must write 0)
[4] - enable flash memory write
[5] - enable 2MB sample RAM instead of YRW801M
[6] - reserved (must write 0)
[7] - reserved (must write 0)

The bit1 was inverted to keep it compatible with the original MSX-Audio code/register function. It's easier to handle it in software this way too. Note that the default value was also changed to reflect this, thus having the same I/O port enabled when the cartridge is booted without a BIOS.

2) SRAM paging register

The SRAM register needs a small modification.

64xxH: SRAM memory banking register (default: 10h)
[2:0] - SRAM segment for frame-1
[3] SRAM disable on frame 1 (1: disable). The flash will be shown instead.
[4:5] - SRAM segment for frame-2
[7] SRAM disable on frame 2 (1: disable). The flash will be shown instead.

The amount of segment bits where changed to address 32KB of SRAM, which is a standard chip size. With 4 bits it would address 64KB, but that would require two 32KB SRAM chips or a 128KB SRAM chip (more expensive and unnecessary). The separate paging/SRAM-disable bits for each frame are necessary because different parts of the BIOS are used in each frame, and to keep backwards compatibility with the NMS-1205 BIOS expansion kit.

On frame-0, the SRAM must always be enabled, and the page-0 of the SRAM must always be shown. Otherwise there will be problems with the interrupt handler routines.

On frame-3, the SRAM is never enabled. Only the flash is shown. This will be a workaround for poorly written software.

3) BIOS Flash size

I'd recommend to use either a 256KB flash or a 512KB flash. They're usually cheaper than the 128KB, have the same pin count, and will have provide more space if necessary.

Quote:

Let's see what I can do with v2 in the next month. If I feel fun with it, I'll continue to develop v2.5 or v3.0 Smile

Yessss! This give me hope to one day finally have a so desired version with ADPCM and a SFX processor. Big smile

Quote:

If almost all software use BIOS instead of I/O ports, can't the BIOS emulate ADPCM through OPL4 ?

Unfortunately, most software don't. Yes, I have in my TODO list to implement ADPCM emulation via WaveTable in the BIOS someday, for the OPL4 cartridges that don't have ADPCM hardware acceleration. But this will of course require the existing user software to be patched in order to use the BIOS. IOW, it's not something that will work out of the box, and will require a considerable amount of work.

And it's a feature that will only work with cooperation from the software developers. But this is the kind of love-or-hate subject. Just like the OPLL->OPLn software translation, where I have feedback from people in both sides of the spectrum.

Slowly but sure, I continue my hobby to develop respect-the-codelines-software for the friends who love and see its advantages. Smile

Quote:

Any question and suggestion is welcome always!

I did the best I could here to iron out any possible caveats in the design. Hope it helps. Smile

By msd

Paragon (1372)

msd's picture

14-02-2017, 01:57

@snatcher, I didn't know that. I see you quickly updated the wiki. Is there any known Japanese software using the msx-audio ADPCM?

OPLL->OPL4 register mapping could be done runtime in a FPGA. It could even support msx-audio and msx-music at the same time if you really go wild.

By JunSoft

Resident (34)

JunSoft's picture

14-02-2017, 05:55

sd_snatcher wrote:

1) Configuration register

I have some slight modification to suggest for this register:

67xxH: configuration register (default: 2)
[0] - enable FM I/O port map to C0H-C3H
[1] - enable FM I/O port map to C4H-C7H
[2] - reserved (must write 0)
[3] - reserved (must write 0)
[4] - enable flash memory write
[5] - enable 2MB sample RAM instead of YRW801M
[6] - reserved (must write 0)
[7] - reserved (must write 0)

The bit1 was inverted to keep it compatible with the original MSX-Audio code/register function. It's easier to handle it in software this way too. Note that the default value was also changed to reflect this, thus having the same I/O port enabled when the cartridge is booted without a BIOS.

OK. For the sake of software development, let's sacrifice some logic gates. Smile

Quote:

2) SRAM paging register

The SRAM register needs a small modification.

64xxH: SRAM memory banking register (default: 10h)
[2:0] - SRAM segment for frame-1
[3] SRAM disable on frame 1 (1: disable). The flash will be shown instead.
[4:5] - SRAM segment for frame-2
[7] SRAM disable on frame 2 (1: disable). The flash will be shown instead.

The amount of segment bits where changed to address 32KB of SRAM, which is a standard chip size. With 4 bits it would address 64KB, but that would require two 32KB SRAM chips or a 128KB SRAM chip (more expensive and unnecessary). The separate paging/SRAM-disable bits for each frame are necessary because different parts of the BIOS are used in each frame, and to keep backwards compatibility with the NMS-1205 BIOS expansion kit.

I meant 8KB-sized banking. Anyway now two 4KB-based SRAM banking registers are needed. Again sacrifice of logic gates. Wink

Quote:

On frame-0, the SRAM must always be enabled, and the page-0 of the SRAM must always be shown. Otherwise there will be problems with the interrupt handler routines.

On frame-3, the SRAM is never enabled. Only the flash is shown. This will be a workaround for poorly written software.

According to the readme file of MSX-AUDIO bios v1.3,

b) The memory mapping must be as follows:
0000h-2FFFh: ROM
3000h-3FFFh: lower 4KB of the RAM
4000h-6FFFh: ROM
7000h-7FFFh: lower 4KB of the RAM (mirror of 3000h-3FFFh)
8000h-AFFFh: ROM
B000h-BFFFh: upper 4KB of the RAM
C000h-EFFFh: ROM
F000h-FFFFh: upper 4KB of the RAM (mirror of B000h-BFFFh)

Your suggestion seems breaking above conditions. I need confirmation.

Quote:

3) BIOS Flash size

I'd recommend to use either a 256KB flash or a 512KB flash. They're usually cheaper than the 128KB, have the same pin count, and will have provide more space if necessary.

The minimum configuration is 128KB. In fact, v2 will support up to 512KB. However, exactly what sized chip will be assembled, is not determined.

Quote:

Yessss! This give me hope to one day finally have a so desired version with ADPCM and a SFX processor. Big smile

Anything's possible although something is realized Tongue

Quote:

Unfortunately, most software don't. Yes, I have in my TODO list to implement ADPCM emulation via WaveTable in the BIOS someday, for the OPL4 cartridges that don't have ADPCM hardware acceleration. But this will of course require the existing user software to be patched in order to use the BIOS. IOW, it's not something that will work out of the box, and will require a considerable amount of work.

OK. ADPCM support will be the number one objective of v3 in the near future.

Quote:

And it's a feature that will only work with cooperation from the software developers. But this is the kind of love-or-hate subject. Just like the OPLL->OPLn software translation, where I have feedback from people in both sides of the spectrum.

Slowly but sure, I continue my hobby to develop respect-the-codelines-software for the friends who love and see its advantages. Smile

Just do it, whether others like or not. I'll make hardware whether it is sold or not Wink

Quote:

I did the best I could here to iron out any possible caveats in the design. Hope it helps. Smile

Better than nothing always!

By Grauw

Enlighted (7961)

Grauw's picture

14-02-2017, 11:55

JunSoft wrote:

Just do it, whether others like or not. I'll make hardware whether it is sold or not Wink

Love this quote ^_^

By Langoor2

Supporter (12)

Langoor2's picture

14-02-2017, 18:28

Jun Soft, please know that MoonSound has traditionally been an I/O only device. As a result of this, many users use MoonSound in a slot extender (not slot expander). If you will add a memory-based configuration register, people will have to swap cartridges more often, because it can no longer work in an I/O only slot. This particularly hurts enthusiasts that built their 6 or 8 slot expanders in a closed case.

I can see three possible solutions to this:
1. Make the configuration register available on I/O somehow. Preferably without needing a dedicated I/O port.
2. Make the configuration persistent on a hardware level, so people can configure it to their liking once (such as enable the 2MB RAM) and then put it in an I/O slot.
3. Add dipswitches or jumpers on the cartridge that set the default configuration.

I am less interested in this unit if the 4MB RAM mode is not available from an I/O slot.

By JunSoft

Resident (34)

JunSoft's picture

15-02-2017, 02:56

@Langoor2

First of all, I like clean hardware, too. My motto is "simple is the best", believe me.

However, think about that.

1. We have only 256 I/O ports. Already most ports are filled with other hardware. Of course, the number of ports can be increased by some kind of "indirect method". I think it's not clean hardware, then.

2. MSX standard forbids direct I/O access to keep compatibility. Application programs must use API given by BIOS ROM of the hardware. Or simply use CALL statement when BASIC environment. Direct I/O access is very convenient. It's more simple for software development and even for hardware. However, it is really a big problem as a result.

3. I don't think people must swap cartridges. It's just a "easy-difficult" problem. Software must detect which slot is used for the target device. It's not convenient but possible.

I also have been playing I/O ports, and that was really fun. However, it must be limited to a private purpose.
Indeed, direct I/O accessing of VDP spoiled MSX spirit. I understand that situation in the past. I'm very sorry about that.

Well, let's focus on DalSoRi v2. Smile

After reset, v2 is the same as v1. All existing software for OPL4 must run if you disable the BIOS by a given hardware switch. You can put it in any slot, you can access I/O ports directly.

Do you need 4MB RAM after reset? You can write some codes to switch memories or use a simple program given by others.
Is this annoying you? I can consider additional switch to change default memory map.

Let me know exactly what environment/situation makes you uncomfortable to use v2 with memory mapped configuration registers. I respect your opinion.

Jun

By Langoor2

Supporter (12)

Langoor2's picture

15-02-2017, 04:20

I'm not sure what triggered your talk about I/O ports. MSX standard does not forbid the use of I/O ports. In fact, it specifically allows them to be used under certain conditions. MSX is also not a Hardware Abstraction Layer. It is a specification of hardware that is compatible at the hardware level, as well as a set of API for system functions and non-standardised hardware. In any case, I did not ask about extra I/O ports in Dalsolri...

As I suggested in option 3: Please provide a hardware switch to enable 4MB RAM at reset. My situation is that I want to use Dalsolri v2 in a slot splitter/extender and therefor do not have access to memory mapped configuration.

Please realise that slots are rare on MSX and people do not want to swap cartridges. I am not talking about a software problem, but a physical problem.

By JunSoft

Resident (34)

JunSoft's picture

15-02-2017, 05:02

Langoor2 wrote:

I'm not sure what triggered your talk about I/O ports. MSX standard does not forbid the use of I/O ports. In fact, it specifically allows them to be used under certain conditions. MSX is also not a Hardware Abstraction Layer. It is a specification of hardware that is compatible at the hardware level, as well as a set of API for system functions and non-standardised hardware. In any case, I did not ask about extra I/O ports in Dalsolri...

I just wanted to tell the original concept of MSX. I/O only-devices are wrong approach.
Just practical and commercial products won the game.

Quote:

As I suggested in option 3: Please provide a hardware switch to enable 4MB RAM at reset. My situation is that I want to use Dalsolri v2 in a slot splitter/extender and therefor do not have access to memory mapped configuration.

Please realise that slots are rare on MSX and people do not want to swap cartridges. I am not talking about a software problem, but a physical problem.

You mean:
You have "I/O only slots" so you can't access memory of a cartridge at all.
You must change the configuration manually.

Right? Then I understand your system environment. I'll consider your request.

By Langoor2

Supporter (12)

Langoor2's picture

15-02-2017, 14:22

JunSoft wrote:

You mean:
You have "I/O only slots" so you can't access memory of a cartridge at all.
You must change the configuration manually.

Right? Then I understand your system environment. I'll consider your request.

Yes! Thank you Big smile

Many people in Europe have a 6-slot or 8-slot slot expander. This kind of device has 4 normal slots, and 2 or 4 I/O only slots. I guess this is less common elsewhere.

By sd_snatcher

Prophet (2992)

sd_snatcher's picture

15-02-2017, 22:18

msd wrote:

@snatcher, I didn't know that. I see you quickly updated the wiki.

I imagined the misinformation could have been from the wiki, so I fixed it to help. Smile

Quote:

Is there any known Japanese software using the msx-audio ADPCM?

Not that I know. Maybe some BASIC programs published in the MSX Magazine.

Quote:

OPLL->OPL4 register mapping could be done runtime in a FPGA. It could even support msx-audio and msx-music at the same time if you really go wild.

That would be a dream of a sound cartridge! But since I'm mostly a software guy with some small adventures in the hardware field, I do what's within my reach: software solutions. Smile

But you must agree with me that at least my solution is very cheap. Only requires a ROM, a RAM and a TTL chip to be put in the cartridge. Wink And it uses classic design: could have been perfectly built in the 80's, when FPGAs or uber powerful microcontrollers didn't exist.

Page 7/12
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12
My MSX profile