Tursi

Nice thing about that one is because it's monochrome, I doubled the frame rate. But I don't have a generic player for that one so I never got around to cartridge-izing it.

pCode needs disks, yes, which are scattered all over this forum and I am pretty sure WHTech several times over. Classic99 supports it and also includes the disk images in a subfolder. Pretty sure MAME supports it. I didn't see if JS99er did?

MAMEs in a strange place there. The system was designed to run dedicated computers for which the software was complete and no new software was being designed. With that fact in place, it was a trivial choice to put all the metadata into the executable. No arcade system is ever going to use a cartridge system from an 8-bit micro - it doesn't make sense to change all that. It's fixed. Consoles and computers, even old ones, are different. They constantly get new software and emulators are used for development. So restricting software to what the emulator already knows about is incredibly limiting. As far as I know though, everyone else has a single file format for their ROMs. Nobody else uses the RPK format - well, why would they? Nobody but the NES uses the NES cartridge format either. The NES cartridge format isn't appropriate for the TI. Conceivably it could be adapted, but that would be silly. Likewise, the NES community isn't going to let MAME dictate to them that all NES ROMs should change their file format. So it makes sense that every system would have its own file format.

I don't know that XDT can auto-build a header... if it did, there would need to be a way for you at least specify the cartridge name. Cool feature if it's there! It's trivial to add the header to your source code though... something like this will do it (assuming your start label is START). * Cartridge Header AORG >6000 DATA >AA01 * AA for valid cart, 01 is version by convention DATA >0100 * 01 is number of programs by convention only, 00 unused DATA >0000 * not used on ROM carts DATA PROG1 * address of first program information block DATA >0000 * not used on ROM carts DATA >0000 * not used on ROM carts * program information block - this is what shows in the list PROG1 DATA >0000 * link to next program (0000 means no more) DATA START * start address of program BYTE >06 * length of display name (note that it's a BYTE, not DATA) TEXT 'MYFILE' * the actual string to display EVEN * good idea to always do this after the header in case text misaligns it ;) * This takes us to >6018 END Naturally the rest of the code needs to be in the ROM space as well (6000-7FFF). To run from memory expansion RAM instead, you would need to write a little bit of software to copy it there.

Hey Rich. The discussion was limited solely to cartridges, not all software, and I was resisting attempting to make it any smarter than it is today. So we're good there.

I don't know the contents of any of the files in there right now, so I can't answer your question about which file, but obviously I'm only concerned about the metadata that describes the layout of the memory files inside the archive. My understanding was that you were trying to move that metadata into MAME itself for all known software, meaning there'd be nothing useful inside the archive itself except to MAME. Sounds like the betting on inertia is the best bet though, hehe. Thanks for the thoughts!

The synth synth really is analogous to an MP3 player, but the encoding used is really limited to voice frequencies - it does a generally poor job on music (and in fact can't even handle all voices). But it is indeed just playing back a recorded signal. I've been bugging Matt to give me the tools I want for audio.

Yes, that was mine. I took down all my YouTube videos when the rules changed six months ago or so, but I put some back up. In general I've lost confidence with YouTube and I'm tired of literally everything with audio being copyright claimed. (My own voice over was once copyright claimed.) My main channel is now over at lbry.tv, which seems to be a bit of a cesspool in general for random browsing and has very poor discovery, but they're working on it at least. It's distributed which makes shutting down or claiming videos a lot harder, so I've put more samples up there than on YouTube (since I believe they are no more than tech demos). https://lbry.tv/@tursilion:1 It looks like I did not repost that particular video at either site. It's a 2MB cartridge ROM made with an early version of the tools -- as a result it actually plays a little too slowly. When I did Dragon's Lair I fixed the toolchain to encode at the correct rate. misc_Spaceballs8.bin This is a four megabyte ROM that will play in any emulator that recognizes the banking and can play sampled sound. Doesn't look like I saved the playback video. Also, IIRC, it takes only /just/ over 2MB, so if you just crop it to 2MB for burning to EPROM, you don't miss anything important. This version is actually re-encoded with the Dragon's Lair settings, so you get the more stable dither and the correct speed playback. I also quietly stored all my demo video ROMs here: http://harmlesslion.com/temp/TI_vids/ (Edit: you can also fast forward, rewind, and pause with joystick 1 ) For quick and easy browsing, after extracting the zips you can just drag and drop the carts onto Classic99 to play them.

Do you want to post the cartridge binary, and we'll humanly auto-guess it to see what's wrong?

And IMO this was a great solution -- but are you still trying to obsolete the embedded metadata file? That was the main reason I hadn't put any urgency behind implementing them, you had announced it was going to change again. If they ARE going to stick around though, I'll happily throw my weight behind them too! I suppose I could look at history and see they /haven't/ gone anywhere, but I might as well ask while you're right here.

I love when people reply to me with "yikes"... you haven't seen me get grumpy for years. The "cart->user->open" function has to guess what you are providing it, because it needs to turn what is nothing more than a filename into the entire Classic99.ini structure that other carts get. It needs all that information - load address, size, memory type and banking type - to bring it in. It's pretty easy with the tag since that tells us memory type and banking type in a single character. We can get the size from the file size. That just leaves load address, which it guesses is >6000 cause that's usually right for a cartridge. So, it's auto-guessing. If the tag's missing, it assumes it's a 378 - non-inverted banked ROM - since that has become the standard for the FinalGROM. But that has high risk of being wrong - the filename just needs to end with a letter that matches one of the tags. I wasn't being facetious about the request for suggestions. When I do it by hand, the only way to know if I'm right is to actually run the cart and see if it works. It's very difficult to make an emulator do that, but if the tags are going to keep disappearing and we aren't going to replace them with anything, I'm open to other ideas.

More of a MAME thing to support hardware like that, but if I ever reach that point where adding hardware is simpler I can look at it for Classic99.

How do you propose it be improved? Short or trying to determine whether there is a cartridge header, WHERE the cartridge header is, whether it's the FIRST cartridge header, and then trying to interpret the executable bytes to see if they are 9900 or GPL -- all of which is tricky and/or error prone -- I have no ideas how to improve it. It's meant to simplify the loading of carts that you already know what they are, and you tell the emulator. Making it guess is never going to work 100%. As a human, there are few things we can look for that help us guess, like the addresses in the header, but ultimately, we have to try it and see if it's right. If it's wrong, we try "the other way". That's another tricky thing for the emulator to do. Instead of me spending hours on the problem, and then countless more on all the bug reports, just tag your files. It's ONE CHARACTER. It's been a system that has worked well for 30 years and also means when someone finds your file in an archive 30 years from now, they KNOW WHAT IT IS.

Screenshots...

Well, it's not a complete analysis, but MOST of the Popcart EPROMs "just work" when mapped into Classic99 correctly. The "Right" EPROM is two GROM bases, the entire memory space from >0000 to >FFFF is replaced at base >9800 and >9804. (Based on Gary's comments in the other thread, up to 8 bases are supported by the PALs, but here there are only two). The "Left" EPROM is ROM data. It seems to contain 4 pages of 8K ROM paged with our usual write-to-ROM tactic, non-inverted order. Only three of the four pages are actually used, accessed with writes to >6000, >6002, and >6004. I don't know whether the PALs echo the rest of the space like XB does. The rest of the EPROM seems to contain some code, and a simulated disk image. There are certainly FDRs and the data is laid out in 256 byte blocks, there are even the recognizable E5 bytes of empty sectors, but I didn't see the index sector. Might have missed it. The GROMs contain a DSR called "CART" so I suspect this is the data for that. It was not clear to me how to get these working, yet. The software frequently hits 9 CRU addresses - from 0x580 through 0x587 are always written in sequence. I couldn't get a clear pattern, except that it appears that 0x586 is related to turning the RAM chip on and off that Gary mentioned. (The Popcart in question did not ship with RAM, but there's an option for it in the XB3 menu, so I could toggle it at will. However, Classic99 had ROM there, and it appeared to test whether there was ROM or RAM before deciding what to send, so I only got one result). It also writes to CRU 0x780 at startup and before DSR access in XB3, but I only ever saw it set 0. To get that far, I split the right EPROM into two 64K files, and then loaded it all with this Classic99.ini. Everything except the XB3 menu (and the software underneath it) appears to work. [usercart1] name=Test Popcart (menu not working) ; loading it all appears to work, and lets the XB3 menu start (but it is still corrupt) rom0=8|0000|20000|D:\classic99\MODS\XB3_Asgard-Winkler-Birkenau-2017\XB3_Winkler_Eproms\left_AM27C010.bin ; GROM is loaded into two bases rom1=G|0000|10000|D:\classic99\MODS\XB3_Asgard-Winkler-Birkenau-2017\XB3_Winkler_Eproms\right_xaa rom2=G1|0000|10000|D:\classic99\MODS\XB3_Asgard-Winkler-Birkenau-2017\XB3_Winkler_Eproms\right_xab This readme covers my findings so far... readme.txt

I don't know about what versions are all floating around out there, but @Schmitzi posted an archive that purports to contain this same version back in April 2017. In the archive are four dumps as well as photos of the board. I haven't dug deep into the contents of the dumps, although there are a lot of duplicate files in the XB3_Winkler_DUMP folder. But the one labelled XB3_Winkler_Eproms seems to contain the dumps of the two 128KB EPROMs, and they look reasonably legit. The photos included say this is the same version that Adamantyr has.

When you only got the TI BASIC screen, you should first check the debug log to see if it recognized the cartridge type correctly. Since you didn't mention how you were loading it, I assume "auto-guess", and if you don't provide the final tag character in the filename (in this case it probably should end with "c.bin" for an 8k cart), all bets are off. It's every bit as likely Classic99 doesn't know how to load it as the header is off. If the debug log suggests it detected and loaded correctly, the next step is to use the debugger, look at address >6000, and see if it's appearing correctly there.

I suppose it can't hurt to ask. (edit: issue filed here: https://github.com/santiontanon/mdlz80optimizer/issues/10)

We have the dumps and we have photographs of the PCB, but there are four PALs that we don't know the operation of. At any rate, taking your cart apart won't teach us any more than we have. We can either reverse engineer the code to figure out how they work, or bug Gary to dump as much as he remembers. It's not at the top of my personal priority list, but it does look like a pretty impressive cart.

Classic99 399.031 Bugfix for multiple GROM bases that was preventing the OPA menu from working: - fix GROM access to console GROMs from banks larger than Classic99 supports - also mask cartridge access in those cases instead of outright rejecting the access - some future todo notes added http://harmlesslion.com/software/classic99

That's good to know, and I'm glad the MOD converted well for you! It's nice to be able to expand the MOD conversion after so many years.

It seems to have a lot of trouble understanding the output of SDCC, sadly. I wasn't able to get very far. 😕

There's more to it than just that though... the board has two 128KB EPROMs. To use them, I would need to know how the PALs split them up between ROM and GROM. I put a couple of hours into it before just using what already worked.

That's cool, there are a lot of files in there... Sound Effects are just really short audio clips, so you can make them with a tracker that outputs VGM, or by hand, or from a perl script of your own devising, or from the other sources the toolchain supports. The goal of the intermediate files being plain ASCII text was to make it easy to create input files for the compressor. There is a separate player dedicated to SFX, for cases when you want music AND SFX this is necessary for two reasons. First, each must maintain their state (unless you pause the music, but I really wanted the music to keep going in the background), and second so the SFX can keep the music off channels it is using. Of course if you are not playing music but ONLY sound effects, then just use the regular player.

This idea amuses me far more than it should... we've spent so much time using PIs to extend retro systems, it'd be hilarious to use a full PC to extend the PI. But I support VNC or Remote Desktop would provide that illusion quickly enough.