Tursi

Unfortunately, you're going to need to dig deeper to help troubleshoot that. It sounds like uninitialized memory, but it could also be a state issue in Classic99. I don't have the time right now to trace through GPL code to see what is locking up, so the first thing to do is to identify what is happening WHEN it locks up. A screenshot or two, and a copy/paste of the disassembler (AND DEBUG LOG) would help. (Please, not screenshots of the logs, use view->freeze and then you can copy/paste the text). If you understand the lock up, some description of what the code is doing would also help. Basically.. I'm not debugging third party code anymore. I realize you didn't write the GPL Assembler, and we're stuck with what IS, but neither do I have any experience with it, and I will spend hours just getting up to speed. So help me help you, collect as much information as you can about what is happening under the hood, and then we can try to figure out WHY.

Don't forget you can use the Magellan tool to create large maps and have it automatically generate the characters needed for smooth scrolling. I haven't done much with it myself, but it can save you some time -

Pretty impressive though!

I'm still torn on whether load errors should pop up a message. When I first wrote that loader code way back when, they couldn't. But it's never going to do what you want if it failed to load a file, so maybe the interruption is warranted...

No, C/D images are standard "inverted" 16k images, it should work.

Congratulations! A couple of thoughts... The high voltage line was removed in the Rev 3 board because people were blowing up the flash chips. The high speed programming mode requires a source voltage of 9v or higher - the only way to get that on the Jaguar was the raw, unfiltered 9v line which comes right from the wall jack. If it spiked, or people plugged in a higher voltage power supply expecting the regulator to take care of it, the chip would pop, usually with a visible hole. Therefore, I don't recommend putting it back in. The 3.x BIOS optimizes the byte writes and is pretty close to the 2x's 16-bit writes (in fact I recommend all 2.x boards should make this mod and update the BIOS to the 3.x code). Not sure on the boot strap issues you ran into, but nothing wrong with using the upgrade process. We programmed the CPLDs through the JTAG port using a bench power supply for the 3.3v. I had a little piece of perfboard with a set of pogo-pins on it, so I could slide the board under, press the board down onto it, click 'program', and repeat. Nothing fancy at all, not even hinged (just loose on the desk), but it made programming 200 in a sitting a lot easier.

For what it's worth, Classic99 already includes a LINES demo object for the MiniMemory in its DSK1 folder

As always, "read the debug log". The filename in the archive does not match the filename in the README file, and Classic99 tells you this: Loading file (D:\classic99\mods\XB28GEM\XB28GEM\XB28GEM_G.BIN) from disk: Type G, Bank 0, Address 0x6000, Length 0xA000 Failed to load 'D:\classic99\mods\XB28GEM\XB28GEM\XB28GEM_8.BIN', error 2 Error 2 is "file not found", and if you look in the archive, you'll see it's not XB28GEM_8.BIN, but XB27GEM_8.BIN. This would break drag and drop, too, since the two files has different names. Rename the file and it will work.

One important detail - as there is way too much information up there for me to figure out what I need to answer next... The ONLY thing that decides whether an entry shows up in the menu is the existence of "Name=". If you don't see your entry, either you typoed the group name or you typoed (or omitted) the "name" line. Don't get fancy with punctuation, you can never be sure how a filename/text parser will deal with it. Particularly since the square brackets are meaningful syntax in an INI file. When in doubt, simplify. You shouldn't need quotation marks around the values. First thing you need to do when it doesn't work, is read the debug log and see if the emulator did what you expected it to do, and did not emit any warnings.

Haha, well, that was easy. It has been so long since I added a group that I never thought about how the emulator knows what groups you want. You need to add one more section to your INI, that lists out the groups you want it to search. "Usercart" is automatic, you do not list that one. So, mine looks like this: [CartGroups] Group0=Mikes Group1=Test So... yours would be something like this: [CartGroups] Group0=Spill Group1=Games You can have up to 100 groups, numbered 0-99. But, of course, I don't know what Windows will do if you exceed the screen real estate, so stay conservative. The "usercart|xxx" and "usercart0xxx" are not valid, but I totally understand why you tried them! Sorry about that!

I can confirm those aren't working. I will write again after I know why.

I didn't, I found it online somewhere. Sorry, I know that's not terribly helpful.

The temporary data is internal only, so there's no place to copy it out. You could take the information out of the english lines in the log, but the steps listed above are going to be faster. Can't help with the "subfolders didn't work" unless you show me what you did.

Hehe, sorry, I jumped into the middle of the thread. The QI was the last release of the TI99 - consolidated some discrete logic and supposedly improved the quality (QI = Quality Improved). They're generally less common and less desirable to most people.

Ah ha, okay. Yeah, I got tired of chasing down every time someone released a new file format for something we already had. So Alpiner is an easy one! When you drag and drop, it loads, so you know that Classic99 successfully autodetected it. That means (most of the time) that the last letter before the .BIN correctly identifies the file type. So to add the file, you need to answer four questions. The first question: how many files are there? Some games will have multiple files with the last letter changing - ALL the files need to be accounted for in the INI, while drag-and-drop will search for alternates automatically. In this case, there is just one file. The second and third question are answered for each file. The second question: what kind of memory is the file? The drag-and-drop only recognizes a subset of the many types in the manual (at least for now), and they are: C - Standard 8k ROM file D - Second bank of 2-bank 16k cartridge (XB and AtariSoft games are usually all that use this) G - GROM data, up to 40k 3 or 9 - 3 is obsolete, but you may see it on old files. Represents an "inverted" bank-switched ROM (using a 74LS379 "mapper") 8 - Represents a "non-inverted" bank-switched ROM (using a 74LS378 "mapper" - that's where the numbers come from ) N - this is non-volatile RAM for the MiniMemory There's one exception so far. If there is no ".BIN" extension at all, and Classic99 still successfully loads it, treat it as a type '8'. FinalGROM images are often distributed this way. The reason that I insist on testing via drag and drop first is that there are several other old naming schemes, such as for the PC99 emulator and the GramKracker devices. When you encounter these image files it takes a little more effort to get Classic99 to play with them, since Classic99 wants raw memory data (the naming scheme comes from the V9T9 emulator). This letter will be the "type" character in the INI file. In the case of Alpiner, the type is "G". The third question: where in memory does this data load? For cartridges this is really easy. It's almost always "6000", which is the base address of the cartridge port. There are two exceptions: 3/8/9 - Bank switched ROMs can be much larger than the 8k available, so they live in their own memory space, and start at "0000" N - the MiniMemory RAM starts at "7000" Alpiner here is a standard GROM, so it starts at "6000". The fourth question: How big is the file? Normally cartridge images are padded out to a power of two, but regardless, you just need to get the size of the file, and convert it to hexadecimal. You can actually use Windows calculator for this if you don't have anything else - switch it to "Advanced" or "Programmer" mode, depending on which version of Windows you have, and you can type a number in "DEC" (decimal) mode and click the "HEX" option to see the hexadecimal. The one thing to be careful of - the Windows file list rounds the size. Either use properties or the command prompt to get the true size. (Of course the rounded value is fine if you know it's properly padded out.) AlpinerG.BIN there is 32768 bytes. Plug that into calculator, and we get "8000". (There are only a few common values you'll find, eventually you'll have them memorized ). Creating the INI entry: that's everything we need, now we can update the INI. Close Classic99, otherwise your changes may be lost as it rewrites the INI on exit. Open Classic99.ini and jump down to the end. First you want to choose a folder for your files and move them there. They can be anywhere that Classic99 can read, it will not attempt to parse the path you specify. In my example, I have ALPINERG.BIN in "D:\new". If you already have "UserCart" entries, select the next index. Classic99 supports indexes from "1" to "99". Note you can create subfolders in the menu by using a different word than "UserCart", as long as it doesn't conflict with any of the reserved words. So for instance, "Games" is fine. I'll assume here the first entry, and use an index of "1". First create the section header - this tells the system that the following lines are associated with a particular cartridge. [UserCart1] Inside a section, everything is defined as a "key" = "value" sequence. Next, we need to enter a name to appear in the menu. Anything will do after the equals sign. name=Alpiner Finally, for each of your ROM files, you need to enter a rom line. Classic99 looks for lines 0-99, but the actual key index has no meaning except the order in which the files are loaded. (Sometimes, very rarely, you might have overlapping files on purpose. That's the only time it matters.) You have just a single file, so we'll use "rom0" as the key. If you had a second, you might use "rom1", and so on. The value for a ROM line needs to specify all of the above information, so at a glance it may look like some kind of nonsense code. It's divided into four fields by the vertical pipe symbol (|), and they are: Field 1: Type character (G) Field 2: Load address (6000) Field 3: Load size (8000) Field 4: Filename (D:\new\ALPINERG.BIN) So for Alpiner, filling in all the information we have and inserting the pipes between fields, it looks like this: rom0=G|6000|8000|D:\new\ALPINERG.BIN Finally, it's often helpful to leave yourself a reminder of what an entry is, or any special cases you encountered, or whatnot. You can have a "comment" in the INI file by starting a line with a semicolon (;). Classic99 will completely ignore these lines, it's just for your own notes. ; Alpiner by Texas Instruments is the BEST GAME EVER! Putting it all together: [UserCart1] name=Alpiner ; Alpiner by Texas Instruments is the BEST GAME EVER! rom0=G|6000|8000|D:\new\ALPINERG.BIN That's actually it! Save the INI, close it, and open Classic99, and your game will show under Cartridge->User (or possibly a subfolder of that if you used a different name). Troubleshooting and unknown ROMS: I could write a whole 'nother massive post on this, but it's basically experience that will lead you to how to identify unknown ROMs. - there are GRAM Kracker and PC99 ROMs, which have a 6 byte header that gives all this information - you can sometimes use the size - normal ROMs must be 8k. Cartridge GROMs normally can't exceed 40k. GROMs may be a multiple of 6k instead of 8k. - you can open the file in a hex editor and look for the cartridge header for clues - ultimately in the end you make a theory and try it. When it doesn't work, as this Alpiner doesn't!, the first thing to do is open the Classic99 debug log (Edit->Debugger), reset the emulator (File->Cold Reset), and look for the line that loaded your cartridge. In this case we see: Loading file (D:\new\ALPINERG.BIN) from disk: Type G, Bank 0, Address 0x6000, Length 0x8000 You're looking for anything that's wrong, or any warnings nearby. I don't see any, which means we typed the INI correctly and there's something strange about the image itself. Troubleshooting that is far beyond this class. But, just because I was curious, I took at look. I don't expect you to learn this far, but the debugger showed that it was jumping into CPU ROM space at >6000. This suggests that indeed, there should be a second file for Alpiner's ROM - and indeed my own archives show that yes, there should be. ALPINERC.BIN So if we go through the process for this file, then we can quickly work out the four questions: Field 1: Type character (C) Field 2: Load address (6000) Field 3: Load size (2000) Field 4: Filename (D:\new\ALPINERC.BIN) Note how the load address is the same, the type changed to C, and the load size went to >2000, which is 8192 in decimal. If we make the rom1 line and add it to the INI like so: [UserCart1] name=Alpiner ; Alpiner by Texas Instruments - Don't forget the ROM file! rom0=G|6000|8000|D:\new\ALPINERG.BIN rom1=C|6000|2000|D:\new\ALPINERC.BIN Then we can enjoy some crash-free gaming!

Wow, that's super clean, I didn't have that. When the heck did Mainbyte post that one? Thanks!

Yes, please upload the files. That said, I have no idea what a CTG file is. Does it load when you drag and drop it onto Classic99?

It's not naturally understandable for me at all, it's the result of 20+ years of dealing with it, not only in my own work, but most other people's who use Classic99. Well, we can go through a couple of carts if you want, till it starts to make some form of sense. Once you have done a couple you'll find that 90% of cartridges follow the same pattern. Go ahead and post one here to start, and I'll walk through what I would do to make it go in the INI.

Yeah, they are PROGRAM image files, I don't think there's a way to move them to disk with XB. (Maybe there's already a copy tool out there somewhere?) Do you have a way to get disk images from the internet to your TI? The files are all available that way.

I got color out of a 9928 in a 4A console without jumper changes, but it looks like I DID have the resistors in there (using a component to VGA adapter)! The colors were not /correct/, but they were present ;). Not sure why the picture is so bad, probably hiding the awful soldering job. You asked if checking for shorts was going to work - you got something to lose by trying? Even experts sometimes short the pins by accident.

Yeah, I actually took deeper examination of his issue to the thread he started in the TI forum. That said, be careful with the schematic - the commonly available schematic is for the the 99/4 rather than the 4A, and the clocking is a little different (as far as I remember, I need to get my TI's here to verify that my old memory is still on track.)

You can also create subfolders under User by using a custom area tag. For instance, I have one called "Test", and for that I use "[Test1]", "[Test2]", etc. Before I go too deeply into it, though, did you read the manual? I put a lot of detail into there. However, to manually add cartridges you need to know what kinds of memories are in it, it's not automatic. That means you need to know if it's ROM or GROM, paged or not, and the particular details of those memories. After a while you get used to it, but that's kind of why I just added drag and drop. There are some assumptions you can make that help all that. For instance, non paged cartridges almost always start at "6000", whether they are ROM or GROM. Non-paged ROM is never more than 8k (and normally should be exactly 8k). Cartridges with paged GROM are extremely rare, and the GROM should be less than 40k. Paged ROM - you just need to know if it's "inverted" or "not inverted", and the Classic99 load address for paged ROMs is usually "0000". Finally, if the images you have are tagged properly (that is, they load when you drag and drop or use cartridge->open), then this information is actually right there in the last character of the filename. The characters Classic99 knows are in the manual.

I didn't see the details on your post in the Coleco forum - now I understand how it's attached. You're going to need to cut some traces. The three video pins on the 9928 are 35 (B-Y), 36 (Y) and 38 (R-Y). On the 9918, these pins are CPUCLK (38), Composite Video (36) and Ext VDP (35). (I erroneously stated in the other thread that one of them was tied to reset, different issue, not related to this). Anyway, I don't have a console handy to check, but I believe one or both of pins 35 and 38 are connected to something. CPUCLK /is/ used on the 99/4 but not the 4A, so I'm not 100% certain. The 4 schematic says that 35 is not terminated to anything and I do believe that is correct on the 4A as well, so I'd focus first on pin 38. Of course, after checking your wiring for shorts as suggested above - the 'Y' signal is your black and white picture. If that's shorting to the other pins, you'd also get that.

For me, you're dividing it, but I get the feeling I'm the only one who reads every thread. With additional forums added, I'll certainly choose a couple to dedicate my time to and ignore the rest. But my vote is indifference.

(TI-99/4A) Yes, the VDP provides the audio clock. I've run a console with the 9918A replaced with a 9928A before. I don't remember if I tested sound, but everything else worked. If you are getting the title page, you can be certain that the VDP, VDP RAM, scratchpad RAM and GROMs are working. Color would be a function of the video output. If you just plugged the chip directly into the motherboard, and it's a US console, then yeah, you're only getting the luma output, thus, black and white. There's no circuitry on the US motherboard that will support the 9928 directly, not even with jumpers. In fact you are wiring one of your video out pins to the console reset bus. You'll need to lift the three video out pins and wire them to the mod board manually.