Pages: 1 2
| KingMike |
Posted on 19-06-17, 21:35 in 32X CRAShTEST: the mushroom of doom strikes back!
|
|
Post: #21 of 36
Since: 12-21-18 Last post: 1207 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) |
| KingMike |
Posted on 19-06-20, 19:35 in Why is ROM translation so (technologically) hard?
|
|
Post: #22 of 36
Since: 12-21-18 Last post: 1207 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.) |
| KingMike |
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: 1207 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. |
| KingMike |
Posted on 19-07-25, 23:20 in Resolutions of consoles
|
|
Post: #24 of 36
Since: 12-21-18 Last post: 1207 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.) |
| KingMike |
Posted on 19-07-27, 23:35 in Resolutions of consoles (revision 1)
|
|
Post: #25 of 36
Since: 12-21-18 Last post: 1207 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". |
| KingMike |
Posted on 19-08-28, 03:09 in [Famicom]Konami QT Adapter finally emulated
|
|
Post: #26 of 36
Since: 12-21-18 Last post: 1207 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? |
| KingMike |
Posted on 19-08-28, 16:00 in [Famicom]Konami QT Adapter finally emulated
|
|
Post: #27 of 36
Since: 12-21-18 Last post: 1207 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. |
| KingMike |
Posted on 19-08-29, 15:10 in bsnes v108 released (revision 1)
|
|
Post: #28 of 36
Since: 12-21-18 Last post: 1207 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. |
| KingMike |
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: 1207 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? |
| KingMike |
Posted on 19-09-30, 05:20 in GDQ Zelda II. With live music.
|
|
Post: #30 of 36
Since: 12-21-18 Last post: 1207 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 |
| KingMike |
Posted on 19-11-12, 06:50 in Heuristics fails
|
|
Post: #31 of 36
Since: 12-21-18 Last post: 1207 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 |
| KingMike |
Posted on 20-03-04, 22:47 in I had not heard of the Xavix console until somewhat recently
|
|
Post: #32 of 36
Since: 12-21-18 Last post: 1207 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.) |
| KingMike |
Posted on 20-06-19, 13:46 in The old revision hunting preservation.
|
|
Post: #33 of 36
Since: 12-21-18 Last post: 1207 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. |
| KingMike |
Posted on 20-07-19, 14:37 in EA Genesis baseball games
|
|
Post: #34 of 36
Since: 12-21-18 Last post: 1207 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) |
| KingMike |
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: 1207 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.) |
| KingMike |
Posted on 21-08-02, 03:50 in bsnes for Windows 98?
|
|
Post: #36 of 36
Since: 12-21-18 Last post: 1207 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
