| |||
Views: 88,608,902 |
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search | 05-21-24 03:27 PM |
|
Guest: Register | Login |
Main - Posts by smkdan |
smkdan |
| ||
Ninji Level: 36 Posts: 222/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
The 'S' is for squaroid? what the hell I thought it was Tile Set Assembly and while it doesn't pull words out of an imaginary dictionary it doesn't make much sense either. Metatiles are the way to go. In my source I just call them 'blocks' and 'bigblocks' because I'm just that boring I guess. |
smkdan |
| ||
Ninji Level: 36 Posts: 223/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
People sell their shit for ridiculous prices on ebay all the time. You can throw it up there with a stupid BIN price and hope someone bites. 99% of vintage video game sales are like that so it must be working to some extent.. |
smkdan |
| ||
Ninji Level: 36 Posts: 224/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
That's true of simpler mappers but MMC1 doesn't suffer from bus conflicts (neither do most/all ASIC mappers). It doesn't enable the ROM when during writes so there's no issue there. That's wierd code Trax, only A13 and A14 actually reach the MMC1 so yes the entire $C000-$DFFF range is the same. Only D0 and D7 matter on top of that so that's odd of the program to read a table when it should just be shifting and writing directly to mapper register.. If this really is MMC1, they were either being obtuse for the sake of it or they assumed bus conflicts when it wasn't an issue to begin with. Also, considering only bit0 is used for data, I don't know why they bothered with AND #$0F when only the LSB matters to the MMC1. The only other used bit is bit7 and that's for resetting the chip. This is really an MMC1 game? What game is this? That's something you'd normally see in a game that uses discrete h/w for a mapper.. |
smkdan |
| ||
Ninji Level: 36 Posts: 225/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
CMP sets carry flag if content of A is larger or equal to the value used in the CMP. It will not branch, it will simply fall through to the instruction if carry flag ends up being set. BCC just branches if carry flag is clear. BCS being the opposite. BEQ/BNE is the same for zero flag and there's more for negative/overflow. It's important to know that much about how they actually work to get the full use out of them.
Another way to do conditional stuff (can be faster in some places) is to follow up an increment/decrement with BEQ or BNE. INX/INY/DEX/DEY set the zero flag based on the result in X or Y. If I wanted to do a loop using this...
bit more obscure: this tests the number of '1' bits in a RAM address:
DEX sets zero flag based on what result was after decrementing X. Until it hits zero, it will keep branching back to loop so STA $2007 is run 64 times. The branches just act based on what flags in status register are at the time and instructions like INX/CMP/ADC etc. modify them. The other example uses the fact that LSR puts bit0 into carry flag so it can then be used by BCC to determine if bit0 was set or not. --- For rom expansion I'm guessing this is the NES? You have to take a look at what mapper the game uses (if it uses one that is, a 32KB program ROM on a mapperless game demands you hack in a mapper before increasing amount of PRG ROM). nesdevwiki is a decent reference for popular ones. If the games uses CHR ROM then the PRG ROM is sandwiched between the iNES header and CHR. If the mapper allows for expansion based on the current ROM isze, you can insert however many banks of data for your own use. But then you have to hack the game to actually take advantage of the free space, you must insert a hack to switch to the free bank (how you do this depends on the mapper of your game) since the NES only sees 32KB or sometimes 40KB of ROM at any given time. On the SNES it's not really an issue since you have direct access normally to 4MB of ROM without bank switching. On the NES you have to switch manually for almost every game. |
smkdan |
| ||
Ninji Level: 36 Posts: 226/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
http://www.romhacking.net/utils/674/
Is easy to use and has decent feature set. I used ca65 before for NES stuff but it requires some setting up to get it up and running, but it's very powerful. Not the best one to use for starting out for sure. Labels, includes and whole bunch of other stuff (depends on feature set) are specific to the assembler so try out asm6. |
smkdan |
| ||
Ninji Level: 36 Posts: 227/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
KP9000 has a point about keeping SMWC issues at SMWC so I won't talk about that specific thread =). Long story short he got banned shortly after, that's all for SMWC.
Anyway, Googling "Aaendi dragonboy" should make the purpose of this thread pretty obvious A rather tacky attempt at seeking approval from an alternate forum under an alias. Anyway I'll provide some honest criticism. The fact that you don't have that much insight is totally fine, nothing wrong with that. The fact that you've managed to convince yourself otherwise along with the narcissistic view of yourself is honestly pitiful though. I saw your threads here about 'snes emulator bugs' or whatever and you post code that shows you don't know the simpler parts of programming, but ofcourse, you blame the bugs of the emulator. There is no possibility that dragonboy could ever be in the wrong, right? You post another thread on an 'xkas glitch' and it turns out you simply didn't read the manual. You don't seem to think for a minute that it is possibly *you* that is wrong, which makes it hard to reason with you and is a horrible attitude for someone that is trying to learn. Is that a bit clearer now? It's hard to take you seriously when you have this attitude, see the thread you posted. It's also really disrespectful to byuu/emulator authors/people who know what they're doing when you instantly assume that all the issues you are finding are entirely their fault. Put the superiority complex aside and consider that you aren't always right etc. Hopefully this isn't interepreted as inflammatory, just some advice. If you genuinely want to improve at this you really have to leave that attitude behind. |
smkdan |
| ||
Ninji Level: 36 Posts: 228/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
Yet another price rise on the SNES Powerpak puts it at $140 now. I remember it being cheaper than the NES one some time back. It seems fairly quick to restock so you might not have to wait so long for one.
It seems ideal if you just want to sit down and play SNES games and definitely more usable than the first two you listed for testing. Unless I was doing some really in depth testing of some obscure SNES quirk (byuu stuff I guess) I'm not sure if a quickdev is worth it over just using a Powerpak. bsnes already provides a fantastic debugging/testing tool outside of testing on a SNES, I'd just do the occasional test on real h/w for the really uncertain bits of code like very carefully timed code to APU ports or something. |
smkdan |
| ||
Ninji Level: 36 Posts: 229/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
Nice,didn't notice the updates at the bottom of that page.
Cool to see this is finally sorted out, I only just saw the progress they were making with this at nesdev. |
smkdan |
| ||
Ninji Level: 36 Posts: 230/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
Posted by Aaendi
...? No surprises here if that's what your debating tactic boils down to. |
smkdan |
| ||
Ninji Level: 36 Posts: 231/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
Posted by Kiokuffiib11 A common criticism I see is that while experienced programmers in advice threads obviously mean well, they don't always look at their own post from the perspective of a beginner and end up leaving out details that they think are 'obvious', and then the beginner is left confused... So sometimes they end up cramming every little thing they can think of in their post, even if it's only tangently relevant or genuinely obvious! Also, why is the thread being randomly derailed by the guy who started it?! =p |
smkdan |
| ||
Ninji Level: 36 Posts: 232/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
Nintendulator is up there too in terms of NES accuracy, but is nowhere near as popular as Nestopia.
All the current popular N64 emulators are still pretty terrible in accuracy as far as I know. I saw pretty good progress of N64 emulation in MESS which seems to be low-level emulating everything. No 3D acceleration and it does come at great cost of CPU time. It does have the obvious compatibility bonus though over the emulators using high level emulation for the RCP. |
smkdan |
| ||
Ninji Level: 36 Posts: 233/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
Why did you even stay as long as you did?
Shit I'm not even sure what I'm doing here.... I'm only here to send and receive PMs. |
smkdan |
| ||
Ninji Level: 36 Posts: 234/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
I had a look and that's some pretty good progress. I'm surprised at how much you guys already figured out. It's nice to see the older versions getting some attention. I know this game has a bad reputation for being horrible on the inside but I haven't really dug into the actual code myself.
I have some old snippets of code from when I was helping someone else figure out a few things in the Red ROM. I didn't see them on the Mercurial page so I'll pastebin them for reference. The comments are probably inaccurate and I'm missing huge chunks of info so double check everything in a debugger if you plan on using anything here. It might save you guys some time atleast. critical hit probability some attack/defense/critical hit manipulation, setting up for damage calculator damage calculator main part - should be consistent with the damage formulas floating around, covers some special effects like the suicide moves cutting enemy defense in half. Missing lots of comments. some code for fixed damage moves I know I have more than that but it's probably on my other PC. I'll have a look later on. @blackhole: I heard IDA has issues dealing with the 65816 8bit/16bit variable length oddness but I don't know if it's been fixed in a recent version. |
smkdan |
| ||
Ninji Level: 36 Posts: 235/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
I check regularly just to see how projects are going. I used to post a lot in technical help threads but we don't have many of those now. I don't have any big projects to share either so I haven't been as active here as I was before. |
smkdan |
| ||
Ninji Level: 36 Posts: 236/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
I don't know if it's the heuristics as much as the dynamic instruction length. This here is one of the few posts I can google on the topic but it refers to really old versions. I found another module here but it recommends you turn off the autoanalysis when using it. Looks like a really recent version added a 65816 module.
I'm still stuck on 5.2 and the other module I linked doesn't seem to work with it. I'm guessing the new versions have added flexibility that make 65816 more practical though. |
smkdan |
| ||
Ninji Level: 36 Posts: 237/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
If I want something different to do when I'm taking a break from other projects, I'll get an account there and commit a few comments. Until then, here's what I have left in terms of commented code. I have most of the damage calculator figured out but I saw a table with type effectiveness that makes it look like you already have that stuff sorted. When you say you have plenty of info but few people to work with it, do you mean info in terms of commented disassembly like this or does it mean info that needs to be tied to something in the disassembly? Are you guys sitting on a lot of code that hasn't been committed yet?
Move effect jump table code. Knowing that would make it easy to trace any move effects that you guys don't already know. Freeze/burn/paralyse effect handler. Called from the above jump table code for moves that possibly have any of those effects. Substitute effect handler. Also called from the jump table code. Note the 0HP bug. Code that checks target for substitute. Just a random helper routine. A few flags in RAM that I didn't spot in constants.asm. The last critical hit code looked pretty awful so I got the debugger out and confirmed a few things. This copies base stat data of the current monster to D0B8 in RAM which is then used for the critical hit stuff (for base speed) and whatever else happens to use it. Here is the critical hit code with less terrible commenting. Focus energy is used there with the bug that cripples your chances at scoring a critical hit by quartering the speed used in the probability check. |
smkdan |
| ||
Ninji Level: 36 Posts: 238/238 EXP: 289236 Next: 18874 Since: 05-26-07 Last post: 4088 days Last view: 4037 days |
I know it's a late reply but I very rarely check this forum. I don't have any time to look into it today but I might know what problem 2 is. I think the actual tile that kills you is directly *below* the spike so it's the actual ground tile that is deadly. I'm not sure on either problem since I forgot most of the tech details from years back. |
Main - Posts by smkdan |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
MySQL - queries: 122, rows: 151/151, time: 0.227 seconds. |