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.

Oh man, again THANK YOU so much! This tool you've made is awesome and works perfectly for me! Not sure what you mean here by "disk files"--do you mean disk image files? Because I no longer work inside of them directly when programming stuff in Classic99. That's given me problems before. Sorry if I wasn't clear on that. I only use disk images after I've finished my work and put everything onto CF7 images to transfer to my real TI. No problem, just glad it wasn't some stupid oversight on my part. And now with your new tool I guess I won't have to worry about all this in the future. It seems pretty automated now. Quick question (at least I hope it ends up being quick): once a song has loaded and played through to the end is it possible to load another track? I did try this of course after the tune had finished by FCTN-4 to break out of the program and modifying the line where it loads music to load another track (at line 150). I then re-ran the program directly at line 150--it did seem to load the new file but when I went to play it, it just played the first file that I had loaded. When I tried to load that second music file, did it actually load somewhere in memory after the first track with the player routine still pointing to the first track? If so I suppose that's probably ideal for having multiple music tracks in a game... Otherwise I'm wondering if it is possible to clear the music data completely after it plays so that a new track can be loaded in it's place? Sorry for all the questions--appreciate your time!

Thanks very much for taking the time to help me! Good to know I at least have the process correct now! Yeah, I remember you telling me before how you disliked disk images--in fact, you got me to stop that practice a while back (I was running into bizarre issues in some programming projects until I started working with folders/FIADs and the issues ceased). So yeah, when I copied over the .OBJ file I simply copied it into a subfolder of Classic99 that I had mounted as DSK1. This folder contained all the raw files including your demo program (I extracted those files from the disk image into the folder). I "printed" this object file to a TI file per your instructions in the Editor/Assembler cart. Everything seemingly went well except that none of the files I created in this way loaded in the player. So here are some of the files. Track 1 is the longer track and track 2 is pretty short--the TI file for track 1 is called MS1 and for track 2 it's TITLEO. track1.zip track2.zip

Sorry to be a nuisance but I'm still having some trouble here, though I'm further along. I've downloaded all the above tools and followed the above outline. I took a few SBF files and first I put them through the bin2inc tool with the same parameters as outlined above to create an .a99 file. I then edited that file in Notepad and added the DEF MUSIC at the top and END at the bottom. Then I assembled this with WinAsm99 (under assembler options I chose Produce HEX Obj File and did not check off the compressed obj box so as to leave it uncompressed (bear with me, this is the first time I ever used this or assembled code so I don't really know what I'm doing). So this made the .OBJ file and I loaded that in Classic99 under the Editor/Assembler in the way described above with EDIT/PRINT--everything seemed to go smoothly and it produced a file. I'm not sure how to play the file though... I opened the example program that plays the GUILE tune and changed the filename to point to my file but this gives me an I/O ERROR 02 when trying to load. Does this have something to do with the size of the music being different than the original supplied tune or some difference in the addressing? I was looking around in the BASIC code and I couldn't figure it out--looked to me like the code was setup to auto-detect addressing and stuff... I also did try out that VGM2XB converter but unfortunately I couldn't get it to work with the few VGMs I tried. I see from the original posting that it was based on an older version of the VGM Compressor toolkit so perhaps it only works with SN76489 type VGMs (I was trying Gameboy and NES). While I think Tursi's player would be the more efficient route for any reasonably complex music, I do think VGM2XB could be very useful for sfx at least and will delve further at some point.

Thank you both for the quick responses! Thank you, you are too good to me! I appreciate your explanation above--clearly there were a bunch of things I was missing, gaps in my understanding (exactly as I knew there had to be). But you've laid it out concisely enough that I do follow and may yet manage... I need to get your tool bin2inc and WinAsm99. Again, thank you for making it make sense to me! Thank you, yes I do remember stumbling across this a while back but somehow I totally missed that it has the ability to convert to BASIC code. Converting to CALL SOUND statements is fascinating to me and I wonder if this might work in conjunction with the sound tables that can be setup in XB256... That would be super cool and I wonder how that method might compare to Tursi's method outlined above. I will definitely be trying all this out, thanks guys!

OK, so I've hesitated a long time in asking this cause I figure it's probably way over my head. I have no knowledge of assembly (just a BASIC programmer here) which is why I've started a new thread and not just tacked this onto the main VGM Compressor thread (most of the questions over there seem to at least rely on some baseline knowledge that I am lacking and so a lot of that conversation is currently over my head). I'll try to break it down simply where I'm at: Inside the VGM Compressor toolkit there is a Players folder with a bunch of player routines including one for XB. I loaded this XB player from the included vgmcompXB.dsk image. It works sure enough and I do think I understand how the code works in principle. My question lies with the music file itself--in this case the file is called GUILE (Guile's theme from Street Fighter 2 I think). I figured this must be one of those .SBF files that the VGM compressor creates but there is something different about the file. For one thing, all of the SBF files I've created myself will not play with this player when I try to load them directly (with the folder mounted as a disk in Classic99). And when I tried to put my SBF files onto that .DSK image with TI DIR I found that they weren't already in TI FILES format and the program was asking me things about how to write the files that I really wasn't sure about (maybe this is part of the problem in that the SBF is not formatted quite the way I need from the get-go). Also I tried extracting that GUILE file from the disk image into a folder so I could access it with the VGM Compressor tool set but the testPlayer doesn't recognize it. So clearly there is something different about this file. Looking through the included readme.txt I see that the music must DEFine a label named "MUSIC"--or is it the program itself that has to define a label named "MUSIC"? Looking through the included BASIC code I can't find any label called "MUSIC" so I assume it has to do with the SBF file? This is the part I don't understand, probably due to the fact that I don't know assembly... I'm sure this is why my SBF files don't work out of the box. Can someone explain to me what I need to do with the SBF files or how to structure them to work with the included XB player? Or am I indeed in way over my head here? Thanks!

Thanks for all the info. Good to know it's not some random bug (I didn't think so since it happens on both my real machine and in Classic 99). I thought there might be some common workaround I wasn't aware of but it seems based on the above that there is just no way around this when executing automatically from a LOAD file. Well maybe with RXB, I'll have to give that a try in the emulator but unfortunately I don't have that physically for my real TI. And to answer your question Tursi, yes I was trying to re-execute quickly from the main screen, but no it doesn't matter how long I hang on the main screen, it still gives the same sequence when the program is auto-loaded (at least on the real machine, haven't yet tried in Classic99). I guess that means any games I've been working on I had better not plan on making auto-loading as they all use random elements in some form or another. Also this begs another deeper question in my case specifically--I have a NanoPEB with a bunch of game compilations on it. Since disk images can be much larger than 5 1/4" disks, I put several games on each disk image to conserve space on the flash card. Then I made auto-load XB menus for each disk image so I could quickly load games without cataloging a disk to find an executable, especially considering all the files that would end up in these compilations. So now I'm wondering if my auto-load in the beginning might kill a games' sense of randomness... true XB games anyway--I realize that a lot of stuff isn't necessarily written in XB but can be converted to an XB executable--these games would presumably not be affected. Not that I've ever noticed any non-random behavior before but it's food for thought anyway.

This is probably a novice question but I'm finding that RANDOMIZE no longer produces random results if the program happens to be an XB auto-booting program called LOAD. Here is a very basic example of what I mean: 10 RANDOMIZE 20 PRINT INT(10*RND)+1 Obviously this should just print a random number between 1 and 10 and under normal circumstances it works. That is it at least appears to give a random number every time I run it, which includes if I save it as any file name other than LOAD. I can reset the computer and load the program (either with OLD or RUN in XB) and it still appears to give a random number each time. But if it is an auto-booting LOAD program, it just picks 5 every time (well every time on the first boot I mean). If I modify the program to pick two more random numbers, it always picks 6, then 2. So now my program always picks 5, 6, 2 when it auto-boots. Is there something simple here that I'm just missing about LOAD programs? Thanks

Thanks for the clarification. I had thought the latest version was Isabella... well that may explain a few things.

Thanks for your quick responses! Yeah I had been meaning to check out the GEM package and the only reason I hadn't up to this point was that I'd thought it was only available as a cartridge image. I was sticking to things I could find as .DSK images mostly as I have a CF7 and that is how I get things to the real machine. I don't yet have a FinalGROM99 and up to this point didn't really need one as the CF7 has taken me pretty far. But my thoughts are beginning to change considering awesome software like this, not to mention other things... I mean I haven't even looked into RXB yet(!) But aside from all that, I'm using Classic99 a lot more lately for developing so I've downloaded the latest GEM package (and really I should download RXB right now too); after all, anything I compile I can always send to my real machine and that's mostly what I care about. Thank you Pixelpedant for those specific tips. I need to look through the documentation that came with the latest GEM package cause I can't seem to find that section in my copy of the XB compiler.PDF that came with Isabella (I was just skimming though so maybe I missed it). Kudos to you BTW for the YouTube videos! They've given me inspiration recently!

I've recently been playing around with XB256, mostly cause I wanted to see for myself how fast certain BASIC operations could be speed up... well now I'm hooked! Up till this point I've mostly been using The Missing Link because I want access to the bitmap graphic loading. I've been working on a TML project that could really benefit from this kind of speed increase... Now I'm assuming it is possible to compile TML programs as I read about it somewhere in the XB Game Developer's Package thread. I think even the TMLDEMO file itself was compiled with a nice speed increase. But I am having trouble compiling any TML programs myself (including the TMLDEMO). Is there a special compiler for TML? I am using the latest version XB256 package as well as TML 2.0. In TML I save my program with a -M at the end of the filename followed by ,MERGE. Then I run the Isabella loader and go to the compiler from the menu and give it the file I saved in TML. It seems to compile fine (no errors) but when I go to assemble it I get several errors (a bunch of "undefined symbols"). Making a loader at this point just makes a file that crashes when I attempt to load it. Honestly I'm confused by all this--I would think that the compiler wouldn't handle TML programs as TML has subroutines that XB256 does not (the bitmap mode for instance). Also the XB256 compiler manual states that it only works with XB256 routines (says nothing about TML)--but again, I definitely saw something about TMLDEMO being compiled on a thread over here. I am running everything on Classic99 right now; I have Isabella and TML each in their own folders (not as .DSK images but as individual files). I tried copying all the TML files into the Isabella folder so that when it came to compiling/assembling, I thought maybe it might find those subroutines it needed. But still no luck. Just as a simple test I made the most simple program in TML: 10 CALL LINK("PRINT",1,1,"THIS IS A TEST") 20 GOTO 20 I saved this as TEST-M,MERGE and I tried feeding TEST-M into the XB256 compiler. For this simple program I was able to get through every step with no error messages. But the compiled program does not display "THIS IS A TEST"--it just crashes. So considering the simplicity of that I'm guessing I'm just doing something wrong...? Is there a special compiler for TML programs or is there maybe a particular way you have to prepare them before compiling?