Thanks to FRS and friends the MSX-AUDIO chapters of the MSX Datapack were translated, they are available on the MSX Assembly Page.
Excellent, thank you - now next question - are all MSX-AUDIO ROMs compliant to those (e.g. this one)
I insist much on that because as developer I always program the MSX platform using the BIOS features (like originally was intended), so if I'd program for MSX-Audio I'd use its BIOS for device handling. And because this for me it is so important.
You do know that if you do this, your software will not work with either the Philips Music Module or the Toshiba HX-MU900, right? Only the Panasonic FS-CA1 has the MSX-Audio BIOS built-in, and I can count the number of people who own one on one hand. I've only ever seen one myself once, a couple of years ago (after being an MSX user for many years), it's super rare.
But that is the standard. If a new standard is made, the MSX-Audio one, and some manufacturers releases their ones not following the standard, then is not my fault.
Sorry but on computers I always develop following the standards and the norms as habit.
Remember that I develop for MSX-Audio, not for the OPL1 electrically adapted to the MSX slot.
The problem mainly was that MSX-Audio was not intended for general public, so each one released their one with its own built-in program to use the device (sample and composing). Like a tool for use in a closed environment.
Excellent, thank you - now next question - are all MSX-AUDIO ROMs compliant to those (e.g. this one)
That is the platform one, so you can follow it. If some others made its own version, do not take it into account.
Philips Music Module and Toshiba HX-MU900 do not have an YM3526 OPL chip. They have the same Y8950 MSX-AUDIO chip as the Panasonic FS-CA1 has. Also what you say about MSX-Audio not being intended for the general public, I wonder where you got that from… It failed commercially, was too expensive (in Japan), and then the FM-PAC came and blew sales out of the water, so instead they standardised that and built it into new MSX computers, is my theory .
Anyway if you choose to require a BIOS for hardware while most devices on the market since the 80s don't have one, then yes, it is your fault. It is also your choice of course, but one I can not really comprehend, seems based on dogma instead of supporting the hardware users own, and contrary to your stated reasons for wishing to use the BIOS (compatability). At least let me say that developing software is in my experience much more fun if you have many people actually using it
.
And if you make the choice to not support such commonly available hardware, surely you could not blame others for not wishing to support, say, alternate VDP I/O ports for rare hardware like the MA-20 .
@Eugeny I would use FRS's MSX-AUDIO BIOS v1.3, or v1.2. Amongst others it adds turboR R800 mode support.
The not intended for general public from the devices themselves. See that there is no one made to be cheaper, removing the keyboard and sampler connections, what is the same, ones with the only purpose of playing sounds. Simply take a look at the size!
Also, I think it is a standard, it even is registered as device on MSX EXTBIO, like the DOS2 memmap. Then is not good to only implement it partially. Precisely the use of the HAL layer (through the BIOS) is intended for what you say, the usage of different chips to achieve the same purpose from each manufacturer, being transparent to the software. Today is the same than Nvidia or AMD for GPUs and using the drivers/APIs to access them.
We can't, and less in an open architecture with multiple device manufacturers like MSX, to look specifically at each device one by one, even if it is considered popular. OK, each one can do as wanted, but by specific device is only a specific way, so it could be considered as private software for private environment. I don't follow that line.
And if you make the choice to not support such commonly available hardware, surely you could not blame others for not wishing to support, say, alternate VDP I/O ports for rare hardware like the MA-20 .
That is another story. In fact, the MSX technical handbook says that you should, not directly, but looking at how the MSX should be programmed.
http://www.konamiman.com/msx/msx2th/th-4a.txt
At point 1.3.
I only follow the manual from the designer of the platform. Is that so bad? I think not.
I think this is some off-topic anyway.
Other great advantage of GR8NET Playing Audio Waves on MSX 1 Computer.
https://www.youtube.com/watch?v=_nhDzqyUVB4&feature=youtu.be
Sharing File:
https://drive.google.com/open?id=0BylCIPwrn3FvZTEzLVZsQmRJcHc
Device received, one question: what is the purpose of the attached cable? I suposse that recover FPGA in case of firmware failure during update proccess but, where is supossed you have to connect that cable? It's not USB.
Thanks.
PD.: ok manual read, it seems that goes attached to USB Blaster.
No, cable is used to update the FPGA chipset and you will need an USB-BLASTER.
You have 2 update files :
1- update of flash chip (update.bin)
and
2- update of FPGA (gr8net-fpga-fwimg-xxx.rar => which contains .pof files)
(my webpage can help you : http://www.sebbeug.fr/msx/gr8net/)
(in french sorry... google translate it :) )
Ok I've seen that there is a online way to update firmware but, can you update offline similar to Zemmix. I mean, simply put new firmware in the sd card and use PDLOAD file.bin to upgrade.
You have 2 differents things :
1- Yes of course, you can download update.bin file...
Browse on your SD card, press space on update.bin to load it, and execute call netfwupdate(3)
But it's easier with the online method
This update is only for FLASH CHIP update !
2- To update the FPGA, you have to use your cable.
(it's an other update !!!)