Jump to content

kevtris

+AtariAge Subscriber
  • Content Count

    813
  • Joined

  • Last visited

  • Days Won

    20

kevtris last won the day on March 23

kevtris had the most liked content!

Community Reputation

3,071 Excellent

2 Followers

About kevtris

  • Rank
    Dragonstomper

Contact / Social Media

Profile Information

  • Custom Status
    FPGA Whisperer
  • Gender
    Male
  • Location
    Flyover, USA

Recent Profile Visitors

64,560 profile views
  1. Is the mapper for this game documented anywhere? I looked but didn't find much. Oh yeah, and why is the ROM size off? it's 8195 bytes vs. 8192.
  2. Yeah, and those investors are going to want some return on that investment. If it's like most of these projects, they have some say in what happens if they don't turn a profit in X time.
  3. The problem is they vastly underestimate how difficult it really is, and figure they can just pay someone to do the work for them and they'll sit back and count the money as it rolls in. Polymega only got what, 600 grand or something? That sounds like a lot, but when you need to make all those plastic molds, and have a large monthly burn rate (salaries, building rent, etc) it goes fast. Then they have to have some money left to actually make the product.
  4. There once was a man in France, who had his hands down his pants. Some day they'll see our glowing LED, but without engineers, there's no chance. (sorry, I had to)
  5. the board looks good. does it work is the question? (I don't know if they showed it running yet) I also don't know if it will fit in their original plastic box. There's no way they will reach consumers by the end of the year if it is not in production right this second. What's another 6-12 month delay at this point? haha. There's no cooliing solution shown either, but there are mounting holes for it.
  6. I was very close to making the SNES 'refresh line' an option you could toggle on and off for lulz. Don't make me do it 🙂
  7. thanks! looks pretty easy to implement.
  8. xboard didn't exist at the time, so no. If you can find a spec and how it works it could be added at some point. melody games won't run because it'd need to emulate an ARM CPU
  9. it's a unique mapper, and it's UNIF format on the ROMs.
  10. I can vouch for the customs in Andorra being the weak link on shipping. My mega sd was stuck in Andorra customs for around 12 days, then it made the rest of the trip in 2 days. Quality is top notch on the box, cart, and PCB design.
  11. The lynx is 8 bits, it uses a 65C02 as its CPU. I'd consider the TG-16 an 8 bit machine also, regardless of the marketing, because its CPU is also 8 bits. The intv is indeed a 16 bit CPU, however, even though the ROMs were usually 10 bits wide (but don't have to be). They got away with this, since there's 1024 opcodes (2^10). To represent 16 bit values there's an extension instruction. Interestingly, the ROMs must return 0's for the upper 6 bits, or else nothing will work properly.
  12. I was talking about how the demo version won't let you proceed. I didn't find the RAM test stuff until later when I got the full version. Interestingly, most games clear RAM out to a known state (all 0's for example) so this isn't a problem. Only a poorly coded game or piece of software relies on the random RAM contents on initialization, because it cannot be relied upon to be in a usable, workable state when the software runs. I highlighted two other Coleco titles with a random number problem because of this earlier, and have found others on other systems. I consider a piece of software broken if changing ram contents causes the game to crash or fail in some way; because this can happen on real hardware by chance. There is no guarantee that say, my Coleco will have compatible RAM trash to your Coleco. Coleco could've used different manufacturers for the RAM in the systems depending on date of manufacture, or simply whatever they could buy cheapest that month for production. It's very possible some brands or revisions of RAM produce all 0's or FFs, or some other static pattern. I have some Motorola 8K SRAM chips that output 0xAA for every location on powerup. Granted, these are military rated parts, so this could be in their spec to prevent problems like this. (For those that are curious) I have actually researched RAM power up values for different kind of SRAMs; specifically 6116 and 6264 and 62256 style SRAMs (2K, 8K, and 32K static RAMs such that are found in many NES era to SNES/genesis/gameboy era systems and carts). Their powerup patterns tend to be repeating blocks of mostly 00 and FF, with the spacing of each run determined by manufacturer and chip size. While the data is mostly 00's the FF's, it is more complex and there will be plenty of single bit flips. These can be static, or change on every powerup, or only sometimes on subsequent powerups. The exact behavior is determined by voltage, temperature, the silicon process itself, and tiny imperfections. It is very possible that some RAMs have a lot of these single bit flips, and others will have very few. The latter will trigger on the first memory test as a failure and the game won't run. It is acceptable to hash the entire contents of RAM (or some portion of it) to generate some entropy for a random number generator, but that is the only valid use of checking uninitialized RAM. On several NES games, they will use two bytes for random number generation. They use whatever value was in RAM as the starting seed but are safe about it. If for some reason, the 16 bits hold 0, it will write a fixed seed into RAM so that the game will function even in this case. Coleco could've learned a thing or two about this for THEIR random number generator! They do not do the test. Also, reading uninitialized RAM is such a problem for current day developers, that many emulators will actually throw a warning if you do it. The easy solution is to simply clear RAM out when your code starts.
  13. I have no reason to contact you about the game; it was having issues on my hardware but turns out it wasn't my hardware after all, and was the game. This means I have to debug it to find out why it happened. I got interested when things didn't add up, and fell down the rabbit hole of figuring out exactly why it didn't work. This is basically my job, to debug why videogames don't work on my hardware. As such, this was just another thing to debug and I approached it like any other game that had problems. That's when I discovered that the problem wasn't my fault. The rest of the procedure was documented on my blog. I am free to explain what I found during the course of the investigation; it was interesting and I figured others might want to see, too. All I did was pull the curtain back a little on what was lurking inside when I discovered the cause of the failure was something more than a garden variety core bug of some kind. I am not saying anyone is lying, but the functionality of those two checks is not in doubt. They are defacto designed to stop it running in certain places. There is literally no other purpose for it. Sending the program counter into the weeds using a bogus PUSH BC : RET leaves no doubt why it was there. This will do nothing but crash the CPU, since no valid address is ever put into BC, and the state of BC depends on what happens before. The DJNZ before that point though will keep it looping through the checking routine for quite awhile and may never actually break out of it. Obvious obfuscation was obvious at the very start of code too. Adding 0x2a to HL and pushing it onto the stack to build a jump address was pretty humorous, and was a giant screaming red flag that I was about to find something really good a bit farther in, and I sure wasn't disappointed. Adding something to HL before setting it up wasn't the smartest way to hide it- I just had to look at what the BIOS did after reset, which is load the start address into HL and jump to (HL). If you want to really learn how to obfuscate, I did a nice writeup on how I reverse engineered the Famicom "pirate original" Earthworm Jim 2 game. It used some truly insane things like strings of seemingly random code that actually manufactured critical routines in RAM, and writing to bank select registers in the "middle" of what looked like a function, but if the bankswitch doesn't take place the code will eventually crash. They hid the bankswitch register using mirrors of it and long strings of what looked like mapper initialization code which really didn't do anything of the sort. They also hid code in what looked like data tables. The link to that is here: http://blog.kevtris.org/blogfiles/EWJ2PROT.TXT
  14. Come on, I wasn't born yesterday 🙂 I have been poking and reverse engineering games for a long time now since I have to implement hardware that runs said games. When things go wrong, I have to break out the disassembler and debug tools to find out why. I never saw the game fail in any way on emulators or my own FPGA Coleco hardware, other than not being able to progress past level 1 (on the demo) or before adding RAM data pattern initialization (on the full version). The game isn't doing anything tricky at all, and isn't stressing cycle accuracy or timing. Having two ROMs for PAL/NTSC makes perfect sense and is a good way to go when it comes to localization. The shielding is only there to keep the FCC happy and serves little to no electrical purpose outside of this. It is not required for operation and just keeps radiation from the digital logic from ripping up your neighbour's TV. (though honestly their TV would have to be pretty darn close. Maybe in an apartment? If so, I feel bad for my neighbors of years past for all the electronic stuff I ran without shielding!) The digital trash might leak into the RF if you're using RF to connect your Coleco to the TV. This was a problem on the 2600, but I ran my Coleco for years without the shielding on RF without an issue. (interesting and related ramble follows) One good thing is this highlights how important it is in emulators and FPGA systems to initialize RAM to a state similar to how uninitialized RAM manifests to get around these tests. As a bonus, at least on Coleco, it fixes two games that rely on randomness in RAM. These games are Fraction Fever (if RAM is zeroed before running, the game will continuously use 1/1 as the fraction). The other is Yolk's on You, which will appear to freeze when the game screen appears. This is because the "random" number generator is an LFSR, and since it's loaded with 0's, it will continue to generate 0. The game checks the random number for 0; if so it re-rolls but it keeps coming up 0. This makes the game hang, because the "random" number never deviates from 0. The fix in all cases is to load RAM with data that simulates the power-on state of a RAM chip.
×
×
  • Create New...