Pages: 1 2
Post: #21 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
I've heard the same people that last year(?) made a flash cart replacement for the Turbo CD have announced one for the Sega CD.
That is, a Genesis flash cart which includes a Sega CD emulator, I believe.
I think it's been said it does support being added on top of an actual 32X. So... that's getting a step closer to a 32X-CD emulator.

I had been asking for a Sega CD flash cart replacement but now that I see what it'll actually cost is quite a stinger. 250 euros.
What's that, like 300 dollars?

What I wondered is it was possible to somehow put something in the port between a Genesis and Sega CD, like a replacement BIOS to otherwise use the actual SCD hardware but load from flash instead of the CD. Wonder if that would've been cheaper than emulating the entire CD unit itself. (since as I have heard, the TurboCD was largely just a CD reader but the Sega CD had a more significant hardware upgrade)
Post: #22 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Also, putting two characters on one kanji is a brilliant idea, you say?
You know that games with lots of kanji (or more than a handful) usually use two bytes per kanji? So how is using two bytes to represent a two-character title saving space compared to one byte for one character?

Also, I thought about using two characters on tile early in my "career" but I stopped when I realized it looks like shit.
(other people say they're okay with limiting it to pairs like il and ll, but I think it still looks ugly when all other characters are evenly spaced)
Of course using VWF would fix the looking like shit part, but then you're back to the first problem.
I've only done that with the RPG Maker games where I'm FORCED to fix text within the available space (due to the specific nature that it the games are to be editable in-game and thus compatible with the in-game engine. Also because the menu text is embedded within some custom programming language. And I sure don't want to spend more time fully reverse-engineering that language so I can write a re-encoder. See that's another thing that comes up in SNES games, I heard the Romancing SaGa games did that.)
Posted on 19-07-07, 06:36 in Cool to see the shaders back in bsnes
Post: #23 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
CRT was nice, though I recall there was once an option to add a curvature frame to give the appearance of an old CRT.

I imagine it would not be feasible to add some kind of occasional-shitty-broken-RF-video-distortion option. The random warping and colors and snow, as a sort of bizarre preservation of the "how we actually saw these games back in the day when many of us could only wish we had composite" as much as the wonderful preservation of the intended functionality of the consoles.

I know byuu is crazy dedicated, unlike this crazy post.

Yes, I feel like Cranky Kong now.
Posted on 19-07-25, 23:20 in Resolutions of consoles
Post: #24 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
At least, going by the list in byuu's Twitter.

"SMS 256x240"
I thought the standard resolution was 256x192.
What I had thought was that 224 lines was only supported by a VDP revision commonly known as the "SMS2" VDP since it was more commonly found in model 2 consoles. And possibly only PAL at that. At the least, the only games reported to have used it were Codemasters games, which I believe were made only for the PAL market. (and speculation on SMS Power has been made that maybe Codemasters developed their games on a later console without being aware of the difference).
Not sure if 240 lines was even used. (was that also only PAL, or am I confusing it with the Mega Drive? I suppose it doesn't matter too much unless games used it.)
Posted on 19-07-27, 23:35 in Resolutions of consoles (revision 1)
Post: #25 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Did that thread just say NTSC gives us 256 pixels and some of the 288 pixels are lost from overscan.
Because I sure remember on the SNES not getting even the 256 pixels visible on my CRTs as a kid. Sometimes losing as much as 8-16 pixels from each edge. Probably at least 8 of the visible scanlines from the top and bottom as well.
(I recall Sega's docs told devs to consider at least 16 pixels from each edge of the "visible" screen to be potentially lost to overscan when designing games.)

I know NES did 240 lines, but I believe as RHDN has noted for its reason for accepting 224-line screenshots is that it was common for devs to not even bother managing the farthest scanline data and leave garbage there, like "nobody will ever see it anyways".
Posted on 19-08-28, 03:09 in [Famicom]Konami QT Adapter finally emulated
Post: #26 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Possibly the most obscure licensed Famicom games, and among the few remaining "licensed" games still undumped. (not sure how many "hibaihin" are left)

It was a cartridge Konami made to sell educational games to schools as add-on cartridges.
It seems four of the seven games have been dumped recently. (that thankfully includes the one Kotaku famously reported on a decade ago selling for over $4k. "This Famicom game is crazy rare and crazy expensive.")
Though it sounds like playability would depend on someone with some serious bucks willing to buy and scan the manuals which apparently have necessary information in them.

It also is the only software to use the previously unknown Konami VRC5 mapper.

I don't think I could post some links since they contain ROM links as well but I guess I can only say a certain Russian person known in the dumping scene dumped them and figured out the emulation and released a FCEUX build supporting it.
Apparently the missing part he couldn't tell a decade ago, from lacking the QT base cart, was a 64KB graphics data ROM inside that he was able to reproduce with only a 32-byte table, he said.

Though I don't know how likely higan is to support it. As I understand, byuu likes to have a real copy of the game for reference, which probably is not likely to happen with something this scarce?
Posted on 19-08-28, 16:00 in [Famicom]Konami QT Adapter finally emulated
Post: #27 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
I'm forgetting to mention, but I feel the Study Box briefly seen in the video was another similar device also mostly or completely undumped?
It was another cartridge device which used cassette tapes to load educational games.
Posted on 19-08-29, 15:10 in bsnes v108 released (revision 1)
Post: #28 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Rotation function?

Makes me wonder how you'd do Yoshi's Tospy-Turvy for GBA. :D
Will recreating the intended visual effect of this game be the A.S.P. of GBA emulation? :P

(a platformer with a gyro-sensor. The gimmick is that rotating the console rotates the direction of gravity.
I believe Yoshi's sprite rotating as the console is moved is supposed to indicate which way is straight down (as the background image doesn't change, just Yoshi and whatever other sprites are gravity-impacted), but it was just visually confusing to me years ago playing on actual hardware. It's a hard adjustment to make when, I don't know about others, but when playing portables I'm just holding the console perfectly straight and level the whole time, so my eyes are already used to viewing the screen at angles.)

My only guess to recreate the intended effect (aside from probably needing extra buttons to emulate the gyro tilt left/right) would be in a larger window with the room to emulate the tilt range from I think 90 degrees left to 90 degrees right and rotate it

I know WarioWare: Twisted was the only other gyro game, but I haven't played it so I don't know how important the view angle of the screen compared to the viewer is towards the gameplay.
Posted on 19-09-11, 14:26 in N64 emulators vs. "PJ64 v1.x" emulators
Post: #29 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Someone on RHDN making a SNES checksum calculator using 8 threads because existing ones "are too slow".
One thing to note is the author adds header support.

Why header support, I wonder? Oh yeah, probably because of Lunar Magic. I'm guessing Lunar Magic still requires headered ROMs. In 2019. Is that correct?

Headers being data added by game copiers. Game Copiers which allowed games to be loaded to the device using either a parallel port or floppy disks. Parallel ports and floppy drives both have not been produced on new PCs in over 10 years.

So why again is there an argument for headered SNES ROMs?
Posted on 19-09-30, 05:20 in GDQ Zelda II. With live music.
Post: #30 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Well, now we know how you can get the MSU-1 experience on an NES game: hire this guy to be your human MSU pack. ;)
Like the chat did, really have to applaud the pianist for being able to keep at it for the entire hour+ it took the runner to finish the game.
https://www.youtube.com/watch?v=stS0hbobbl8
Posted on 19-11-12, 06:50 in Heuristics fails
Post: #31 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Yes, we know one of the points byuu has made is that sometimes headers have wrong info. Usually prototypes but sometimes even released official games that are "supposed" to have correct info.

Just not sure if there's a practical need for a thread but I suppose.

Have seen quite a number of Genesis games that seem to have Bad Checksums as it is. Probably since it doesn't matter so much unless games have self-validating checksum code (like EA games).

I have known Zero Wing has the wrong ROM size indicated in the header (effectively indicates it is a 512KB game when it is 1MB).

But the last two games I dumped: Captain America and Two Crude Dudes. Both US releases, both Opera House-developed ports of Data East arcade games. Both used Japanese header data. That is "SEGA MEGA DRIVE" text, Japanese titles (AVENGERS and CLUDE BUSTER) but most significant for emulation, Japan-only region ID ("J"). The former it seems did not have an actual Japanese release at all. (rumored at some point DECO planned to release the separate NES game in Japan, but that is all I heard of that)
Good thing the real console TMSS doesn't care about regions. :D
Post: #32 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
It was like some weeks ago, now that I remember to actually post.

RetroPals playing some console that was kind of like, you know the LaserBirdie? Imagine if it was normal for every game on the console to have a peripheral like that. Like, they were even ahead of the Rock Band/Guitar Hero trend.
And I was thinking "emulate THAT, byuu!"
Shocked when they later said someone on MAME actually was working on it.

It's like if someone tried to out-Nintendo them at their own console, a console with motion-control gimmicks like a year before the Wii was announced. I think that was the timing.
He said it was engineered by a bunch of guys familiar with Famiclones, and the main CPU to this 2004 console was a 6502.
Which they realized was maybe a bit outdated, but that's okay because reportedly they put a 65816 in each of the carts.

Just about lost when he revealed how the cartridges were to be inserted into the console.


(hope the idea comes across. Maybe I should've put the cart near the back of the console where the ZIF actually is for proper demo)
Imagine we just take a Famicom-like cartridge and just shove it through downward into a spot on the top of the console.
It's like they took Nintendo's ZIF connector, as a solution to make a sleek 1985 console, and how can they make its 2004 analogy (you know, MAKE IT SLEEK, but hide that it uses that cartridge format like only consoles for preschoolers like the V-Smile were still using.)
Posted on 20-06-19, 13:46 in The old revision hunting preservation.
Post: #33 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
I'm assuming we had long ago determined certain revisions of games in the US set were never released.
Stunt Race FX 1.0, Mystic Quest 1.1, Fighter's History 1.0.

That is the last one I think one glaring issue people had forgotten, including me until I randomly checked while ordering a bunch of random games and noticed there was about a six month delay between the Japanese and US releases.
And then I remembered there was a good reason for that: it was certainly delayed because Capcom USA unsuccessfully filed a copyright infringement lawsuit against the game.
Plenty of time to get Rev 1 ready by the time the judge declared it no worse than any other games saturating the market.
Posted on 20-07-19, 14:37 in EA Genesis baseball games
Post: #34 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Someone on No-Intro apparently just redumped Triple Play '96 and Gold Edition.
Saying that they were not previously dumped correctly because it maps SRAM in the middle of ROM. (3 MB ROM, but the last 1MB mapped to $3xxxxx region, with SRAM mapped to $2xxxxx.) They report existing dumps just dumped the whole 4MB range.
Do non-SNES games still use Manifests? I would suppose if so it'd be simple to support that on higan (dumper saying the correct dumps are not emulated in anything)
Posted on 20-09-13, 14:43 in I've been called a SNES-hating Genesis fanboy.
Post: #35 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Old Nintendo Life article about Blast Processing.
I mention Nintendo marketing doing exactly what marketing does: twist the numbers a bit.

I explain to him things like vblank, tilemaps and the idea of not displaying the entire tilemap on screen at once (which I think high-res would do?) to have some off-screen workspace for loading map data.

Turns out I was wrong, SNES doesn't have vblank limitations and 320x224 is a commonly used SNES resolution, the NES has enough VRAM to natively support free direction scrolling (not just a single-axis), Mega Man doesn't have cheap death falls, Genesis and PC-Engine shooters aren't very popular

(Sigh) Great we got another Sega shrill who doesn’t know what he’s talking about. Buddy your numbers talk was seriously flawed and this entire comment is false and biased. There is no reason that high res mode was used only for those types of things. And no, higher resolution doesn’t mean that the program has to write more data to the VRAM, it can actually do it without having more data. And VRAM doesn’t only be written during vertical blanking and what you heard is false since there is enough time to upload a full tilemap so you can update to VRAM during one VBlank. (There isn’t one frame.)

Using higher resolution doesn’t and still doesn’t mean that video memory had no offscreen space to work since time and time again that has been proven wrong and for loading upcoming level map data for smoothly scrolling in background/sprites there are not that many limits.

(No you wouldn’t, also that was never the problem on the NES since is actual,t designed to scroll on both axis at many times. Doing to opposite wouldn’t mean to reposition all the tile map data in memory and keeping up with scrolling isn’t hard to do. And no the mega man series scrolling is irrelevant and it didn’t have slow vertical scrolling. Capcom never utilized that to create that bull you call megaman jumps.

No the majority of Snes games ran at high res of 320x224 and or more. The genesis standard resolutions were not around 256x224. Wasn’t a common standard resolution and not useful by any means for porter games. Also they didn’t use 320x224 in any game. Thats another fallacy. Nintendo has 256 colors and more and that’s not only achievable in mode 7, it’s achievable in snes hardware regardless of modes.

Again, normal commonly used screen modes didn’t have lower color counts. The snes never used 2bpp and didn’t use 4bpp. Normal tile based modes would NOT have been max 241 colors. That’s a huge downplay and you should know better. Also most of their games used many colors from their pallets and they have shown to have more color and it’s not 16 palettes. Each of those color palettes don’t have a transparency color so no it’s factually NOT only 15 that are useable.

There are no VBlank limitations and it wasn’t even a thing. You never spent any time to rewrite the (it’s not poor either) textbox routine in that game and there was no desperate need to extend the textbox. The game would never glitch out and two tiles wider is lowballing.

No you really aren’t an SNES fan if you’re actually going to be downplaying the snes and highballing the genesis like it’s your daddy. Also what you said was a lie. I’ve played many shmups and they are mostly better on the snes. Sorry but those Shmup fans are saying things false. When it comes to 16 bit shmups most people talk about the snes and play Gradius 3, Star Fox and
Super R Type. Space Megaforce is NOT the only game you heard to get a strong recommendation, you need to expand your taste buds because most shmups are better on SNES. And another thing, it does NOT seem like Genesis and PC Engine get more talk from that generation, it’s actually and factually the complete opposite. The Snes factually gets all more talk by most people in that generation and you know that for a fact.
Posted on 21-08-02, 03:50 in bsnes for Windows 98?
Post: #36 of 36
Since: 12-21-18

Last post: 990 days
Last view: 115 days
Asking for bsnes compatible with Win98 is very much the modern day equivalent of people back in the day asking for ZSNES that could run full framerate with sound on a 486 CPU (or did people ask for even older than that?).
Pages: 1 2
    Main » KingMike » List of posts
    Yes, it's an ad.