kevtris

it's game genie only. it should work on everything since it's internal; but if you're in the sd2snes or similar menus, you should disable the codes first!

looks like all 5V logic so it should be fine.

bomberman 5 is what we did 3 player with for a few hours. it was awesome. Definitely the height of bomberman technology.

the hi def NES is complete. It is not going to be changed and there will only be bug fixes. The hi def uses the existing PPU so it cannot add more sprites or whatever. The FPGA on the board is at 99% capacity and there is no room to add anything else even if I wanted to.

I did not create it so I am not related to it, btw.

Where did I say that? I might've implied it, but I have always thought of it as more of a system, since on the sd2snes it isn't just a "chip". It's a combination of FPGA, microcontroller, and other things to make it work. I consider SA-1 to be an expansion chip, since it is a purpose-designed ASIC for the system itself and is a single chip.

Without analogue, my FPGA stuff might never have saw the light of day. They provided an outlet for my cores and other work so that thousands of people can use it, so I think that counts for something. What's a "long term solution"? emulators and ROMs?

I don't trust/believe them on their ESD capability having been burned by that before. I would still put TVS diodes on those signals. The cartridge port is fine but the controllers/keyboard/video/audio should really have it. Going hdmi only is a decent method and does save all the stuff for analog use. You could make an hdma to analog adapter if people really had to have the analog out. SDRAM is harder to implement but it is a lot cheaper. If volume isn't too high there might not be a real need to change it from sram though.

I fixed the -1 thing (pretty sure... lol) it was because I was multiplying by 0xff instead of 0x100 in the scaler at some point. This turns 0xff into 0xfe, and 0x8 into 0x7. i.e. 100h = 1.00, 80h = 0.5, etc. yeay for fixed point math. The SNES itself was outputting what you'd expect, so I knew it wasn't that, so I checked the video chain in the scaler and some lerps wouldn't do 1.00 and only 0xff (0.996). That's been fixed. The MSU-1 audio is coming out of a DAC on the cart, and the DAC is totally missing its filter, at least on the rev h sd2snes. I opened mine up and looked, and the DAC output normally has an RC lowpass filter, but it is missing. The audio is being buffered by a fairly fast op-amp and nothing else. To do a proper job of it, that op-amp could've been turned into a two pole active lowpass filter to clean the audio up and remove most of the ultrasonic components. I could hear some aliasing from my ADC due to this. The proper fix would be to add the lowpass to the sd2snes itself (indeed earlier versions have this filter but no buffering, and the filter was replaced by an op-amp in buffer mode). There's going to be some lowpassing going on inside the SNES audio path itself, but you're not going to be digitizing the SNES audio very often, but instead just running it through a TV/monitor/stereo system which will pass any ultrasonic not stripped out by the SNES audio circuit and you won't be able to hear it.

I had heard about the ZX-UNO but not the other two. I hope I am not stepping on some toes but I would like to give them some protips on the Collectorvision board. It should have ESD protection on the two controller ports, keyboard port, and RGB/audio outputs. The original Coleco had a big problem with the controller ports failing due to ESD. Also, the audio looks like it is just some RC filtered PWM from the FPGA. A real audio DAC isn't very expensive and would sound a whole lot better. Ditto for the video DAC. I see what looks like 3 bits of weighted resistors but not a DAC. I don't see any pullup resistors on the inputs either, unless they (and possible ESD protection) is on the bottom. Also, DDR/SDRAM would be a lot cheaper and 32 times bigger (i.e. 16mbyte vs. 512K) for the RAM.

It might be a little bit of "not invented here" talking, but I generally don't see the set of peripherals or design that I like in the existing FPGA videogame boards that exist. I know of about 5 or 6 of them at this point. Usually the peripheral set is lacking in some way. And since I like hardware there is something to designing my own that is very satisfying. The "Standard platform" that satisfies one set of devs might not satisfy others. All of the FPGA videogame boards up until the mister add-on has been composite, s-video, or RGB. The amount of RAM has been lacking, too. I know of the following projects. have I missed any? * MCC-216 * FPGA Arcade "Replay" board. * MIST * Papilio FPGA board (not really marketed as an FPGA videogame board) * A2601 (seems to be a one off project) * MiSTER (dev board + add-ons) The problem I have with the Mister project I have is it's a dev board, which means it is heavily subsidized. This is good for users, but the hardware side isn't very sustainable and you're at the whim of Altera (now Intel) when it comes to availability since it is most likely being sold at a loss. The entire board costs less than the FPGA on it. If it ever got some real traction and started selling thousands and thousands of units very quickly I suspect they would pull the plug or raise prices or put restrictions on who can buy them (i.e. potential industrial customers only). As for knockoffs of the Analogue products, I don't think they would be a very juicy target at this time. The costs of production are way too high to justify a direct clone so there isn't enough profit there I don't think to go through the hassle. If it was simpler and cheaper to make then I would say there might be a worry but as it stands now, the worst you'd see would be an SoC or NES on a chip slapped into a copy of the nt mini enclosure or something.

I see a big problem between open software and open hardware. With software, reproducing the software has almost zero costs. With hardware, you have to make a large monetary investment in getting hardware made, tested, programmed and distributed. The Mist project is a great example of what happens when you open source your hardware- other people come along and undercut your manufacturing and you're left holding the bag with inventory you can't sell. So now you're out $10K, 20K, 50K or more because someone's undercutting your hardware prices by a large margin using cheaper manufacturing, not having to obey certain local laws, etc. Sure some people will still buy one from you because they want to support the project or whatever, but the majority of people will buy based on price. I can't really blame people for going with the cheapest option possible, but then they come to you for all their support needs too. This forum post about "The last MIST" lays this problem out fairly well. http://atari-forum.com/viewtopic.php?t=32998 I am not against open software or hardware, but the reality of the situation is you cannot manufacture open hardware and expect to make the money back or heaven forbid, make a profit off your work. When I was 20 years old I might've been able to afford to work for free (or a loss) for months or years on end, but these days I have a lot more responsibilities and have to pay for food, shelter, etc. I have to make money in order to survive and I don't think this would be possible by open sourcing works that can actually make a profit. Some of that profit generally is generally plowed back into my projects, too- I can afford to pay thousands of dollars for an HDMI analyzer, or an oscilloscope, or buy dozens of $50-100+ games off ebay to make sure my compatibility is high. If I was not making anything off my projects, then there's no real impetus to fix it once I wrote it, or feel like I am obligated to provide a good product. "eh, I released it free, fix it yourself" doesn't ring very true if someone paid for the hardware and got some bum firmware/core and no updates other than "you have the source, fix it yourself!" In regards to your comment about "producing documentation" for an open implementation of say, an nt mini, producing (and supporting!) such things has a very real and large cost. That effort could be spent on documenting everything for no money at all (and in fact negative money as the Mist guy found out needing to support it) or the effort could be used to make more new stuff. I am as altruistic as the next person, but I have to eat too, and being able to live by writing FPGA cores and making FPGA hardware has a real attraction to me. I respect those that wish to open source their hardware/software and all the more power to them. Being able to produce a really nice "experience" if you will around the FPGA cores has a real value I think too- the nt mini and super nt both have a very nice enclosure, you can plug it in out of the box and it "just works" and looks good while doing it. That all takes money to make happen, and without it you'd be stuck with PCB-only with maybe some kind of home made enclosure. Not that there is a problem with this (I have made many home made enclosures) but there is just something special to me having a fully custom injection molded enclosure and all the trimmings. As for the cyclone V not being around forever, this is true but I will most likely be making FPGA videogame systems for a long time to come. I have already brought my NES core through the cyclone 1, 3, and now 5 on the nt mini. I am not going to abandon it so long as people wish to use it and buy hardware. Every time someone buys a system containing my code, it gives me another little shot in the arm to keep developing new stuff and fixing the existing stuff. I don't think that driving force would be so strong if I was not getting paid and using my time away from things I want to do for unpaid support on a free project. Even if I do not open source my core work, I *have* released multiple documents on how various videogame systems work that I have personally reverse engineered. These documents are valuable in their own right if you wish to know something about how those previously undocumented or underdocumented systems work. Pretty sure there will never be a homebrew scene for such fringe systems, but not at least it'd be theoretically possible. I am planning on releasing my SNES technical notes when I get a chance to clean it up, too. I found several previously unknown and underdocumented things during my research for the project.

It won't get fixed, because it can't be. I originally converted RGB to YUV in all cases, then back to RGB again which is what happened to the colours before. I added a "bypass' mode that lets RGB flow through unless you're using hqx scalers. In that case it must have the conversion active. It takes a lot of blockram to store the graphics for 3 scanlines, so I store it in YUV and back-convert it to RGB. This is still going on for hqx scalers. Sorry 'bout that. It might be possible to fix it in the future but I have no immediate plans to do so.

Well that'd explain why no one had a menu bounce checkbox any more. The checkbox is for that, but it looks like the entry got removed somehow. I have fixed that without knowing it, so that should be working on the next rev. I think the two entries might be overlapping so pressing down selects font, down again selects bounce (not visible except its checkbox) and once more is dim game in menu.

After how long SNES took me, they have a looong road ahead doing multiple brand new emulators, if you want it to be accurate. They would need at least 1 person per system if not more to get it done in any reasonable amount of time I would think.

Yeah I don't buy it. If they can't dump it, they can't run it. SA-1 and SDD1 games require a working lockout chip in order to get anything out of the cartridge. Without this, the games can't be dumped and won't run no matter what. It all sounds like a bunch of smoke and mirrors and "trust us". Like the ataribox, show us the working prototype that isn't just a dev board running open source emulators. Sure seems to be a lot of that lately (announce videogame system, never produce concrete evidence it exists/works, keep pumping it up, then go radio silent). Polymega/retroblo(x), Ataribox, Lythium, and earlier Coleco Chameleon/RVGS. Did I miss any? It's hard to keep up.

haha, I didn't see that. I still am curious how they are going to get around the whole BIOS ROM problem (among the 2000 other issues they will have). It's pretty hard to run CD based systems without the BIOS ROMs. I guess they could take a stab at rewriting one but it's a big job and compatibility will be suspect. It sounds more and more their "hybrid emulation" is basically a retron 5, where it uses a simple CPLD/FPGA to read the carts and stuff and interfaces it to an android system running emulators. There's zero way to get a software emulator to actually run a cartridge without dumping it IMO. They could theoretically run a CPU emulator, but it cannot do anything else, because running the cart bus will take all available CPU cycles, and it cannot be sped up (because the cartridge can only be read at the "usual' rate and it cannot be sped up to help do bulk processing).

With it off, the system outputs absolutely "perfect" cartridge bus timing, but two things I know of exploit race conditions to work at all. Super powerpak and game genie. They were designed as if the SNES bus worked like the NES bus (which it does not). The /RD and /WR pulses are delayed around 3ns from the CPU clock. Ideally both edges should happen at the same time, and they do on the super nt. But due to the way the CPU is made, there's very slight timing discrepancies. This adds up to around 3ns of delay. It appears that propagation delays in the CPU chip itself cause this. 3ns is around a 340MHz edge rate! Pretty fast for a "slow" system running at 3.58MHz maximum CPU rate. Anyways, super powerpak and game genie need that 3ns to latch data. In fact the game genie can be hacked to work properly and not require this. The GG fails on various real systems due to this timing thing. The super powerpak apparently can as well but I didn't have this problem. The "launch system timing" delays /RD and /WR 6ns which is the smallest step I can delay on the FPGA. The super powerpak uses the B bus /wr and /rd signals, which were not delayed so I delay them now too with the timing thing. The spp is the first cartridge I know of (other than my PPU/APU test cart) that uses the B bus at all.

it's still in there, just turn it on. it's under "menu options" and is "menu bounce"

No it didn't seem to be affected. I am not sure yet what is causing this. I tried different resolutions here and didn't really see much rhyme or reason to it. Sometimes it works, sometimes it doesn't. When it boots it seems to work OK though; I did 4 rounds without a problem.

The only thing I found that didn't like "launch system timing" was the game saver +, everything else I tried did run fine. I personally leave it off but if you're having no trouble, then you can leave it on or off.

Some debuggin' updates: I figured out what causes the monopoly bug today. It's really wacky. The game is absolutely 100% fine. The problem is the game is manually reading the controllers (vs. using the autoread like most other games) and it only reads them every 8 frames, in time with the chance/community chest animation. This causes my controller reading state machine to fail, thinking the game crashed, so it starts reading the controller itself (so the menu still works). The game reads once, and this breaks it out of me reading it, and the system gets sent "no buttons down" for the first read. Well, the game only reads it once so it gets 'no buttons down'. then it waits 8 frames, it times out, and the cycle repeats. This is why before the game would blow through that screen without stopping- it would return 'all buttons down' instead! That's what broke starfox 2 and a few other games that complained about incompatible controllers. Certainly a very weird bug, and if the game was programmed different it would've never happened. I have a fix for it though. The fix will be in the next update. I also figured out why Twistit was crashing, and it's actually TWO DMA bugs. After I fixed one of them, the demo almost never crashes (took 4 loops through it). This also seems to have fixed Samurai Shodown/Spirits (I ran both of them 6 times, cannot reproduce the crash on boot any more). I am calling that provisionally fixed for now. Twistit was slightly naughty and does DMAs during rendering, and it was a HDMA during DMA that was causing the problem. If the two happened with juuust the right alignment it causes the failure. The second DMA bug it uncovered is similar but much harder to make happen. I don't think that bug is causing any issues anywhere else but I am going to fix it tonight.

It's probably because the lack of gamma. When gamma is "on" but no scanlines, it was set to 1.25. When gamma is "off" but scanlines are on, it was set to 1.25. When gamma and scanlines are both on, it was set to 1.40. I am going to totally retool the scanlines in the future once I fix the rest of the major core bugs.

It's possible your monitor is adjusting to it. The symptoms you will see if your monitor doesn't switch: * Full range on a limited range monitor - blacks and whites get crushed, since anything below 16 is clipped to black, and anything above 235 is clipped to white. * Limited range on a full range monitor - blacks (like the left/right bars) turn dark grey and the whole image seems to get slightly brighter and possibly washed out. Be sure to uncheck "dim screen while in menu", this will make it easier to see. If you have limited range on a limited range monitor, vs. full on a full, it won't look much different. There will be some fine brightness detail lost (most noticeable on gradients) but overall brightness and such should look the same, since the 0-255 range is being squashed down to 16-235. The super nt does this "squashing" conversion now, where before it just sent out full range RGB no matter what.

It was there all along and is for the LED pattern loading. It was moved from under menu options to hardware is all.