All Activity

4.49g has been fixed, it resolved mostly all strange issues I had with PBI devices. I don't know what the hack would have been, other than simply using the sdx imager utility to add items to the sdx rom/cart image

The file formats are all documented in the VGMComp2.pdf that's included in the zip (or directly at the download page). At the very end there is an example sequence of the minimum steps to compress a file for the SN, I'll refer back to that again in a moment. In this case, this is a single channel dump. There's metadata in the filename that is important for parsing it - but we can assume that it's 60hz - every one is 1/60th of a second. What's not entirely clear is whether it's a tone or a noise - only the filename identifies that. The first column is the frequency shift rate (IMPORTANT: even if it's noise!). The second column is the volume as an 8-bit ratio (where 0x00 is mute, and 0xff is maximum volume). Noise frequencies have extra flags for periodic and retrigger, but I don't see any here so you can look up the docs if you need them. When you extract a VGM, the toolset writes every channel separately, and preserves as much detail as possible so they are easy to manipulate. When you are ready to play on the SN, you need to adapt the data to fit. You can do this manually - assuming the shift rates are all legal (001 to 3ff). You can divide the volume by 16 and flip it to get the valid range, but I already have a tool in there to do all this for you (and it will map the volume to the logarithmic scale the real chip uses, and clip invalid tones). You already used vgm_psg2psg.exe to extract the VGM. (This reads SN PSG data from a VGM file). In your case you got 1 channel, but you can get all four depending on the music. To prepare it for SN playback, use prepare4sn.exe. This takes in 4 channels (three tone channels and a noise channel) and outputs a combined file with everything processed to be legal on the SN -- shift rates are verified and enforced, noise shift rates are determined and mapped to the correct noise type, and volumes are mapped into the valid range. The output file is very similar to the one you are looking at, except all four channels are on a single line. For example: 0x000B4,0x4,0x000D6,0x5,0x003FF,0x7,0x00004,0x5 Frequency, volume, frequency, volume, frequency, volume, noise type, volume - ready to throw at the chip. In your case, you only have one channel, but you can still use it. Use: prepare4sn.exe mytune.vgm_ton00.60hz - - - mytune.snpsg The "-" means "no input on this channel", so there are three. The output is whatever name you want, but I like "snpsg" to remind me this is processed for the SN sound chip. Feel free to throw a ".txt" on there if it makes it easier to read. The output looks like so: D:\work\TI\vgmcomp2\test>prepare4SN.exe x.vgm_ton00.60hz - - - x.snpsg VGMComp2 PSG Prep Tool - v20240414 Opened tone channel 0: x.vgm_ton00.60hz Channel 1 (tone) free Channel 2 (tone) free Channel 3 (noise) free Imported 27 rows 0 custom noises (non-lossy) 0 tones moved (non-lossy) 0 mutes mapped (non-lossy) 0 tones clipped (lossy) 0 noises mapped (lossy) ** DONE ** In that case, your lines will look like this: 0x00027,0x1,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x00027,0x2,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x00027,0x2,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x00027,0x3,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x3,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x4,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x4,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x5,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x5,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x6,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x6,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x7,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x8,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x8,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x9,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0x9,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xA,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xA,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xB,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xB,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xC,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xC,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xD,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xD,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xE,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xF,0x00001,0xF,0x00001,0xF,0x00005,0xF 0x0001F,0xF,0x00001,0xF,0x00001,0xF,0x00005,0xF All your data is in the first two columns - note how the volumes are now the correct values for the SN sound chip. Since you know the rest of the data is empty, you can ignore it. Note that although there are 5 nibbles displayed in the tone, that's to leave room for internal flags. You only need to care about the last four - two bytes. (One byte for the noise channel). To play it back, you need to add the command nibbles for the channel you want to play. (My compressor doesn't store that nibble to aid compression). And, unfortunately, the SN requires you to "swizzle" the nibbles. So once you have the bytes (I don't know what your sound code looks like, in C you can just write to "SOUND" if it's set up appropriately), so: const unsigned char myTone[] = { 0x00,0x27,0x1, 0x00,0x27,0x2, 0x00,0x27,0x2, 0x00,0x27,0x3, 0x00,0x1F,0x3, 0x00,0x1F,0x4, 0x00,0x1F,0x4, 0x00,0x1F,0x5, 0x00,0x1F,0x5, 0x00,0x1F,0x6, 0x00,0x1F,0x6, 0x00,0x1F,0x7, 0x00,0x1F,0x8, 0x00,0x1F,0x8, 0x00,0x1F,0x9, 0x00,0x1F,0x9, 0x00,0x1F,0xA, 0x00,0x1F,0xA, 0x00,0x1F,0xB, 0x00,0x1F,0xB, 0x00,0x1F,0xC, 0x00,0x1F,0xC, 0x00,0x1F,0xD, 0x00,0x1F,0xD, 0x00,0x1F,0xE, 0x00,0x1F,0xF, 0x00,0x1F,0xF }; // note, assuming sound chip is at SOUND and a function "waitnmi()" exists for timing void playtone() { unsigned char *pTone = myTone; int bytesleft = sizeof(myTone); unsigned int val; while (bytesleft > 0) { // wait for an NMI to happen for 60hz timing waitnmi(); // handle frequency bytes - some manipulation is required val = ((unsigned int)(*(pTone))<<8) | (*(pTone+1)); // read two bytes into int, MSB first SOUND = 0x80 | (val&0xf); // command nibble and least significant nibble of value SOUND = (val>>4)&0xff; // two most significant nibbles of value // and the volume SOUND = 0x90 | *(pTone+2); // command nibble and volume value (MUST be 0-F) // next row pTone += 3; bytesleft -= 3; } } Hopefully you can extract the missing knowledge from this. Note that this format is intended for two things: - to be input for the compression tool - to be easy to read and manipulate It's NOT intended to be a playback format. As you can see, there is a lot of redundancy and storing every 60hz tick makes the data much larger than it would otherwise need to be. You CAN do this, though... but it'd be better to use the file as input to some other tool that packs in a format you find easier to play. Not sure about the quip that I seem unwilling to help. I'm not willing to rewrite my tools for you, nor to deep dive into the web page generator (which I did not write), but otherwise I think I've stepped in where asked!

Some more info: 1.1) Colours Taken from mess/vidhrdrw/tms9928a.c in MESS, by Raphael Nabet. The first 3 columns are taken from the TI datasheet (in volts). The next 3 columns are based on this formula: Y = .299*R + .587*G + .114*B (NTSC) The coefficients are likely to be slightly different with PAL. I assumed the "zero" for R-Y and B-Y was 0.47V. The last 3 coeffs are the 8-bit values. Colour Y R-Y B-Y R G B R G B 0 Transparent 1 Black 0.00 0.47 0.47 0.00 0.00 0.00 0 0 0 2 Medium green 0.53 0.07 0.20 0.13 0.79 0.26 33 200 66 3 Light green 0.67 0.17 0.27 0.37 0.86 0.47 94 220 120 4 Dark blue 0.40 0.40 1.00 0.33 0.33 0.93 84 85 237 5 Light blue 0.53 0.43 0.93 0.49 0.46 0.99 125 118 252 6 Dark red 0.47 0.83 0.30 0.83 0.32 0.30 212 82 77 7 Cyan 0.73 0.00 0.70 0.26 0.92 0.96 66 235 245 8 Medium red 0.53 0.93 0.27 0.99 0.33 0.33 252 85 84 9 Light red 0.67 0.93 0.27 1.13! 0.47 0.47 255 121 120 A Dark yellow 0.73 0.57 0.07 0.83 0.76 0.33 212 193 84 B Light yellow 0.80 0.57 0.17 0.90 0.81 0.50 230 206 128 C Dark green 0.47 0.13 0.23 0.13 0.69 0.23 33 176 59 D Magenta 0.53 0.73 0.67 0.79 0.36 0.73 201 91 186 E Gray 0.80 0.47 0.47 0.80 0.80 0.80 204 204 204 F White 1.00 0.47 0.47 1.00 1.00 1.00 255 255 255

Here are the screens at SDX launch, first the normal SDX and then the 'hacked' SDX: norm 'hacked'

I have a set of disks for the P-Code card. They are marked with a sticker which says, "For Internal Use Only, Not For Resale." Is there any historical reason for these to be special?

I dunno the Atari VCS released in 1977 was pretty much 100% right out of the box! 😂

Double post bug caught me.

Just a company that bought or licensed the IP and rereleased it, kind of what Atari is doing today(NTSC). Also did Quest for Quintana Roo.

Kaboom! 6,751

I detected a problem when running on the real console on a CRT TV, the image does not stay fixed, it keeps rising vertically. In the emulator it works perfectly. I can't say if this is only happening specifically in my case. Have others tested on the real console?

Meanwhile, in my neck of the woods this meme is correct...

Thanks for that.

Done.

Sorry about that. Maybe a moderator can remove the attachment. I put the direct url to your site. I can't edit the post in this forum.

Love seeing card games on the 2600. Nice work!

Love the early 80s setup! I think my brother & I had that same TV with rabbit ears.

Ignoring any real or hypothetical licensing issues: Rally-X for the 7800 Bosconian for the 7800 Dark chambers 7800 (Yes, this one please!!) HERO 2600 (I suspect that there are still plenty of people out there who don’t even know about this game yet but would really enjoy it if given the opportunity to purchase it. )

As for the download link above - please don't repost my software. Would prefer to only support the latest version

That said... the TMS9918A doesn't /have/ exact colors. If you search the forum, you will find a lot of discussions, some heated, over what is "correct". But this is an analog device. The taps inside the 9918A for color were hand-set, and even the chip designer (IIRC) was not 100% sure the datasheet values are correct. After that, it runs through analog filter circuitry that varies per platform, to a display with (usually) manually adjusted settings for hue, brightness and contrast. I have the palette I use in Classic99 -- and Convert9918A will dump that palette into the configuration file if you want an easy way to pull it. But I have half a dozen other palettes that are also logically likely.

Computer bugs continuing the legacy

Plants vs. Zombies 2600.bin

Is this software emulation or a hardware thing? If it's software you can just about forget the AN0-2 bus and just process graphics data with regard to timing and GTIA mode. There's stuff like the HSync and VSync commands that software doesn't need to worry about since they're usually fixed in time. The timing also relates to palette entry changes, you should notice a single color-clock delay when one occurs.

New Rally-X Raid.bin

Rally-X Raid.bin

As always, "Read the debug log™". I should register that as the Classic99 trademark. Those numbers are the /authority/ in the INI file. If it ignored them, it wouldn't be possible to load the ROM because it wouldn't know what to do with it. (The exception being type '*', which is the same as drag and drop). That said, you're right that all bank switched types (so 8 and 9) load into an /eprom/ space, not CPU memory space, so you want to start them at 0000 unless you have a reason not to. Paging would be way off in that case. Yep. Seems a red herring. Exactly what Classic99 does (but it might be the other way around, since I implemented inverted first). Classic99 looks for a bank to start in these days. That might be causing an issue if the cart has an assumption, but generally any bank with a header is a safe bet. This is not detected. It's loading non-inverted because it believes you have told it to. In this case it's because it can't recognize 'r' as a bin type, so it falls back on non-inverted. killercater.bin does run - but are the background graphics supposed to be all blocky like that? They look corrupt. So getting it working. After drag and drop, Classic99 reports: [34204] Loading file (D:\new\killercater.bin) from disk: Type 8, Bank 0, Address 0x0000, Length 0x4000 [34204] Loaded 16384 bytes, non-inverted, bank mask 0x1 [34204] Found ROM header in page 0, setting bank. NOT REALISTIC. Everything you need for the INI file is right there in that first line: name=Killer Caterpillar rom0=8|0000|4000|d:\new\killercater.bin Type 8, address 0000, length 4000 (and the filename) With that, it works fine from the menu. Was also able to make it work from App mode. (That is kind of a fun use, now that you make me try it ). I vaguely remember that! Someone must have done a conversion at some point, cause this definitely runs as a non-inverted cart.