I think this is the FS-CA1 specifications. It's not indicated as clearly in the various descriptions. There are even contradictions, especialy about ROM and RAM for PCM and the 128kB ROM content. So I think it's better to consider BIOS, BASIC, RAM for PCM. Otherwise, we must remove the NMS-1205 and HX-MU900 from the list.
From my point of view, FS-CA1 is the only MSX-AUDIO standard device, NMS-1205 and HX-MU900 are incomplete implementations. This is also said on the MSX-AUDIO wiki topic. Pretty much all MSX standards require a BIOS, I don’t think it is different for MSX-AUDIO.
Doesn’t mean software should not support the NMS-1205 and HX-MU900, of course. There is not much point to support only the FS-CA1 and exclude the others, since it is such a rare device.
I’ve updated the MSX-AUDIO programming wiki page to clarify the situation to avoid future confusion.
The bits 1 and 2 of the MSX-AUDIO status register are floating. Because of that, this way of detecting only works on MSX computers with pull-ups on the machine’s internal bus, which makes those bits go high. So you should mask these two bits out before checking the value: in(C0h) & 06h == 0.
The 12 cycles of waiting between the writing in the address register and the data register, take into account the execution time of the instruction out(n), A ?
If it is the case, since it already takes 12 cycles, we are supposed to be able to chain the 2 out without worries, no?
It's the VGMPlay code that makes me doubt, but maybe it's to handle CPU turbo mode?
I have uploaded a new version of MSXgl on GitHub.
Here are the new features:
-- Added MSX-AUDIO module to detect hardware and allow direct access to registers.
-- Added MSX-AUDIO data support for the VGM replayer (thanks to Grauw). The s_vgm sample has been updated with 2 MSX-AUDIO tunes. I don't put a WebMSX link this time because it doesn't seem to support MSX-AUDIO (or at least, I haven't found how to configure it for that).
-- Added a new module to manage character sprites (game_pawn). You can define different sprite layers for the character and define a list of animations. Then, the module takes care of updating the frame to display and display the sprites on the screen. I updated my s_game sample to show how it works. There are still many things to optimize, but it is already functional and the interface should not change. See: https://webmsx.org/?MACHINE=MSX1J&ROM=https://github.com/aoi...
Your library is very nice to work with! Thanks for releasing it.
I left an 'issue' (with solution) on Github to make compiles instantaneous.
Apart from that, perhaps this RNG is of use to you:
r+=r*r|5;
This silly tiny thing, seeded with an arbitrary 16-bit value, will produce a quite good sequence of random numbers, at a very low cost. Source: https://blog.demofox.org/2013/07/07/a-super-tiny-random-numb...
I think the multiplication of two 16-bits variable values should not be so fast in Z80 assembler.
MSXgl already include lot of 8 & 16-bits pseudo-random generators but I keep the idea for a future test.
Thanks for the suggestion on GitHub. I will add a date check.
The 12 cycles of waiting between the writing in the address register and the data register, take into account the execution time of the instruction out(n), A ?
Yes they do. You calculate the time from the start of the first /IORQ signal (I/O request) to the next /IORQ. The /IORQ signal is active in the last three cycles of the I/O instruction, this is relevant when you combine e.g. OUTI with OUT (n),A, when OUTI comes before the OUT the time is 12 cycles, and when OUTI comes after the OUT the time is 18 cycles.
aoineko wrote:
If it is the case, since it already takes 12 cycles, we are supposed to be able to chain the 2 out without worries, no?
That's correct.
aoineko wrote:
It's the VGMPlay code that makes me doubt, but maybe it's to handle CPU turbo mode?
I am trying to create a 48K rom with about 30KB in a few global arrays. When I do this, I get a 4GB rom file, which is subsequently rejected by the emulator. Removing some of the arrays does produce a valid rom file, so it looks like I can't have that amount of data? Is there a limit to the size of global arrays (beyond the obvious, for a 48KB rom)?
