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.

I have a slight soft spot for the Epoch Game Pocket Computer too, so if Kevtris needs a system to RE, I can send it to him. However, almost all (?) the RE-work has been done on this system. Anyhow, here's my page on it: http://www.chrismcovell.com/GamePokekon/index.html (Um, and the now-defunct tech-info page: https://web-beta.archive.org/web/20120702170734/http://www2.odn.ne.jp/~haf09260/Gpect/EnrGpt.htm )

OK, here's a comparison of Rolan 2 in the NT Mini GB core (green-hued pic) vs a capture from a Famicom + WideBoy + cartridge (greyscale pic). Rolan's Curse 2 does a weird diagonal warp even on the real hardware; however some garbage at each scroll transition is visible on the NT Mini.

Sorry, I'm just jerking your chain. I know you're probably incredibly busy with multiple things at once. I just want to know how to write bug reports / requests in a way that none of their contents gets overlooked (as I'm paranoically starting to believe...)

Kevin, I noticed some (diagonal) graphic shearing during the title warp-in to Rolan's Curse 2 on the GB. Did you know about it? This is in RGB, and is regardless of the framebuffer setting. Also, any comment to my request for (or plans to put in) Action Replay code support for the GB/GG/SMS?

More on the FDS RAM adaptor, I have another one with an HVC-02 board. It has a Hitachi SRAM for U1, and 4 DRAM chips for U3,4,6,7. This RAM adaptor starts fine in the NT mini, but disk loads fail in the same way as my other one.

Thanks! It already sounds quite good in the NT mini SMS core.

I'm not sure if you noticed my 1st post on page 84 ( http://atariage.com/forums/topic/242970-fpga-based-videogame-system/page-84?do=findComment&comment=3718588) but I'm running the NT in RGB all the time, and I tested a real FDS drive, as well as 3 different types of FDSEmu/FDSStick (8 disk side, 256 disk side, SD card) and all failed _most_ of the time for me. (my RAM adaptor says "HVC-FMR-04" and appears to use a Fairchild SRAM for U1, and the common Sharp SRAM for U3.) You can test individual SMS FM settings with my tool here: http://www.chrismcovell.com/data/SMS_FM_Tool.zip Not sure which emu is the most accurate to the real SMS/MkIII; perhaps you have real hardware to test it on too.

I tested my FDS RAM adaptor a bit more, and even ran the test feature with it (hold start & select on power-up) and VRAM, SRAM tests seem fine. There seems to be no graphical corruption for a correctly-inserted RAM adaptor, and the BIOS menu runs properly. So, the cartridge part of the FDS appears to be fine. What fails is most/any kind of loading from the drive. Do you have bad IRQ handling or something, Kevin? Also, more bug reports: the FM chip on the SMS has buggy per-channel sustain emulation. I tested it out with my own FM ROM tool and the "sustain" option for each channel appears to have no effect, contrary to what the real hardware does.

Hi, folks and hi, Kevtris. I received my NT mini last weekend, and it's fantastic! I'm running it through RGB on a CRT monitor. Anyway, is this the best place to post error/bug reports, or do you have a preferred forum? So, some bugs (core just prior to 7800 support): I guess you know the GBC core is unfinished, but the audio pitches are messed up & volume sliders don't change anything in the menu. I ran Snow Bros. Jr in both the GB and GBC cores and could really tell the difference. NES Solstice, both on cart and in the JB core, has scratchy static coming out of the noise channel (heard in-game). If the noise channel is set to 0, static stops, but even at volume level 1 (see pic) it is heard. (Not a bug, but if you have sprite limit set to 16, some garbage is seen in the Solstice intro.) FDS loading via RAM adaptor (and real FDS disk drive) in the Fami slot does not work at all. This is a shame. Loading stops / games crash during initial load. Also, several FDS NSFs, such as 3-D Hot Rally, Ai Senshi Nicol, Almana no Kiseki, etc. crash or go off the rails a few tracks in, in the NSF player. So, perhaps your Fami core does not properly enable all the (cart) RAM space needed for FDS games, or there are bus/address range conflicts with some other registers, or something? My wish list: Please re-enable the Famicom expansion controller for other game cores & the NT menu. That's the only way to add rapid-fire joypads on original Fami hardware, and I'd love to keep using mine for playing games in other cores. Could you add Action Replay support to cores such as GB{C}, Game Gear, SMS? These simply write some value to RAM each VBlank (not so hard to do) and there are plenty of codes out there already for these systems. Ideas for other users: If you want to listen to GB music, try tracking down .GBS rip packs that have standlone .GB music ROMs as well. If you want the GB Boot ROM to scroll down & finish faster, hex edit location $0049 in the bootstrap ROM from value $0C to something lower, like $04, $02 or $01.