ccovell

It's alright, I certainly can wait. Please take days off, take a trip; you deserve it.

I knew you would say this so of course last night before making my post I re-downloaded plenty of NSFs and tested them again. I used JoshW's archive linked from here: http://www.vgmpf.com/Wiki/index.php?title=NSF -> http://nsf.joshw.info/ With so many of them working in players on the PC yet failing on the NT Mini, I don't know what to say. They could, in theory, all be dirty rips. I'll check one or two of them out in a debugger, but could you at least look into your NSF player for a bug causing crashes / glitched music? You might remember many pages back that I posted oscilloscope traces of a failed FDS load on the NT Mini, and you said that perhaps you needed to add a stronger filter to the IRQ line in your FPGA core for the next release?

Hi, Kevtris. I know you're nonstop busy, but I still hold out hope that you can someday fix the NT Mini core bugs, like the FDS IRQ not working on both my RAM adaptors on the Mini (meaning no loading of FDS disks), and the SMS FM sustain emulation being somewhat broken... But did you know that the NSF player core has several bugs? The most disappointing one for me was in FDS NSFs. From my quick test of Konami & Nintendo NSFs, the following FDS ones simply crash/freeze the player: Exciting Boxing, Exciting Soccer, Green Beret, Famicom Golf JP Course, Zelda II (Link no Bouken), Time Twist, Doki Doki Panic. Some FDS NSFs will play, but will crash / play obvious erroneous notes starting from a certain song number. These include: Almana no Kiseki (crashes from song #9); Dracula II (#2); Exciting Baseball (#4); Gyruss FDS (#2); Meikyuu Jiin Dababa (#3); Famicom Golf US Course (#C); 3-D Hot Rally (#5)

I posted some tests with 2 FDS RAM adaptors (which failed on the NT mini) and 3 different FDS drive/devices earlier last year. Kevin himself said that "all he has to do" is filter the IRQ on the NT mini, but we're still waiting for some kind of fix. Kevtris... hint, hint, nudge, nudge, punch, punch. My posts: http://atariage.com/forums/topic/242970-fpga-based-videogame-system/page-109?do=findComment&comment=3738175 and http://atariage.com/forums/topic/242970-fpga-based-videogame-system/page-95?do=findComment&comment=3723160 and http://atariage.com/forums/topic/242970-fpga-based-videogame-system/page-93?do=findComment&comment=3722264

The jailbroken NT mini doesn't play .FDS files yet. For some people (at least myself) when an FDS RAM Adaptor + FDS drive are used with the NT Mini, games fail to boot / load properly: http://atariage.com/forums/topic/242970-fpga-based-videogame-system/page-109?do=findComment&comment=3738175 I still have hope that this gets fixed sooner rather than later...

The FM sound is a bonus, but I am disappointed that it is a bit off, not just harshness problems. I pointed out a specific bug in an old post: http://atariage.com/forums/topic/242970-fpga-based-videogame-system/page-92?do=findComment&comment=3721883 there and on the following page.

And can you give us guided tours through your house, kinda like at Graceland?

Yes, I've seen this problem before on a couple CRTs when using the Super GameBoy, WideBoy, etc. as the SGB screen is usually a small(ish) bright white square in the middle of blackness; I figured this played havoc on the electron gun or something. It's not something the NTmini specifically is causing, but one solution could be selectable borders in the GB/CGB etc core?

Fixed-point math and lookup tables, c'mon. Nah, I joke. I guess you used a really beefy FPGA for that one, and it was just an experiment, right?

Kevin, this is apropos of nothing, but would it be possible to make your Mandelbrot generator work on the NT mini?

I think it is hit and miss. I have 2 FDS RAM adaptors, HVC-02, and HVC-FMR-04 (one with SRAM and one with DRAM) and both of them crash early during disk loading, no matter whether it's from a real disk or FDSStick. Looks like it might be a lack of filtering for the IRQ line in the NT mini... (Let's hope you are lucky.)

According to the update log in the firmware readme, older versions of the firmware DID allow the NT mini menus to be controlled by a Famicom controller in the FC expansion port, but Kevin took this feature out. I made a request that this feature be put back in, a couple dozen pages back. :[

Cool. Again it's possible that IRQ differences might not be causing the problem, but are just a sign of a problem elsewhere. I look forward to seeing if things get fixed up. Also, did you see my GB bug post 2 pages back?

A look into why FDS games fail to load for many people using a RAM adaptor & real FDS hardware... An "FDS mapper" built into the NT mini's NES core sounds nice, but some of us have real hardware that we want to keep using. Anyway, I have started probing pins in the RAM adaptor cable, comparing FDS disk loading on a real Famicom vs. the mini. First I probed the "read data" signal on pin 4 of the blue 12-pin connector, where disk data hits the RAM adaptor. No differences between the Fami and NT mini. So, data coming in to the RAM cartridge is fine. I then tried loading a disk on the NT mini, which failed, and used CopyNES to dump the contents of RAM/ROM. The PRG files seem to load into RAM mostly fine, all the way up to $DFFF. I then checked the /IRQ pin on the Fami connector to check for differences. The IRQ signals seem to come in OK, as seen in the 1st picture below, showing the 1st IRQ triggers to the Famicom/NT when data comes in from the disk drive. However, at the VERY END of load, oh dear: (This might not be connected to the end of loading; stray IRQs might be triggering at random times during disk activity, but it happened in the same place a few times, causing the final load to fail, and the program loaded in to memory to not start.) Kevin, I hope this is helpful. Again, if there is a better place (um, less "crosstalk") to post bug reports or tech questions, please let us know.

Hi, Kevin. I noticed another bug in the Gameboy and Gameboy Color cores. There is random garbage on the right side of the GB's display when any sprite has its X-position set so that 1 pixel is visible on-screen (on the right side). On a real GB[C], a single column of the sprite's leftmost pixels would of course be showing, but in your cores, it's an 8-pixel column of blank/black/shimmering garbage. See the attached picture. This is most noticeable in the GBC core because the garbage usually shows up as a shimmering mess of blue; however it is there in the GBC core for regular GB games, as well in the GB core. You can spot this bug in many games, but I've picked Alfred Chicken because its background colour is a medium grey, showing the "white" garbage in the GB core, and "black" garbage in the GBC core. The scrolling platforms at the end of the 1st stage of Super Mario Land is also a reliable place to find them. You'll notice that even when the GBC core has its sprites set to orange/sepia as an alternate palette, the garbage still shows up as a different colour, like blue or green.