Jump to content

blzmarcel

New Members
  • Content Count

    67
  • Joined

  • Last visited

Community Reputation

16 Good

About blzmarcel

  • Rank
    Star Raider

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. From what I've tested for a good three months on a friend's Mister setup, systems like NES, Genesis, SNES, TG16, 2600, AO486, don't have any slow down that wasn't present in the original system. NES and Genesis especially were known for slow downs with too many enemies on the screen. NES SMB3 on 1-2 where ones does the gumba 1-up trick. On a real NES (which I tested on my original on a CRT tv) it gets bogged down after several gumbas have spawned in from the pipe and the Mister matches this behavior exactly with default options.
  2. I noticed this thread when I was browsing No-Intro's forums, and it looks like the general conclusion made there is that the No-Intro S&K + Sonic 2 rom is just the two individual roms directly combined one after the other, without any modifications. The author hypothesized that the reason is that resulting rom layout should be as it would be with real carts, and the responsibility for reading and acting accordingly should be on the system running the game, which sets the correct values and such, like a real Genesis/MD would when it detects something in the address space after the main S&K rom. This makes a lot of sense to me and would indicate that the MegaSG isn't behaving exactly like a real Genesis/MD for S&K lockons.
  3. Assuming you're referring to vanfanel, he did state several facts. I have seen and heard the tearing and audio issues that he mentioned first hand, so he is right, and so far no one has addressed that, neither by you nor Mattlelot, who described the MiSTer implementionations as "garbage", which from what I have also witnessed first hand as a friend of mine has one set up, every core we have tried works really well and does not have those issues mentioned before. There was also a very recent update adding 5x crop capability to most of the main cores which also works really well.
  4. Even if it were possible to use NES cartridges with a Pocket, NES cartridges were fairly large, about twice as tall as a Famicom or Genesis/Mega Drive game and wider too. You would need some kind of adapter that either holds the game under the Pocket, or have it stick way out in the air, both of which likely wouldn't be very comfortable, practical, or be able to fit in any but the largest cargo pockets. Sega was able to make the Nomad that used Genesis cartridges due to their rather compact size for a home console cartridge and NEC was able to make a portable that could run PC-Engine/TG-16 HuCards, which again was feasible mainly due to being relatively compact, though neither of those were pocket-able systems, as they both had a bit of bulk to them. Famicom (and maybe SNES/SFC) games might be more workable, as they are short like a Genesis cartridge, but still a bit wider, so it would still be a rather bulky set up. But NA/EU style NES cartridges? It's hard to see a practical way to implement that. They were simply never meant to be used in a portable system.
  5. IIRC, the NES 2 (top loader) didn't do any lockout checks, which is why unlicensed games like Little Red Hood can be played directly without a licensed cart attached S&K/GameGenie style on the pass-thru slot, so it seems very unlikely that there would be a kill switch based only on the CIC lockout.
  6. @Kaide That may be true about MAME, but what about this (as I mentioned in one of my previous posts) ? I have cloned the repo to my hard drive and searched through it and couldn't find any sort of list of games or checksums/hashes/etc. I even searched the binary release in a hex editor and couldn't find anything there either. Over at that friend's place where he has it set up, we threw every home brew, prototype, and demo we could find at it and it just ran them, so it seems the author of that core found a more abstract/generalized approach, which leads me to believe that there is some way of determining what a game needs (what mappers, etc) from the main ROM data itself, which might be worth more study.
  7. Some good points, though my point is that there was some kind of header early to help emulators do the right thing, but afaict nothing of the sort existed at all for Intellivision ROMs at all until recently.
  8. What I'm wondering is if the mappers as similarly important for the Intellivision as they were on the NES, why wasn't there an equivalent of the iNES header prepended to the ROMs early on? This was recognized as a necessity for NES ROMs going at least as far back as ye olde NESticle emulator. I've seen people mention there were cfg files, but packs like the Everdrive and MAME sets don't seem to have any. I tested in both MAME and on my friend's Mister again, both of which ran every homebrew, demo, and prototype from the Everdrive set that was thrown at either without any issue. In the Mister case, we browsed from a computer and couldn't find any cfg or similar files that were generated (since it's a third party core (github/source code) that didn't come with the system.) This makes me wonder if there isn't already something in the ROMs that lets newer emulators and cores know how to treat them, especially if homebrews and such run just fine.
  9. I'm all for adding extra information similar to iNES headers, and agree that it's nicer to have everything together in one file, though that extra information still needs to be read upon loading, so in the end it really shouldn't make much of a different where that needed info is read from (from a header/footer, or accompanying file.) Is it really known which order actually matches the original ROM? Even if it was read directly from the chips, from what I know, that should be the same data that would be read through the edge connector (by an Intellivision or a proper dumping tool.) Aside from the NT Mini (and I assume also other Analogue systems), emulators and FPGAs that that support Intellivision all assume the byte order of the long established ROM set that's been out there for decades. So why was this necessary for just this one system and not all of the others? I did a test with the int2intv tool, using Frog Bog, and found that it is adding to both the beginning and the end, and not just the end of the file: Frog Bog (1982) (Mattel).int (Matching: <rom name="frog bog.50" size="0x2000" crc="37222762" sha1="58842e4425ad5a8f6ec65528c4b485039057f289"/> from the MAME intv.xml hash file.) 00 66 00 56 00 1C 00 50 00 91 00 59 00 71 00 50 .... 02 90 00 80 02 0C 00 03 00 12 01 C9 02 51 02 B7 Frog Bog (1982) (Mattel).intv (Using int2intv -m 0, with a -m value of 0 going by the spreadsheet linked from the int2intv github page.) # Added header section. 00 50 00 00 00 10 00 00 # Same bytes as original, with every pair of bytes swapped (16-bit dword endian flip.) 66 00 56 00 1C 00 50 00 91 00 59 00 71 00 50 00 .... 90 02 80 00 0C 02 03 00 12 00 C9 01 51 02 B7 02 # Added footer section. 00 00 00 00 00 00 00 00 Due to the added information to the start, in addition to the byte endian flipping, I don't see how INTV2 (.intv) files could be used with all the other emulators out there. If the header wasn't added (but rather just the footer) and the bytes weren't flipped, then yeah, it would probably work in most emulators, but from what I can see, people will need to have two (three when counting MAME, due to the zipping and different file naming) separate sets of files, wasn't granted, isn't a huge deal, as the full Everdrive set for Intellivision, including home brews, prototypes, demos, and all the regular games, is less than 4 MB total.
  10. I'm honestly a little confused. What do you mean by "core's native architecture" ? It is my understanding that with FPGA, the architecture of an original system is being replicated, all the chips, processors, circuits, et al, and thus all of the original behavior of said system. I assum what would happen (and what appears to be the case with other FPGA systems) is that the data from a ROM file is handled the same way an original system would read the ROM data from a cart, as AFAICT, the .int/.bin ROMs that have been around for quite a while are the original binary 1:1 dumps of cart ROM which any other FPGA and emulator expects. But the NT Mini (is this also true of the Super NT and Mega SG?) needs a change of endianness which still strikes me strange that no other FPGA system or emulator requires this.
  11. Don't know, but I recall when the byte order of N64 ROMs was a deal because your backup unit used Big or Little Endian. Considering that the Jailbreak is going to run them like a backup unit might then they need to be mapped to memory correctly. Still, I expect it should recognize something like that and flip the byte order if needed. What I do find interesting is that the NT Mini seems to be the only platform to need the INTV2/.intv format. I noticed, when I was looking through a recent Everdrive pack that I found, that the included Intellivision roms all matched the checksums of the ones that I've had since somewhere around 1999, which also match the ones from both older MESS and newer MAME sets (within the .zip files), as well as the ones used for standalone emulators and Retroarch cores, and even the Mister core (which I recently tested at a colleague's home, using the Everdrive set), which are all .int/.bin and in the format that int2intv.exe expects on the input side. I know people here have explained that the issue is one of endianess, and I understand what that means, but what is strange to me is that nothing else that I can find uses the INTV2/.intv versions of those roms, so why is the NT Mini so different than all the rest?
  12. Thank you, this really helped, as I'm aware of other systems, like the C64, that also used bank switching techniques. Cheers and Merry Christmas if applicable :)
  13. Thanks. Might I ask why the mapper chips aren't dumped along with the CHR and PRG ROMs? I'm not too keen on what mapper data looks like, I was mostly just aware of the two mentioned ROMs.
  14. I've sometimes wondered why an original NES or Famicom would know what to do without any such header, yet emulators always seemed to need it. Conventional thinking would be if an emulator is doing what an original system was doing in reading and parsing the data on the cart, though there is likely something more to it otherwise this would have been solved a lot more easily.
  15. Good point. The headers are information tacked onto the beginning (hence the 'head' in 'header') of the image file but the rest after that is the binary data from the cart. Such headers serve a similar purpose as a .cue file for a cd/dvd/bd .bin, to give additional information about a binary image.
×
×
  • Create New...