kevtris

unfortunately I can't. the ntm's FPGA is out of multipliers and blockrams for it.

the "fix" I did for mecarobot golf broke it a bit. I have figured out the issue though so the next fw should fix it. They attempt to turn hdma's off right at the point they start (similar to golf).

yes it's been reported a few times, I ahve it on the list to check out

Since there's been a few reports of the super powerpak not working, I would like to buy one if someone has one for sale at a reasonable price. PM with details if so. I can't fix it if I can't test one and I'd rather just buy vs. borrowing, but I can borrow if it's the only option. I just will have no way to verify it continues to work after updates.

It sounds like it's drawing too much power off the 5V. This copier has a barrel jack on it for a power adapter, just like my doctor sf6. Maybe you need to use that to power it. There's going to be way too much power draw going by all the chips in there and the disk drive itself. The cartridge port is only designed to supply around 300-400ma to the cartridge.

I noticed this effect on my monitor as well. In DVI mode, it gives you every pixel without overscan. If you start sending those hdmi packets, though, it starts overscanning whether you want it to or not, and there is no option to turn it off on this particular monitor unfortunately. Even the monitor's mode display gets dumbed-down. it would say i.e. "1920*1080 60hz" -> "1080p" going from DVI to HDMI.

If you could set the super nt to DVI mode, you will get no audio because these aren't any hdmi packets any more.

New firmware (4.1) is up on the support page. Fixes: * Controller reading- this fixes street racer's "cannot be used with superscope" message, game genie blowing through the title screen without stopping, and I hope star fox 2's "use original controller" message. I do not had this cartridge, so I hope someone can test this for me that does and verify the fix works for it, too. * Earthworm jim 2 PAL audio - This should be fixed, though due to the extremely tight nature of timing on this game, you can only play it in fully buffered or single buffered. If you play it in zero delay mode the audio will still glitch. This is because the game is extremely timing sensitive, and the time adjustment for zero delay is just enough to cause issues. No other known games are affected. * NBA jam not letting you get back to the menu (on its title screen and some other places) easily - the game had a broken "manual" controller reading loop left in by accident it looks- they clear then set the latch bit on the controller and read it 16 times with latch set! This is never going to work. I don't know why it was in there, but obviously the game cannot use the results, they will just read the Y button 16 times. This was tripping up my "piggybacking" on controller reading. That has been fixed now. enjoy!

higan was super dark compared to *my* 2 chip, and 1 chip though. I am not sure what else I can do since it's not like the snes has a palette like on the NES. Since it's 999 RGB (approximately) it isn't possible to make a palette either. It's 555 RGB but there is also the 4 bit brightness register to worry about, too.

You're the one that keeps perpetuating it. Please stop it. It's clogging the thread up with your talk of bank fraud.

MLIG livestream with me in it starting in a few mins: https://www.youtube.com/c/mylifeingaming/live

It's got some adhesive holding it on. I saw someone on a video peel it back to get to the screws. I dunno how that affects the warranty if you do this though.

yes that's correct.

It compiles with EDID in your tv/monitor, and will select the highest quality source possible (by default). You can always try setting 720p on another working monitor, and it will never try to output 1080p after that. By default it is set to 1080p, and it should "ring down" to 720p, or 480p if your tv/monitor does not support 1080p. The EDID is read and this determines the mode your tv/monitor can use. Apparently some early hdmi crt's (yeah I didn't know those existed) might've had bad EDID information or something that prevents them working right. Since it's impractical for me to test one of these, I cannot fix it. If someone sends me an EDID dump, I will give it a look to see if I can figure anything out. (note: if you change it to output 720p max, be sure to save settings or else it won't stick) I don't know a lot about the mister project, so I looked it up: https://github.com/MiSTer-devel/Main_MiSTer/wiki No disrespect, but this makes it pretty much a non-starter for most people who would want to use it unless they can get PCBs made, solder surface mount parts to them, etc. The only source I saw for completed boards was a person selling hand made ones on a forum thread and it seems he only had made 50-100 of the boards so far, and was sold out. There's no enclosure and it's just bare PCBs. Again this is no disrespect or anything and I wish 'em the best, and please correct me if I'm wrong. Since the super nt is RGB, there's no palette. In the near future I will be exposing the gamma boost function so you can set it to any value you like, though. (vs. it being preset to 2 values like it is now. off and on). It does.

hah. yeah that's the 5200 Jr, an all in one atari 5200 that fits inside an atari 2600 jr. shell. I made it back in 2002-2003 or so. It has a "Scene demo" style menu I did and real live ripped scene demo music! I was going to make a video about it at some point but haven't had time yet. That orange chiptune player has a few videos about it, and the other is the super nt proto/dev pcb.

that's a good idea. I will pass it along.

Yes it does, sorry. There is not much I can do about that. If more settings are added, it causes the hash to fail and it clears the settings. It'd be extremely difficult and nontrivial to include a way to prevent this happening. Sorry 'bout that. Maybe in the future I will work on a way that lets it retain the old settings when possible.

If 4.0 is up, that means that I can say the fixes are: Mecarobot golf now works perfectly. The cause was the game shuts hdma's off at the very last second, and I still was letting it go through. Note that there is a little bit of scanline fuzz around the middle of the screen below the treeline. I checked on my SNES and it is there, too.. looks exactly the same, so that is not a bug! One line with about 8-10 pixels of "fuzz" and then the scanline directly below has a few pixels of fuzz. The game uses an IRQ to update a ppu reg near the end of the scanline and doesn't quite hit the target. It's possible they didn't catch it due to CRT overscan. The other fix is for mega lo mania. The shield graphic had two wiggly scanlines at the top and middle. This was due to the faster sprite reading for 64 sprite mode (even without this turned off, it still reads them "fast"). The fix was to simply slow it down to normal speed when not in 64 sprite mode. The game uses 64 huge 64*64 pixel sprites to totally cover the screen, and then bankswitches the graphics at the top and middle using hdma. By reading the sprites too fast, it was fetching them before the bankswitching could happen. I am clueless why they did it this way. When the "stars" around it animate, the game turns it into a mode 7 screen (with sprite overlay for the lines) and the issue goes away, which is why it seems to "fix' itself partway thru the intro. That golf issue was mighty hard to find, I have to say. I was sure it was an interrupt or other timing issue.. nope! Glad that one is fixed. I was watching it on signaltap (FPGA logic analyzer) and noticed that a DMA would occur and not occur, and it corresponded to the irq jitter. This lead to the solution. It couldn't have been IRQ timing, since that has been beaten on a lot by mortal kombat 2 and a few other highly timing sensitive games. Joe and Mac appears to be OK, we tested that for quite awhile so no issue there. Stiil working on the other things and I hope to have some more fixes soon. Enjoy!

haha I didn't think of that. It updates pretty fast, several Khz. It updates whenever that pixel is drawn. The pixel is latched when it flies thru the scaler, and the led is instantly updated. Oh yeah, forgot to add. that pixel is captured on the *input* of the scaler, so it won't show the true speed after scaling. Sorry 'bout that. I guess I could make it do that though. If I get time I will change it to monitor the "output" end of the scaler. That would be a cute way to do lag testing.

This is exactly it. The change amounts to around 1 second over the course of 10 minutes.

no, the video is all generated internally to the FPGA. There's several PLLs on the FPGA itself, and I am using those to generate the various clocks. There's around 22 clock domains on the design as it stands. The problem is I would need some non-integer N/M ratio to get the right clock for the HDMI stuff from the 21.47Mhz domain. Right now video gets a clock that varies depending on video mode. i.e. it's 148.5Mhz in 1080p mode. There's no easy way to lock the two PLLs together (the one generating 21.47Mhz and the 148.5Mhz one) in the proper ratio to offer 60.09 hdmi. The video always runs at 60.00 fps and it will cause cycle stealing on the snes side to make it stay in synch with the hdmi for the zero delay mode. If you run full/single buffered, the cycle stealing is turned off and is allowed to free run.

Yeah I usually keep it on too. It was very obvious looking at the PVM vs. flat panel during development that the flat panel was too dark. I cannot output a 60.09fps hdmi signal if that's what people are asking. I can't lock the two PLLs together (system and video) so it's a non starter. Also, I don't want incompatibility issues with monitors that cause it to not work. i.e. someone turns that mode on, without knowing what it does, then after that, the monitor goes dead and they get no video any more.

It won't. I just have to make it smarter than the game. lol. It cannot be added; the ntm has a second, separate CPU that handles power control duty. This CPU constantly reads the controller to determine if you are pressing the buttons needed to power it up, then it fires up the power supplies if you are.

You can, it takes 500ma all by itself, plus whatever cartridge you are using. I found that running an sd2snes took a total of 666ma (really!), and a game genie + super mario world was around 750ma. A supply that can provide 1A or more should be fine (i.e. a lot of TVs can supply at least this much on their own). Just make sure the cable is high quality so there isn't excessive voltage drop. During development I had several cables (they were mainly 'freebies' included with stuff) that had over 1V of drop at 500ma. Yessir. I did all PCB, firmware, and software for it. Ernest did the plastic enclosure design, and manufacturing and packaging (box, etc). Yes, the super gameboy does this as well while it is booting up. The reason is it is doing partial controller reads which is confusing the controller reading state machine. I am going to fix that soon; I believe this is what's causing the interesting controller message on startfox 2. The switchover from automatic controller reading to game-based controller reading is causing it to falsely think a non-gamepad controller is connected. This only happens the very first time it's read, but it is enough to cause the issue. I had to do it this way so that the controller will work in the menu when a game is not running, and then still continue to work when the game runs. This nets "zero lag" controller reading (i.e. I am not simply reading the controller then passing it on to the game) and is quite a bit more complex but IMO worth it. My friend calls these "troll" USB cables. It seemingly looks like any other USB cable, but won't actually pass any data. This was fixed in the 3.9 firmware update. If you map both buttons to the same thing on firmware before 3.7 (I think it was) then you were stuck until you power cycled it. I am not sure how that bug got missed for so long but it did. Now on 3.9 if you attempt this, it will swap the buttons. i.e. if you use A and B for enter/select and then set enter to B, it will swap them. enter will be B, and select will be A.

This means the system detected a corrupt firmware image on the SD card. Try reloading the file onto the SD card, and/or trying another SD card. If that fails, re-download and unzip the update file. The USB port is power only. The data lines are not connected.