 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by Dish |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
| User | Post | ||
Dish Spiny Level: 38 Posts: 361/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by iamhiro1112 Nope -- top and bottom half use the same palette -- only 3 colors (doesn't use black -- which I'm assuming the BG color is). Just three shades of grey and a very good job of shading. (edited by Disch on 04-25-05 06:42 PM) |
|||
|
Dish Spiny Level: 38 Posts: 362/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Bush Hater This is very offtopic, and I don't want to sound rude or anything, but this has always baffled me. What on Earth is the appeal to JNes? Don't get me wrong, it's not a bad emulator, but it certainly doesn't stand up to FCEU, NEStopia, or any of the several awesome NES emus. It's got decent emulation (but again, not as good as the others), and it completely LACKS features. Don't get me wrong, I don't mean to knock it. But it's like taking a taxi to work when there's a limo you can ride for free. I just never understood WHY JNes got so popular. |
|||
|
Dish Spiny Level: 38 Posts: 363/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
I don't know how/why x86 got introduced here, but I have to say it's a strange idea  -- and I'm not sure it will really benefit S&T much for what he's trying to do. I mean the whole reason he's learning a different assembly language before 65816 (which is what he ultimatly wants to learn) is to soften the blow with an easier language. x86 would just intensify that blow -- not to mention it doesn't share the similarities 6502 has with 65816. I mean if he's going to sit down and learn x86, he might as well sit down and learn 65816 and save himself some time and trouble. 6502, on the other hand would be taking a smaller step in the same direction (65816 is just a 'beefed up' 6502, so after learning 6502 he'll only need to look at a few extra things and he'll have 65816 down).I mean it's not like 6502 tutorials or learning resources are in short supply or anything. |
|||
|
Dish Spiny Level: 38 Posts: 364/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Revenge This doc does cover things nicely, however it does have the occasional error/misprint, so for the technical stuff (opcode lists, cycle counts, stuff like that), use the link Para provided instead. Some problems with 6502.txt and other things I feel like bringing up: 6502.txt documents Relative addressing mode all wrong. It implies that a branch of $FE is a branch of -126 when it's really a branch of -2. Relative addressing mode arguments branch in the usual "two's compliment" fashion: $FF = -1, $FE = -2, $FD = -3 ... $80 = -128, $7F = +127, $7E = +126, etc. Not the method covered in 6502.txt. 6502.txt refers to the high status bit as 'S' (Sign flag), whereas pretty much every other doc on the planet refers to it as 'N' (Negative flag). There isn't really a 'B' status flag -- or an 'unused' status flag. When processor status gets pushed to the stack (via IRQ/NMI/PHP/BRK) -- the bit representing the 'unused' status flag is always set, and the 'B' bit is set on BRK/PHP (and cleared on IRQ/NMI) -- however the status of these bits aren't tracked as the CPU runs (so the only "real" status flags are C, Z, I, D, V, N) The V flag is not explained very well at all usually. On ADC: V is set when Positive + Positive = Negative, or when Negative + Negative = Positive. Under all other circumstances V is cleared. On SBC: V is set when Positive - Negative = Negative, or when Negative - Positive = Positive. Under all other circumstances V is cleared. Other instructions that change V don't rely on any such logic (BIT/CLV/PLP/RTI -- all pretty straightforward) |
|||
|
Dish Spiny Level: 38 Posts: 365/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| yes, use a hex editor and zero out bytes $00008-$0000F Emulators shouldn't have to autocorrect bad headers |
|||
|
Dish Spiny Level: 38 Posts: 366/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by dan That's not their job. The whole point for headers is to supply that info -- that's what the header is for. If emus have to CRC check everything anyway, what's the point of having headers at all? I mean if their info can't be relied on or even used, they're completely worthless. Emus that are lax in this area just encourage further bad headers from being spread. After all, people will think that if the game runs fine through hacks, why bother to correct the problem? Personally I feel that attitude is completely shitty. When there's a problem, the emulator should treat it as though there's a problem. It's the emulator's job to play the game as the system would -- if you wire the wrong mirroring mode or put the wrong MMC on a cart and pop it in the NES -- it won't play. So why should an emu be expected to play it? But yeah -- emulators letting ROMs get away with having bad headers is bad news. I mean if the first Diskdude ROM was actually treated properly, we wouldn't have this problem at all, because the person adding DiskDude to the headers would realize "hey, this doesn't work". Instead the emus looked the other way and now a good 20% of the dumps out there have bad headers as a direct result. So I stand by my statement. It's not the emu's job to look for bad headers. And in fact, I'd say it's the emus duty to be as strict as possible when it comes to such things. I mean it's not like the real system lets you get away with that crap. (edited by Disch on 04-27-05 06:48 AM) |
|||
|
Dish Spiny Level: 38 Posts: 367/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| It's not a simple matter of ignoring bytes. The 'DiskDude' text occupies space used legitimately by other ROMs, like the high bits of the mapper number for example -- and more recently (but far less common) NTSC/PAL bit and CHR-RAM size. Besides -- emus correcting this perpetuates the problem. If you build hacks into the emu to play bad dumps/bad headered ROMs -- it makes bad dumping practices acceptable, which just leads to further problems, as was my point in the previous post. If emus never let DiskDude get away with this bullshit, we wouldn't be having this debate. Hence lax emu behaviour is partially responsible for the problem. "Reserved - Must be 00" does not mean "Unused - put whatever you want here". It means must be 00. (edited by Disch on 04-27-05 08:13 AM) |
|||
|
Dish Spiny Level: 38 Posts: 368/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| You must just be doing your pointer handling wrong. I can't think of how writing 0xFFFFFF would draw a red green and blue pixel though, that's pretty strange. What depth bitmaps are you using? 32/16/8-bit? You can do 24 bit too but it's harder to work with (to the point of not being practical). | |||
|
Dish Spiny Level: 38 Posts: 369/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| int* MainBMPData = 0; MainBMPData[(Addr + (3*i))] = (Colour[p] & 0xFF); MainBMPData[(Addr + (3*i)) + 1] = ((Colour[p] & 0xFF00) >> 8); MainBMPData[(Addr + (3*i)) + 2] = ((Colour[p] & 0xFF0000) >> 16); There's your problem. MainBMPData is an int pointer -- you're treating it as though it was a BYTE pointer. The index you're using (Addr + (3*i and all that jazz ) is really being multiplied by 4 (or really sizeof(int)) by the index -- instead of being multiplied by 1 (sizeof(BYTE)) which it looks like you want. Furthermore each one of your writse is actually writing 4 bytes to the buffer! Not 1 byte like you seemed to want. And furthermore -- this code is exactly why 24-bit bitmaps are stupid to work with. Save yourself a headache and make it a 32-bit bitmap with following code: as you can see -- much simpler -- much less errorprone -- much faster. Slightly more mem -- but if that's a huge problem go with 16-bit bitmaps (just be sure to change the pointer to a short then). The quality loss is almost never noticable. |
|||
|
Dish Spiny Level: 38 Posts: 370/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by dan It's not about it being difficult, it's about it being counter-productive. Emus bending over backwards to support improperly headered files is not a good thing -- they shouldn't do it... it's not their job. The header works for the emu, not the other way around. Now an auditing tool -- yes, a DiskDude check and removal would be great -- and in fact would be a GREAT value in solving this problem. However emus doing it doesn't solve a thing, and just perpetuates it. Building the auditing tool into the emu is one idea (correcting and saving the ROM when its loaded in the emu) -- but personally I'd be pissed if an emu started changing my files around when it loaded them -- since that's not what it's supposed to do. |
|||
|
Dish Spiny Level: 38 Posts: 371/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| The thing is, when 99.9% of the people click the "Do not show this warning again" box, that becomes completely worthless. Or it auto-fixes every file it loads (which might not actually be broken). My position seems to have become clouded. So let me clarify my standing on these points. 1) DiskDude headers are bad. They should not exist. Every ROM which has one should be fixed. 2) Emulators should not go out of their way to support bad files -- whether the header is bad due to DiskDude, or someone just setting the header wrong -- the emu should not have to correct it. If the emu can't use the header as-is, the whole point of having a header at all is lost. 3) The problems listed in #2, which I said emus should not do, are the perfect job for an auditing tool -- since that's kind of what auditing tools are for (well that and renaming files). 4) A hybrid emu/auditing tool would be cumbersome and/or intrusive. As I'm sure most everyone would agree -- having an emu change files without prompting you is bad. Likewise being prompted every time you load a file is also bad. 5) The clear, simple, straightforward, make-everyone-happy solution to this problem is to run an auditing tool once to correct all your bad headers, and have an emu run normally. This solves the problems listed in #2, while avoiding the problems associated with #4, and keeps an emu doing the work of an emu -- and nothing more. 6) To further address #1 -- problems should be solved -- not "worked around". Weaseling around these problems so that bad ROMs will run just furthers the problems and opens the door to allow more problems in. Format specs exist for a reason. Diskdude broke/ignored these specs -- and because of that several ROMs are broken. Instead of emus conjuring ways to support broken ROMs, people should just fix their ROMs. (edited by Disch on 04-28-05 05:38 AM) (edited by Disch on 04-28-05 05:41 AM) (edited by Disch on 04-28-05 05:51 AM) (edited by Disch on 04-28-05 05:58 AM) |
|||
|
Dish Spiny Level: 38 Posts: 372/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Sometimes. I'm pretty sure that 32bit DIBs don't use the 4th byte at all (at least BitBlt doesn't when blitting -- maybe AlphaBlt or some other function does). In the case where Alpha blending is used... 0 would be fully transparent, FF would be opaque, with values inbetween being the degree of transluscensy (sp) -- but like I said I really don't think this applies to windows DIBs -- not unless you load them to D3D textures or something. As for your blue problem -- you're not still writing byte-at-a-time are you? if you have a 32-bit bitmap, you can write each pixel in full with a single write to a long buffer (each 32-bit long would represent 1 pixel -- you can treat the array of longs as a direct array to the pixels). Byte order might also be a problem -- Low byte is blue, 2nd low byte is green, 2nd high byte is red, and high byte is unused (or A). so 0x00FF0000 is full red, 0x000000FF is full blue. But keep in mind that it uses little endian, so the blue value is stored first: FF 00 00 00 = 0x000000FF = full blue |
|||
|
Dish Spiny Level: 38 Posts: 373/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by dan Most of the time you're right. However it is possible for a proper ROM to have some of those bytes having a nonzero value. If you apply the DiskDude "correction" to that ROM, you're breaking that ROM in order to fix the broken ROMs. Auto-correction in this manner is not the solution. It's not even a solution -- it's just a way of weaseling around the problem to make the problem work.
It's the only solution. The ROMs are broken -- they need to be fixed.
That describes the problem we're debating quite well. That's exactly why these headers need to be fixed. Emulators treating the header properly don't run these games and because of that people think it's a problem with the emulator... which it's not. Compare this to the whole IE thing. If you make a page that will only load in IE due to its faulty rendering methods -- and someone tries to load the page in Firefox or Opera and it doesn't show up right -- they might think it's a problem with the browser -- but it's not. It's a problem with the page. And in fact -- some more educated users embrace that Firefox and Opera play closer to the standards than IE does. This is exactly the same as the diskdude situation. The iNES format specs are layed out clear as day -- DiskDude ignores them. It breaks the rules. Because of that... THE ROMs DON'T WORK. They're broken. A less educated user might think that an emu not running these ROMs has a problem -- but that's not the case. As with the IE example... it's the ROM/page which has the problem -- not the emu/browser. A more educated/advanced user would appreciate the strict header check. And just like the browser situation -- the solution is not to ignore the standards and make up your own rules to make the bad ROMs work. When you start doing this you're working towards making the IE of emus -- focusing more on getting the games running rather than running them right. NESticle is the perfect example of this kind of emu -- it doesn't follow strict specs -- rather it relies on many, many hacks to get games up and running -- rather than emulating properly. And because of that, NESticle is a piece of shit.
This is exactly why I dislike GoodNES. "Verified Good Dumps" have bad headers and don't run properly/at all. Rad Racer 2 comes to mind -- which isn't plagued by DiskDude, but still has an otherwise broken header (wrong mirroring mode set) -- only way to 'auto-correct' it is to CRC check. If GoodNES actually looked for and flags bad headers like it should, these problems would be a lot less common.
It's not sensible at all. It's problematic. For any given ROM... there can only be only ONE mapper number. only ONE prg size. only ONE chr size. only ONE sram state. And provided the mirroring is hardwired... only ONE mirroring mode. There can only be ONE correct header. Dumps floating around with "slightly different headers" have bad headers. There's only 1 correct one. There's only one that will work properly.
That's the thing... It's not compatibility. The ROMs are broken! They have incorrect mapper numbers! They're BUSTED! Emus should not disregard file format specs in order to get BROKEN games running. I'm tempted to point you back to my IE examplE. |
|||
|
Dish Spiny Level: 38 Posts: 374/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by X-Grade How do you figure? Besides... perhaps he's coding in C and not C++? ;P I'm a C/C++ hybrid guy myself -- but I still prefer to use stdio.h for file i/o. Much cleaner/simpler more straightforward. Some C++ additions are good... some are just downright silly (like iostreams) (edited by Disch on 04-29-05 01:56 PM) |
|||
|
Dish Spiny Level: 38 Posts: 375/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by GRAVITEH What? What doesn't it display properly? Are you sure your html isn't screwed? Example code of what messes up? |
|||
|
Dish Spiny Level: 38 Posts: 376/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Judging from his sig "I do not support W3C" -- I think it's safe to say he doesn't know what proper HTML is -- or he doesn't know what W3C is. In either case, his beef with firefox is misplaced. | |||
|
Dish Spiny Level: 38 Posts: 377/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| No, see. Those bytes were never unused. "Reserved for future use, must be 0" was there for those bytes prior to the iNES update for this exact reason. 'Reserved' does not mean "put whatever you want here". It means "Reserved, MUST BE 0". DiskDude didn't put 0 there, because of that it ignored the file specs -- because of that the ROMs broke when the format updated. ROMs that actually followed the specs didn't break and still work to this day -- even with the most recent iNES specs. Current day -- DiskDude ROMs are broken. I don't know how you can debate this -- I mean they say to use mapper 65 when it's really mapper 1. That's about as broken as a header can get. So your comparison is flawed -- it's not providing backwards compatibility (iNES already is fully backwards compatible with previous versions/revisions) -- it's providing 'compatibility' (though I hate using that word in this context) for files which disregarded the format specs and made their own rules causing them to require special treatment. I'm saying you shouldn't provide special treatment to goons which want to break the format. The file format is there for a reason -- the rules it has are there because they're how the file works. If some goon is going to piss on the format and advertise his name in the header, breaking his ROMs in the process -- then no... emus shouldn't go out of their way to support him. I really want to point you back to my IE example -- because I know that's something you'll be able to relate it with, and it really sums up my argument quite well. DiskDude ROMs are like broken webpages -- they don't follow any standard, and an emu doing things in accordance with the standard will not run them properly. In order for emus to run them -- they have to break the standard (potentially breaking ligit ROMs in the process -- and yes, while unlikely this is a possibility. Escpecially so as iNES updates and uses more of the expansion bytes). Without the standards why bother having a format at all? I mean really, if every ROM is just going to use the bytes differently -- what's the point? (edited by Disch on 04-30-05 05:04 AM) |
|||
|
Dish Spiny Level: 38 Posts: 378/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| CreateDialog does a Modeless dialog (active alongside the parent). If you want a Modal dialog (takes control -- parent does not get control back until dialog is closed), look at DialogBox. I'm not sure you can make a Modeless dialog without having a parent window. I recall it being problematic for me in the past. Most of this stuff could be figured by actually READING the remarks section under the function name ;P.. .but anyway: hInstance - the instance of the application to load the dialog from (just pass it the instance passed to your program in WinMain() ) lpTemplate - the ID to the dialog -- although if your dialog ID is in integer form you need to use the MAKEINTRESOURCE macro. For your DLG_0100 (crummy name, btw ;P ) you'd do: MAKEINTRESOURCE( DLG_0100 ) hWndParent - handle to the parent window. NULL would specify the desktop as the parent (although, again, I think modeless dialogs need to have a parent window within the program). lpDialogFunc - the window procedure for the dialog. All windows messages and control notifications will be passed to this function. The param itself is a function pointer. For more info on how to declare this function look up DLGPROC on MSDN. When you're done with the dialog, DestroyWindow() gets rid of Modeless dialogs, whereas EndDialog() gets rid of Modal dialogs. Again I really suggest looking at DialogBox() unless you're sure you want a modeless dialog. |
|||
|
Dish Spiny Level: 38 Posts: 379/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| For common mappers I'd recommend Kevtris' page as your main point of reference: http://www.tripoint.org/kevtris/mappers/mappers.html Firebug's doc has several mappers which Kevtris doesn't cover, but Kevtris' docs are more recent/accurate. Especially if you're going with MMC1 or MMC3 -- Firebug's doc is pretty unreliable. Also be weary of mappers with bus conflicts (UNROM -- mapper 2, CNROM -- mapper 3, AOROM -- mapper 7, and other simple mappers) -- most emus aren't strict when emulating those conflicts -- but some are. If you choose such a mapper be sure to do reg writes properly -- and test it in several different emus (Nintendulator is probably the best to test with -- it sacrifices everything for accuracy). As for your graphics problem -- it looks like whatever emu you're doing is zeroing the CHR swapping regs (which is probably what its supposed to do). If you want to correct this problem you'll have to cut off the Reset vector and add some code which writes desired values to the CHR swapping regs -- it also might not be a bad idea to prep the PRG swap reg as well -- even though it doesn't seem to be needed in this particular emu. MMC4 is especially weird in this area because of its latch behavior -- tiles FD and FE are special tiles which automatically swap CHR when they're drawn to the screen. You may want to consider going with a more common mapper (MMC3 perhaps?). It always confused me why DD chose MMC4 for Mario Seasons. If you want to stick with MMC4 I can provide more details on how the latched CHR swapping works, if you're interested. |
|||
|
Dish Spiny Level: 38 Posts: 380/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| It's good -- but unreliable. It comes down to how the emu inits the mapper regs. Register state is pretty much undefined on startup. AFAIK, the only thing that's for certain on the MMC3 on startup is that $E000-$FFFF will contain the last 8k of PRG. Everything else is undefined and should be prepped by the game. It just so happens most emus default to swapping the first 8k of CHR in and the first 16k of PRG at $8000, with the last 16k of PRG at $C000 -- satisfying SMB. However this behavior should not be relied on. So anyway -- to make this hack proper and stable across any emu (and on the real system) -- you'd have to have the Reset vector jump to somewhere in the hardwired bank ($E000-$FFFF) -- where you prep all PRG swapping regs before accessing any other PRG in the game. And you'd have to prep the CHR swapping regs before any drawing is done, as well (and before any data is pulled from CHR -- SMB reads title screen info from CHR-ROM, iirc, so you'd have to swap in the proper CHR banks before it does that). Anyway -- it's good that it's working -- but at the same time it's kind of bad because if the emu just happens to run the game without you having to do the required prepwork -- it may pull you away from doing the job right. Prepping MMC3 isn't exactly a small amount of code either -- it'll take a fair amount of free space (which I hear SMB doesn't have a lot / any of). Here's a sample of what you'd need to do. Note this should be in the hardwired bank ($E000-$FFFF) -- which the Reset vector should jump to first thing: That's a good 70+ bytes you'll need. Although you can problably shrink it by putting some stuff in a subroutine and JSR to it... but it'll still take a good amount of work. MMC4 would have considerably less prepwork to do -- but remember ANY mapper is going to require prepwork. Don't expect the emu's defaults to work all the time (even if they do!). EDIT: Optimized a bit. This uses 43 bytes: I think I have an idea of how to shrink it further....... EDIT again: down to 26 bytes. Lookup tables are awesome: That's about as small as I'll be able to get it. (edited by Disch on 05-01-05 07:41 AM) (edited by Disch on 05-01-05 07:47 AM) |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
| Acmlm's Board - I2 Archive - - Posts by Dish |
