, 22 tweets, 4 min read Read on Twitter
This thread will contain all new SA-1 chip findings

Data verified on real hardware. Emulator authors should definitely keep in mind this information for updating the SA-1 emulation later.
1) Banks $50-$5F and $70-$7F are mapped on SA-1 CPU side.

$50-$5F is BW-RAM mirror. That means everything between banks $40 and $5F is BW-RAM. Does that mean SA-1 could map up to 2 *MEGABYTES* of RAM?
There is no such answer for that. There are only enough pins for 256 *KILOBYTES* of RAM.

There is no info about how to activate 256KB of BW-RAM, but please make $00:FFD8 = #$08 give 256 KB for SA-1 and not 0 KB currently.

Only banks $40-$4F and $60-$6F are mapped on SNES side.
$70-$7F is the virtual memory mapping as well (so it continues the data though $60-$6F).

Virtual memory allows reading only two or four bits of the BW-RAM, useful for storing packed 4bpp or 2bpp pixels.
You can also **read** the virtual memory region just fine. The official SNES doc only stated about **writing** to said region.

The circuit responsible for the SA-1 bit stream feature has a few oddities.
1) It only accepts even addresses. The least significant bit is completely ignored.

That means ROM addresses like $00:8001 will be read as $00:8000 instead.

2) The address expects the actual memory map.
However regions that does not map to ROM will just mirror to bank 0 instead
For example, $00:0000-$00:7FFF is the same as $00:8000-$00:FFFF.

Even worse, for banks $40-$7F, *everything* is bank 0 mirror (LoROM!)
$41:8000 will actually mirror to $00:8000 (LoROM) and NOT $01:8000 like expected.

Banks $C0-$FF works as expected (HiROM).

In other words, divide the memory map in 32 KB blocks.

$00-$3F; $80-$BF: LoROM ($8000)
$C0-$FF: HiROM
Everything else: Mirror to bank 0.
Everything else includes banks $00-$3F; $80-$BF 32KB blocks of $0000-$7FFF and all 32KB blocks of banks $40-$7F.
Why are the odd addresses completely ignored? This is simple to explain: because the SA-1 ROM has a 16-bit bus, so the address is halved when tossed to the ROM circuit, discarding the low byte. It does not add any special treatment for reading the high byte first or something.
Variable Length Bit reading automatic mode DOES NOT WORK on my cart. It always automatically shifts 16-bit words regardless of the setting you select, when picking auto mode. This may need more studies. Fixed mode works fine.

You can enable FastROM on a SA-1 ROM.

What happens? The SA-1 chip is paused whenever SNES attempts a fast ROM reading, however it does not crash. The system is smart enough to allocate all of its I/O resources and hand to the SNES system.
However, that behavior only exists on the actual FastROM accesses. Accessing though DMA or banks $00-$7F, the SA-1 CPU speed is not affected.

This is extremely clever and even more if you consider that's only possible with the chip monitoring changes to the $420D register.
I have accidentally made HDMA access not use FastROM access and I ran out of erased ROM chips. But I need to make sure the speed is not affected by HDMA as well to confirm this. DMA reads from bank $C0 which is FastROM.
But is there any point in using FastROM on a SA-1 ROM if the chip will end up getting paused? Yes!
You can always trigger an IRQ when calling SA-1 on WRAM. That means if you only use SA-1 only or S-CPU only per time, you can get the best speed of both with 10.73 and 3.58 MHz, with one paused while the other one is running.
Even if you use SA-1 and SNES CPU at the same time... Like, for example, in Touhou Mario 2 SA-1 is used for processing bitmap graphics in background at certain sections, during critical timing situations you enable FastROM on SNES and pause SA-1 temporally.
This is useful during interrupts. You can run though V-Blank and do all PPU operations much faster on SNES side for a few scanlines and sacrifice SA-1 for a bit more V-Blank time in your game. Or somewhat improve SPC transfers by minimizing synchronization periods between chips.
Picture with FastROM.
New "toggle FastROM" test. Keeps switching the FastROM flag while running on FastROM area while SA-1 tries running on the ROM. 😂 Literally a statue and run game for the chip!

Also verified that DMA and HDMA doesn't affect SA-1 speed even on FastROM area.
That's all for now! Next week who knows there will be more mad findings? 😁😁😂
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Vitor Vilela
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!