krikzz MD Pro features announced

[Pyroptotic]

@turboxray: I had replied to you yesterday but for some reason, my post didn't go through. Luckily, I was editing it in a local text file so I was able to recover it.

4.1 Should be the method that syncs/genlocks the cpu to the VDP.

Yes, indeed. The timings constraints to fit a 31 colors DMA transfer in-between consecutive scanlines are very tight so it's necessary for the CPU and VDP to operate in lockstep at all times. I forgot to mention this particular detail in my original post but no H/V interrupts are ever involved with this trick. While a MegaColor image is being displayed, the 68K runs inside an infinite loop that either busywaits on the H/V counter until it reaches the value that signals the start of the next frame (at scanline #16) or use dummy write operations to the VDP data port to sync on the 288th pixel of the scanline (this works because the 68K bus is locked until the operation comes through and it can fit exactly 16 of those while 288 pixels are drawn).

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?

Each scanline is divide into 4 strips of 9 tiles (or 72 pixels). A single color palette is statically assigned to each strip. In other words, the palette assignment in the tilemap looks like this (where each tile is represented by a single character).

Line 0: 111111111222222222333333333444444444
Line 1: 111111111222222222333333333444444444
Line 2: 111111111222222222333333333444444444
...
Line 190: 111111111222222222333333333444444444
Line 191: 111111111222222222333333333444444444

Colors of palette N only appear in column N except for the background color which is shared across all columns. So each strip of 9 tiles receives 15 unique colors in addition to the background one.

At the end of every scanline, 31 colors are replaced in total. On even scanlines, palette 1 & 2 are replaced and on odd scanlines, 3 & 4 are replaced (via DMA to CRAM). Consequently, for either half of the screen, palette pairs are shared across two consecutive lines. In the following diagram, each letter represents a unique set of 15 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 ...


Thus, you can convert a standard RGB image to MegaColor format simply by splitting it into strips of 72x2 and performing color reduction on each individual strip. I hope the diagrams make my explanations slightly clearer!

[Pyroptotic]

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).

I had not noticed this, thanks for the info. That's not due to a limitation of the algorithm itself, however. I assume the best possible choice for a background color is the dominant color of each pair of lines but it can also make sense to set a static background color for the entire image such as black. Singling out a single color for each pair of lines likely complexify the color reduction algorithm so maybe that's part of the explanation.

[axel]

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.

Thank you for explaining it, that is a clever way to store the frame and not at all what I expected from looking at it.

[turboxray]

@turboxray: I had replied to you yesterday but for some reason, my post didn't go through. Luckily, I was editing it in a local text file so I was able to recover it.



Yes, indeed. The timings constraints to fit a 31 colors DMA transfer in-between consecutive scanlines are very tight so it's necessary for the CPU and VDP to operate in lockstep at all times. I forgot to mention this particular detail in my original post but no H/V interrupts are ever involved with this trick. While a MegaColor image is being displayed, the 68K runs inside an infinite loop that either busywaits on the H/V counter until it reaches the value that signals the start of the next frame (at scanline #16) or use dummy write operations to the VDP data port to sync on the 288th pixel of the scanline (this works because the 68K bus is locked until the operation comes through and it can fit exactly 16 of those while 288 pixels are drawn).



Each scanline is divide into 4 strips of 9 tiles (or 72 pixels). A single color palette is statically assigned to each strip. In other words, the palette assignment in the tilemap looks like this (where each tile is represented by a single character).

Line 0: 111111111222222222333333333444444444
Line 1: 111111111222222222333333333444444444
Line 2: 111111111222222222333333333444444444
...
Line 190: 111111111222222222333333333444444444
Line 191: 111111111222222222333333333444444444

Colors of palette N only appear in column N except for the background color which is shared across all columns. So each strip of 9 tiles receives 15 unique colors in addition to the background one.

At the end of every scanline, 31 colors are replaced in total. On even scanlines, palette 1 & 2 are replaced and on odd scanlines, 3 & 4 are replaced (via DMA to CRAM). Consequently, for either half of the screen, palette pairs are shared across two consecutive lines. In the following diagram, each letter represents a unique set of 15 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 ...


Thus, you can convert a standard RGB image to MegaColor format simply by splitting it into strips of 72x2 and performing color reduction on each individual strip. I hope the diagrams make my explanations slightly clearer!

Nice!! I definitely appreciate the info. That's interesting. I would have thought that kind of pattern would have shown more artifacts than simply using two palettes per line setup.

[GameUser-16-32-128]

The NES option was really unnecessary. I bet without out it, he could've shaved off a bit of the price of the MED Pro. The current price is still competitive, but since I only have a CDX...

[Sik]

I'm going to assume that most of the extra hardware is idle when the Mega CD part is not in use and the NES support works by repurposing it (in short, it really shouldn't affect the hardware's cost, I imagine?).

[EPSYLON EAGLE]

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.

Thanks!

[Black_Tiger]

The Everdrive Pro mapper does sound similar to MSU1 now.

Like MSU1 though, it's a neat bonus I'll gladly accept if I end up with a flashcart that has it, but the software that makes use of it will be a novelty.

I'm glad that these kinds of upgrades so far mainly encourage people who might not be able to develop new games to do things like add CD doundtracks. I'd hate to have something that essentially creates a new 32X like format which could draw people away from creating new homebrew or specoal hacks for games that run using only original hardware.

[zilogandmoto]

I know I'm going to end up buying one of these at some point, but every time I go to look at it and I see almost $200, it's hard to cough it up. That's two, good condition, uncommon games that I still need.

But I definitely eventually want it, for nothing else than being able to hear the alternate FM Master System audio.

[IrishNinja]

upgraded my SNES NES & SMS everdrives on the black friday sale this year, couldn't say no to improved savestates...idve done the same for this one, but as someone who likes leaving the 32x plugged in, still sucks that the feature can't really work properly with that setup. no idea what kind of workaround would be needed for it, but i stay hopeful.

[roce]

The Black Friday -20% sale ends today, maybe already ended. So you may be too late to get one at a discount this year.

[Zeus]

Doom port on a stock Genesis?


https://t.co/Xw0CrkVtgq?amp=1

https://twitter.com/krikzz/status/13...031061508?s=20

[roce]

Haha, frames per minute

[eeplox]

I was waiting for the sale all year but completely spaced and missed it.

[slider1983]

Does anybody know if Krikzz has added support yet to allow the Pier Solar CD to run with the cart? I believe that was a feature the Terra Onion Mega SD had which people complained the MD Pro didn't have?