Jump to content

Kismet

Members
  • Content Count

    494
  • Joined

  • Last visited

Posts posted by Kismet


  1. There's always the option not to upscale and let people hook up their favorite thing to it. While many would complain of the lack of HDMI, it would be good to get an open source core out there while we wait for cheaper and larger FPGAs to become available.

    You'd still need a DVI-I or HDMI output anyway to send it through an upscaler, but HDMI does not support anything below 640x480p60. A DVI-A to VGA works in this case BUT VGA may not support 15Khz either.

     

    But the problem is, SNES and NES aside, if you are dealing with a FPGA device that can output multiple consoles, is going to be a problem that isn't futureproof in the slightest. 4K monitors do not come with VGA inputs, 4K TV's may or may not have any analog inputs on them depending on your part of the world. So it comes back to being able to produce a device that people can use without having latency-adding boxes.

     

    At any rate. I think kevtris is definitely on the right track, but 4K is ultimately going to be a problem one way or the other. We may not have a FPGA solution for 4K ($9000 for such FPGA's) and may need to press on TV manufactures to do line-by-line pixel scaling, and not these gross bilinear buffer filters. If you read one of Altera's solutions for doing this:

    https://www.altera.com/products/reference-designs/all-reference-designs/broadcast/ref-4k-video-upscaling.html

     

    You actually see that what they do is concat 4 1080p streams horizontally. But they use a buffer.


  2. Yup my order number was #3000 something so I didn't think I was that far down the list. Maybe they were worries about sitting on too much product

     

    That's interesting actually, because the JB firmware was basically a surprise, and that might have sent more people to see a better value in it than simply a $450 NES.

     

    (Many discussions immediately after the NT mini was released but before the JB firmware poohpoohed the NT Mini for being twice as expensive as the RetroUSB AVS, and 9 times the cost of the NES Classic (assuming you could find one) or the Raspberry Pie (which costs what? $10)

    • Like 1

  3.  

    Their could be copyright issues for a FPGA Core on a SNES,

    SNES and a lot of it parts which could of been designed by FPGA which would add a copyright along with the patent

     

    Which would mean if someone designed a FPGA it could fall under a Derivative Work

     

     

     

     

    Believe the above is stopping people from releasing a public FPGA since it unknown if it copyrighted and difficult to track some of the parties down

     

     

     

     

    At least one project uses a WDC sourced CPU core, and for all intents, we don't really know what the Japanese one did, almost seems like they just guess-and-checked.

     

    If you run http://pgate1.at-ninja.jp/SNES_on_FPGA/through a machine translator, it sounds like this one was designed without probing an original SFC, Note the date started was 2005. They now appear to be working on the expansion chips in 2016.

     

    Incidently, if you read the note around this video

    It says SNES FPGA with original SPC, because it's a DE1 dev board with no room for it.

     

    A note later in the page says that they would need two DE1's and that just seems too expensive.


  4. What FPGA cores run SNES with the required accuracy?

     

    There are at least 3 known projects/attempts at this and I linked to them earlier. Until such time one of them is publicly available, we just have to take it at the developers word that it's correct.

     

    In the case of jwdonel's VeriSNES, that's not his first crack at a FPGA emulator, but this is the first one that nobody else has published a working FPGA hardware core for. At last I checked he had not implemented sprites or color math (transparency.) We only know that the other two worked to some degree because the developer told us so, and in the case of the one with a video, they actually have a posted fitting report http://pgate1.at-ninja.jp/SNES_on_FPGA/rpt_DE2-115.htm, so we do have some idea how much space on a FPGA is required for the SNES alone, but not enough to include upscaling like in the NT Mini. The Z3K proposes to do this by putting that upscaling logic into another chip. But note that all of these were built on devboards on much larger FPGA's. The DE2-115 is actually a $600+ board with a $350 FPGA

     

    You can see what FPGA is needed for upscaling in the OSSC already https://www.niksula.hut.fi/~mhiienka/ossc/diy-v1.3/bom_v1.3.xlswhich is the EP4CE15E22 (Cyclone IV E, 15408 LE), so if that much is needed to upscale to 1080p without a frame buffer, than you can be sure that the 28,417 LE needed on a Cyclone IV E for the SNES combined needs around 44K total, of which kevtris already said he wants to use a 49K FPGA for the system and a max10 for the scaler. So if you need 16K LE for this, the cheapest MAX10 with that amount is $34 for 10M16SAU169C8G. The next one up is 25K LE and $49. Now assuming that the SNES was the maximum thing that you wanted to fit, and you wanted to do the same thing the NT Mini jailbreak does, that means the SA1 would have to be emulated which is another CPU, so going back to that fitting report, the CPU alone is 2160 LE. Then we have to consider things like the Sufami Turbo games, DSP chips, CX4, BS-X, MSU-1, and Super Gameboy. To be able to do any one of these devices requires emulating at least one extra chip. Probably the only game that might not be doable in a FPGA is the one with the ST018 chip.

     

    But going back to the point of the question, short of someone uploading raw video comparing games running on the real SNES to the complete FPGA SNES we won't know how accurate they are, yet.


  5. Which emulators and games are unplayable? On a moderate to fast desktop.. Nevermind the R-Pi things.

     

     

    Look at what CPU's are in everything. Unless you're willing to buy a $2000 PC, what you're typically getting are 1.6-2.0Ghz dual core systems that are about 1/2 to 2/3rds the performance of the performance point you need to run Higan, it's very likely that no available laptop or desktop CPU can run Higan at more than half the speed. Most of the games I throw at it top out at 45 frames per second and I have an i7-4770.

     

    SNES emulators have been out since the 90's. The accuracy and compatibility back then was pretty bad. While these legacy emulators (ZSNES, Snes9X) compatibility have improved since then, they still resort to the same timing hacks that were needed in 1999.

     

    Which is I have to keep mentioning the problem is that many of the people who play games on these, have no idea that's not how the game is supposed to behave. One of the more earliest attempts at running a SNES emulator that I remember was to play the FFV translation, but because ZSNES at the time didn't have 16-bit color mode, you'd get into the ship graveyard and everything was impossible to navigate around without turning off backgrounds. You can't report a bug in a game if you haven't actually played the original game that far.

     

    Just recently I bought a SFC cart of a game that I played in Japanese and in English before, and the first thing I noticed was that the text color was not always white. Was this a bug in the emulator? Was this a bug in the translation? Was it a bug in the cart dump? Did I just not notice before? It's things like this that causes people to mistakenly believe that the emulator is correct when it is not. While a color being wrong is not the end of the world, that goes right back to the accuracy question. For many people, they just see emulation and piracy as a way to play free games, and thus emulator developers have no way to verify if a bug reported by someone seen in a game is a bug in the emulator or the game was actually supposed to do that on all versions of the original hardware or only the version with a certain hardware bug.

     

    But when things like the Raspberry Pi (RetroPie) just come out and the color isn't even remotely correct in the first place, that kinda makes you wonder why you spent money on something that not even the developer cared enough to ensure it worked properly.

    • Like 1

  6. I find it quite amusing when people complained about the sharp squared-off edges that strict software emulation generates by default. But all-of-a-sudden it's perfectly acceptable on fpga simulations.

     

    The irony is that while FPGA hardware emulation can achieve the closest thing to 100%, that comes with some of bugs/artifacts that were in the original hardware (such as sprite limits and stray lines in the case of the Atari and NES.) However software emulators always, always, have to use performance hacks to get reasonable performance on a desktop because not everyone is going to be running a 4Ghz processor. So when it comes to the entire input latency-output scaler latency you will never achieve 100% on a desktop computer, though it will be better than underpowered devices like the RPi. Some people will not even realize that the software emulator is so inaccurate because they never had the original hardware.

     

    That is why you see so many youtube videos with square-pixels. To get the correct aspect ratio requires adding two stages of buffering latency in software, thus the games are not actually playable while scaled to the monitor's native resolution in most cases. The best you can get with a desktop is to not do it in software but instead leverage the GPU to scale, which can bring it down to just one stage if the emulator is writing directly to the texture and not to a software buffer first. Never mind the other CRT effects.

     

    That's why a desktop's software emulation is about as close as you're going to get to accurate in software. The latency on the desktop is about the same as capturing it from the real hardware with a high-quality capture card.


  7. I like how this has become the do-everything emulation and FPGA discussion thread. (not complaining at all, I really do like it)

     

    Probably because too many of the posts are in the Zimba 3K thread and it's hard to track anything in that thread that kevtris doesn't respond to directly.

     

    Anyway, when it comes down to it, if you don't directly address the cartridges or discs, then what you are developing is a piracy device. That is exactly how it looks to the copyright police everywhere. Any device that can run Kodi looks the same as any Video game device that runs libretro. They can't play any of the original physical media and their primary selling point is playing pirated content even if they can play legal content. The only games you can legally play on these are games you backed up yourself, which almost nobody has the equipment to do.

     

    When you directly address the cartridges and discs, then you can go "hey our device isn't a piracy device", even if everyone knows it is, and the device is going to primarily be used to backup the games. Basically the MPAA vs the VCR is the legal precedent that says "as long as the device is neutral to what it can record", the MPAA lost the ability to control how movies are distributed as a consequence, but we still got Macrovision as a crappy DRM scheme that was also easily defeated with an image stabilizer.

     

    https://en.wikipedia.org/wiki/Sony_Corp._of_America_v._Universal_City_Studios,_Inc.

    • Like 1

  8. Nah, there was no "console war" it was a marketing war.

     

    Half of the time people are comparing consoles that came out in different years, and had different software licencing mechanics. eg Atari's Tengen division was basically a way to dump more games on Nintendo's console, and many Japanese companies relied on American companies to localize their games while the Japanese companies localized American games for the Japanese market.

     

    Marketing can put lipstick on a pig.

     

    From a purely technical perspective, SEGA's gear was always weaker stuff and was accessory shovelware. Sega brought all this stuff to the US but Nintendo didn't bring theirs. Zappers, 3D glasses, 32-bit upgrades, CD-ROM's, power-base converters, etc.

     

    So if you get down to it, SEGA didn't win any battles except "who can push the most shovelware" which was something Atari was known for before it crashed the market.


  9. I'm convinced somebody will release a SNES core sooner or later and this one does look promising. I'm not too worried about 8bit and 16bit systems as a whole, slowly they will get there.

     

    For 32bit and above, in general 3D systems, it's going to be more challenging due to specialized chips. But 3D is an area where I think emulation makes more sense, upscaling to much bigger resolutions and making the animation smoother. Some emus even allow inserting high resolution textures to some games.

     

    True, however if you look at arcade systems, they used FPGA's in some versions of the Playstation-based hardware (I believe all it does is add mpeg-decoding in the case of the Bemani kit with it), so it's not much of a logical leap that FPGA based emulators make sense for games that are timing-based (eg DDR), that otherwise software emulation will remain terrible at dealing with. With the PS/N64 and later it will be a personal taste of either wanting high-resolution output or low-latency-high-accuracy output since you can't have both, but not every game actually needs both.


  10.  

    I thought that's why they need cartridges. You make the snes fpga rig, then plug a cartridge into it. Otherwise you'll need to model each cartridge's internal circuitry, too. That's where BSNES/HIGAN come then. It does that.

     

    The clone hardware has never supported SA-1, Flash carts like the SD2SNES and Everdrive do not support it either. Software emulators (eg Retron5/RetroFreak) with slots can't run them either.

     

    A perfect FPGA SNES would be able to run a real SA-1 game. So far nothing but a real SNES does. Software emulators kinda-sorta run them, but need speed hacks.


  11. Regarding the My Life in Gaming video :

     

    https://youtu.be/uMwBxL5ZlGw?t=1290- 21:30 - Their example here does not really show any substantial sound distinction between the real NES and the Nt mini

     

     

    I think the chip is accurate, just the frequency response is different, and that might simply be how it was captured.

    29oribp.png

    I captured the youtube stream, normalized it (to make the volume closer to +1/-1,) and then cut the NT Mini Analog section and put it below the NES.... err I'm not sure which one is which actually, thank you crop feature.

     

    Which is to say, I don't think there is an issue with the emulation, maybe the filtering or compression.

     

    Looking at more sections of the audio, it looks like the initial volume envelope on the NES starts louder. It could also be that they didn't sample the loop from the same point in the song.

    • Like 1

  12. I have a SNES Jr and there are not that many capacitors to begin and it seems fine, so told electronics does go bad and usually without notice. I wasn't aware of the SNES having a higher death rate than any other console, to be fair many older systems were built like tanks still finicky though, I guess the issue with SNES is that finding the custom chips is hard, older consoles may be easier to fix if they used many off-the-shelf components (CV for example, the triple-powered VRAM [+12,+5V,-5V] almost always fails on its own but it is easy enough to replace with 5V only chips .... I have one having been in store for 10Y, it was put in store in perfect working order but that's not how it came out, there was no rust, rot, leak or anything like that on the motherboard but the VRAM broke anyway, but not the SRAM :) ).

     

    The Snes Jr is typically the 1-chip model. If you look around online, you'll find that SNES systems have been failing like a plague hit them ever since 2012. So I'm really looking forward to seeing a FPGA SNES at some point, regardless of who does it.


  13. There is a SNES FPGA but for now the author isn't sharing it (either commercially or open source):

     

    Genesis is being developed for the MiST now, there is a working beta available with sound. PC Engine works (arguably not fully a 16 bit console though).

     

    On the computer side you have the Atari ST, Amiga with AGA chipset, Acorn Archimedes, Mac Plus with 4MB RAM expansion, and the russian 16bit computer BK0011M.

     

    Now these are all open source projects, meaning they can survive if the author stops working in it (in fact many were ports of older projects). But it also means it's being done by volunteers so progress depends only on motivation. It will keep progressing though and code sharing for big parts (e.g. accurate implementations of the Z80 or 68K chips) is already happenning.

     

    Ahem

     

     

    There has been no less than 3 SNES FPGA attempts. The one above is likely the most likely to not become vaporware. See his other videos.

     

    Most of the time the reason you won't see a SNES FPGA released is because they are student projects that used WDC IP in it. http://ece545.com/F15/reports/F10_SNES.pdf

     

    Plus the SNES is unique in that you can't create a FPGA of "just the SNES", as that doesn't cover the expansion chip games, and those are the games that don't run even on clones.

    • Like 1

  14. Might have been sleeping during that piece of news, care to elaborate?

    Personal experience. In 2000 I put my SNES in it's original packaging, and it was moved to a new house, and by the time I pulled it out of storage 2 years or so later, power LED comes up, nothing else. My sister bought one from a pawn shop, it quit working sometime while she was away at University and thus it just stuck her bedroom until she moved out of the parents house. I bought one from the local game place here, dead on arrival. I bought a SFC and a SNES off eBay, the GPM-02 works, the SFC initially worked but then stopped working sometime between testing it and getting a SFC cartridge to test. All of these except the GPM-02 are SHVC-CPU-01 systems, and the SFC is a 1/1/1, while the rest are 2/1/3's. So I have one working SNES, 2 non-working SNES, 1 probably-just-dirty SFC, and the remains of the original SNES I had's PCB. If you look on eBay, you'll frequently find lots of dozens of "as-is" lots of SNES systems.

     

    So yeah, they're timebombs, information found online suggests it's always the CPU. That said, the ones people seek out are the 1-chip models which have more bugs than GPM-02 (identical to SHVC-CPU-01 just the APU chips are on the PCB instead of it's own shielded box) but apparently have the best RGB output.

    • Like 1

  15. Yea, if it can't support the Dreamcast, Gamecube, Wii, Xbox, or Ps2 I really hope it could support up to the Saturn, n64, and psx. That would still be 5 more consoles I would need to keep around and have modded for hdmi and odes (or jailbreak to run backups in the case of ps2, wii, and xbox) but I could live with that. I just don't want to have thousands of dollars in modded consoles lying around if I can have a 99.9% accurate all in one with native hdmi and the ability to read backups. But for the love of god support reading from an external harddrive or 1tb sd cards something.

     

    I think most of us are just one house/apartment/flood fire aware from having no collection. My personal feelings on piracy tends to be pushed aside when it comes to preservation of software I've purchased (sometimes multiple times.) Preservation takes precedence, so if I can save the games from being lost permanently by using something like the Z3K or NT Mini in place of using the original console or computer, the original console gets to live longer (unless they're timebombs like the SNES, then nothing you can do can save them.)

     

    For example, Larry Bundy JR, 3 of the first 4 videos on his youtube channel are detailing how his video game collection was destroyed by the storage container's roof leaking

     

    It's not likely the Z3K will be able to use an external hard drive or sd card over 64GB because FAT32 maxes out at 64GB. In order to use more space you have to use a more complicated file system, and you will not be able to read in anything else. For example my 1TB external plugged into the WiiU, the WiiU had to format the drive first ( http://en-americas-support.nintendo.com/app/answers/detail/a_id/1359Nintendo says 2TB max) If I want to backup the external drive, I'd still need the same WiiU, so if that WiiU dies, and no more WiiU's are available, those games are essentially lost. However there is another issue here, and that's you have to use GPT partition tables to access more than 2TB.

     

    I expect, at least until there are affordable 2TB SDD's, that the Hard drive manufacturers will continue to produce 2TB drives because there are plenty of legacy servers out there that would also have the same problem.

     

    In the case of the z3K, the quickest solution is to just divide the drive into 64GB partitions (1TB = 16 x 64GB,) but that will make it a pain in the ass to manage. The file systems (eg UFS (FreeBSD), NTFS (Windows), HFS+ or APFS (Mac/iOS)) are too complicated to implement on a FPGA due to the need for large amounts of memory and journaling. Only FAT12/16/32 is friendly in this respect because the file system is simple, but it's also not very reliable (you can trash a cheap USB drive from power-cycling what it's plugged into.) exFAT is basically perfect for Flash media, but due to patents, you can't support it without a license.

     

    I suppose in a pinch UDF would work. UDF is what's used on DVD and Blueray discs, so it's not likely any patent encumbered, however writing to those on computers might be complicated. But reading should be no problem. However it's even worse for reliability since no drive maintenance tools that I'm aware of support UDF. Though I also suppose the Z3K can format a drive with UDF that Windows/Linux/MacOS/etc can read and write to, and if worse comes to worse the Z3K could just build all the dumping into the firmware.


  16. I've been trying to downsize my collection and started to sell a couple of my systems.

    I am going the Craigslist route so postage and eBay/paypal fees are avoided as well as no in transit damage by courier/mail service.

     

    I found the hard way that there do not seem to be many interested parties ... to put it midly!

    Maybe my bundles are a little on the expensive side but usually CL is merciless in that regard and low-ball offers should flock in that case, instead nothing .... and it's been a while.

     

    Maybe I am selling exotics nobody cares to buy on CL, who knows, what is your experience? Should I turn to the dark side and let eBay drive it home for me? [i do buy on eBay but I do not sell if I can help it via CL]

     

    They are different markets. CL is basically local "anything that isn't illegal *wink*wink*", but you'll have problems getting people to commit.

    eBay* is "sell anything legal wordlwide" has strict rules about what can be sold, and people just throw a fit when they can't sell their collections of games that may contain one rare bootleg version of something in it.

     

    Mostly, the danger for eBay* is, don't sell modified consoles. The quality filters are actively looking for piracy keywords to weed out piracy devices. Accidentally list something illegal once, and you will never be allowed to sell anything again. The sellers that get hammered the most however are those in Asia since nobody thinks twice about selling a blank flash cart.

     

    *I once worked for eBay in this department, taking down all the reported world-wide pirate devices is something that can be done in about an hour, if anything people don't report pirate devices enough because they're scared they will bring further scrutiny to finding rare things.

    • Like 1

  17. Since the FPGA mostly simulates a digital device, how difficult is it to accurately simulate analog components such as resistor networks, high/low pass filters, harmonic oscillators, etc? Most game consoles merely used resistor ladders to internally bridge multiple outputs on a CPU into discrete logic levels for analog output, and also used duty cycling and other trickery. Duty cycles and pure resistor networks would be easy enough to implement. HF noise can cause real issues with a DAC chip creating all sorts of harmonics if digitally sampled without a low pass filter at half the sample rate or less. Most consoles suppress HF noise in the ultrasonic range. HiFi stereo equipment do this typically with a 20-20,000 Hz bandpass on inputs but consoles are a wild wild west sort of thing.

     

    Any Console or Computer that uses a FM Synthesis (eg Yamaha YM3812 found in the Adlib, SoundBlaster) actually produces frequencies that can't be captured with 48Khz. The SN76489 (Sega Master System, Coleco, PcJr/Tandy 1000) can generate frequencies that are well outside human hearing (eg 111Khz.) So yeah, audio is a bit more of a crapshoot to get perfect because the original audio generation wasn't perfect.

    • Like 1

  18.  

    Well, maybe I will ask a few audio related questions too. :)

     

    1) Nt mini generates 48khz 16bit audio, so I guess this results in crisper sound and that's cool... But maybe original lower quality NES audio has some nostalgic value as well. Err... something like cd vs vinyl? I love how you recreated the NES composite signal with all the artifacts, is something similar possible for audio, i.e. recreation without all this digital crispness, or are there some technical limitations connected with the analog nature of the audio signal? Original quality audio seems like a nice (optional!!!) feature.

     

    2) If the Famicom "has some lowpass filtering" maybe it could be implemented for expansion audio in your NES core as well (at least optionally), since the expansion audio was originally present on the Famicom and not the NES. :P

     

    3) Kevtris, how do you check your FPGA implementation against original audio? A simple ear test or do you look at some signals (or maybe both)?

     

    4) Some time ago you talked about problems with implementing "external analog hardware" for your C64 core. Could you explain this in more detail? I don't know much about the Commodore... :grin:

     

    Keep in mind that it's generating 48Khz 16bit audio on the output side for HDMI spec. On a real NES, it's mixing 4 digital channels of undefined "sampling rates" that are generated digitally and goes into multiple filters (two high pass filters and one low pass filter). (Also why when software emulators artificially limit themselves to 22khz or 32khz, it acts as a high-pass filter.)

     

    To create all the analog artifacts comes back to the same reason why scanlines are a taste thing and shouldn't be enabled by default. The equivalent of "scanlines" for audio to make it sound like an old TV would mean applying additional low-pass filters, noise and normalizing the audio to make it louder, hence many of the trademark distortion noises of 8-bit systems. The NT Mini produces "too clean" output so distorting the video with scanlines and distorting the audio makes it less clean. Some people want it, other people don't like it.

     

    My personal opinion is that the only thing ever wrong with digital audio output is that the sound chips on PC motherboards tend to have too much noise, and many cheap devices *cough*Raspberry Pi*cough* have the same problem. If you use a dedicated sound card, or a high-end motherboard on a PC, (the trend 3 years ago on gaming motherboards was to have replaceable op-amps) you usually get a better experience by just connecting a home theater to the S/PDIF and thus have more control over the audio equalizer. I imagine most people who play games on their TV, connect the HDMI to to the TV to reduce latency and instead route the audio from the TV to the home theater if they have one. If you have a subwoofer, then it already has a high-pass filter on that channel, while the regular speakers have low-pass filters on them to prevent them from being damaged.

     

    That's how things have changed since the 80's. Prior to the 90's people only had "HiFi Stereo" systems which often included large speakers with crossovers in them to send the frequencies to better-suited speakers in the same cabinet. Around the late 90's we switched to subwoofer on a low pass filter, and small 5 speaker surround systems.

     

    So I don't know to what extent you want to create analog distortions but as one earlier video showed, the audio was essentially identical but which frequencies were louder than others was different. That can be chalked up to sampling rate of the capture just as easily as it can be chalked up to signal attenuation.

    • Like 1

  19. And then there's the issue of the controllers: If the Zimba has USB ports, then the question of actual compatibility with the plethora of different USB controllers available will come into play. Will specialized drivers be required like it's done on Windows? It could be relatively easy for Kevtris to manage, or it could be hard, tedious and time-consuming.

     

    I did some research (a few times) and basically there are two problems with USB/Bluetooth

    1) Bluetooth is basically "wireless USB", as in you only ever see it implemented as a bridged over USB, even on devices like the Wii. So you need drivers that understand the USB Bluetooth device, and then on top you still need to support the devices synced with it. You will never have BT gamepads with "better latency" than USB because they are USB.

    2) USB polls at 125hz. This "good enough" for a digital gamepad (eg most of the things the Z3K would be able to run) but not quite great for an analog one. Essentially there is a circuit in USB controllers that are sampling the pointometers on the analog controls, and the computer just sees whatever the HID driver tells it to. BUT...

     

    You can also switch HID devices to interrupt mode. You can also apparently just set most USB devices to any arbitrary polling rate you want if you know the device supports it. That is frequently done with USB mice. I don't know if this would be needed but there might be some inherent latency in just one mode or the other. It's not like the NES/SNES/Atari/Sega controller buses which are wired to the CPU with no translation effort in the controller or console.

     

    When I was, 12 maybe, My cousin had something that looked like the NES Advantage (which I seem to have, but don't remember buying) but it had a swappable wireless (infrared) box that let you switch it between the Sega Master System and the Nintendo Entertainment System. So I imagine that the whatever was in the box or the cable end didn't have anything complicated in it.


  20. I'm actually wondering now.

     

    Would it be possible for the NT Mini to use pin-adapters on the NES or Famicom slots to load other cartridges (eg GB/GBC, Sega Master System, Colecovision,C64 cartridge, 2600 cartridge) ? I'm sure none exist at the moment, but it seems like all the 8-bit systems and some 16-bit systems could use the 72pin NES adapter slot. It seems most 8-bit systems have 12 or 16 address lines and 8 data lines, plus a few other connections. The Famicom/NES has two 12-bit address buses and 2 8 bit data buses, it seems like it could be pin-adaptered to anything up to 24-bits of address and 16bits of data. I'd just be more worried about discovering improperly wired pin adapters from China.


  21. So I hooked up my Wii to my nice little flatscreen today to play some NES Castlevania. This was on a homebrew emulator, not a virtual console game. The lag was unbearable. Is the TV the main culprit? Is it worth it for me to drop $10 or $20 on a tube set? Thanks.

     

     

    There are three reasons for lag, and it depends what you're talking about

     

    1. Output lag, between the device and the TV. This includes cables, "active" cables (ones with chips in them, like some HDMI adapters), Upscalers/line-doublers, TV/Monitor based upscaling/de-interlacing.

    2. Input lag, between the controller buttons and the device CPU. This includes, again, cables/adapters, wireless or wired, and even some interfaces like USB.

    3. Communications lag, more typically used in the multiplayer context, but applies to digital communications latency and analog communications error correction.

     

    There is only so much you can do about communications lag, and that pretty much means remove as many stages as possible. So a wired "dumb" controller like a NES/SNES/N64 pad is better than ALL USB controllers, which are in turn better than all Bluetooth controllers.(The Wii U's tablet actually uses WiFi.) On the output side, don't buy a SmartTV :) Don't run the HDMI through any device before it gets to the TV.

     

    With Analog cables (Composite, S-Video, Component) you just get more signal attenuation with longer cables, so the images end up darker/noisier.

     

    The more likely thing in an uncontrolled environment is that the analog input on the TV runs through an upscaler/deinterlacer, which adds 2 frames of latency (42ms) by design. If the TV has frame-rate doubling features (seen in many large TV's, "soap opera effect" motion smoothing) that adds an additional 2-3 frames of latency because it has to deinterlace (1 frame), upscale (1 frame), duplicate 2-3 times (3 frames), so two incoming frames at 60i are converted into 4 60p frames or 8 120p frames. Things start to get really silly in latency once you compare the output lag to the input lag of a wireless controller.

     

    On the input side, each console is designed only for it's pack-in controllers. So if you use a Wiimote with a Wii, all Wii games are designed with that latency in mind, but you may have 2.4Ghz hardware nearby that adds noise (like a WiFi router) and thus makes the bluetooth circuitry have to correct more errors, adding more latency. The Wii is connected by WiFi to the internet, so if it has to use a stronger radio signal, it will drown out it's bluetooth controllers. The BT chip on the Wii is made by broadcom (BCM2045A) https://fccid.io/MCLJ27H002and only puts out 0.0025 watts. All Bluetooth radios are bridged over USB (see next statement.) The latency will increase exponentially the farther you are from the Wii.

     

    Wired controllers typically will not have latency unless they are USB. USB latency polls at 125hz, which is more than enough, however not all USB drivers and chipsets are the same. However in the case of the Wii, the Gamecube ports are not on the USB bus as the Wii is an evolution of the Gamecube. AFAIK only gamecube games can use the gamecube ports BUT, some Wii games can use the gamecube ports if they were designed for it. http://gaming.wikia.com/wiki/List_of_Wii_games_that_use_the_Nintendo_GameCube_controller, which I don't know if the homebrew channel supports that, but if it does, that's undoubtedly the lowest latency solution and the easiest to determine if it's wireless controllers or the TV. If the latency persists even with the wired controllers, then it is definitely the TV.

    • Like 1

  22. http://microsoftremotedesktop.wiki-site.com/index.php/Microsoft_Remote_Desktop

     

    Guys,

    when I try to stream whatever is happening from my PC to the iPad I can't do it with a few systems, such as Atari emulators... is there a way to fix this?

     

    I mean, some emulator that works like ePSXe, pcsx2, dolphin, snes9x?

     

     

    Point of reference, the Microsoft Remote Desktop doesn't use your GPU, it uses a virtual video card, hence games that need to use the GPU are still trying to use the GPU, and don't typically recognize they are running under Terminal services.

     

    If you want to stream things to your iPad, you have to actually capture the game/application (eg with OBS) and stream it as a video feed. If you use RDP, you're not likely getting more than one frame per second (unless there is a hardware encoder,) because even if the emulator can run under Terminal services, it can't make use of the real GPU, it uses the RemoteFX virtual GPU. Without getting into a complex explanation, the emulators that likely don't work are using "overlay" mode or are using OpenGL (Windows 10/Server 2016 only.)

     

    https://blogs.technet.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview/

     

    So check to see if the emulators are configured for DirectX/Direct3D. Also keep in mind that it might specifically have to use DirectX 9 or later.

    • Like 1

  23. Yes I got this problem to the dpad is awful on my nes30 I got a replacement but it was bad to .

    When pushing the dpad it will register two inputs at the same time , for example when pushing up it will register up and right at the same time.

     

    I have a sfc30 to from 8bitdo and that controller working as it should.

     

     

    That almost sounds like a short on the controller board, but I don't have any of those 8bitdo controllers to reference. It's almost certain that the PCB's inside these are nearly identical to each other.

     

    Take note of what the SFC30 controller PCB looks like

    (source http://muchreviews.com/index.php/8bitdo-sfc30-vs-original-snes-teardown/ )

    8Bitdo-close-internal-1-e1452629149851-7

     

    Also take note here:

    http://forum.8bitdo.com/thread-446-1-1.html(8Bitdo D-Pad PCB Contacts Issue)

     

    If you read the thread, it sounds like maybe the 8Bitdo is "supposed to" do this. Maybe get some input from a few more people with the controllers to see if maybe it's supposed to be that way?


  24. If this is a serious question, it doesn't need emulators.

     

    There are upper scale FPGA recreations of some computers that have a full suite of original ports. Like the Suska for the ST: http://experiment-s.de/en/

     

    The MiST can't connect to printers but can do Ethernet on the Atari and Amiga cores:

     

    It can also be setup to use serial NULL-modem communication (by disconnecting the MIDI extension). Somebody hooked it up a Raspberry Pi:

    http://www.minimig.net/viewtopic.php?f=14&t=655

     

    These are just some examples, but basically FPGA can be wired to old and new peripherals if they provide the connections on the PCB.

     

     

    I think we're not far off from being able to do this. Like emulating proprietary printer interfaces may simply need emulating more of the "south bridge" type of chips to use a PC analogy. The problem is more likely that there is little demand to do this since the old printers (especially dot matrix printers) and their paper hasn't been around for 20 years unless you've been working in a government office that still uses them :P However there is the occasional demand to connect to old industrial hardware like CNC machines, broadcast hardware like genlock/video toaster, just to do "retro" types of things.

     

    It still amazes me that "Halt and Catch Fire" was able to find so much working 80's kit to film that series. The probably had to get some people actually familiar with the hardware to produce vintage looking screens and not just secretly connect the monitors to non-vintage hardware.

     

     

    I'm new here but pretty sure I can speak for everyone when I say please take irrelevant worthless printer posts to a different thread.

     

    @kismet

     

    You have to be kidding me with that overwrought explanation of why you personally are poor and why you personally don't want one (neither do I btw). 200-300$ is not a lot of money, college or otherwise. FPGA's do not exist for anything past 8-bit atm, and for the forseeable future, so your second point is mute. Everyone in 2017 is "the pirate", so that point is stupid also. "The Pirate" SCAAAARRRSGAAARRRDDD!!! would love to have a nice retron-style system with an SD slot. Maybe .1% of users actually care about streaming to youtube so another pointless point. And if you're arguing electricity cost is a factor for using FPGA, you really need to get a job and probably shouldn't be involved in retro gaming anyway.

     

    Did I strike a nerve? Are you a dirty pirate? :grin:

     

    The point is that emulation goes beyond piracy, but piracy is part of collecting and preservation. You don't seriously think the MAME developers have hundreds of arcade cabinets stored in a warehouse somewhere just collecting dust do you? CRT monitors don't last more than 30 years before they hit their brightness halflife. Waiting too long, like "Marble Man" is likely to result in the game never entering the public domain, and any working hardware long since becoming unusable by 2087.

     

    Software absolutely has to be preserved because copyright-law doesn't take into account things like format shifting, or hardware operational life.

     

    Everyone who is just downloading whatever they want and showing off that they didn't pay for it, are disqualifying themselves from work in Law Enforcement. As someone once said on a police forum "If your ambitions are to work in law enforcement, stop breaking the law now, because we don't hire people who can't show restraint."

     

    Which goes back to the topic of what is the point of many of these libretro devices. They are piracy devices, the amount of people who legitimately have the software is not going to be very high, and the amount of people who actually can dump their own software even fewer. I wish a few more companies would follow SEGA's lead and just build their own emulator-packaged software, leaving the ROM unprotected so if you really don't like their emulator you can use your preferred one. Many DOS games in fact are distributed this way now on gog.com and steam. It's not a huge leap to do the same with any other vintage software. The only companies I see never coming on board are Nintendo.

    • Like 3
×
×
  • Create New...