Joe I was asking over on the Everdrive forums and they said for the FM master system sound you need a master system Bios. I am still waiting for delivery for my Everdrive pro, I was just thinking it would be great to replace The Sega CD Terminator fmv sequences in the game for the higher colored versions but dont know if that would be possible.
I was the one who pointed out to Krikzz that the smsbios needs to be present. He has already fixed the issue in a firmware update.
On that note, thanks for reminding me:
Apparently you need to set up something before it'll work at all (in particular, make sure the BIOS is present or it'll refuse to enable mode 1). This may catch people off guard since one of the interesting features of MSU-MD is that it does not rely on the BIOS, so it may be tempting to try loading a MSU-MD game without setting up one (which will not work). Whoops.
The ROM header part still applies, so you may still need to hack the ROM header on top of that.
What do you mean by making sure a BIOS is present? I have a BIOS for each CD region on my SD card, but the one Mode 1 game I have refuses to work on the Mega SD after the January firmware update, but it does work somewhat on the Mister. Sometimes at random the music won't start with a new zone, but it's not consistent. On the Mega SD it's just sound effects.
My Collection: http://vgcollect.com/zetastrikeOriginally Posted by A Black Falcon
Just going by this tweet:
https://twitter.com/WaferMouse/statu...94648938000385
Seems like there's a separate BIOS setting for mode 1?Long and short of it: MegaSD users need to make sure they set up a BIOS to match the region they select in the "BIOS for MD+ & AudioCD" setting.
Hi everyone!
First time poster but long time lurker. A friend of mine told me about this new Megacolor effect and I must say I was thoroughly impressed by the quality of video playback that is now possible to achieve on the Genesis when bandwidth and capacity constraints are being lifted off with the help of a custom mapper. I felt compelled to have a closer look at it so I disassembled the example ROMs. I'm really no expert on the technicalities of the Genesis so I'm hoping that people with more knowledge than me can chime in and bring additional precisions. Anyway, here are my findings in case anyone attempts to replicate a similar effect on his/her own or try to improve on it. Most of what I'm about to say is already known by now I guess so you can see this post as independent confirmation for what it's worth.
I mainly concentrated on the mechanics involved in the display of a single frame rather than the task of uploading the frames at 30 fps for FMV. From what I gather, the name table data is static and uploaded only once during initialization. The name table consists of four columns of nine tiles each, for a total of 4 * 9 * 8 = 288 pixels of horizontal resolution. Each tile column uses a different palette (column 1 = palette 1, column 2 = palette 2, etc), for a total of 60 + 1 colors (incl. background) per line. Only CRAM data is being streamed in by DMA during active display. On each line, two color palettes get replaced in alternance, for a total of 31 new colors per line (palette 1 & 2 on even lines and 3 & 4 on odd lines). Thus, 31 colors are reused from the previous line. The DMA operation is timed with the help of 16 dummy writes to the VDP data port and a few additional NOP instructions. Then, the display is disabled, the DMA transfer CRAM operation is initiated and the display is re-enabled immediately after. Every frame, the first 16 lines are skipped by busypolling the H/V counter, then 192 lines are processed as explained above and finally, the display is disabled until the next frame. This is probably done to leave enough room to update 288x192 pixels worth pattern data at 30 fps, but as I stated above, I didn't look at the details of the FMV player itself.
So here's an outline of how each frames are processed by Megacolor:
1. Disable display
2. Wait until the H/V counter hits 0F00h
3. Enable display
4. Loop 192 times
*** 4.1. Delay DMA with 16 dummy writes to VDP data port and some NOPs
*** 4.2. Configure DMA transfer of 31 colors to CRAM (palette 1 & 2 or 3 & 4)
*** 4.3. Disable display
*** 4.4. Initiate DMA transfer
*** 4.5. Enable display
5. Goto 1
Hopefully, this helps removing some of the mystique surrounding Megacolor. I can provide further details if anyone is interested. And finally, thanks to Raijin Z aka Mister Xiado for helping me out with profile activation!
No matter what I do I can't get that ToeJam & Earl Panic on Funkotron "MSU" game to work. Just boots to the Sega CD screen. Game never runs. I'm guessing liekly because I don't have the obscure ROM that the IPS patch file wants. Don't know which one it wants either because the download link is long gone so I don't have access to the readme. Does anyone happen to know which ROM file I need? I'm not sure why people don't just include the ROM file with their projects. They are already including copyrighted audio, why not the game itself too? Does it save you from jail somehow?
EDIT: I can get it to work with Mega SD but not Mega Everdrive Pro.
Last edited by Joe Redifer; 07-30-2020 at 12:48 PM.
4.1 Should be the method that syncs/genlocks the cpu to the VDP.
Also, from what I saw of the artifacts, it looks like palette groups divide the screen in half. I.e. On a given scanline, the left half (0 to 144?) is one palette, and the right half (144 to 288?) is the other palette. I haven't looked in the debugger, but the artifacts from what I've seen align up to that (and it makes sense). Are you saying they're using the non-updated group of two palettes on the same line (sprinkled through out) in an attempt to remove artifacts? Did you confirm this?
The Mega Everdrive Pro mapper, as fas as I understand, provides "acceleration" in the sense that it allows bank switching across a huge swath of memory (at least, by 90s standards).
The space required to store an individual MegaColor frame is:
Palette data: 2 bytes/colors * 31 colors/line * 192 lines = 11904 bytes
Pattern data: 288 * 192 * 0.5 bytes / pixel = 27648 bytes
Total = 11904 bytes + 27648 bytes = 39552 bytes/frames
At 30 fps, each second of MegaColor FMV requires 39552 bytes/frames * 30 frames/sec = 1186560 bytes/sec = 1.132 MB/sec
To put things into perspective, the Sega CD drive speed is 1x (150 KB/sec) so displaying a MegaColor FMV at 30 fps requires ~7.7 times the amount of bandwidth that the Sega CD can possibly provide. If you instead opted to store a MegaColor video on a standard 4 MB cartridgge, the bandwidth would be sufficient but the video could only last up to ~3.5 secs. In other words, it was not reasonably possible to achieve MegaColor level of quality FMV on the Genesis with the storage technology that was available back in the day.
As for displaying MegaColor frames via the Genesis VDP, the Mega Everdrive Pro does nothing to accelerate this. It's all clever programming and careful timing of instructions and DMA transfers. Games from back then could have used this trick to display high quality stills, etc.
Yes, I believe so. The timings are pretty tight to initiate/complete the DMA to CRAM in time for the next scanline so it is indeed necessary for the CPU and VDP to be in lockstep at all times. I did not mention this particular detail in my original post but no H/V interrupts are ever involved. The 68K is processing an infinite loop while the MegaColor frames are being displayed, either waiting for the H/V counter to reach a certain value to signal the start of a new frame or doing dummy writes to the VDP data port to land a perfectly timed DMA transfer to update color palettes.
Each scanline is divided into 4 strips of 9 tiles (or 72 pixels). Each strip uses its own 15 color palette. The palette assignment in the tilemap looks like this (where each tile is represented by a character).
Line 0: 111111111222222222333333333444444444
Line 1: 111111111222222222333333333444444444
Line 2: 111111111222222222333333333444444444
...
Line 190: 111111111222222222333333333444444444
Line 191: 111111111222222222333333333444444444
Colors of palette N only ever appear in column N except for the background color which is shared across all columns. In other words, each strip of 9 tiles (72 pixels) is assigned 15 unique colors in addition to the background one.
Immediately after each scanline (288 pixels), 31 colors are replaced in total via DMA to CRAM. On even scanlines, palettes 1 & 2 are replaced and on odd scanlines, 3 & 4 are replaced. Consequently, palette pairs are shared across two consecutive lines.
In the following diagram, each letter represents a set of 15 unique colors. A, B, C & D are the initial state of palette 1, 2, 3 & 4 respectively.
Line 0: AAAAAAAAABBBBBBBBBCCCCCCCCCDDDDDDDDD At end of scanline, replace palette A & B with E & F
Line 1: EEEEEEEEEFFFFFFFFFCCCCCCCCCDDDDDDDDD At end of scanline, replace palette C & D with G & H
Line 2: EEEEEEEEEFFFFFFFFFGGGGGGGGGHHHHHHHHH At end of scanline, replace palette E & F with I & J
Line 3: IIIIIIIIIJJJJJJJJJGGGGGGGGGHHHHHHHHH At end of scanline, replace palette G & H with K & L
Line 4: IIIIIIIIIJJJJJJJJJKKKKKKKKKLLLLLLLLL At end of scanline, replace palette I & J with M & N
Line 5: MMMMMMMMMNNNNNNNNNKKKKKKKKKLLLLLLLLL ...
So, to convert a 288x192 RGB image to MegaColor format, you would first split it into strips of 72x2 and perform color reduction on each strip individually.
Yeah, it's feasible for stills (less than 39KB isn't so bad, could be even decompressed to RAM), just not for FMV :P
One thing that was overlooked in that description is that background color seems to be always black, it's not part of the streamed palettes (which means black is always available anywhere on the picture and doesn't otherwise take a color slot in one of the palettes).
There are currently 1 users browsing this thread. (0 members and 1 guests)