ruthven

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?

Thanks again. You were right about that--I was indeed trying to load all these files using all caps. Actually you really cleared up a couple mysteries for me--for one, I wasn't really sure if you could even use lowercase characters for file names on the TI and I figured it defaulted to all caps. And so I just assumed TIDir was writing the filenames in all caps when I copied them into the .DSK image. I guess I just wasn't paying enough attention cause sure enough, TIDir clearly shows that the files retain their lowercase names within the .DSK image. Didn't realize it was recommended not to use .DSK images in Classic99... can understand the argument for an open file system. I've been using .DSK images just cause it's easy to transfer them to my CF7 and most of the time I'm using the real machine.

Thanks Tursi. I was using the GUI version which is set to TI-99/4a by default, I left the dropdown selection on QuickPlayer (didn't choose any of the visualizers though I did try one at some point in my many attempts), usually checked Loop playback though I did some tests without it, plugged in the .SBF file in the field directly underneath labeled SN Music, pretty much left everything else as is (had no SID music, left the 3 channels set to pulse and usually tried typing something in the text window though sometimes I'd try leaving this blank as well). Clicked Build, typed sonic for the filename and the program outputted 2 files named sonic and sonid, the first of which sonic is showing up as a DOS file, the other is a TI file. I've included them in the attached .zip along with the .SBF that I made them with in the QuickPlayer. I had actually forgotten about the command line version of QuickPlayer so I just tried that out and unfortunately things just got weirder. The command line version takes the same .SBF and outputs 2 files again, but this time they are both showing up as TI files in TIDir. So I figured it was working and I dropped those two files into a .DSK image and mounted that in Classic99. But both files give me I/O error code 7 when trying to run in EA option 5. I've also included those 2 files in the .zip--they are built from the same .SBF and are named TEST and TESU. Much appreciated you looking into this for me! test.zip

Oh wow.. holy cow!! I've been away for quite a while; sorry for arriving back so late to the party. I see this VGM compression/conversion software has come super far along just as promised. The last time I checked in on this post (wow, almost 2 years ago now) we could only compress/playback .VGMs for the SN76489 specifically which still provided access to a huge archive of awesome music from multiple systems. Back then I figured out how to convert NES music to SN76489 oriented VGM format manually by copying/pasting the track information out of one tracker to another. Now it's great to see the new conversion tools can do this automatically but not to mention all those other chips it handles... where even to begin :) Naturally I want to get in on this but unfortunately I seem to be having a problem with the QuickPlayer. When I give it a prepared .SBF and build the files, it creates 2 files but when I look at these files with TIDir (the PC program I use to create disk images) only one of them is seen as a TI program file and the other one shows as a PC DOS file. Shouldn't both of these files be TI files? I try copying them into a .DSK image I made with TIDir and the TI program file copies over fine but for the PC DOS file it asks me what kind of file to copy it over as. I copied it over as a program file but it seems to be corrupt when I try accessing it in Classic99. I tried loading both files in EA option #5 but I get I/O error code 7. I tried this with a few different VGMs from NES and SEGA but always the same results, even with some of the same SEGA VGMs that I got to work previously with the old compression tool. Just to provide some more detail on my complete process (using a SEGA VGM for simplicity sake): I start with vgm_psg2psg to extract the individual tracks out of the VGM, then use prepare4SN to make a single file out of the individual tracks, then use vgmcomp2 to compress this single file into a .SBF file. All of these steps seem to work fine--I get no errors and the TestPlayer plays all the files up to this point, even the final .SBF file. So I don't know if the problem is with the QuickPlayer or is it something on my end?--am I not understanding something correctly? The old QuickPlayer (which sadly I no longer have due to a hard drive crash) used to spit out 2 files, one with an "A" at the end and the other with a "B"--or maybe that was just my own naming convention, I can't remember honestly but the first file--the one that ended in "A" was the one to be run in EA option 5. But as I say, the new QuickPlayer is only producing one TI file, the other seemingly a PC file and neither being able to load in EA... can anybody clear up this mystery for me? Would be greatly appreciated as I am just a humble BASIC programmer and haven't the knowledge to use this music proper in assembly. :)

Thanks so much! Yes that worked like a charm! Very much looking forward to creating something with TML now, it will be my first time using it. Also interested in your upcoming XB GEM cartridge now that I've just learned of it!

OK, forgive me--I'm coming to this a bit late but as I was reading though this thread it seemed to me that the incompatibility with TML running on the CF7 was finally solved... I downloaded TML from the pinned development thread on this forum very recently thinking it must be the updated version that is compatible with the CF7. However when I run it on my actual CF7 (mounted as DSK1), TML itself will load up but I am unable to save or load anything. I can't load bitmap graphics that are saved on my CF7; heck I can't even save the BASIC program I typed in--as soon as I try to save or load anything whether in immediate mode or from within the program, the computer crashes on a blank screen that I can't function-break or function-quit out of. So is TML not compatible with the CF7 or do I just have the wrong version (hopefully)?

This is really exciting news! I for one am totally psyched about the possibility of playing chiptunes from all those different systems on the TI! I was actually in touch with Tursi just a month or so ago about this very thing. He was kind enough to get me up and running with his .VGM quick player (which he actually created at that time as I was still using his older/now obsolete EPSGMOD quick player which was much more limiting on the size of the music files it could play). The new quick player is great and seems to handle anything I throw at it size wise. I built up quite a collection of Sega tunes and they sound great coming out of real iron! I couldn't stop there though--I knew Tursi was working on a NES playback routine but I was impatient and started converting .NSF files to .VGM by copying the data out of FamiTracker and pasting into a SN76489 compatible tracker. The results are not perfect and vary from track to track but some music actually came out pretty decently using this method. Especially music from the Mega Man series--all that stuff sounds great, almost like the original and does not suffer too badly on the SN76489. I even converted some Gameboy stuff using this same method. Some of that stuff sounds amazing too, other times certain tracks have bizarre tuning issues I haven't worked out yet. But I only did all this cause I didn't actually think Tursi would get around to updating his routines anytime soon. Let alone include support for Gameboy, Atari and MSX! I can't wait for the converter as it totally antiquates my previous method, firstly by simulating envelopes etc. which my method has no provision for, but also automating the entire process (no more endless copy and pasting)! Also I like the idea of that testplayer outputting for different sound chips other than just the TI's. I have a good few vintage computer systems and chiptunes are an interest for me across the board.

I have a film project in mind and I was wondering if there is any animation software available for Atari 8bits? Also, can anybody recommend any good art/drawing programs? In a pinch I could just get by with an art program in place of animation software (the animation will all be done in camera anyway). ALSO: I'm assuming it's possible to load pictures created with art software in BASIC... while I won't ask for the technical details involved in that right now, I'm just wondering if there is a specific art program I should look into for this purpose (one that saves pics in a format easily loaded in BASIC)? Thanks.

That's what I meant by "disabling" the custom OS--more like re-enabling the original OS. So from the sounds of things I'm going to have to open up the Atari to find the switch/jumper..? Hmmm...think I'll save this for if I get really desperate to play some of these games. Good to know though, thanks.

Thanks. That one from Holme's Archive was one of the few I hadn't tried yet. And now I can scratch that one off the list cause it didn't work. I'm convinced it must be this weird OS of mine. I don't know if there's a way to disable it completely--I can't find any mention of this in the documentation. Maybe the solution is to boot from an old OS or translator disk first, then warm reboot with the game disk. I did try "freeing up the $C000 page" by holding down select while pressing reset. I almost thought this was going to work as the game seemed to get further into loading--the display started flashing garbled characters randomly (as often happens loading games)--previously I hadn't gotten Guard to display anything but a black screen (or a loader screen on some .ATRs/XEXs) while loading. But then it ultimately hung on a black screen again. I feel like it definitely got further along by freeing up the memory--maybe this method will work with one of those other versions of Guard I previously tried. Oh well, maybe I'll get back to it but for now I'm moving on; plenty of other games out there.

Thanks for the info. I didn't realize the Z80 was required to run CP/M in general. I guess the C128 has a Z80 coprocesser which is how I am able to access CP/M disks on that machine. Specifically, I was trying to recreate a piece of software that controls an old synthesizer. This software has never been ported from it's original Kaypro II format. I managed to find the raw files on the net and get them into C128 CP/M format. From here I can use C128 software to write a Kaypro II CP/M disk of these files. But what was really cool was that I found I could just run this software straight up on the C128. Only problem is I'm stuck in 40 columns with my current C128 setup... So I was thinking it would be cool if I could get it running on the 130XE (another feature of Omniview XE is built-in 80 col mode). I guess this would be possible if I had the ATR8000, which I would need anyway for the COM port to control the synth.