Jump to content

blzmarcel

New Members
  • Content Count

    74
  • Joined

  • Last visited

Community Reputation

19 Good

About blzmarcel

  • Rank
    Star Raider

Recent Profile Visitors

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

  1. Not sure if that is a good comparison, as the 3DS does not advertise any capability to play games of other consoles (outside of any virtual console stuff at least, if TG16/PC-Engine games were on it), while the Pocket does advertise being able to play Gameboy games, IIRC, so it stands to reason that it should work, or am I misunderstanding something?
  2. I was referring to this: Which isn't a jailbreak issue, since that doesn't exist yet for the Pocket, but something at the stock firmware level.
  3. I'm not yet very keen on these .pocket files, but it'll be far nicer to have a rom loader to load regular rom images proper. I really do not believe that the world needs yet another proprietary / device specific rom format.
  4. It's these crashing and other issues that keep coming up that kind of bothers me. These are systems that have been advertised as being 100% compatibility, due to using FPGA to recreate the original hardware, yet some games are not acting like they would on original hardware. And while I don't want to bring up other systems, I have not observed these sort of compatibility issues on the likes of the Mister, including Metroid II on Gameboy, as well as those SMS games like Desert Strike, and other examples I had previous checked on, after seeing posts here, when I was able to use my friend's Mister. Do not misunderstand. Analogue makes some great systems, but it's hard to feel complete confidence that all of the original behavior of these classic systems is being properly replicated here. And a lot of that stems from the closed source nature, which I understand the reason for, but at the same time it is hard to deny the benefits of have cores open to the community, as there is a very clear difference in how fast issues get resolved with Analogue's cores vs. something like the Mister's or even libretro cores and mame as well. Again, I'm not knocking Analogue here, just saying that the difference is pretty clear and perhaps that they should consider opening the cores themselves, while keeping everything closed, so that they themselves don't have to keep struggle to find time to address every little issue for a given core (whether built-in or "jailbreak".)
  5. By the way, while using -exec rm {} \; work fine, this can be done more directly (and more efficiently if there are a lot of hits) with -delete instead, as it's a built-in feature. So you can just use: find / -name ".DS_Store" -depth -delete Further, according to the documentation [1] for find(1), the use of -delete implies -depth, so this can be reduced to just find / -name ".DS_Store" -delete [1] https://www.man7.org/linux/man-pages/man1/find.1.html This should apply to any version of findutils from at least the past decade, if not further back.
  6. Last post was on the 7th of this month. Not what I'd call dead. From what I've been hearing, both the Noir and higher end Everdrives can handle that. For the former, there are some menu options to adjust when using running from an SD card for cartridge audio.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. @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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...