It is currently Sun Aug 18, 2019 10:25 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 252 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17  Next
Author Message
PostPosted: Tue Jul 16, 2019 2:01 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 724
Shifting in 1s is definitely on the weird side - really wonder why the data sheet makes no mention of it, too. It sounds like something that people programming for that chip would need to know, heh. But then, data sheets are also always vague about when flags are set and all that, too.

byuu wrote:
Tangent: there's a Japanese supermarket near me that plays the same song you hear on the Shougi game title screens over their loudspeaker on a loop.
Listening to it again, it is a very typically "traditional" Japanese-sounding soundtrack - I don't think I recall ever hearing it in Japan myself, though. (Mind you I've only entered a supermarket there a couple of dozen times at best :p)

RE: putting the bios at the end of the rom files - I'd agree with tepples here, using the bytes in the SNES "header" that determine which chip is needed should be enough to assume that the bios might be present at the end of the file and check for it before falling back on standalone bios files (and HLE after that if it's supported).

Quote:
Well, thank you for that. And in that case, please accept my apologies that I now do.
No need to apologize at all, and feel free to keep HLE support in if you want, too! I agree having the no-intro hashes include the bios in the file would probably be the simplest way for everybody.

Good to know the chip for X2/X3 is relatively simple, too. The Super FX, SA-1 and X2/X3 chips are essentially the ones I want to get done next, since they're also the ones that are used in the more popular games. I might try to tie up some loose ends and release a 0.2.0 version before I try to get started on those, though, since they'll probably take a while to get working.

The ARM6 chip is probably out of scope for me - at that point it's almost like putting a raspberry pi in a NES cart and then asking emulator authors to emulate the chip + its OS. :p
Like you said, I doubt anybody actually wants to play that particular game (and if they do, they can just use higan). Someone in the future will inevitably say "Mesen-S sucks, it doesn't work with X game that works on Y emulator", but after 290+ NES mappers, I've gotten used to it!


Top
 Profile  
 
PostPosted: Tue Jul 16, 2019 3:15 pm 
Offline
User avatar

Joined: Wed Oct 22, 2008 9:27 pm
Posts: 115
Millions of people have downloaded ps1 and ps2 firmwares and placed them in the emulator's firmware dir. It ain't hard and it keeps the data distinct. Blobbing stuff together just makes it harder to isolate checksum and size info, it also lowers awareness that it's even there.

I mean, just take this simple scenario. I dump my SMK cart. Its checksum is xxxxxxx. I compare it to the existing dump in no intro. Turns out the csum is different. Do I have a new dump? Bad dump? Did I forget to remove the copier header? Suddenly something that should be simple even for the layperson becomes a chore involving research and file splitting. Just to verify the part of a file thats actually dumpable.


Top
 Profile  
 
PostPosted: Tue Jul 16, 2019 4:15 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 201
Location: Germany
Yes, heuristics can get commercial games working, and adding/detecting firmware is possible. But internal headers don't have to contain valid data (e.g. prototypes) except for the vectors, and firmware can't be stacked indefinitely. These solutions needlessly (imo) put a lid on future extensibility.

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Tue Jul 16, 2019 4:19 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
FitzRoy wrote:
Millions of people have downloaded ps1 and ps2 firmwares and placed them in the emulator's firmware dir. It ain't hard and it keeps the data distinct. Blobbing stuff together just makes it harder to isolate checksum and size info, it also lowers awareness that it's even there.

I mean, just take this simple scenario. I dump my SMK cart. Its checksum is xxxxxxx. I compare it to the existing dump in no intro. Turns out the csum is different. Do I have a new dump? Bad dump? Did I forget to remove the copier header? Suddenly something that should be simple even for the layperson becomes a chore involving research and file splitting. Just to verify the part of a file thats actually dumpable.

This, a thousand times over. What is it with certain people and file "formats"/screwing with files? Stop it already.

Other emulators -- example: Mesen (not Mesen-S, but could certainly be added to Mesen-S) -- already have the equivalent of databases of MD5/SHA1 hashes of ROMs for identification. There's your identification model, re: heuristics. For these titles, require an external BIOS/FW/whatever file, selectable somewhere else in the UI, or even just a compile-time hard-coded filename that must exist in the same directory as the ROM (I don't care how it's done) that correlates with said game. Famicom Disk System/FDS BIOS is a good example: when loading an FDS file, Mesen prompts you to the path of the FDS BIOS filename.

The number of games requiring this on the SNES has got to be astoundingly small -- I am guessing in the extremely low 2-digit range. These games are thus the exception to the rule, not the rule itself. There were 1758 official SNES/SFC games released during its lifetime; so 20 games requiring this is literally 1.1% of all the games released for the system. It's not worth it. Just think about it.


Top
 Profile  
 
PostPosted: Tue Jul 16, 2019 4:42 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 724
As usual, the mere mention of file formats ends up with everybody giving their (incompatible) personal opinions on the matter. No surprise here :p
I've never overly cared too much about file formats (and am not interested in the endless arguments about them), I'll support things if they exist and are helpful for the end user, and won't if they're not, and that's about it.

That being said, let's not end up with another page of file format discussion like what already happened at the beginning of the thread - this is not what this thread is for. Thanks!


Top
 Profile  
 
PostPosted: Tue Jul 16, 2019 6:10 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1518
Quote:
The Super FX, SA-1 and X2/X3 chips are essentially the ones I want to get done next


I'll just warn you that you're going to become very cynical and jaded when people here complain about the difficulty of the MMC5 once you implement those two. Especially the SA-1. Nintendo threw the kitchen sink at the SA-1, and then games barely used it. There's a good half-dozen major features I try to emulate, but not a single commercial game uses them, so my implementations are likely wrong (eg HVIRQs ... how does it keep track of the H/V counters without H/Vblank pins?)


Top
 Profile  
 
PostPosted: Thu Jul 18, 2019 6:47 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 724
Just released version 0.2.0
This version is mostly accuracy/timing fixes and a lot of debugger tool improvements (+ DSP support).
Many thanks to everybody in this thread for helping out! I think I've had more help fixing emulation bugs on Mesen-S in 3 months than I have on Mesen in 3 years :p

Next version will probably be focused on adding support for the missing chips and peripherals (e.g multitap, super scope). Might also try to get around to adding options like removing the sprite limit and maybe try to implement the same kind of CPU overclocking that NES emulators use and see how that works out.

byuu wrote:
Especially the SA-1. Nintendo threw the kitchen sink at the SA-1, and then games barely used it. There's a good half-dozen major features I try to emulate, but not a single commercial game uses them,
That's actually good to know - thanks! This makes it sound like the most painful part of the SA-1 is integrating it with the rest of the system in terms of bus accesses, etc.? Since the CPU core is essentially identical, I might try to do the SA-1 first (rather than the Super FX) - that way I can focus on figuring out how to properly integrate it with the rest of the code & managing bus accesses, without having to worry about whether or not my problem is caused by a CPU bug or something else.

But for now, I'm taking a step back from this for a few days - I need a break!


Top
 Profile  
 
PostPosted: Thu Jul 18, 2019 8:03 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1518
Quote:
Just released version 0.2.0
This version is mostly accuracy/timing fixes and a lot of debugger tool improvements (+ DSP support).


Congratulations! Looks great :D

Quote:
Many thanks to everybody in this thread for helping out! I think I've had more help fixing emulation bugs on Mesen-S in 3 months than I have on Mesen in 3 years :p


It's seriously long overdue that we had a fresh face in SNES emulation. I hope you'll stick around long-term and that we'll find lots of new hardware discoveries out together ^-^

The more we figure out about the hardware, and the more quality open-source implementations we have, the easier it'll get for more new emudevs to enter SNES emulation and quickly get up to speed, as is the case with the NES scene currently.

I dream of the day we have a drop-in PPU core similar to blargg's DSP that has the accuracy we have in NES emulators. I'll seriously consider the SNES well-preserved and be able to retire feeling content once we reach that point.

Quote:
and maybe try to implement the same kind of CPU overclocking that NES emulators use and see how that works out.


I'm interested in this as well. The obvious trick of adding more Vblank scanlines would bias the timing (frame rate) and thus require us to clock the CPU faster to compensate, which may interfere with timed raster effects as with Air Strike Patrol and lots of buggy games that overshoot blanking periods. Only making the CPU faster during Vblank lines is likely the best strategy, right?

Quote:
This makes it sound like the most painful part of the SA-1 is integrating it with the rest of the system in terms of bus accesses, etc.?


The most painful for performance, yeah. Snes9X came up with an approximation that's not too bad if you want to focus on performance. But if you're going for all-out accuracy (^_^) then a different approach will be needed.

This is the gold standard test ROM for it: https://github.com/VitorVilela7/SnesSpeedTest

The design of the SA1 is ingenius and evil: the CPU cannot be stalled because the SNES CPU has no concept of external wait states (/DTACK on the Genesis, for instance.) So instead, the SA1 detects when the SA1 CPU tries to access ROM, BWRAM, or IRAM while the SNES CPU is accessing it, and will insert wait states into the SA1 CPU. The obvious million dollar question is, what happens if the SA1 is in the middle of reading from one of those when the CPU comes in to try? As far as I can tell, the answer is it just lets it finish doing the read and somehow there's enough headroom to let everything still work.

The way I do it is for every CPU read/write to set a "MAR" (memory address register) variable to hold the current state of the address bus pins. This also has to be done for DMA/HDMA accesses. It took a whole lot of trial and error to get the best results in Vitor's test ROM, but I still don't have it perfect.

Key findings:

https://github.com/byuu/higan/blob/mast ... ry.cpp#L11
It doesn't seem? to invalidate the address bus pins on idle cycles (but much more likely, the reason is that idle cycles tend to set the address bus to the current program counter, which is still going to stall out the SA1 because it doesn't seem to recognize it's an idle cycle.)

https://github.com/byuu/higan/blob/mast ... ng.cpp#L30
This one's going to suck to emulate. Past logic analyzer traces done on SNES refresh show it actually looks like 5-cycle read + 3-cycle idle, repeated five times for 40 cycles total. Just having that pulse run for 40 clocks gave me less precise timing matches than breaking it into five sections. I rounded to 6-2 x5 because everything else steps by 2, and even forcing 5-3 at a good speed hit (have tp step the IRQ counter at 21.4MHz instead of 10.7MHz) didn't improve the results any. It turns out that the SA1 carts connect the DRAM refresh pin to the SA1 CPU, and it really does affect the timing.

https://github.com/byuu/bsnes/blob/mast ... rom.cpp#L2
To avoid destroying performance completely, I added a setting to bypass the memory address stall and synchronizations on ROM, BWRAM, IRAM accesses. This of course is not accurate and fails Vitor's test, but it also kind of acts like an SA1 overclock so ... call it a feature! ^-^;;

Once you've implemented this let me know, and then I'll dive into the nitty gritty stuff I haven't fully been able to figure out yet :3

Quote:
I might try to do the SA-1 first (rather than the Super FX)


I went the same route. It's a good strategy even if the SA1 ends up being more complex as a whole.

Quote:
But for now, I'm taking a step back from this for a few days - I need a break!


It's well earned. No rush, see you when you're back.

...

Side note, I just fixed my own bug in Donkey Kong Country 2, it appears the game is messing with sprite registers mid-scanline? Didn't dig too deeply, but I had to revert my tile/item caching so that one line renders from the previous line's cache. Might be worth taking a look with Mesen-S just to make sure the sprite timing changes didn't affect it.


Top
 Profile  
 
PostPosted: Fri Jul 19, 2019 11:34 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 724
Thanks!
byuu wrote:
Only making the CPU faster during Vblank lines is likely the best strategy, right?
On the NES, the overclocking used is to add scanline after the end of the picture but BEFORE vblank/nmi.
This means that games have as much time as normal during NMI/vblank, meaning timed coded at the top of the screen, for example, will still occur at the correct timing. During those scanlines, the APU is suspended so from the APU's point of view, nothing changes.
This gives the game more time to finish up calculations before NMI occurs, and the majority of games appear to be compatible with this on the NES. Some people have done a lot of testing with as many as 1000 extra scanlines before NMI with no adverse effect on a lot of games - 1000 extra lines is usually enough to remove all traces of slowdown in all games.
I imagine doing the same on the SNES (e.g adding scanlines between scanlines 224 & 225 and pausing the SPC during them) would probably work out relatively well in most scenarios - but games with really tight SPC timings might potentially end up locking up?
You know, the more I think about it, the more I think it's actually pretty easy to implement - I'll give it a try soon and see how that works out :p

Quote:
This is the gold standard test ROM for it: https://github.com/VitorVilela7/SnesSpeedTest
Thanks for the SA1 info and the link! Hopefully it'll be useful to test basic SA1 behavior at the start when all the games refuse to boot. I think I have a pretty decent idea where to start, just need to figure out how I want to handle having 2 different CPUs with 2 different memory mappings (in terms code design).
One question though, does bsnes run the SA1 1 cycle at a time like it does for the SPC? I'm guessing it does? But in that case, my next question is, does anything break if you don't? e.g if I just run a full SA1 instruction and then wait X master cycles before running the next, should I expect games to break?

RE: DKC2, it seems to be working properly on my end, as far as I can tell - any specific part of the game that had issues? I took a look in the event viewer, and it doesn't seem like it's writing to the OAM registers outside of vblank, as far as I can tell.
Attachment:
dkc2.png
dkc2.png [ 57.99 KiB | Viewed 2344 times ]
The HDMA seems to be mostly to adjust BG2's scroll offsets and the only OAM writes I could find at part of the PPU writes at the bottom. I might just be looking at the wrong part of the game, though?


Top
 Profile  
 
PostPosted: Fri Jul 19, 2019 4:49 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 724
Sour wrote:
I'll give it a try soon and see how that works out
So, did a quick implementation of overclocking as I was describing it. So far it seems to be working pretty well - depending on the game, it looks like some games prefer having the extra scanlines before NMI and others at the end of regular vblank (i.e after NMI).

I've mostly tested with 1000 extra scanlines (to be a little extreme in the timing changes) and it seems to fix the slowdowns in Gradius 3, Super Ghouls & Ghosts and Super R-Type. The emulator only runs at around 100fps (with some frame skipping) with that much overclocking, though.

Some games will lock up if putting the lines before NMI, others will lock up if putting the lines after NMI, but it seems like the majority of games actually run fine in at least one of the 2 modes. Obviously, CPU "timed" code like the triforce animation in Zelda: LTTP is affected by it. Putting 1000 scanlines after NMI in that case makes it go super fast and kinda screws up the last bit of the animation, too. 1000 lines before NMI speeds it up a little bit, but beyond that no difference. A.S.P and even games that have been picky on my SPC timings so far (e.g Tales of Phantasia, Rendering Ranger R2, Illusion of Gaia) seem to work with 1000 extra scanlines, too. Some do break, though - Super Metroid stops booting at ~440 lines after NMI (and less than that when before NMI).

Overall, though, this was pretty easy to implement and doesn't really add any overhead to regular emulation. The SNES itself can already change when the NMI occurs due to overscan mode, so having a couple more settings on top of this and recalculating the values once per frame doesn't change much.

If anybody wants to play with it, it's in Options->Emulation->Overclocking.


Top
 Profile  
 
PostPosted: Fri Jul 19, 2019 6:39 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1518
Quote:
I imagine doing the same on the SNES (e.g adding scanlines between scanlines 224 & 225 and pausing the SPC during them) would probably work out relatively well in most scenarios - but games with really tight SPC timings might potentially end up locking up?


It would break streaming audio games like Tales of Phantasia, Breath of Fire II (d4s), etc. Not a large portion of the library but still unfortunate. Well in any case, all we can do is implement things, have people try it out, and add refinements.

Quote:
One question though, does bsnes run the SA1 1 cycle at a time like it does for the SPC? I'm guessing it does? But in that case, my next question is, does anything break if you don't? e.g if I just run a full SA1 instruction and then wait X master cycles before running the next, should I expect games to break?


With libco (my cooperative threading library), I can switch from one CPU to another at any point within any function at any call stack level. So if you turn on that "fast sync" hack I mentioned, the SA1 can execute many instructions before the SNES CPU starts running again, and vice versa.

The thing that hurts libco with the SA1 is that both the SNES CPU and SA1 can simultaneously access BWRAM and IRAM, which are of course volatile, and ROM can be dynamically remapped. So in effect, for perfect synchronization you would have to synchronize to the other component every time ROM, BWRAM, IRAM, and I/O registers were accessed, which is almost every cycle.

So essentially, yes, bsnes' SA1 core is cycle accurate. But Snes9X's SNES CPU and SA1 cores are both opcode-based, and to my knowledge it does not break any games. You won't be able to perfectly pass Vitor's speed tests, but you may consider it a sacrifice worth making for performance and sanity. If not, you will need to have a cycle-granularity state machine, at least for your SA1 CPU core. And truth be hold, I'm not entirely certain you can completely pass his test with just cycle-based granularity, I guess we'd find out though ^-^; (you -should- be able to ...)

What you're going to find out and hate about the SA1 is, in spite of all this power and all of these cool functions, games barely use the chip. It feels more like they put it in there for anti-piracy than any other reason, and it's rather disappointing to emulate.

Quote:
any specific part of the game that had issues?


Every level had flickering sprites, hahah. It looks good, so then there's no issue with your sprite implementation, perfect! :D

Quote:
it doesn't seem like it's writing to the OAM registers outside of vblank, as far as I can tell.


... now that is very weird to hear. I guess I should have researched more instead of reverting my one-line item/tile cache design.

I'll look into it more when I have time and then talk about it again later. Thanks for verifying!

Quote:
Putting 1000 scanlines after NMI in that case makes it go super fast and kinda screws up the last bit of the animation, too.


Call that one ZSNES mode? ^__^

Anyway, sounds good! I'll give it some time to see how it goes for your users before implementing it :3


Top
 Profile  
 
PostPosted: Sat Jul 20, 2019 7:42 am 
Offline
User avatar

Joined: Fri Mar 16, 2018 1:52 pm
Posts: 93
Location: Finland
Sour wrote:
Note: The emulator currently requires the 64-byte SPC bios to be put in Mesen's data folder (i.e the one you picked on startup) and named "spc700.rom". If the file cannot be found, the UI should print an error message about it when trying to load a game.


Where is this "data" folder located? There were no subfolders in the main directory. Just the .exe file


Top
 Profile  
 
PostPosted: Sat Jul 20, 2019 7:58 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1518
Hey Sour, when you're not busy, can we talk sprite evaluation for a bit? ^-^;

https://github.com/byuu/higan/blob/mast ... u/main.cpp
https://github.com/byuu/higan/blob/mast ... ct.cpp#L34
https://github.com/byuu/higan/blob/mast ... ct.cpp#L94

I implemented the H=0-255 sprite evaluation, easy enough. Had to come up with a rather hacky way of representing the main emulator loop to avoid destroying performance, but it works.

But let's talk about this:

Quote:
H=270-337: OAM reading to determine which VRAM addresses need to be fetched (starting from the last sprite index stored during evaluation)
Even cycles: Read X+Y (word)
Odd cycles: Read 2nd word (priority, palette, etc), determine the VRAM address to load on the next cycle. If all tiles for this sprite have been processed (e.g based on its width), move on to the next sprite index in the sprite evaluation table.

H=272-339: VRAM fetches for the sprites
Even cycles: Read first word of sprite tile, based on the address calculated on the previous cycle
Odd cycles: Read the 2nd word of the sprite tile


If H=270-337 reads from actual OAM, then it would have to update the OAM address, which would alter where writes went during Hblank. Doing so breaks Uniracers.

If all of H=270-339 looks up addresses to fetch VRAM from, then we will break Mega lo Mania's introduction and half of the scanline at the top of the screen and half of the scanline in the middle of the screen will be rendered incorrectly. The game is changing OBSEL right around H=300. If we try caching OBSEL at H=270, the the entire first and middle scanlines get rendered incorrectly.

I have some theories on both, but I'd like to hear your thoughts first, and also to hear if Mega lo Mania looks correct with your current renderer, and if so ... how ^-^;;


Top
 Profile  
 
PostPosted: Sat Jul 20, 2019 8:40 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 724
SusiKette wrote:
Where is this "data" folder located? There were no subfolders in the main directory. Just the .exe file
It's the folder that gets opened when you click the "Open Mesen-S folder" button in Preferences, at the bottom left.
The SPC bios is no longer required as of 0.2.0, though. And for DSP games, the UI will prompt for the file if it's missing and store it in the Firmware subfolder.

byuu wrote:
If H=270-337 reads from actual OAM, then it would have to update the OAM address, which would alter where writes went during Hblank. Doing so breaks Uniracers.
Based on paulb_nl's posts and the FPGA implementation, the "current" OAM address is (roughly) this:
Code:
if(_forcedVblank || _scanline >= _vblankStartScanline) {
   return _internalOamAddress;
} else {
   if(_memoryManager->GetHClock() <= 255 * 4) {
      return _oamEvaluationIndex << 2;
   } else {
      return _oamTimeIndex << 2;
   }
}
_internalOamAddress: the OAM address written to the registers
_oamEvaluationIndex: The sprite index currently being evaluated by OAM evaluation (0-255)
_oamTimeIndex: The sprite index being read by the "sprite rendering" portion (270-337). Note that the value is apparently used starting right after sprite evaluation. The value stops at the last OAM entry processed for the scanline (in reverse order from their order in OAM) - if a scanline has no sprites based on sprite evaluation, then this value is retained from one scanline to another, until another scanline with sprites occurs.

So in Uniracers' case, the game writes to OAM on a scanline that has no visible sprites - this means it will write to the address of the last sprite processed on the last scanline that contained sprites (this makes it work). It's supposed to write to BOTH the "low" table of OAM and the "high" table of OAM for the current sprite at once (most likely because the PPU is accessing both addresses on the same cycle). Though I think it still respects the latch for the low table, meaning it would only write to it every other write. Unsure what happens in terms of the OAM address set by the register (e.g: does it get incremented by a write in this scenario?)

For Mega Lo Mania, the OAM select bit isn't cached, I'm reading it on every odd cycle from 270-337 to calculate the VRAM address. It works because there are a few transparent sprites before the non-transparent ones:
Attachment:
megalo.png
megalo.png [ 47.52 KiB | Viewed 1648 times ]
At scanline 128, the PPU will start by loading sprites 42 & 43, which are 8 tiles wide, which will take 16 cycles. (270-285). It also looks like the first 1-2 "tiles" of sprite 41 are fully transparent on that line. So, by the time it processes the address for the first tile with opaque pixels, it's at least on cycle 287, and most likely closer to 289-291. Since the register write occurs at cycle 283 at the latest, there are no missing pixels on the line. In reality, the first few tiles (on the right side) of the scanline are most likely rendering using the first "bank" of tiles and it switches to the next bank after the write occurs - since the pixels on both banks are all transparent, it has no visual impact.

Keep in mind this is just my understanding of it after spending a day re-reading forum posts and reading through the FPGA implementation. I most likely have some details wrong (and some stuff is still unknown), but at the very least it's enough to make all (known) affected games (mega lo mania, aladdin, uniracers) behave correctly.

Hope that helps!


Top
 Profile  
 
PostPosted: Sat Jul 20, 2019 9:44 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1518
Thanks for the help!

Quote:
_oamTimeIndex: The sprite index being read by the "sprite rendering" portion (270-337).


Quote:
It's supposed to write to BOTH the "low" table of OAM and the "high" table of OAM for the current sprite at once


Oh, from the notes it sounded like it was writing to the low table only. Okay then.

Quote:
It works because there are a few transparent sprites before the non-transparent ones:


Oh, I get it. It doesn't take 34*4 hclock cycles to do the tilefetch, it takes 34*8 hclock cycles.

Before:

Code:
43 @1080 [270]
42 @1096 [274]
41 @1112 [278]
40 @1128 [282]
OBSEL write at 128,1136[284]
39 @1144 [286]
38 @1160 [290]
37 @1176 [294]
36 @1192 [298]


Sprites 43-40 end up using the old OBSEL value, and sprites 39-36 end up using the new OBSEL value.

After:

Code:
43 @1080 [270]
42 @1112 [278]
OBSEL write at 128,1140[285]
41 @1144 [286]
40 @1176 [294]
39 @1208 [302]
38 @1240 [310]
37 @1272 [318]
36 @1304 [326]


We should probably use Hclocks (0-1363) instead of Hdots (0-340) when the values are known, if that's okay ^-^;


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 252 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group