So, while investigating, I've found out a way to improve the original CE file, but it's a bit of hardwork (although there could be better ways to automate the process that I'm not aware of).īasically, I was able to successfully create new controllers for swapping the Portrait of additional Characters in-game, beyond that of the 5 starting Characters Party Creation: Characters (00), (38), (39), (40), (41), based on the in-game counting system in the Adventurer's Inn when your mouse hovers the Character Portraits that are resting in the there), and according to this simple chart I've made recently: For the patterns in this current post, although approximate and leading to the solution, were doomed to anomalies because I needed to further verify all the Hexadecimal values (00 to 15) on all those digits and make exact matching calculations on an appropriate counting table for them. I reverse engineered the set 1 back in 2010 quite extensively, and browsing my notes I came across this piece of Z80 code: install a modifiable routine in $8C24 (self-modifying code usedĪs we can see, the game installs some code into $8C24 which is in RAM (as opposed to the lower half like the above code which is in ROM).UPDATE: After long, please, check my Post at on this Thread for the final answers on those Portrait Addresses. The 68020 instruction cache isn't big enough for this to be a (visible) issue.Īnother completely unrelated example is the Pengo arcade video game. So the code changes the jump address depending on the situation (without flushing the caches afterwards). It's difficult to find an example of a real game that used self-modifying code on an official CD32 game but I found one: Zool CD32ĭisassembling the executable, we found several occurrences of this instruction in the code, (setting a label plus 2 is fishy enough and often a sign of self-modifying code): MOVE.L #LAB_0411,LAB_0404+2 00cefe: 23fc0000b2fa0000abd6 The fact that the processor is a 680EC20 could cause issues, so when detecting a CDTV title, the CD32 console turns the caches off, to handle CPU-dependent issues such as CPU-busy loops and cache issues (i.e. The CD32 console can also run CDTV titles. Since those 2 consoles inherited a lot of Amiga games with very little adaptation, and some amiga games use self-modifying code, you can say that those consoles can use self-modifying code. Same can be said for the Commodore CDTV, an earlier version, less powerful, which inherited a lot of Amiga games too. it's sometimes easier than creating a tableĪ CD console like the Amiga CD32 is a console but cannot run the code from CD obviously, so it has to load it into its 2MB RAM.On computers on the other hand it happened all the time, just because The consoles using cartridges usually don't have a lot of RAM, so I think it's VERY rare if someone uses the small RAM used for data to store code just to perform self-modifying code. RAM and ROM are reachable by the CPU for execution, so most consoles can execute code from RAM. It required rewriting that section of the code. Playability is ruined: The robots would never shoot.īy using only a 2-byte instruction, the cracker couldn't just replace it with a 3-byte JSR to a replacement subroutine. But in a RAM copy, it corrupts the gameplay table. This operation writes the shifted value back to RAM. For bits 6 and 7, I would ASL - bit 7 drops into carry and bit 6 drops into sign. table_ref is a zero page location preloaded with the table location). To get to bit 0, I did ROR ($TABLE_REF),YĪnd the value would pop into the carry flag. So I would store 3 binary tables in the same byte array: in bits 0, 6 and 7, and other values in bits 1-5. If there were 30 levels, that was 30 bytes per parameter unless you wanted to do a binary unpack. Some were binary: The robots do not shoot on level 1, but do on level 3. On the other hand, games have many tables of gameplay parameters. It was easy enough for the crackers to disassemble the code and unbolt them. typically a loop that wrote garbage into the ROM area (having no effect on ROM but destroying a RAM copy). Usually, copy protection was bolted on after-the-fact by adding code that had no purpose but copy protection. We ROM programmers were always in an arms race with people who cracked games. I did, however, use a variant for copy protection. I did do it on the IBM PC, where I had bunches of block moves to do that were not contiguous, and doing so eliminated looping overhead during a critical time, at the expense of some RAM. Doing that had a lot of overhead both in ROM space and RAM space, and I rarelysaw an occasion where it would be worth it. I rarely had occasion to use self-modifying code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |