- This topic has 19 replies, 3 voices, and was last updated 5 years, 3 months ago by
.
-
Posts
-
Haai All/developers,
I like to use Arkostracker 2 for use in MSX software.
But i have some troubles with the PlayerAkgTester_MSX.asm
I compile the source with RASM. Seems to compile fine.When using “test.bin” with bload in BlueMSX or openmsx 0.15 it plays the music, but when pushing space it seems to crash the virtual computer.
What am i doing wrong here? The source tells me it has been tested in bluemsx. I would like to have a working example before using/implementing Arkostracker 2
The software on the pc seems fine, though a “undo” and a “midi in” would be great to have.
Thank you for your amazing work!
Hi!
Just tested again, and it works fine with BlueMSX. When you space space, the “Stop music” function is called, then a RET is performed. Being not a MSX-developer, I’m not sure it is the best way program should return to the system, but it doesn’t matter. What matters is that the music is well played, and that is can be stopped.Then, it’s up to you to call the init/play/stop method in your program.
Thank you for your response. I didnt get a notification, sorry for the late response.
Normally when exiting to basic from ml, a ret will do. If the computer crashes that means, e.g. stack problems. So its not fine. lol. I will check it further, but it will be a problem for msx users.I believe there is a misunderstanding. The code of the player itself is stable and bug-free. But the tester maybe is not, because I don’t know the “good practices” about how to develop on MSX. When you will develop your app, I’m sure you will have no problem doing what is right. But I can try figuring out what’s wrong, if you want to.
mmm
i changed to:
MainLoop:
xor a
call #00d8 ;Checks the space bar. If pressed, stops the music.
or a
jp nz,Exitei
halt;Plays one frame of the music.
call PLY_AKG_Playjr MainLoop
Exit:
call PLY_AKG_Stop
ret—
seems to work now, Thanks again
Yes, it works better, you are right… Yet I don’t understand why :). Because doing a JP to a call that makes a RET does the same.
Anyway, I forgot something in the code:PLY_AKG_Stop:
ld (PLY_AKG_SaveSP + 1),spThis line makes it cleaner. It wouldn’t crash because when playing the song, the stack was already saved into PLY_AKG_SaveSP . I won’t make a new release for that, but I’ll correct that for the next one. Thanks a lot!
Looks like its working in Glass assembler with the method described on your website.
Haai,In the example the cursorkeys are the some sfx (4).
Space will continue the msx system, it all looks fine.
I will try this example on several real MSX systems, this weekend.The next problem for me though is find memory. The player uses self modifying code, my project is gonna be in MEGAROM (128k) and 16kB ram min.
What are the odds for getting a MSX ROM player, please aaaahhh 😉
There is no ROM player currently. There are indeed a lot of self-modifying instructions, however it shouldn’t be too hard to make a ROM player that don’t modify itself. I could do it, but how many people would use it?
Thank you for responding.
Well, you released a player for MSX. That’s really great, but i think the majority of the current MSX game releases (home-brew or commercial) are based on a (Mega) ROM.
Even the yearly MSXDEV.org game contest the first Category is 48KROM and 16KRAM. The ROM format is very ease to use on MSX, it has all memory available, its fast and easy to load in Emulators, SDcard and FlashROM hardware modules. It starts at unused ROM memory, only used by Basic.
Using a e.g. Konami ROM mapper you can easily use more then 64k ROM to max 512kROM.
For ROM only advantages on the MSX System.Your player works superb on a MSX for PSG, and because it uses PSG, developers who gonna use Arkos Tracker 2 for MSX gonna use the ROM format. IF they want to use other (external) sound hardware, you dont use Arkostracker and you could go for other non ROM formats because your have more RAM already available running an OS or something. The origin of the development of the PSG has been low memory resources…
I have already the setup created that the player will be moved to RAM from ROM and the Music data stays in ROM. But the flexibility is less, i use Glass Z80 assembler and i have to compile your RASM code first and use fixed memory addresses. In ROM setup on a basic MSX, from 16kRAM available, i lost 3k for system variables and for the player 2k9 excluding the sfx player with i need to imply yet.
I use MSX-O-Mizer data cruncher and it offers 3 version. RAM, ROM and VRAM. This gives a lot of flexibility. The ROM version needs still 2 fragments of RAM, one even aligned on 8 bit boundary.So answering on your question. I am not a statistics guy nor a die-hard MSX club fanatic. I just have/use the system since 1986 and want to build home-brew for MSX. I think all of the serious MSX developers who want to use your amazing tracker and player routines use the ROM format. Why release floppy disks or tapes? Maybe its different approach in the CPC, i am not familiar with this machine.
So its just a question, i am not forcing you at all 😉 (an undo in Arkos tracker 2 editor would be great though hehe)
If you say “NO ROM version” that’s fine, then i will continue with the current setup. But i know what to do 🙂
Thanks for reading and the good stuff!This is interesting, I didn’t know about this. On CPC, we put the player in RAM, so we don’t have that kind of problem. The CPC+ has a cartridge which could however use this ROM feature.
So I didn’t know that aspect about the MSX. I’m not opposed to doing a ROM player. Basically, “all” I would have to do is to declare all the variables inside a block, which you could then declare anywhere in memory, right?
What would be the most convenient way?
PLG_AKG_Variables: equ #4000 ;For example.
PLY_AKG_MySpeedStuff: equ PLG_AKG_Variables + 0
PLY_AKG_MyOtherStuff: equ PLG_AKG_Variables + 1
…And so on?
Rasm has features to handle this more elegantly, but would a solution like that would be satisfying?Also, an important question: this will slow down the player a bit. I am wondering if you have played a bit with the “stream” play, the AKY player, which is waaaaay faster, but which music take more memory. Do you think it would fit the ROM feature better? Basically, my fear is that, by modifying the AKG to ROM, it would become too slow and you would finally not be able to use it. The AKY player is also much simpler to convert to ROM.
What are your thoughts on this?
If you already worry about the speed then i would not bother. Speed is important too. It will cost you a lot of time and maybe its not usable in the end. I still need to check the cpu times on the MSX.
Maybe i can move the PLY_AKG_PeriodTable to ROM and stuff like that. I just want to keep the player as original for possible future updates. Its hard to hear the differences now when i “demolish” the code 🙂
I already needed to remove the “:” for Glass assembler e.g.:
db -128 : dw AHarmlessGrenade_Arpeggio1 + 0 + 1 ; Loop.
The assembler doesn’t like the : and i don’t know why only here this “:” is placed. I could not find the use in RASM manual.Maybe switch between AKY and AKG, eg intro screen AKG and ingame AKG.
I was just wondering about your thoughts about it.
Thanks again for your time and response.What I would like you to do, if possible, is take one song (“A Harmless Grenade” for example) and use the AKG and AKY testers to check how many CPU they take (I don’t know how to show a raster on MSX). Also compare the size of the music.
Converting the players to ROM, I believe, will cost a few scanlines to the AKG player, and less for the AKY player. In that regard, would they still be relevant? Or should only the fastest player (AKY) be converted?
Anyway, I believe all the players you used till now suffered from this problem, and I’m pretty sure mine are faster than the existing players (but I can be wrong).
I am really eager to convert them to ROM if it is needed. I never did an “official” release of Arkos Tracker on an MSX forum, but maybe I should and ask the community about how it feels about the players and what is the best way to go? What is the largest forum for MSX?
About the “:” in the labels, it’s not a RASM syntax, it’s an habit from mine. This makes the search for a label easier. However, I can write a script to remove them (the platform players are all generated from a more generic player).
Oh, a note that can be important: the AKY player does not manage sound effects. So it’s probably not suitable for a game.
Sorry for the late response, but it was kinda more work to find all the hardware.
The package should contain all the info you need. I only did the AKG. The AKY i didn’t check yet at all, but i will make same package.
Best forums i guess is msx.org, i cross posted already there.http://112-226-144-85.ftth.glasoperator.nl/public/at2/testAKG_ORG.zip
Let me know if i can do anything else.
- You must be logged in to reply to this topic.