ruthven

Thank you and no rush--I have plenty to do with my current projects before they're really at the music-stage anyway. It's not much but I thought I'd share this anyway, for anyone following along who is interested or just likes some classic NES VGM tunes playing on their TI... I always wanted to hear Tursi's Mega Man 2 tracks that are built into Classic 99 running on my real machine... well here's the next best thing: a Mega Man VGM sampler running from XB. I did this as a test of getting lots of music loaded into high memory by separating the tracks into their own embedded BASIC programs as described above. The method seems to work well with one caveat--most of these music files are actually too big to fit into memory when running TML. I found a work-around, a way to load them in regular XB. Normally if you try to load these in XB without TML you get a SYNTAX ERROR in the CALL LOAD line. But I noticed that these music files would play if I tried them after loading HMLOADER. So I modified HMLOADER deleting all lines of code except for line 110 which sets everything up (obviously there is some embedded assembly in here as well). I also modded it to RUN my own menu program called MENU1. This modified version of HMLOADER I saved as MENU, so all you have to do is RUN "DSK1.MENU" which sets everything up the way HMLOADER would, then it runs my MENU1 program which sets up the screen and lets you select the music. This all works great in regular XB even despite some of these music files being quite large. I made these VGMs myself as I was unsatisfied with the looping of the VGMs I found online--I took pains to make sure each track plays through it's main loop twice before ending as I think it just makes for a nicer listening experience. Yeah, I could have just programmed it to loop back exactly once before advancing to the next track but it's a bit complicated as most of these tracks have a sort of "introductory" part at the beginning before the main loop. Instead I just captured the music for exactly the amount of time I was looking for which kept coding simple. The main purpose of this little demo was to have it play Mega Man tracks at random on it's own which it does. After a track plays through twice it will randomly select another track unless the loop is engaged by pressing 2 (at which point it will loop indefinitely until the loop is disengaged). Once the track is playing, the menu will no longer respond--you can only engage/disengage the loop or stop the music by hitting space bar or enter. Once the music is stopped the menu becomes active again and you can select another track or go back into random mode. I made it this way on purpose as I wasn't initially sure if I could get clean looping with the program reading through so much code looking for input for all the options on my menu. But it works--it's a little janky but whatever... On a sidenote: I did make the discovery that all this works in XB256 without the memory constraints of TML. This is very exciting to me as I've been meaning to check out XB256 for other projects anyway. I might even try another Mega Man VGM sampler with XB256 as that would provide me with more character pattern memory... then I could make my Mega Man sprite do more than just stand there and blink! Not sure what's more convenient for people so I'm providing this in both .DSK and .ZIP format (if you want easier access to the individual files). The .DSK image is for CF7 and sounds GREAT on my real machine! MEGAMANVGM.dsk MegaManVGM.zip

PERFECT! Thanks so much! I've been playing around with your updated routines and they will definitely fit my needs perfectly! I appreciate you including a simplified means of selecting the music track within the SONGGO command itself--I haven't even tried this yet as I'm still just loading single track music embedded BASIC programs at the moment. But the CALL LINK("ACTIVE",variable) is VERY appreciated! Sure beats all that XB code and hey, it works in high memory first shot! Appreciate that you're willing to do this for me, considering I'm (perhaps) the only one out there nuts enough to try to get all this working in BASIC. I like to think that at least this information is out there now in case anyone else wants to follow in my footsteps. In the meantime, if I'm the only one then I wear it as a badge of honor. Hopefully I'll be good on the questions for a while now as I wait for senior_falcon's updated compiler.

Thanks for clearing that up. So now I've deleted the first portion (lines 10000-10110). I just have the exact code above and my program GOSUBs to it before attempting to play it with CALL LINK("SONGGO"). Now I'm getting a NUMERIC OVERFLOW in line 12090 CALL LOAD(N,I)...(?) I'll try re-copy/pasting in case I messed something up... Hmm... my first thought was that maybe I forgot to restore the interrupt, but no, I restore it to the original saved one. Not sure why that's killing your sprite motion... This was during my very first test getting this to work in TML. The first time I tried getting that music to work with my "title screen/introduction" program, I did as you suggested and issued the CALL LINK("STOPSN") command before the music even began playing (following your original XB example program as a guide). My program starts right off with sprites moving on the screen but with the STOPSN command issued first, the sprites would only be drawn to the screen but not move. As a test I removed the STOPSN command and changed nothing else about my code and once again the sprites moved as they did before. So then I omitted the STOPSN command and just immediately played the music which didn't interrupt sprite activity. I was just so excited to see everything finally coming together that I didn't think much of it at the time. Figured I'd tackle that later but apparently there are deeper complications senior_falcon is trying to work out.

But on that note--Tursi, I do have a question for you concerning your last post about finding the memory addresses in high memory... I notice your adjusted code above, apart from being slightly different in places, is also missing some of the original lines of code. Specifically I'm referring to line 11010 CALL PEEK(8196,N1,N1)::REM GET TOP OF FREE RAM and 11020 N=N1*256+N2. Also I notice in your above code that you did not post any changes to the first section staring at line 10000 REM FIND ADDRESS OF MUSIC TAG AND RETURN IN 'A'. In that section the very next lines of code are 10010 CALL PEEK(8196,N1,N2)::REM GET TOP OF FREE RAM and 10020 N=N1*256+N2 which are identical to the omitted lines of code from your post above. So I'm wondering was I supposed to keep the omitted lines of code in from the original program? In my program I've included all the code from line 10000 through 10110 of your original XB program, then replaced the rest with what you've posted above (keeping those lines in question omitted). Now when my program issues a CALL PEEK(ACTIVE,A) I get a NUMERIC OVERFLOW and the program crashes back to the BASIC prompt. When I type PRINT ACTIVE it reveals ACTIVE=60915 (if that provides any clue)...(?)

Thanks very much for taking the time with all this, it is much appreciated! Good to know--I was in fact going to ask if sound lists could be used in TML (compiled or otherwise)... now I see it is something you are still working with. Ah, that explains some of the behavior I noticed when I first got some music working with my latest TML project. I was noticing the music slowing down as text was being printed to the screen. I wasn't too bothered by it as I was just thrilled to have it working at all. Also I thought compiling it might solve the issue but now I understand the issue is deeper rooted. I also had some sprites moving on the screen with auto-motion that just stopped dead in their tracks once issuing Tursi's CALL LINK("STOPSN") command. I was going to ask about it but clearly this must be related. I noticed sprites still seemed to work OK once the music was loaded and playing so I've kept it really simple so far. In fact I've shifted gears for now while Senior_Falcon works on the above. I've been happy just getting a bunch of music loaded in regular XB using Senior_Falcon's HIMEM technique as it seems to load pretty quickly. Previously I had converted all my SBFs into self-loading looped music with Tursi's QuickPlayer. I then converted the EA files into XB loadable files with some code I found on this forum (EA2XB) so they could all be loaded quickly from an XB menu. The menu was called LOAD to keep all typing to a minimum--the idea being to autoload the menu, select the track with a single keystroke, the music plays and loops indefinitely until I press FCTN 0 to reset the computer, then repeat the process to select the next track. This works well enough as the computer can be reset and autoloaded very quickly. But I like this new method of loading the music into HIMEM more--it affords more control, like choosing whether or not to loop the music and then have the computer automatically start the next track (selecting a random track even). Since I have my actual TI connected to a stereo system, I like the idea of loading up my program and just letting it play music randomly unmanned while I'm doing something else around the house!

Understood. Very good sir, thanks! And I will give the sound lists a try as well.

Forgive me, I'm a bit slow... this method of getting the music working in TML that we've been discussing where I merge my code in with the high memory-embedded music program--is this just for getting it to work in regular non-compiled TML or should this method also work compiled? I was originally under the assumption that this should compile but I had some difficulty and now looking at your above comment, I'm realizing that maybe this is something you are still trying to work out in general? I say this because as I go through the compiling process I see the message "Put runtime in low memory?" which defaults to N. So I change this to Y figuring I need to spare the high memory for the music that is loaded there. Only problem is that further into the compiling process I'm informed that I cannot use additional assembly routines with the runtime in low memory. So that's a catch 22, and if this is something you're still trying to figure out generally speaking then I'll just shut up and let you get to your thing. I just wanted to make sure I'm understanding this correctly is all. That said, don't get me wrong--I'm still thrilled to get this awesome music playing even in uncompiled TML! But just on the off chance this was supposed to compile--I'm wondering where that line CALL LINK("TML16") would go? Since that is mentioned in the manual to be placed at the very beginning (line 1), but also you've instructed me not to place any CALL LINKs before the line 3 CALL LOAD(8192,243,028) which is in the music embedded file that ultimately gets compiled. So I ended up trying it both ways (leaving the runtime in high memory) but both times the compiled file gave me a "SYNTAX ERROR" when run.

Thanks so much for explaining that all out for me! Yeah, I knew that "one line XB program" had more to it than the one visible line of code--I just kept referring to it that way so as to be clear what specific file I was referencing. But yeah, what you outlined above was pretty much the way I was thinking it needed to work but I just wanted to get confirmation on this. The only thing I really wasn't sure about was the initial loading of the playback routine/music--at first I figured this code would just be imported into my existing program (which is kind of the way I can do it from regular XB with Tursi's demo program). But now I see the opposite is true for this case, which is no problem given the various methods of accomplishing this. Thanks BTW for teaching me how the MERGE command works in this way--so far I had only been using it to compile my programs which (per your instructions) I had basically just been hitting enter a whole bunch of times! Also thanks very much for informing me about LIST "CLIP"--I knew there had to be a way to do this but I hadn't gotten around to asking. Yes, this project I'm working on now (and most others for that matter) will run from a bunch of chain-linked programs. This due to the scope of it, the additional space/memory limitations when using music, and just the fact that I'm not exactly the most efficient programmer. Perfect, I actually did try this last night and got it working so I'm glad for confirmation that this is the proper approach. And in fact--Tursi, this may eliminate the need for "clearing" the music data as we were talking about a while back. I figure I'm probably only going to get a couple of tracks combined into a single .SBF at the 8k limit, but honestly, each of my game's program segments are probably going to be reasonably small (I mean play-time wise) so even just 2 tracks would probably cover it. By the time I need a third track to begin would probably be about the time I'm loading another program segment that itself would have a couple new tracks of music embedded with it. And the act of loading a new program naturally clears that memory out and refreshes it with new music, so this is perfect for my needs actually! Guys, I want to thank you both so much for getting me to this point! I'm pretty much 95% there now, and if nothing else I can at least make cool demos now with nice music and graphics! The only thing I might check back on is switching tracks when I have a couple pieces of music in the embedded SBF (cause I haven't actually tried this yet--I know there are some instructions from Tursi above that I will give a shot but very likely I will end up getting confused about something knowing me). That and looping the music--which I actually did figure out when I was tinkering with Tursi's XB program, so I'll probably be good there. It's good to know the order of operations now and to have a good idea of program size limitations when making room for music. So I think I'll leave it at that for now, at least until some specific issue comes up. Thanks again!!

Thanks, didn't think to check there as I don't work off the TML disk directly too often. OK, inching my way ever closer... Following Senior Falcon's instructions I got Tursi's player and some music loaded into high memory and playing in TML! So that's a good start, however I cannot load anything in TML after loading this "1 line XB program" that has the music/player embedded. Or rather, I can, but then I lose the player routines and presumably the music as well. As a test I loaded the music in TML per instructions above and once the music was playing, tried loading my title sequence I was referring to earlier and this just crashed the system. So then I got the music running in TML again and this time loaded a real simple program that just prints "This is a test" on the screen--this didn't crash, however the music that was already playing began to get really wonky, flat like a broken down jukebox or something , rather amusing actually but unfortunately not the effect I'm going for! I suppose this is probably to be expected, huh? I'm guessing I overwrote some memory somewhere by loading another file... so would the idea be to code my program within that 1 line XB program that HMLOADER spits out? Because I did try adding some TML code there and sure enough that all worked fine. If this is the case I will need to somehow copy over my code from my existing program into this new high memory code. I can live with that if it gets music going in my game!

No rush, enjoy your vacation! I have plenty to work on in the meantime

Thank you both again for your perseverance in helping me! Unfortunately I haven't been able to try the high memory method yet because apparently I am missing HMLOADER from my Juwel folder...(?) Maybe I don't have the latest version--that wouldn't be the first time :/ I need to look into that. So I take it then that I would just load tiSNHi.obj after loading HMLOADER in the way Senior Falcon outlined? And then the music (just to make sure I'm understanding this correctly) Sorry, I'd try this out myself but I got to locate HMLOADER first. Meanwhile I've been trying to cut my code down to get it ready to test with music. At first it consisted of a title/introductory sequence and then sets up the first part of the game. For testing purposes (probably permanent purposes) I've cut out the game engine so it is just an elaborate title sequence. This cuts the file down to 10K so it should be perfect for testing with music. Going forward at least I know to keep my program segments limited to not much more than 20K. Since I'm pretty early into coding this thing I feel I can work inside of this limitation for the sake of having music. As for the specific music I think for starters I'm going to stick with the tracks I posted here--the longer one at least; we'll see about the feasibility of getting both of them in there a little later I suppose (I still haven't tried combining the tracks into one SBF file yet as Tursi suggests but that's next on my to-do list). Tursi, I saw your comment about putting the music in VDP RAM and playing with the console player... I was wondering what this is exactly as I have heard mention to it before? Clearly this can be accessed from RXB but is this at all related to the "sound table" music that can be played from XB256? I'm just curious but regardless, I think memory might be too tight for me going that route as I am using bitmapped graphics and some of the music is probably too complex. For my particular needs I think we are definitely on the right track getting your VGM player working in TML.

Thanks very much, I appreciate your willingness to look into this for me! But now that I know the size limitations I need to work within, I'm afraid my code is going to need some serious optimizations first. I don't know how big my program file is in TI standards but in Windows it is 23KB. Plus Tursi's routine itself I think he said takes about 1042 bytes. So I'm probably over the limit already and this before even loading the music file. So apparently I need to do a lot of optimization to get my code down in size. This can probably be done--the main thing that bloats it is a lot of text. I didn't worry about this at the time because this is only the title/introduction to my game--I figured I'd get all of the introductory text out of the way here and then load the main game engine program. But it seems I've already painted myself into a corner. What I will probably have to do is offload the text into a file that can be read as I need it. Sadly this is the case for all of my recent TML projects--they are all over that 24KB mark already even though none of them are complete. :/ Again, they are all text heavy and I wasn't really worrying about it at the time because my plan was always to do the chain-load technique. So I got some work to do before I take up any of your time--I will get back to you though and appreciate it!

Thank you all for chiming in and sorry for the delay in responding (just got my internet back after a storm). So I typed CALL PEEK(8194,BOT1,BOT2,TOP1,TOP2) and then PRINT TOP1,TOP2,BOT1,BOT2 I get: 63 0 62 254 (not sure what all that means It's a fairly large program and that zero maybe doesn't bode well ) That's a bit complicated for me at the moment because my game isn't nearly finished yet. I'm not sure if I gave the impression that my game is complete and just needs music--far from, I'm simply at a point where I really wanted to see what my little "demo" as it is for now felt like with music added to it. Also I think in any case, this game is going to be much too large to fit inside a single program file. The game is going to have to be split up into several sections as chain-linked XB programs. I'm hoping that each individual program in the chain (or section) can load it's own music. So I will have to leave enough memory free in each to hold at least a track or two. My idea was to clear the music data in between loading XB programs so that memory could keep being reused and loading new music from files on disk. Sounds like I'm probably going to need to do that. So if I understand this correctly, if I am forced to go the high memory route (as it sounds to me like I may be) then I will NOT be able to clear the music data that is already in memory and reuse this space for loading more music from file? Which considering what I'm trying to do here, I might be in a Catch-22 situation. No you didn't misunderstand... sorry, I think maybe I wasn't clear--ideally I would like to get all this working in a compiled TML project. I was just noting how that might be a tall order and I would also be satisfied getting it to work in regular non-compiled TML. But that would be for another project I am working on--not the current one that had me all excited to even start this post to begin with. Yes, I am working on far too many concurrent projects! Most are TML. A couple of these will probably be able to remain regular non-compiled TML once they are finished. And I also do have a couple regular plain-vanilla XB projects that could benefit from the music as well. So I was simply trying to state that I was happy to get music going in any of these scenarios. But within a compiled program would definitely be the gold standard! Now that I've started compiling my stuff and seeing what can be accomplished, it's kind of hard to go back...

Thanks again for that very thorough response, I appreciate you taking the time to research the answer! And for laying it out in simple terms. To be honest I haven't tried this out yet as I'm not nearly there yet in my code--I was just asking ahead of time. Didn't mean to send you doing any real work on my behalf in researching my answer! But unfortunately I'm having another issue in my current project... Yeah about that, time for the million dollar question: I'm guessing there's just not enough memory to load this player/music inside of a TML project (?) And I totally get it if the answer is no, seems like a tall ask. I tried loading my Missing Link project, omitted the CALL INIT and tried just loading TISNONLY and got a MEMORY FULL error. And with the CALL INIT I then lose the TML commands afterwards, so obviously that won't work. To complicate things, yes I am compiling this project as it requires the speed given some complicated animations. So I get that this is a very tall order. That said, I have other TML projects that don't necessarily have to be compiled and if it is possible to get them working with music that would be great!--again, I get that even that may be asking a bit much here. Either way, thank you for all your help in getting me to this point. Even if I can't use it with TML projects, I certainly do have plans to use it in regular XB games--I've already got it working in a very preliminary kind of way in an old XB game I've had on the back burner for a few years now. It's a classic style XB game with small 8x8 character graphics and I have to say, it's amazing the level of gravitas that is added simply by adding some nice chip tunes! All of a sudden it's feeling more like a NES game! But in general I've been gravitating more towards The Missing Link as of late, mostly for it's bitmap loading abilities (which I'm using prolifically in conjunction with your Convert9918 program ) and for it's enhanced sprite abilities compared to plain XB. I do want to try out XB256 sometime as well for access to extra tile patterns but for now I'm loving those bitmaps in TML.

Ah I see, thanks for that info. I had always wondered how to pack multiple songs into a SBF so that's good to know. Of course this is the proper way of doing it, but it does have me wondering how many tracks I could even pack in given the memory constraints. I'll have to try it out and see. But let's just say I had a whole bunch of music I wanted to get in (which I do for a certain project at least ) -- is there a way I can clear the music data out of memory and then just load more from another file? I'm thinking like I'd have a SBF file with 2 or 3 tracks of music and have the game play them, then at some point later it could clear the music data to free up enough room to load another SBF file with more music? If this is possible, theoretically I could keep doing this to have a bunch of varied in game music.