Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

190 Excellent

About Kismet

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Seems to me the logical thing would be to have the "HDMI" part of the DAC report itself to the SNT/MSG/Future-console-here via the EDID and have the FPGA devices output the native output straight to the DAC device. If connected to anything else, then just report the capability based on the NTSC/PAL switch. You shouldn't need an OSSC/XRGBMini with the DAC. But people do strange things in the name of wanting a consistent experience.
  2. The Mega SD goes in the cartridge slot, and similar to the SNES, many of the pins on the expansion connector are also directly on the cartridge bus. Like there is a reason for that, you'd normally have a BIOS/Save memory in the cartridge slot. A game like Shining Force CD can't even be played as intended without a save-game backup cart since the internal SegaCD save memory is not enough for the four games on it.
  3. Well games that use a bulky 3D game engine (eg Unity, Unreal, etc) probably have no control over the input latency. Since the PC is a crapshoot, you can't really design a game around tight input. Game consoles have their own hypervisors that likely introduce their own latency on top of the latency from the controllers. Then you have straight bluetooth controllers which would have an additional level of latency from the bluetooth stack that the straight USB would not have. The input latency wouldn't be that much compared to the render latency that is beyond your control. Some computer screens and television screens have a "game" mode that bypass the color correction, frame interpolation and energy control features (on some TV's this results the picture being brighter, but the colors blown out.) The issue however is that a 60hz panel has a frame buffer so it can do all the SmartTV features so you'll end up with an additional frame of latency so it can do this compositing. If it has to be upscaled to 4K, that's can also be another frame of latency. A 120, 144 or 240fps panel might be able to use it's interpolation feature to do a "freeze and hold" and reduce the latency so instead of 16.7mz sync, it could be down to 8ms or 4ms. But who knows if that's actually what they do. But as far as the game dev's are concerned, they're not going to test every model of TV and computer screen with every console, so if the game is laggy the blame is laid at the TV manufacturer.
  4. The cabinet owner should write up a screen play/film draft and see if he can sell it to anyone.
  5. Well there's multiple angles, but I hold the view that if you didn't make it, and don't have the right to copy it, then you don't get a say in what happens to it. Regardless. option 1, The ROM was stolen somehow. I, J random person on the internet, might seek it out, see if it works in MAME, play it for 10 minutes, and then forget about it. This is what happens to the vast majority of game ROMS, be them EEPROM's or Blueray discs. The collectors collect things, they see the value in having it, bonus if it works. They want to be the person who "has it". option 2, The ROM was RE'd from some existing code. eg someone produced a counterfeit. This is probably not the case since the collector is upset and seems to "know" it came from their cabinet. option 3, The ROM was backedup at some point , years ago, and the leaker IS the collector, and just wants to deflect attention from themselves. Like of the rare arcade things I'd be interested in, the Marble Madness sequel is the one I would probably want to see emulated. So why Akka Arrh and not Marbleman? If a tech really did "steal it" , how did they get enough time to do so? Regardless of the number of chips, how would they have known WHAT the chips were to have the right hardware to dump them? So my money is on the collector is the leaker, and he either had it dumped personally by someone, and then released it himself, or that "someone" who dumped it, kept a backup and released it themselves for whatever reason. The fact that the account connection is 2005 suggests that this could have happened 14 years ago, and the user was just waiting for a reason to. Like here's a wild possibility, what if someone dumped it 14 years ago, created a draft post on the forum, and then never posted it? And whoever posted it was maybe instead had their account hacked? Who knows. I'm kinda of the mind that if you're holding onto something that can reasonably restored, it should be restored, an arcade cabinet still has value regardless of the game it runs, but you're absolutely kidding yourself if you think you have any rights to the game software. For all intents, if Atari wanted to sell it themselves, the only thing stopping them is a finding the original software and a purpose-built emulator.
  6. Of course it's not even close, you're comparing the original hardware with specific output tolerances to a software emulator that has to be tweaked on a per-device basis. The developer certainly doesn't have 1000 different smartTV models laying around to test. This is one of the things that most software emulator dev's don't want to understand. If I, the end user are to use something, it needs to work, out of the box, and if it's to replace an existing device, it needs to meet or exceed the capabilities of the device it replaces. Nothing in Retroarch, except maybe 8-bit systems will ever come close to the original hardware in a software emulator environment. And never so out of the box. It's very likely the configuration is setup "out of the box" to run on a Raspberry Pi which has a fixed HDMI codec on it, rather than on a SmartTV device which is running it through a compositor (eg the TV can add UI layers, or PiP the video.)
  7. I just run everything at 5X. On the Master System games, there's usually still an inch of overscan space that winds up being a solid color anyway. On MD games, there's usually stuff in that space, (eg Starflight has framing graphics) but the games were designed with overscan so that information doesn't disappear. Sonic 2 is fine, but if you put it in 2-player mode, the time is half cut off on P1's half screen. Sonic 2 (Mega Drive) Starflight (Mega Drive) Phantasy Star (Master System) Ghostbusters (Master System)
  8. That is a crime, that is horribly ugly, I sure hope that's just a proof of concept. That undoubtedly uses look up tables to replace graphics at load time. eg "draw $1234 at $X $Y" , a NES, SNES, SMS, MD and any other 8-bit or 16-bit console/arcade could probably do the same thing on a per-title basis, but really, this is madness, you're basically not drawing the machine's frame buffer and replacing it with a "HD" frame buffer. Of course in the N64 emu's (where this kind of thing has been going on for a while) what they do is straight up replace the textures sent to the host GPU and leave the emulated GPU alone. 8-bit/16-bit consoles don't do texture loads so this scheme requires instead tracking the PPU/VDP data. Like in my mind this seems like something that someone would do as a proof-of-concept as as way to run old games on high resolution hardware to try to appeal to people who don't want to look at the blocky vintage graphics, but like, to quote my dad "why are you playing an old game?" (playing a pixelart game made in 2010.) If that's really what people think the appeal of pixelart is, then sorry no.
  9. AFAIK, Emulators have had "high res mode 7" way back in the ZSNES DOS days. The issue would be ensuring this would work with all carts (particularly expansion chip games) and it would deviate from the goal of having an accurate FPGA re-implementation. Though I'm also of the mind that I think if it were to possible to do a "Super PPU" , it would probably be in the same vein of "allow more sprites" features in the NES core of the mini NT.
  10. I have hardwood floors and haven't had any zaps at all in this place. At work though, I get static zaps all the time around laptop touchpad buttons. Haven't recently but that's due to a change in the humidity, as it's typically only a winter condition. I'm thinking if the zaps are brutal these might be a grounding issue. My Mega SG is plugged into the Super NT's USB power supply which is plugged into a surge protector which is plugged into a UPS (The UPS inverter circuit is toast however) though.
  11. The ideal thing would be to have per-cart settings saved, and knowing in advance which carts have certain audio or video features would then allow the user to just load those settings for that cart, instead of all of them. In the case of CD-audio, I have to wonder why not just detect the bus connection and turn it on, The same could be said for the SuperNT since the SGB and the SD2SNES are the only carts that have cartridge audio connections.
  12. These are hardware devices first and only designed to replicate the bahvior of a singular device. Complaining that it doesn't do anything else is completely missing the forest from the trees. Someone (who cares who) offers the JB as a way to add capability to the device, of which the device had to have that capability to begin with, whoever is the JB'er can't whole-cloth create a core for a device they have no documentation for. It doesn't matter if it's the same FPGA, it's still wired differently.
  13. Until the MiSTer is a commercial product that someone can buy (even if some assembly is required) that's just going to be something people buy as a hobby, as much as I think it has potential, if a good-enough fpga console game core for a device ever exists for it, it's going to end up in some cheap knockoff retron-like console. We all know this is going to happen because that's what they've done already with software emulators.
  14. My intent there was that it's more likely someone would own 1-4 of these FPGA devices that cover certain hardware groups (eg Nintendo systems, Sega/9-pin controller systems) So you don't end up with an ugly disaster that the Retron devices are. Then you piggy back all the weirdo cart types that have 9-pin joysticks/6-buttons onto the Sega group device and everything that is fine with a SNES 8-button controller onto the Nintendo one. The SNES controller bus is probably more versatile (see the NTT Data pad), so if someone wanted to they could probably make new controllers with a keyboard add-on. Likewise SNES mouse. The Amiga had mice on their 9-pin controller ports, though I'm not aware of any keyboards that did. Some kind of 9-pin to 9-pin pin converter could be made if the voltage pins are wrong for vintage hardware, otherwise I think it's not unreasonable to have new wired hardware. But I digress, A single device is also a single point of failure. Sure you might be able to play SNES games on the Mega SG if it was JB, but where do you get a controller with the right number of buttons? Likewise on a JB SNES SNT, if it can play the SG/MS/GG/SG3000/SG1000 games with a SNES pad, the button order is not right, so you'd need to be able to re-map the buttons, a minor issue, but then you create further potential for bugs just like how the flash carts "extra" features create bugs when they're turned on. Which brings me back to the Sonic 2 bugs. I played it again, but was not able to replicate the tails glitch. However I also need to point out something that I'm not sure is a bug or not. You are supposed to continue right? Well I noticed this time you couldn't always continue (since I was deliberately trying to get to the continue screen, I burned them all.) Last time, after I got one chaos emerald, it stayed with me the entire time, even after being tossed to the title screen and the only thing I remember doing different is hitting start from the options screen without having done anything on it. This time, the chaos emeralds were lost if it went back to the title screen where it didn't last time. I don't know which is the correct behavior.
  15. In all likeliness, if a JB is coming, it would probably defeat the purpose of the pin converters, but it wouldn't negate the desire of having them, since people still want to use the actual carts. If anything it saves Analogue some money in not having to make additional pin converters for systems people might not have, and might not care about. Like the SG has the 9-pin controllers, so conceivably you could put most of the early Atari systems, Commodore C64, A500 , Coleco, ZX Spectrum, MSX, Apple II, etc on it (or even put the NES on it via pin converter.) It just depends how much RAM is actually on it. Who knows if the firmware has space for that many systems though. Whoever did the SNT JB could probably port one to the other if they were so inclined but I don't really think that's a viable strategy as one of the primary motivations for having the FPGA system is not about having one system that does everything, but systems that work with your existing stuff (carts and controllers and other accessories.) A JB is just a nice to have, and people who wait for a JB before purchasing probably shouldn't own it at all. The last time I had a Sega Genesis was way back in the 90's, and it wasn't even mine. So I only recall large fuzzy TV's. I'll play it again while recording it. I did record it last time, but since I wasn't looking for glitches I didn't wait to get a screen grab.
  • Create New...