12/31/2023 0 Comments Bsnes vs snes9x complicated chips![]() And as for the pass-through limitation, it's not like Nintendo were trying to accomodate for flash carts when they were designing the hardware. Having the access to the cartridge be controlled like it is with the Super FX is much simpler in terms of actual hardware design. The SA-1 is able to be stalled when the CPU is using the bus at the same time, but that makes things slower than they usually need to be, so often either one or the other will still end up running code out of RAM instead, just like you do with the Super FX. If they had both processors sharing the bus (like the SA-1 does), then both of them trying to access the bus at the same time would still cause issues. I don't know if what I am saying will work, but math can bring you a long way when it comes to these kinds of things.īut I do take what you are saying seriously, because you know what you are talking about (you contributed a fair amount to BSNES-Plus, and making a SNES debugger is difficult I can imagine.) I see what you mean though, and I will check the average kilobyte usage of system RAM in BSNES-Plus, and take note of peak usage, and will then figure out how much useful routines can be added without the system RAM overflowing in certain situations. You have to remember mostly routines will be replaced, and that space plus whatever left over space in the system RAM can be used for a routine replacement. So basically the system RAM is totally full (well you said not much benefit, which implies there is some room but not alot). I know this is next step after impossible, but if you were able to run doom on an SA-1 and Super FX at the same time, that would be awesome I really need to learn how the SNES works. On real hardware, it would really help if you could add some extra RAM on a cart, if anything, to increase the memory bandwidth in order to support drawing higher-res graphics and floor/ceiling textures, as I suspect that SNES Doom is already pushing the total memory bandwidth of the system to the limits, which is already at a premium. That means making a lot of adaptations to the code, and "cooking" some or all of the level data, including each time you want to add a new custom level.Įven with that out of the way, you'll really need to write some clever code to take advantage of the "hardware acceleration" on the SNES, with or without the SuperFX chip. ![]() from ROM, while variable things like sector height are stored in RAM. fixed data like the position of vertexes, linedefs etc. space is probably more or less out of the question given the amount of the lower 2MB that's already taken up by Super FX stuff alone.Įven if you get by the ROM size and RAM/ROM access limitations, the main CPU is still too weak to run a "proper" port of Doom -the very least it cannot run straight Linux Doom v1.10 at playable frame rates, and probably cannot even fit a working E1M1 into RAM, unless you abolish the dual disk/RAM form of level data, and separate immutable/mutable parts of the levels, and access e.g. I haven't tried doing a basic profile of the FX-side code to see how much idle time there is between renderer frames, but it's probably not a very promising amount, and trying to optimize for speed vs. All of that still has to be done in software running on a coprocessor, and it's still subject to all the same limitations with regard to execution time. The thing to remember about the Super FX is that it's not a GPU it has no built-in 3D or texture mapping capabilities at all. That's not accounting for the fact that the SNES CPU is, indeed, very slow.Įven given that, I don't really know how much room there is for optimizing the Super FX side code. The biggest restriction is that the CPU and Super FX cannot access the cartridge ROM/RAM simultaneously, so any CPU-side code that runs while the Super FX is active must be run out of system RAM, which is strictly limited to 128 kilobytes (less however much of it is used for game state). ![]() So the most likely/realistic actual limit is probably 4MB.Īnyway, I'm skeptical that having several extra megabytes of space available for CPU-side code will provide much benefit. (Martin Korth's documents say the second additional region is 4MB, but bsnes and higan both disagree with this). There are two different parts of the address space that can be mapped to an additional 2MB, but it's likely that they're both just a mirror of each other, like how the lower 2MB of Super FX ROM (and most other SNES cartridge boards) work. ![]() I think the 8MB max figure is probably not correct either. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |