Kaide

The issue is that by speeding up or slowing down the system slightly changes the underlying frame rate. For the NES/SNES, you get slightly more time per frame to get input to land on a particular frame. Hard to say if that comes out as a wash or not, but it does change the skill required for certain tricks ever so slightly. For the Genesis, you get more frames per second, meaning a slower run still gets the same speed, but frame accurate timing is harder than on stock. In general, for stuff like this you want the same environment and skill bar for everyone. It’s not like runners at the olympics are given different terrain in each lane.

One thing to point out. I think FedEx has the drivers take Sunday as a rest day even if they are on the road between facilities. I’ve never seen a FedEx Ground package “move” on a Sunday in the last 2 years.

Depends on if it is delivered by FedEx or USPS (FedEx SmartPost). The latter adds a day to hand off to USPS (Monday) for Tuesday delivery. Cheaper to ship, but sucks that it adds a business day to the delivery. Sent from my iPad using Tapatalk

Not to mention that if your goal is to have them arrive within a window of 2-3 days while shipping via Ground and SmartPost services, you need to do it this way.

Your memory is right.

FedEx SmartPost from Rockwell, TX to Seattle. Sent from my iPhone using Tapatalk

I got mine this morning as well for delivery on the 26th.

While Retro-bit says it should be available as of a few days ago, they aren’t really in stock anywhere. It kinda looks like they missed their dates.

That's a fair assumption, yes. Honestly, I'm a little curious how well this will work long-term on the original hardware if they are intentionally creating a bus conflict like this. My EE is rusty (i.e. I remember enough to be dangerous), but I am a bit suspicious about the sort of effect this has. To do what Kevtris suggests means the SD2SNES would be causing higher current flow over the data bus when the SPC is supposed to have control of the data lines. What I'm rusty on is which component(s) wind up seeing the increased current, and how much tolerance is built into those components for lower resistance being seen on the data bus. It may very well be all well and good, but this certainly gets outside the intended design of the hardware. And that makes me a little nervous about how it might affect the lifespan of the hardware over the years.

Depends on what you mean by “works”? These things are mostly self contained. They only use the console for power and controller access.

Gameboy audio uses the audio pins on the cart like MSU-1 does. Since there are links to reports that 4.6 broke MSU-1 in this thread, I’m not surprised for the fix.

Of course it will be very different across games, and how they are played. But perhaps Mario isn’t the best “speed running only” sort of title. The first game in particular tends to ramp up the leap of faith jumps in later worlds, and Mario World likes to offer up challenges that make it possible for folks to exist in more than two categories of Mario player. So it’s not just speed runners that start relying on good timing. Think of it this way: For the sake of argument, let’s say that the average response time for a person is 200ms (wrong, but simple to think about), but the range in their response time is +/-100ms from that average. There’s a couple interesting cases to think about here. Consider a game where tricky parts have timing requirements around 300ms. This hypothetical means we have a person who, without any input lag, will pretty much never fail. But add in two frames of input lag, and they find themselves failing more than ~15% of the time. “Huh, that’s weird” may be how they respond to suddenly having to replay a section they usually haven’t needed to before. Or the cases where the timing required is in the 200ms range, where this hypothetical person goes from succeeding more than half the time, to failing more than half the time, again with them failing a little over 15% more often than they used to. I’d honestly love to see some material research in this space, TBH, since I’m pretty certain people’s thresholds for noticing this sort of effect will vary, and it’s obvious that you’d need to account for that person’s reaction time and deviation from their personal mean that’s possible. Keep in mind, I’m not arguing that this makes a game unplayable, or is always relevant, but I am trying to suggest that it’s possible to notice the effects of input lag without necessarily even knowing it’s the lag that causes it. As someone who grew up playing twitchier games, Sonic in particular is one game where I really notice the difference, personally. Mario I notice it in some of the later sections of the games where it starts cranking up the accuracy required.

I’d say that it’s more that the lag manifests in words differently, not that Bob can’t feel it. A speedrunner would be looking at the footage and notice the frames, and say, “yeah, this move was X frames late”. The average player will manifest it more as “Why is this <read: timing sensitive> part of the game so damn hard?” Where they may not have a reason to explain what’s going on, but they The latter is more how I experience input lag. Places where games have these sort of strict timing sensitive periods where the input lag eats away at the slop you have, leading to more “but I hit the button” moments while playing through them. That’s the real problem down the road, IMO. Will HDMI get deprecated 20 years from now and replaced with some crazy new thing? That said, a good OSS core will at least be a usable starting point for anything new on that front, though. Once you have a good, well-debugged core, you can focus more on how the PPU outputs are being handled and less on fixing the various esoteric edge cases that devs relied on for their particular games.

I’ll just add that in my case, I use my Super NT over the original now because of the issues with HDMI. The OSSC output from an SNES isn’t compatible with my TV/AVR setup that are both about a year old, and the Framemeister I have seems to also not be working, but I don’t know if it broke in the move or is outputting an odd signal. So I agree that if you go this route, you will get complaints. And those complaints will also turn to lost sales as folks don’t know if their TV/AVR is compatible or not and skip out entirely.

Yeah, I was thinking of the PSX and Dreamcast drive emulators. Ugh, I forgot just how much hardware was being exported to be available to the Genesis. It would be akin to creating an FPGA SA-1 setup, adding the audio/SRAM features, and bringing your own BIOS on top of that. I couldn’t find much detail online, and I’m a little busy to go do a dive on one of my Sega CD games to find out, but I’m a bit surprised that they don’t include drivers on disc like Sony would. Unless they were really just that strapped for memory then, which is possible. That said, a lot of the drive control doesn’t need to be handled by the BIOS directly unless your goal is to replicate the hardware exactly. The main reason to control the drive directly is to cut the cost of the add on. But if your goal is to be able to use an off the shelf laptop drive of some kind, then a good chunk of this is handled for you in the drive firmware. The BIOS in that case would mostly be involved in passing along the requests to the drive firmware over SATA or the like. Since timing of disc seeks can’t be expected to be perfect, you can probably lean into that to make this work, and avoid writing what amounts to your own drive firmware into the BIOS you are writing. These days, you’d probably have to go this route anyhow, as custom drives without their own SATA-based controller firmware are getting rarer. Your argument is sound in the in the sense that the amount of hardware here that the game has direct access to is daunting enough to be its own console worth of work. But I still don’t think the BIOS is the dealbreaker here. We still are talking about fairly simple electronics compared to today’s kit, and Connectix wasn’t exactly a big company when they reverse-engineered the PSX BIOS with a clean room implementation in under a year. The difference is that Connectix could pay someone to come in and do the dirty work to write the spec for the BIOS, and then have one of their own employees in the “clean room” implement it, on the assumption VGS would make them money. The OSS community doesn’t really have that carrot to dangle in front of people good at reverse engineering, per se. Analogue hasn’t had to deal with clean room implementations up to now either, which would be something they’d have to learn and get right, but there’s plenty of precedent to follow there. But my whole argument at the end of the day was really that the BIOS is not the sword of Damocles that sinks a project like this, and I stand by that argument. I didn’t mean to insinuate that it was something you could slap together in a weekend or a couple months, but more that the BIOS doesn’t have to be an exact replica here to be useful. It just needs to be compatible. I’d even say that even if someone managed to write their own Sega CD BIOS for original hardware, you are still stuck writing your own ATA driver, so you could use drives available today.

And of course, when you can use CAV mode, there are advantages to laying out the disc from the outer edge inward (OG XBox). What is the menu system in the NT Mini and Super NT but a form of custom software, similar to a BIOS? I would argue it doesn’t defeat the purpose at all to have to write your own BIOS, but it certainly adds work to the task. Copy protection in this era isn’t terribly sophisticated. Sega CD has no protection at all. It depended on the difficulty to copy the discs. PlayStation’s copy protection is also rudimentary, relying on data in a part of the disc that could not be written on a CD-R and nothing more. In the case of VGS at least, they implemented copy protection in their BIOS, and it was one reason why Sony’s legal arguments were so weak. Further, the BIOS in these early systems (except maybe the NeoGeo, I haven’t delved much into that one personally) was more of a bootloader. On the PS1 (and PS2, PS3 and PSP) the games came with specific versions of the hardware drivers and bootstrap code. This meant you could have dozens of BIOS versions for various reasons, without worrying so much about breaking compatibility with existing titles. At the end of the day, a Sega CD clone could be made fairly easily, and the BIOS in it doesn’t need to be 100% identical to be useful. Precisely because so much control is handed off to the game itself once it loads. The catch is the effort to do it legally and have a market, you are also competing against used models that when I bought mine could be had for 70$ in good shape. As the used versions wear out, and parts are harder to come by for repairs, the economics start skewing towards some sort of clone of the drive. And if your goal isn’t to play the original CDs, then you might go with a “CD Rom Emulator” backed by SD cards, to cut down on mechanical parts that will wear out. Hasn’t someone already done that? I could have sworn that mod exists. Maybe I’m thinking of a different console that got that mod. Two things: 1) If you are making custom hardware, you have a lot more control over the drive modes than you do as a user-land process running in Windows/*nix. 2) I suggest reading up on this stuff a bit more before making claims like the quoted. None of the quoted is accurate.

Both Bleem and Connectix Virtual Game Station avoided that issue. VGS in particular reverse engineered the BIOS. I assume Bleem did too, but my knowledge of their history is a little fuzzier. And both were effectively beating Sony in court, minus that whole war chest thing. Count me in that sort of market. But part of it is to avoid the level of mods you need for a CMVS in order to keep modern HDTVs happy with the output coming off the system. Especially since there’s a lack of compatibility information for some of the existing pre-made CMVS systems. One of the harder topics to google and get reasonable answers about in this hobby.

I may have even run across your post when I was troubleshooting the problem on mine. It was likely what prompted me to try my Model 1, and realize that worked. Yeah, even if it was feasible in the sense of being able to do the work to replicate the behaviors, there's no telling if the space on the FPGA is even available to fit two SH-2 cores on top of everything else. The more I think about it though, the more I realize that 32X support is caught between a rock and a hard place: To use the existing 32X peripherals, you must support RGB analog output that is within the Genesis spec (240p) enough that the 32X can consume it and composite on top of it correctly. So I think using the DAC module may be out of the picture unless plugging it in bypasses the HDMI output in some way, or otherwise enables 240p RGB output. To bake it into the FPGA, you are talking about considerable space. Two ASICs, two SH-2s, plus DRAM/etc. With a big enough FPGA, you could probably do it. But without knowing details, I think it's very difficult to say if the Cyclone V used in the Mega SG can do it, or even if any FPGA in the price range they need for this price point would do it. I wouldn't be surprised if the 32X doubles the amount of space needed in an FPGA, if not more. In other words, it's possible, but there's very little wiggle room in the engineering sense.

Polygon has a more complete quote: We'll see how quickly they do pull the trigger on the DAC. But I don't think this is gonna be the panacea for 32X like you may be hoping for. It may wind up working with the right adapters to feed the output into the 32X, but I personally would be expecting some compositing bugs (hopefully just minor ones) since the DAC is feeding off the HDMI signal and not the raw RGB, AFAIK. If the FPGA space is available, I suspect handling the 32X behavior at that level is probably going to be more reliable, and easier to avoid some of the compatibility glitches the real 32X hardware/carts have. The fact that Chaotix tends to lock on up on my VA4 Model 2 Genesis boards is unfortunate, for example, as it's one of only a couple games I actually care about on the 32X. I still need to get a good cable that lets me work with stereo + RGB over SCART on my Model 1 Genesis. It was enough to kinda turn me off from collecting the 32X as a platform. I'll be honest, I probably would too. Mine still works, but it would be nice to have some fresh hardware that isn't quite as big.

I have noticed some bugs/glitches that only seem to appear with the original cart, and not SD2SNES. Which suggests there's some potential issues with specific carts that need cleaning. In my case, I hit some nasty sprite glitches with the candles (and eventually more things) in Castlevania IV, but my SNES Classic ROM via SD2SNES worked fine.

I think it still varies based on the upscaler in the TV. I currently play at 720p on my Sony OLED using hybrid scanlines. Will need to play a bit with the 4.3 firmware, but 720p hasn't had any real problems upscaling 720p in terms of softness or the like. It's a bit weird that a 4K set would make hash out of 720p though. You'd think being an integer scale would make things easier.

I'll add that we played through most of TMNT IV with two wireless controllers without any real complaints to be had. Didn't notice the interference, but we put quite a bit on the 5Ghz band in our home, so that may be helping. Good to know. I was a little surprised to see it, and was hoping it was just a trick of the light. I got the SFC style, so I haven't seen the Classic style in person yet. Huh, that makes me wonder if the memory space isn't big enough for ROMs that gigantic. Or if there's just a bug with that size ROM. But considering the smaller size of the pack-in titles, and no shipping titles being more than 48Mbit, I wouldn't be too surprised if it just didn't devote enough memory to hold a 96Mbit ROM.

Yeah, "good enough" territory. I'm a little surprised that Nintendo didn't address the limitations that made it a no-go to use a PAR of 7:6 with the SNES, really. This adds some context that makes it a bit easier to understand what you are trying to say. But this is also why us old folks (at least those who've dabbled in signal processing and video) refer to PAR and DAR as different things. In this case, I almost want a third term like "buffer aspect ratio" so that it's easier to explain that PAR * BAR = DAR, and that they are all related to one another. But I just want to point out that the bit that stuck out at me was when you said "think you're talking about 8:7 pixel AR", which made me go "what?". I actually went to re-read sources because it contradicted everything about the math you also presented, and I thought I had misunderstood something fundamental about the NES/SNES pixel processing. But honestly, I'm not entirely sure you can easily get the average Joe/Jane to understand what's really going on without at least introducing the concept of non-square pixels. Was a flash used on this? That white seems brighter than intended on the Super NT?

Yeah, Im in a similar boat. Had mine longer, and itd be nice to not need the cart for translation patches, but itd be rough losing the titles the flash carts support that this jailbreak doesnt. And the height/width bug seems nasty. Id need to play with that a bit. Except to hit the target aspect ratio, there is no fundamental difference to pixel AR when talking about this adjustment. That might be why it goes downhill, if you are working from a different definition of the term from others. No, the SNES doesnt use square pixels, and yes it can maybe be a bit weird that the buffers height/width in pixels is a 8:7 ratio (256/224), while the pixel aspect is also 8:7. But the end result of the final image with a 8:7 PAR is a 64/49 ratio, or 1.306(...) which is what the SNES uses.

This is the one 32X game I actually kinda wanted to complete, but my particular Model 2 VA4 doesn't like it (it crashes early on like others have reported on some minority of Model 2s), and I don't like the title enough to keep hauling out the Model 1 to hook it up.