FPGA Based Videogame System

[Sneakyturtleegg]

Been searching on the forum as well as in the thread, and I have not found an answer to my follow problem. Any help would be appreciated.

 

On a Jailbroken Nt mini I have an issue where the list of games for a particular core will be truncated and skip large swaths of titles. For instance, for the nes core I can see all the Games from #-F then it will skip to Y and continue until Z. So G-X are missing. This also happens with game boy and other cores as well, just with different sets of games missing.

 

The only thingIn the manual I could find that is vaguely related is there is a section dealing with long files names being "gracefully" truncated to 32 characters.

 

I have had this issue since I received my NT mini which was in early March '17. The only two firmware i've installed were 1.8 and 1.9

 

EDIT: I have an 8gb SD card formatted as fat32

 

Here are some of the solutions I have taken to unsuccessfully troubleshoot the problem.

Unzipped all the files (this is now i naturally keep my roms)

Added the roms in the 7z container.

Removed unusual characters: <>/\?()`'

I have also removed any double spaces

I have removed any non *.nes files such as txt files from the standard rom directory.

 

The only thing I can note is that my collection of roms are largest for the NES and GB.

 

If anybody had any ideas that would be awesome!

 

My 2 cents is to start from scratch. The first thing I would do is download smokemonster's latest N8/NT Mini Rom pack for the NES. It was just released last night (3/27). I would format your memory card in fat 32 with an allocation size of 16kb or 32kb. Don't do the quick format. Next, do a fresh extract of the stock NT Mini firmware v2.3 on your memory card. Load that onto the NT Mini. After that, reformat your memory card again. Put a freshly extracted JB 1.9 firmware on it. Update the Mini firmware with JB1.9. Once that is done, transfer the smokemonster Rom pack to the NES folder on your memory card. It is a few steps, but should work. I did this last night because I was having issues with windows mounting/dismounting my memory card and the Mini displaying double files. It fixed both of my issues. I don't think it is worth messing around with renaming roms. Smokemonster's Rom packs are well organized and just about everything works, with the exception of some hacks. Good luck.

Edited March 28, 2017 by Sneakyturtleegg

[Gandor]

Been searching on the forum as well as in the thread, and I have not found an answer to my follow problem. Any help would be appreciated.

 

On a Jailbroken Nt mini I have an issue where the list of games for a particular core will be truncated and skip large swaths of titles. For instance, for the nes core I can see all the Games from #-F then it will skip to Y and continue until Z. So G-X are missing. This also happens with game boy and other cores as well, just with different sets of games missing.

 

The only thingIn the manual I could find that is vaguely related is there is a section dealing with long files names being "gracefully" truncated to 32 characters.

 

I have had this issue since I received my NT mini which was in early March '17. The only two firmware i've installed were 1.8 and 1.9

 

EDIT: I have an 8gb SD card formatted as fat32

 

Here are some of the solutions I have taken to unsuccessfully troubleshoot the problem.

Unzipped all the files (this is now i naturally keep my roms)

Added the roms in the 7z container.

Removed unusual characters: <>/\?()`'

I have also removed any double spaces

I have removed any non *.nes files such as txt files from the standard rom directory.

 

The only thing I can note is that my collection of roms are largest for the NES and GB.

 

If anybody had any ideas that would be awesome!

I would try splitting the roms into directories. I'll bet there is a limit on how many roms can be in one directory.

If you download smokemonster's rom pack you will see that are already split up in different directories.

[NE146]

Ah yeah good call. That might be it although in my experience that tends to cut off the final part of the directory alphabetically.. not files in the middle. Still worth checking, if it wasn't done that way in the first place. I think 255 files per directory is the rule, although I tend to make it a rough ~200.

[Andromeda Stardust]

Intel has been using the fpga portion of the their low end processors to complete the SoC (bus, timing, pci, webcam, and more) in netbooks for the past 3+ years.

I'm curious, is there any user level access at all to the FPGA portion of these chips?

[Andromeda Stardust]

I would try splitting the roms into directories. I'll bet there is a limit on how many roms can be in one directory.

If you download smokemonster's rom pack you will see that are already split up in different directories.

Yes, this. Famicom Everdrive has a limit of 252 files per directory. Some other models go up to 1000. For the 16-bit systems, you could in theory have up to ~65536 files per directory, but when dealing with thousands of files in a single folder, even if the menu supported it, sorting the directory would be ass slow, and navigating to the desired game, especially if it's in the middle of the alphabet, would take even longer.

 

My workflow when filling a flashcard SD card for the first time: I download a "NO_INTRO" ROMset is to extract the entire archive into one big folder, then extract each of the remaining compressed archives (often they are double compresssed) in one batch operation using a tool such as 7z. Use the "extract to here" option. Next, you'll have a few thousand ROMs and a few thousand compressed archives with the same name. Delete all the individual archived files (.zip, .rar, or .7z) now that you have extracted them all.

 

Now you should have a single directory with possibly thousands of uncompressed ROMs in it. Start with the alphabet beginning with A, create a new folder, rename it "A", and copy all the files beginning with A. Repeat this for the entire alphabet. Some letters such as M or S you will want to split if they have more than ~250 files in them. Some letters can be combined such as UVW and XYZ since few games begin with these letters.

 

Now go back to the directory with 26 subfolders (or however many you used to split the alphabet) and rename it "NES" or "VCS" or whatever. If you select the bottom directory and copy it to the SD card all at once, Windows will typically copy the files to the SD card in alphabetical order, which is important as some flash carts are unable to parse files and directories by alphabet.

 

Sometimes I add new folders specifically for homebrew games as well as hacks in addition to the standard alphabet, to keep them separate from the official NO_Intro ROMset of period releases. It is generally safe to add files to an already preloaded SD card. Just be careful about renaming or deleting lots of stuff as this may cause fragmentation of tiles on the drive (fragmentation may cause errors or corruption when flashing the ROM to memory) or cause files to appear in the order you added them rather than alphabetical order.

 

If the files are not listed by alphabet on the device for whatever reason, there is an application called drivesort.exe that will help you renumerate the files so they appear logically in alphabetical order rather than randomly on the flash cart or device. This will also make sorting faster, for devices that support sorting by filename. Always copy over the OS or BIOS files onto a freshly formatted SD card before you start adding ROMs to it. This ensures the necessary OS files and any games added later will not be fragmented on the card.

 

You should have a directory for the OS and one for the games, or each system the host device supports. Consult Kevtris documents for how to organize the ROMs and folder structure for optimal results.

[phoenixdownita]

Just so I feel even more entitled wrt those pesky speech BIOSes for O^2 .... even the ones that "do not work" are actually correct by a certain definition (all the information is there, nothing was lost, removed or tampered with).

Here it is: the bits are stored one byte at a time in the file but by the other possible endianess and that's it (yeah, there's "bytes in word" endianess and "bits in word" endianess, in this case "bits in byte" endianess).

019.bin file from smokemonster .... first few bytes:

0x17 --->> 0b‭00010111‬
0x00 --->> 0b00000000
0x17 --->> 0b00010111
0x03 --->> 0b00000011
0x17 --->> 0b‭00010111‬
0x06 --->> 0b00000110
0x17 --->> 0b‭00010111‬
0x09 --->> 0b00001001

The other dump of the corresponding file:

0xE8 --->> 0b11101000
0x00 --->> 0b00000000
0xE8 --->> 0b11101000
0xC0 --->> 0b‭11000000‬
0xE8 --->> 0b11101000
0x60 --->> 0b01100000
0xE8 --->> 0b11101000
0x90 --->> 0b10010000

 

Let's see 0x17 when you revert the order of the bits (as in bit0 becomes bit7, bit2 becomes bit6 .....) is 0xE8

check the binary value 0x17 is 00010111 -> reverted -> 11101000 which is 0xE8 (the same binary sequence but in reverse order), you can check the rest of the bytes but it is always the same pattern (obviously so).

 

I spot checked the other 2 files and it is the exact same, bit order within the byte is "reversed".

 

I do not know which one has the right order of the bits in the byte (as in if I make a drop in replacement chip which way would the bus look) as only the original dumpers knows how he/she wired the chips when dumping the data, the "wrong ones" seems to be the ones dumped early on, maybe the dumper crossed the data bus signals (got the bit order wrong) ... who knows. If kevtris dumped them himself whatever the Nt Mini requires is likely the right order (as I cannot even fathom the idea of him crossing the data lines on any chip he "tickles" )

 

But here it is, mistery solved, it's the bit-level endianess!!!

[Sneakyturtleegg]

Possible bug report for the NT Mini NES core. Its a Japanese game, Kaiketsu Yanchamaru 3 (Kid Nikki 3). The core loads the game, but there is a lot of object and character flashing that doesn't look right. Could be the rom dump. Has anybody else tried that game yet?

[Keatah]

I'm curious, is there any user level access at all to the FPGA portion of these chips?

Not in the net books.

[Andromeda Stardust]

Not in the net books.

If the FPGA functions are required to boot the PC, then the "core" is probably embedded in BIOS and cannot be altered by the user after boot. So it seems the FPGA function may be a cost-cutting measure rather than added functionality. I wonder if future CPUs will have their FPGA segments "walled off" to consumer PC users.

[kevtris]

Is anyone having issues with Channel F games? I've got the Roms from the top 3 sites that I could find. I can only get a handful of games to load. I've tried the 3 different bios files too. I got a few more games to work that way, but a majority won't run. I suspect that there may be a bunch of bad dumps floating around and it isn't the fault of the core.

Hmm I will put it on the todo. It's possible there's a bug somewhere.

 

 

I believe that for FPGA to really shine it will need to have cores written by a team. Not one single person. Emulator Mame and Emulator Stella are good examples of starting out as a 1-man endeavor. They then became much more sophisticated because of teamwork. But why stop there?

 

Triple-hybrid rigs are something that's on the horizon. Nothing fancy, but really quite potent. A CPU, GPU, and FPGA in one rig. CPU to handle the OS and outer housekeeping chores, and to manage and coordinate everything. GPU to handle the scaling and CRT effects. FPGA to get the timing right on the original hardware simulations.

 

No special hardware need be designed, no funky kickstarters required. It'll be standard fare on PCs in the next 2 years.

Well I don't see many people writing good FPGA cores for 8 bit videogame systems, so that leaves me. There are some good computer cores though.

 

Page 100. This has officially reached (Well, I'm decreeing it so.) Pretty Freaking Epic. And we haven't even gotten to the actual Zimba3K stage, yet and all of the excitement and hair-pulling that will likely ensue from that future release. Good luck with your other projects, Kev - it's understandable that you're going to be busy for awhile, but your work on the NT Mini has been fab, so far and is a good holdover, for awhile. Far more than I'm going to be able to dig into and appreciate in the short-term, at any rate.

The good news is now that the cores are converted for the nt mini, and mostly debugged (hopefully fully debugged by then!) they will drop in without any hassle, leaving me to concentrate on newer better ones.

 

 

I started playing around with the NES Zapper games tonight. I tested using my Phillips CRT television with the NT Mini hooked up via composite, s-video and component at various points. The Zapper was plugged into the 2nd controller port and the control pad in the 1st port. The games were run off of a SD card on JB Firmware V1.9. NES core settings = controller mode set to standard. I tested almost all of the Zapper/Light Gun games that are in smokemonsters NES Rom set. Here is what I found:

 

Laser Invasion - Inconclusive. I didn't have the time/patience to play the game to the Zapper levels. If you go into options and practice, you need to set the control to Laser Scope (Not Zapper for some reason). Then go to practice - hits would register, but wen't very accurate.

Lone Ranger - Inconclusive. Again, I didn't have the time/patience to play the game to the Zapper levels. Also, I never played it before.

Track and Field II - I couldn't get the Zapper to register when training for the Clay Pigeon shooting event. I am assuming the Zapper is for this event.

*These three games aren't pure Zapper games.They are played with the control pad and have certain levels where the Zapper is optional.

 

Space Shadow - I could get the game to start. The game did register Zapper hits and I could shoot & kill the first monster. But after it was dead, the music continued to loop and the screen stayed in the same position. Control pad didn't work at all. Couldn't progress.

To The Earth - Couldn't get the Zapper to register hits or start the game. I did try switching ports with no luck.

 

Everything else in smokmonsters light gun folder seemed to work fine. Am I missing any Zapper games? If I am, let me know and I will test them. Anybody have the same issues I did? I will revisit the Lone Ranger and Laser Invasion when I have some time to invest.

thanks for the in depth checkout of those games. I put it on the todo and will go over them to see what's happening.

 

@kevtris Save me a few hundred bucks and release a Vectrex core?

Someday! I want to do this really bad so I can play with vector monitor simulation.

 

@kevtris

 

 

Two questions:

 

What audio DAC will you use at Zimba 3000? Will be the same used at analogue nt mini? Or do you are using the FPGA for this?

 

Wich one in that case?: Texas Instruments, Cirrus Logic, Wolfson, ESS Sabre, ...

 

 

Could you think to implement serial I/O ports for Joysticks, MIDI, Mouse, etc... like MiST for Atari/Amiga clones?

 

 

Just curiosity

Yeah right now it's a burr brown DAC so that will most likely stay. It works well and sounds good. I am not sure on those controllers, I kinda want to go USB, but there will probably be a "pony connector" for various hardware expansion stuff.

 

 

Combining a CPU (and maybe even a GPU) with an FPGA is a really interesting idea. But is something like this even possible? Maybe kevtris could tell us more.

I dunno, that's way outside of my league. I tend to like to make my GPU hardware inside the FPGA. The problem though is with the FPGAs we have right now that are cost-effective, it precludes really heavy video processing applications right now (i.e. phosphor dot simulation). Though honestly I am not sure I would go THAT far, because we're getting into silly territory IMO.

[kevtris]

Been searching on the forum as well as in the thread, and I have not found an answer to my follow problem. Any help would be appreciated.

 

On a Jailbroken Nt mini I have an issue where the list of games for a particular core will be truncated and skip large swaths of titles. For instance, for the nes core I can see all the Games from #-F then it will skip to Y and continue until Z. So G-X are missing. This also happens with game boy and other cores as well, just with different sets of games missing.

 

The only thingIn the manual I could find that is vaguely related is there is a section dealing with long files names being "gracefully" truncated to 32 characters.

 

I have had this issue since I received my NT mini which was in early March '17. The only two firmware i've installed were 1.8 and 1.9

 

EDIT: I have an 8gb SD card formatted as fat32

 

Here are some of the solutions I have taken to unsuccessfully troubleshoot the problem.

Unzipped all the files (this is now i naturally keep my roms)

Added the roms in the 7z container.

Removed unusual characters: <>/\?()`'

I have also removed any double spaces

I have removed any non *.nes files such as txt files from the standard rom directory.

 

The only thing I can note is that my collection of roms are largest for the NES and GB.

 

If anybody had any ideas that would be awesome!

 

 

Ah yeah good call. That might be it although in my experience that tends to cut off the final part of the directory alphabetically.. not files in the middle. Still worth checking, if it wasn't done that way in the first place. I think 255 files per directory is the rule, although I tend to make it a rough ~200.

 

Here's how it works:

 

There's a 32Kbyte "heap" for filenames and file pointer information. This means if you have a bunch of short filenames, more of them will fit into memory than if you have longer ones. Filenames are cut down to 64 characters maximum (though only about 28 show on the screen). You should be able to have 500-1000 files at a time, but honestly I think 200-300 is probably better since it will load the directory info faster in that case. The way it reads them is strictly in FAT order, and not alphabetical. This is probably why you had a bunch of stuff in the "middle" missing- it was at the end of the FAT. The menu software reads the FAT entries in disk order, loads them into the heap, and then sorts the list.

 

 

Just so I feel even more entitled wrt those pesky speech BIOSes for O^2 .... even the ones that "do not work" are actually correct by a certain definition (all the information is there, nothing was lost, removed or tampered with).

 

Here it is: the bits are stored one byte at a time in the file but by the other possible endianess and that's it (yeah, there's "bytes in word" endianess and "bits in word" endianess, in this case "bits in byte" endianess).

 

019.bin file from smokemonster .... first few bytes:

 

0x17 --->> 0b‭00010111‬

0x00 --->> 0b00000000

0x17 --->> 0b00010111

0x03 --->> 0b00000011

0x17 --->> 0b‭00010111‬

0x06 --->> 0b00000110

0x17 --->> 0b‭00010111‬

0x09 --->> 0b00001001

 

The other dump of the corresponding file:

 

0xE8 --->> 0b11101000

0x00 --->> 0b00000000

0xE8 --->> 0b11101000

0xC0 --->> 0b‭11000000‬

0xE8 --->> 0b11101000

0x60 --->> 0b01100000

0xE8 --->> 0b11101000

0x90 --->> 0b10010000

 

Let's see 0x17 when you revert the order of the bits (as in bit0 becomes bit7, bit2 becomes bit6 .....) is 0xE8

check the binary value 0x17 is 00010111 -> reverted -> 11101000 (the same sequence but in reverse), you can check the rest of the sequence but it is always the same (obviously so).

 

Spot checked the other 2 files and it is the exact same, bit order within the byte is reversed.

 

I do not know which one has the right order of the bits in the byte as only the original dumpers knows how he/she wired the chips, the "wrong ones" seems to be the ones dumped early on, maybe the dumper crossed the data bus (got the bit order wrong) ... who knows. If kevtris dumped them himself whatever the Nt Mini requires is likely the right order (as I cannot even fathom the idea of him crossing the data lines on any chip he "tickles" )

 

But here it is, mistery solved, it's the bit-level endianess!!!

Ah yes. I forgot about this. Here's what happened: we originally dumped the speech ROMs for the SP0256 in the reverse bit order, because we didn't know what the "official" order was. Bits are emitted and accepted serially to the chip. I bought a GI SP0256 development system off ebay, and thus discovered the bit order was wrong, so I flipped all the bit-endianness around on my files. The ones that work on the mini are the "proper" bit-endian according to GI so that's the ones I use. Fun fact: the odyssey^2 can actually play arbitrary SP0256 speech ROMs, but this isn't supported in the current nt mini firmware. So far I have dumped around 50 speech ROMs and SP0256 resident ROMs from these chips in the last few years.

[Keatah]

If the FPGA functions are required to boot the PC, then the "core" is probably embedded in BIOS and cannot be altered by the user after boot. So it seems the FPGA function may be a cost-cutting measure rather than added functionality. I wonder if future CPUs will have their FPGA segments "walled off" to consumer PC users.

That's right. It is a cost cutting function. My ancient laptop from 2004 has one. Totally not user accessible.

 

It is intel's intent to make these, along with API and libraries, available to the public shortly.

[Andromeda Stardust]

That's right. It is a cost cutting function. My ancient laptop from 2004 has one. Totally not user accessible.

 

It is intel's intent to make these, along with API and libraries, available to the public shortly.

And besides being used for critical system functions, the FPGA likely barely has enough logic elements to perform those critical functions and not much else, if the idea here was to pinch pennies.

 

Maybe someday future CPUs will have enough on die user accessible LEs to emulate a Cyclone V, then you could emulate the NT Mini and all Kevtris' cores!

 

Of course you'd still have inherent emulator like latency reading USB/BT controllers and outputting video to a GPU framebuffer since I doubt the entire GPU could be bypassed completely. On the flip side, you could emulate your CRT masks on 4k displays and all that jazz, with whatever added latency frames that entails. Like my experience with the Retrofreak, the lag was unbearable until I turned off all those frivolous filters...

[gulps]

If the files are not listed by alphabet on the device for whatever reason, there is an application called drivesort.exe that will help you renumerate the files so they appear logically in alphabetical order rather than randomly on the flash cart or device. This will also make sorting faster, for devices that support sorting by filename. Always copy over the OS or BIOS files onto a freshly formatted SD card before you start adding ROMs to it. This ensures the necessary OS files and any games added later will not be fragmented on the card.

 

DriveSort works like a charm!

 

 

I used it for the TurboEverdrive and MegaEverdrive x7. This is one of the best free utilities I found at Windows (maybe there are Linux tools) to order alphabetically all files and folders for the Everdrives. It adds the option to show first the folders:

 

Anerty's Lair - DriveSort (last v1.223)

http://www.anerty.net/software/file/DriveSort/

 

 

Just select the SD, use "order" button (with subdirectories option) and press "save" button.

 

 

 

More info at the Krikzz forum.

[gulps]

gulps, on 28 Mar 2017 - 12:51 PM, said:

@kevtris

 

 

Two questions:

 

What audio DAC will you use at Zimba 3000? Will be the same used at analogue nt mini? Or do you are using the FPGA for this?

 

Wich one in that case?: Texas Instruments, Cirrus Logic, Wolfson, ESS Sabre, ...

 

 

Could you think to implement serial I/O ports for Joysticks, MIDI, Mouse, etc... like MiST for Atari/Amiga clones?

 

 

Just curiosity

Yeah right now it's a burr brown DAC so that will most likely stay. It works well and sounds good. I am not sure on those controllers, I kinda want to go USB, but there will probably be a "pony connector" for various hardware expansion stuff.

 

Good choice! The TI Burr Brown series works fantastic and are well known.

 

 

For the "pony" connector, maybe a standardized DB9 and two/four USB in conjunction ?

[madaspy]

 

 

 

Here's how it works:

 

There's a 32Kbyte "heap" for filenames and file pointer information. This means if you have a bunch of short filenames, more of them will fit into memory than if you have longer ones. Filenames are cut down to 64 characters maximum (though only about 28 show on the screen). You should be able to have 500-1000 files at a time, but honestly I think 200-300 is probably better since it will load the directory info faster in that case. The way it reads them is strictly in FAT order, and not alphabetical. This is probably why you had a bunch of stuff in the "middle" missing- it was at the end of the FAT. The menu software reads the FAT entries in disk order, loads them into the heap, and then sorts the list.

 

I have an update about my issue with my roms not showing up.

Parsing the roms into folders fixed the issue. I have not clue why I thought i could not add extra folders to rom directories.

Kevtris mentioned that more titles will fit on screen if they have shorter file names which is what happened when I deleted extras spaces and symbols.

 

Thank you to the community for suggesting folder parsing, and thanks to Kevtris for detailing what was going on. I really appreciate you translating your technical understanding into a morsel that a lay person can understand.

[NE146]

Check this out.. finally got around to trying SMS, and the colors seem off over Composite (although I'm probably one of the few who care about composite ) I wonder if it's core related?... because the colors on the other cores (e.g. NES, Colecovision) seem fine over the same composite cable. It's kinda hard to take a good pic of a CRT, but this gives a basic idea between the NTMini and a original Genesis running the game.

 

NT MIni

 

Genny/SMS

 

NTMini

 

Genny/SMS

 

If I plug into a hideftv via HDMI, the SMS colors on the NT Mini are good again:

 

So yeah I'm not complaining in the least.. just reporting. Having SMS on this thing if anything is a pure bonus of course.

[AtariNerd]

^Thing is, now that I see the NT Minis version of SMS Composite, with the closer to grey-scale color than the slightly blu-ish on such things as the path and the greater variagation in the greens in that same shot; that along the less-saturated look on the other screens on the Mini in "Composite" Mode, which now look over-saturated on the original hardware or on the Mini in the other modes, I've almost convinced myself the NT Mini version of Composite is closer to the pure off of the chip video of the SMS, before it gets Muggled by the other hardware into any of the other standards. It may not be accurate, but it looks good in my Mind's Eye and I Can Not Unsee.

 

*rubs chin*

 

EDIT: I guess it's just a matter of preference and a pallette swap, but I'm surprised by my perceptions on this, as I tend to be more of a purist.

Edited March 29, 2017 by Standard User

[Sneakyturtleegg]

Check this out.. finally got around to trying SMS, and the colors seem off over Composite (although I'm probably one of the few who care about composite ) I wonder if it's core related?... because the colors on the other cores (e.g. NES, Colecovision) seem fine over the same composite cable. It's kinda hard to take a good pic of a CRT, but this gives a basic idea between the NTMini and a original Genesis running the game.

 

 

If I plug into a hideftv via HDMI, the SMS colors on the NT Mini are good again:

 

 

So yeah I'm not complaining in the least.. just reporting. Having SMS on this thing if anything is a pure bonus of course.

 

I primarily use my NT Mini on a CRT. BY far the best analogue picture on my Phillips 27" is component. I haven't tried RGB since I don't have anything to take that signal. I do have a similar result as you with composite. The color is a bit dull with rainbowing and color bleeding on text and some graphics. I can make adjustments to the TV's settings, but it is a compromise and looks a bit worse. The real systems do look much better on the same video signals on my CRT. S-video on the NT Mini is a step better, but is still a bit dull and not close to component. Everything I said in this post applies to all of the cores except the NES. For whatever reason, the NES core seems to be truer to the real thing on composite and even s-video. All of this is subjective and a lot probably has to do with the quality and variations of the CRT televisions. My LG flat screen in HDMI looks fantastic too.

Edited March 29, 2017 by Sneakyturtleegg

[Great Hierophant]

The SMS displays 6-bit RGB color I believe, so colors should be far more consistent than the NTSC-based NES.

[genfuyung]

@kevtris my soul for a colecovision controller adapter.

[nitro322]

@kevtris, have a question and, I think, bug report for you.

 

I just spent a few days dumping all of my NES carts with CopyNES Mini. Generally worked great, aside from some difficulties getting a clean connection to my carts (is it me, or is the Nt Mini more sensitive than a regular NES? I had a number of carts that work fine in my NES that I had trouble getting to boot in the Nt Mini.). Of the 90 or so games that I dumped, I was able to verify all but one against no-intro.

 

The one that failed is Quattro Adventure, and unlicensed cart by Camerica. You appear to include an appropriate plugin for this (Camerica Quattro Carts), but I'm not able to get a successful dump. I'm consistently getting the same dump over and over, but it doesn't verify against no-intro and doesn't load in an emulator.

 

I did some research and found another plugin for the Quattro carts (CAMERIC2.BIN) here:

http://bootgod.dyndns.org:7777/plugins.php

 

I don't know if those plugins are supposed to be directly compatible with CopyNES Mini, but I gave it a shot and got an interesting result. The internal checksum of that dumped copy does verify, and I can initially boot the ROM in an emulator to the game selection menu, but selecting any game causes the game to fail.

 

I finally downloaded a ROM for Quattro Adventure and verified/played it. It has the same internal checksum as the dump from the bootgod plugin, but the file checksum between the two is different. Upon further examination, it appears that the different plugins are setting different memory mappers in the iNES header:

 

* The downloaded/working ROM uses mapper 232

* The non-working ROM dumped with the included Camerica Quattro Carts plugin also assigned mapper 232, but as noted the internal checksum is different and the game fails to boot

* The partially working ROM dumped with the bootgod CAMERIC2 plugin assigns mapper 1. I'm guessing this is why it initially loads, but then fails as soon as I select a game.

 

So, two related questions:

 

1. Is there something wrong with the Camerica Quattro Carts plugin that can be fixed?

 

2. Should it be possible to use the plugins provided by bootgod with the Nt Mini? or is that expected to misbehave?

 

Thanks again for all your work on this. And sorry for the longish post - kind of a weird issue to explain.

[Reaperman]

So I've been on mine a few days now--holy hell, kevtris, this is an amazing thing you've done.

I don't think it's going too far to say the Analogue NT Mini is the best way to experience many, if not all, of the systems it supports.

 

It handles so many consoles that are otherwise a pain to get connected to modern equipment, and handhelds suffering from fairly annoying screen technologies.

I've really been enjoying the luxury of casually switching systems to quickly compare ports of specific games.

 

Anyway, I'm sure you're well aware that the system is great already, but I had to chime in.

Now, back to playing random ports of Montezuma's Revenge, because that's a thing I do now.

[kevtris]

@kevtris, have a question and, I think, bug report for you.

 

I just spent a few days dumping all of my NES carts with CopyNES Mini. Generally worked great, aside from some difficulties getting a clean connection to my carts (is it me, or is the Nt Mini more sensitive than a regular NES? I had a number of carts that work fine in my NES that I had trouble getting to boot in the Nt Mini.). Of the 90 or so games that I dumped, I was able to verify all but one against no-intro.

 

The one that failed is Quattro Adventure, and unlicensed cart by Camerica. You appear to include an appropriate plugin for this (Camerica Quattro Carts), but I'm not able to get a successful dump. I'm consistently getting the same dump over and over, but it doesn't verify against no-intro and doesn't load in an emulator.

 

I did some research and found another plugin for the Quattro carts (CAMERIC2.BIN) here:

http://bootgod.dyndns.org:7777/plugins.php

 

I don't know if those plugins are supposed to be directly compatible with CopyNES Mini, but I gave it a shot and got an interesting result. The internal checksum of that dumped copy does verify, and I can initially boot the ROM in an emulator to the game selection menu, but selecting any game causes the game to fail.

 

I finally downloaded a ROM for Quattro Adventure and verified/played it. It has the same internal checksum as the dump from the bootgod plugin, but the file checksum between the two is different. Upon further examination, it appears that the different plugins are setting different memory mappers in the iNES header:

 

* The downloaded/working ROM uses mapper 232

* The non-working ROM dumped with the included Camerica Quattro Carts plugin also assigned mapper 232, but as noted the internal checksum is different and the game fails to boot

* The partially working ROM dumped with the bootgod CAMERIC2 plugin assigns mapper 1. I'm guessing this is why it initially loads, but then fails as soon as I select a game.

 

So, two related questions:

 

1. Is there something wrong with the Camerica Quattro Carts plugin that can be fixed?

 

2. Should it be possible to use the plugins provided by bootgod with the Nt Mini? or is that expected to misbehave?

 

Thanks again for all your work on this. And sorry for the longish post - kind of a weird issue to explain.

Yeah I think it might've been to dump the Aladdin versions of those games, since they work a bit different. It's been a very long time now so I am not sure.

 

If you wish to use other plugins that other people wrote, you can do this. You have to modify the plugin slightly, however. Replace byte at location 0x007f in the file with your desired mapper number. i.e. if you want mapper 32 decimal, you would put 20h at 007F in the file. That's the only change you need to make. If you don't make this change, it will dump as mapper 0 (or whatever is in this byte) and you can change it later on the PC with a header editor. The first 128 bytes of the plugin are reserved for a description and don't do anything else, so you can edit that byte without impacting the functionality of it.

 

So I've been on mine a few days now--holy hell, kevtris, this is an amazing thing you've done.

I don't think it's going too far to say the Analogue NT Mini is the best way to experience many, if not all, of the systems it supports.

 

It handles so many consoles that are otherwise a pain to get connected to modern equipment, and handhelds suffering from fairly annoying screen technologies.

I've really been enjoying the luxury of casually switching systems to quickly compare ports of specific games.

 

Anyway, I'm sure you're well aware that the system is great already, but I had to chime in.

Now, back to playing random ports of Montezuma's Revenge, because that's a thing I do now.

glad you're enjoying it! Yes, I too wanted to be able to play all these obscure things in the easiest way possible. Many of the systems didn't even have emulators available, or if they did, poor quality ones at the time.

[atmn]

Now, finally I have a fully working console and can focus on the games.

Have to mention that Analogue exchanged my console without a hassle. I have talked about my faulty analogue port in this thread. Just want to clear that out.

 

 

Tried the HVC-051 Famicom network controller with the Colecovision core. Holy smoke, thanks Kev for adding this controller into the cores that uses numpad controllers. Perfect!

 

Soo looking forward to the Intellivision core, I have always wanted to play this system with a decent D-pad.