byuu's message board

Okay, the 21fx API has been removed and replaced with the S-MSU1 API:



http://code.google.com/p/bsnes/downloads/list

The downside is this breaks the existing 21fx patches, but I did warn that could happen. Good news is that assuming nobody has any objections prior to v060's release, this API will be permanently set in stone and not deprecated or removed from bsnes.

What is "data port bank" for?

(And IMO the ASM would be easier to understand if there were dedicated registers for input/output, instead of different functionality depending on read or write access...)

But this is pretty standard for memory mapped I/O..

Ah, fuck. SA-1 uses $220x. I'll need to move this to $4000 anyway. Fun.

-----

I did consider using two additional registers for read, but there's a couple of issues.

1. read effects from $2200-2207, and write effects to $2208-2209 are now undefined. Obviously, the former would be open bus and the latter ignored; but it could lead to emulator variance.

2. I wanted the API to be as compact as possible. True, the 2-register version was best for that. But by having 8, that means we can fit eight of these for 8-channel audio from $21c0-21ff. That's kind of a very, very long-term thing, if people are interested. Would be used to play high-quality sound effects and such and completely replace the S-SMP / S-DSP portions of code.

3. it gives me registers for identifying the chip. This wouldn't be needed if other emulators supported open bus properly (the version ID would be enough), but since they don't ... the six ports give us a perfect identifier without expanding the MMIO range to 16 registers.

Besides, some MMIO does this anyway, so it isn't that unusual.

Yes, but you don't have to do it only because it's possible or others are doing it...


At least on the SNES the functions are mostly related to each other. Here, "status" and "streaming" are interleaved.

If there are other advantages then that's fine, I guess.

I think he should do it this way because it's simpler to implement and IMO a more straightforward design. The reason I mentioned that it's standard went to show that others didn't find it too confusing. So I guess I should ask, why do you find it harder to understand this way?

I will note that it is uncommon, eg S-PPU has write-only $2100-2133, with very odd PPU-1 / PPU-2 open bus pattens for reads. And read-only for $2134-213f, that sets the PPU-1 / PPU-2 open bus values. S-CPU is similar, as is SA-1.

But there are cases where both read and write have different operations -- $4016 is a fairly good example. Writes perform latching while reads just strobe controllers. Writes to $4016 are tied to both joypads while reads are split over two registers. $2140-2143 is another great example, they are attached to completely separate buffering systems to allow bi-directional communication with the S-SMP.

There is no difficulty in doing this on hardware, simply use the /RD signal as the "A3 pin", and the chip will think that 0-7 = write, 8-15 = read. I think that most of the chips split them up for the sake of being able to name "address = register-name", whereas mine has different register-names based upon reading and writing as it stands.

But yeah, expanding adds in at least two complexities to the equation.

---

Anyway, we'll push this API out in v060, then I'll write up a tiny BIOS for its use.

It's not exactly harder, but it's one extra thing you have to be aware of (WinAPI is another example of 1-function-x-functionality). Programmer-friendly APIs try to minimize that, so that you can memorize functionality by function name.


Anyway...

I know I'm late about this, but I just have to say the choice of using a cart design makes it harder for me and the guys I've gathered up to make an expansion processor which also uses the cart and still be compatible, because of electrical peculiarities and race logic.
I can also say, that this can be avoided, if we make our project a dedicated periferal or work very closely with developement, but the latter seems quite nonfunctional as the development of the S-MSU1 is not in hardware yet.
As a periferal it would rather have its own port on the s-msu1 than using the cart slot, communicating specifically with that and not with other carts and the snes, the only problem with that would be cost and power, cost could be avoided if you don't use a connector on all versions but only those specifically upgradeable... and for power as far as choosing components we have only looked at very low power memory and processors, the only problem would be an eventual fpga for snes specific function upgrades...

But even if you choose to do it this way we might reach compability even if it may be the s-msu designers that will work it out...

/Zorbeltuss, who spends to little time in posting and reading on forums...

I've discussed the S-MSU tradeoffs in depth in the past.

If we aim for the expansion port, it won't work on the SNES mini or clone hardware. Not really a huge deal there. It will also require a special connector that is much more difficult to obtain, raising the cost of hardware. Using it on a cartridge will require exposing all of the extended cartridge connector pins -- this can be avoided if you add your own audio output jack onto the cartridge pass-through. Lastly, it adds a severe impediment to the device's entire purpose: by not being able to stream directly to video RAM, it doubles the overhead (have to transfer from SD to RAM, and then RAM to VRAM), requires a large pool of memory (difficult to come by in existing games), and negates its use as a pool for highly-animated, uncompressed sprites uploaded after each video frame.

The cartridge pass-through gets all of these advantages, and works on any hardware under the sun.

But I'll tell you what, if you can design the S-MSU1 in a hardware design using $21f0-21f7, then I will add support in the emulator to map to the B-bus as well. I personally have little faith at this point that the hardware will be made, at least without the software. And if there's a high probability of this being software-only, I'd rather err on the side of utility. This is a media streaming device, and there's no reason to cripple it to cater to non-existent hardware.

Lastly, it should not complicate the design much at all. Nintendo themselves planned to make one of their co-processors a cartridge pass-through. It'd work exactly like the Game Genie, which never caused any issues with games. As long as you pass through all accesses, it only slightly increases the length of traces, and slightly increases power consumption. Both things the Game Genie did.

I must admit, I initially thought that what you were doing was a bit pointless, since it's essentially new hardware. But even if nobody is interested in this in the end, it's still an interesting academic pursuit, and the project seems to already be underway, so...

Just thought I'd offer my encouragement byuu.

it's just sad that there is no one with the expertise or ability to make it because from what I've seen there are plenty of people interested. I'd buy one. In other words, if this is about money, how much? because I'm very interested.

As for it not working on a SNES Jr. or clone.... the kind of person who would buy this has an original SNES or Super Famicom, or would be willing to get one, I'm almost certain.

Bah, $4000 is no good, either. That's the XSlowROM region for gamepads >.>
I'll go with $2000, then.

Yes, there's a slim possibility for phantom 16-bit writes to $1fff (8k WRAM mirror last byte), but a) that is broken game behavior, and b) it won't affect the current API, as nothing happens on writes to low data port address.

And getting the hardware made is about finding the right expert to make it, heh. Not really all about money, although I suppose with an unlimited budget we'd have plenty of takers :)
They'd probably want some crazy figure like 50-100k though >_<

As I said (or meant to say), I do understand, all your points are valid in choosing a passthrough, it does though complicate stuff more than you think, as we intended something capable of maximum bandwidth between the snes and the extension, now it has to have timing tolerance to a much greater extent but as we haven't gotten to any hardware yet, it shouldn't be any problem at all as long as we could grab a hold of hardware descripions... well we wouldn't get going without that anyway...
Well to reshape what I said in other terms, we intended to handle the snes as functional memory and if that will be the case we need to be able to predict the response time of it, now I think we can scrap that idea, because with the new way it will be continious communication instead of predictable intense periods...

Edit: Added a comma in a sentence

/Zorbeltuss who doesn't mean to sound negative because he isn't, he isn't just the best person at communication skills over internet...

Hey, I just wanted to say, well done. This is most impressive! I hope you are able to have a hardware version constructed some day because I would certainly buy one.