bsnes/higan/systems/Super Famicom.sys/boards.bml

824 lines
22 KiB
Plaintext
Raw Normal View History

database
revision: 2018-04-08
//Boards (Production)
database
revision: 2018-02-27
board: BANDAI-PT-923
rom
map address=00-1f,80-9f:8000-ffff mask=0x8000
sufamiturbo
rom
map address=20-3f,a0-bf:8000-ffff mask=0x8000
ram
map address=60-6f,e0-ef:0000-ffff
sufamiturbo
rom
map address=40-5f,c0-df:0000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-ffff
board: BSC-1A5M-02
rom
map address=00-1f:8000-ffff mask=0x8000 base=0x000000
map address=20-3f:8000-ffff mask=0x8000 base=0x100000
map address=80-9f:8000-ffff mask=0x8000 base=0x200000
map address=a0-bf:8000-ffff mask=0x8000 base=0x100000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
bsmemory
map address=c0-ef:0000-ffff
board: BSC-1A7M-01
rom
map address=00-1f:8000-ffff mask=0x8000 base=0x000000
map address=20-3f:8000-ffff mask=0x8000 base=0x100000
map address=80-9f:8000-ffff mask=0x8000 base=0x200000
map address=a0-bf:8000-ffff mask=0x8000 base=0x100000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
bsmemory
map address=c0-ef:0000-ffff
board: BSC-1J3M-01
rom
map address=00-1f,80-9f:8000-ffff
map address=40-5f,c0-df:0000-ffff
ram
map address=20-3f,a0-bf:6000-7fff mask=0xe000
bsmemory
map address=20-3f,a0-bf:8000-ffff
map address=60-7d,e0-ff:0000-ffff
board: BSC-1J5M-01
rom
map address=00-1f,80-9f:8000-ffff
map address=40-5f,c0-df:0000-ffff
ram
map address=20-3f,a0-bf:6000-7fff mask=0xe000
bsmemory
map address=20-3f,a0-bf:8000-ffff
map address=60-7d,e0-ff:0000-ffff
board: BSC-1L3B-01
sa1
map address=00-3f,80-bf:2200-23ff
rom
map address=00-3f,80-bf:8000-ffff mask=0x408000
map address=c0-ff:0000-ffff
bwram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=40-4f:0000-ffff
iram
map address=00-3f,80-bf:3000-37ff size=0x800
bsmemory
board: BSC-1L5B-01
sa1
map address=00-3f,80-bf:2200-23ff
rom
map address=00-3f,80-bf:8000-ffff mask=0x408000
map address=c0-ff:0000-ffff
bwram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=40-4f:0000-ffff
iram
map address=00-3f,80-bf:3000-37ff size=0x800
bsmemory
board: SGB-R-10
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
map address=40-7d,c0-ff:0000-7fff mask=0x8000
icd revision=2
map address=00-3f,80-bf:6000-67ff,7000-7fff
rom
gameboy
board: SHVC-1A0N-(01,02,10,20,30)
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
map address=40-7d,c0-ff:0000-7fff mask=0x8000
board: SHVC-1A1B-(04,05,06)
rom
map address=00-1f,80-9f:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-ffff
board: SHVC-1A1M-(01,10,11,20)
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-1A3B-(11,12,13)
rom
map address=00-1f,80-9f:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-ffff
board: SHVC-1A3B-20
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-1A3M-(10,20,21,30)
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-1A5B-(02,04)
rom
map address=00-1f,80-9f:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-ffff
board: SHVC-1A5M-(01,11,20)
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-1B0N-(02,03,10)
rom
map address=00-1f,80-9f:8000-ffff mask=0x8000
necdsp model=uPD7725 frequency=8000000
map address=30-3f,b0-bf:8000-ffff mask=0x3fff
prom
drom
dram
board: SHVC-1B5B-02
rom
map address=00-1f,80-9f:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-ffff
necdsp model=uPD7725 frequency=8000000
map address=20-3f,a0-bf:8000-ffff mask=0x3fff
prom
drom
dram
board: SHVC-1C0N
superfx
map address=00-3f,80-bf:3000-34ff
rom
map address=00-1f,80-9f:8000-ffff mask=0x8000
ram
map address=60-7d,e0-ff:0000-ffff
board: SHVC-1C0N5S-01
superfx
map address=00-3f,80-bf:3000-34ff
rom
map address=00-1f,80-9f:8000-ffff mask=0x8000
ram
map address=60-7d,e0-ff:0000-ffff
board: SHVC-1CA0N5S-01
superfx
map address=00-3f,80-bf:3000-34ff
rom
map address=00-3f,80-bf:8000-ffff mask=0x8000
map address=40-5f,c0-df:0000-ffff
ram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=70-71,f0-f1:0000-ffff
board: SHVC-1CA0N6S-01
superfx
map address=00-3f,80-bf:3000-34ff
rom
map address=00-3f,80-bf:8000-ffff mask=0x8000
map address=40-5f,c0-df:0000-ffff
ram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=70-71,f0-f1:0000-ffff
board: SHVC-1CA6B-01
superfx
map address=00-3f,80-bf:3000-34ff
rom
map address=00-3f,80-bf:8000-ffff mask=0x8000
map address=40-5f,c0-df:0000-ffff
ram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=70-71,f0-f1:0000-ffff
board: SHVC-1CB0N7S-01
superfx
map address=00-3f,80-bf:3000-34ff
rom
map address=00-3f:8000-ffff mask=0x8000
map address=40-5f:0000-ffff
ram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=70-71:0000-ffff
board: SHVC-1CB5B-20
superfx
map address=00-3f,80-bf:3000-34ff
rom
map address=00-3f:8000-ffff mask=0x8000
map address=40-5f:0000-ffff
ram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=70-71:0000-ffff
board: SHVC-1CB7B-01
superfx
map address=00-3f,80-bf:3000-34ff
rom
map address=00-3f:8000-ffff mask=0x8000
map address=40-5f:0000-ffff
ram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=70-71:0000-ffff
board: SHVC-1DC0N-01
hitachidsp model=HG51B169 frequency=20000000
map address=00-3f,80-bf:6c00-6fff,7c00-7fff
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
map address=70-77:0000-7fff
rom
map address=00-3f,80-bf:8000-ffff mask=0x8000
drom
dram
map address=00-3f,80-bf:6000-6bff,7000-7bff mask=0xf000
board: SHVC-1DS0B-20
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
necdsp model=uPD96050 frequency=11000000
map address=60-67,e0-e7:0000-3fff
prom
drom
dram
map address=68-6f,e8-ef:0000-7fff mask=0x8000
board: SHVC-1J0N-(01,10,20)
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
board: SHVC-1J1M-(11,20)
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
ram
map address=20-3f,a0-bf:6000-7fff mask=0xe000
board: SHVC-1J3B-01
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
ram
map address=20-3f,a0-bf:6000-7fff mask=0xe000
board: SHVC-1J3M-(01,11,20)
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
ram
map address=20-3f,a0-bf:6000-7fff mask=0xe000
board: SHVC-1J5M-(01,11,20)
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
ram
map address=20-3f,a0-bf:6000-7fff mask=0xe000
board: SHVC-1K0N-01
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
necdsp model=uPD7725 frequency=8000000
map address=00-1f,80-9f:6000-7fff mask=0xfff
prom
drom
dram
board: SHVC-1K1B-01
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
ram
map address=20-3f,a0-bf:6000-7fff mask=0xe000
necdsp model=uPD7725 frequency=8000000
map address=00-1f,80-9f:6000-7fff mask=0xfff
prom
drom
dram
board: SHVC-1L0N3S-01
sa1
map address=00-3f,80-bf:2200-23ff
rom
map address=00-3f,80-bf:8000-ffff mask=0x408000
map address=c0-ff:0000-ffff
bwram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=40-4f:0000-ffff
iram
map address=00-3f,80-bf:3000-37ff size=0x800
board: SHVC-1L3B-(02,11)
sa1
map address=00-3f,80-bf:2200-23ff
rom
map address=00-3f,80-bf:8000-ffff mask=0x408000
map address=c0-ff:0000-ffff
bwram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=40-4f:0000-ffff
iram
map address=00-3f,80-bf:3000-37ff size=0x800
board: SHVC-1L5B-(11,20)
sa1
map address=00-3f,80-bf:2200-23ff
rom
map address=00-3f,80-bf:8000-ffff mask=0x408000
map address=c0-ff:0000-ffff
bwram
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=40-4f:0000-ffff
iram
map address=00-3f,80-bf:3000-37ff size=0x800
board: SHVC-1N0N-(01,10)
sdd1
map address=00-3f,80-bf:4800-480f
rom
map address=00-3f,80-bf:8000-ffff
map address=c0-ff:0000-ffff
board: SHVC-2A0N-01#R
rom
map address=00-2f,80-af:8000-ffff mask=0x8000
map address=40-6f,c0-ef:0000-ffff mask=0x8000
board: SHVC-2A0N-(01,10,11,20)
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
map address=40-7d,c0-ff:0000-7fff mask=0x8000
board: SHVC-2A1M-01
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-2A3B-01
rom
map address=00-3f,80-bf:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-2A3M-01#R
rom
map address=00-3f,80-bf:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-2A3M-(01,11,20)
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-2A5M-01
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-2B3B-01
rom
map address=00-3f,80-bf:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
necdsp model=uPD7725 frequency=8000000
map address=60-6f,e0-ef:0000-7fff mask=0x3fff
prom
drom
dram
board: SHVC-2DC0N-01
hitachidsp model=HG51B169 frequency=20000000
map address=00-3f,80-bf:6c00-6fff,7c00-7fff
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
map address=70-77:0000-7fff
rom
map address=00-3f,80-bf:8000-ffff mask=0x8000
drom
dram
map address=00-3f,80-bf:6000-6bff,7000-7bff mask=0xf000
board: SHVC-2E3M-01
rom
map address=00-3f,80-bf:8000-ffff mask=0x8000
obc1
map address=00-3f,80-bf:6000-7fff mask=0xe000
map address=70-71,f0-f1:6000-7fff,e000-ffff mask=0xe000
ram
board: SHVC-2J0N-(01,10,11,20)
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
board: SHVC-2J3M-(01,11,20)
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
ram
map address=10-1f,30-3f,90-9f,b0-bf:6000-7fff mask=0xe000
board: SHVC-2J5M-01
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
ram
map address=10-1f,30-3f,90-9f,b0-bf:6000-7fff mask=0xe000
board: SHVC-3J0N-01
rom
map address=00-2f,80-af:8000-ffff
map address=40-6f,c0-ef:0000-ffff
board: SHVC-BA0N-(01,10)
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
map address=40-7d,c0-ff:0000-7fff mask=0x8000
board: SHVC-BA1M-01
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-BA3M-(01,10)
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
ram
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: SHVC-BJ0N-(01,20)
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
board: SHVC-BJ1M-(10,20)
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
ram
map address=20-3f,a0-bf:6000-7fff mask=0xe000
board: SHVC-BJ3M-10
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
ram
map address=20-3f,a0-bf:6000-7fff mask=0xe000
board: SHVC-LDH3C-01
spc7110
map address=00-3f,80-bf:4800-483f
map address=50,58:0000-ffff
map=mcu address=00-3f,80-bf:8000-ffff mask=0x800000
map=mcu address=c0-ff:0000-ffff mask=0xc00000
prom
drom
ram
map address=00-3f,80-bf:6000-7fff mask=0xe000
epsonrtc
map address=00-3f,80-bf:4840-4842
ram
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
board: SHVC-LN3B-01
sdd1
map address=00-3f,80-bf:4800-480f
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
rom
map address=00-3f,80-bf:8000-ffff
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
map address=c0-ff:0000-ffff
ram
map address=00-3f,80-bf:6000-7fff mask=0xe000
map address=70-73:0000-ffff
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
board: SHVC-SGB2-01
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
map address=40-7d,c0-ff:0000-7fff mask=0x8000
icd revision=2 frequency=20971520
map address=00-3f,80-bf:6000-67ff,7000-7fff
rom
gameboy
board: SHVC-YA0N-01
rom
map address=00-7d,80-ff:8000-ffff mask=0x8000
map address=40-7d,c0-ff:0000-7fff mask=0x8000
board: SHVC-YJ0N-01
rom
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
//Boards (Generic)
database
revision: 2018-04-08
board: ARM-LOROM-RAM
memory type=ROM content=Program
map address=00-7d,80-ff:8000-ffff mask=0x8000
map address=40-6f,c0-ef:0000-7fff mask=0x8000
memory type=RAM content=Save
map address=70-7d,f0-ff:0000-ffff
armdsp
map address=00-3f,80-bf:3800-38ff
memory type=ROM content=Program manufacturer=SETA
memory type=ROM content=Data manufacturer=SETA
memory type=RAM content=Data manufacturer=SETA
oscillator
board: BS-HIROM-RAM
memory type=ROM content=Program
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-1f,80-9f:8000-ffff
map address=40-5f,c0-df:0000-ffff
memory type=RAM content=Save
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=20-3f,a0-bf:6000-7fff mask=0xe000
bsmemory
map address=20-3f,a0-bf:8000-ffff
map address=60-7d,e0-ff:0000-ffff
board: BS-LOROM-RAM
memory type=ROM content=Program
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-1f:8000-ffff base=0x000000 mask=0x8000
map address=20-3f:8000-ffff base=0x100000 mask=0x8000
map address=80-9f:8000-ffff base=0x200000 mask=0x8000
map address=a0-bf:8000-ffff base=0x100000 mask=0x8000
memory type=RAM content=Save
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=70-7d,f0-ff:0000-7fff mask=0x8000
bsmemory
map address=c0-ef:0000-ffff
board: BS-MCC-RAM
memory type=RAM content=Save
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=10-1f:5000-5fff mask=0xf000
mcc
map address=00-0f:5000
map=mcu address=00-3f,80-bf:8000-ffff mask=0x408000
map=mcu address=40-7d,c0-ff:0000-ffff
memory type=ROM content=Program
memory type=RAM content=Download
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-3f,80-bf:6000-7fff mask=0xe000
bsmemory
board: BS-SA1-RAM
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
sa1
map address=00-3f,80-bf:2200-23ff
memory type=ROM content=Program
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-3f,80-bf:8000-ffff mask=0x408000
map address=c0-ff:0000-ffff
memory type=RAM content=Save
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=40-4f:0000-ffff
memory type=RAM content=Internal
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-3f,80-bf:3000-37ff size=0x800
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
bsmemory
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
board: HIROM
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
board: HIROM-RAM
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
memory type=RAM content=Save
map address=20-3f,a0-bf:6000-7fff mask=0xe000
board: HIROMEX-RAM
memory type=ROM content=Program
map address=00-3f:8000-ffff base=0x400000
map address=40-7d:0000-ffff base=0x400000
map address=80-bf:8000-ffff mask=0xc00000
map address=c0-ff:0000-ffff mask=0xc00000
memory type=RAM content=Save
map address=20-3f,a0-bf:6000-7fff mask=0xe000
map address=70-7d:0000-7fff
board: HITACHI-LOROM
hitachidsp model=HG51BS169
map address=00-3f,80-bf:6c00-6fff,7c00-7fff
map address=70-77:0000-7fff
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff mask=0x8000
memory type=ROM content=Data manufacturer=Hitachi
memory type=RAM content=Data manufacturer=Hitachi
map address=00-3f,80-bf:6000-6bff,7000-7bff mask=0xf000
oscillator
board: LOROM
memory type=ROM content=Program
map address=00-7d,80-ff:8000-ffff mask=0x8000
board: LOROM-RAM
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff mask=0x8000
memory type=RAM content=Save
map address=70-7d,f0-ff:0000-ffff mask=0x8000
board: LOROMEX-RAM
memory type=ROM content=Program
map address=00-7d,80-ff:8000-ffff mask=0x8000
memory type=RAM content=Save
map address=70-7d,f0-ff:0000-7fff mask=0x8000
board: NEC-HIROM
memory type=ROM content=Program
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
necdsp model=uPD7725
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-1f,80-9f:6000-7fff mask=0xfff
memory type=ROM content=Program manufacturer=NEC
memory type=ROM content=Data manufacturer=NEC
memory type=RAM content=Data manufacturer=NEC
oscillator
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
board: NEC-HIROM-RAM
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff
map address=40-7d,c0-ff:0000-ffff
memory type=RAM content=Save
map address=20-3f,a0-bf:6000-7fff mask=0xe000
necdsp model=uPD7725
map address=00-1f,80-9f:6000-7fff mask=0xfff
memory type=ROM content=Program manufacturer=NEC
memory type=ROM content=Data manufacturer=NEC
memory type=RAM content=Data manufacturer=NEC
oscillator
board: NEC-LOROM
memory type=ROM content=Program
map address=00-1f,80-9f:8000-ffff mask=0x8000
necdsp model=uPD7725
map address=30-3f,b0-bf:8000-ffff mask=0x3fff
memory type=ROM content=Program manufacturer=NEC
memory type=ROM content=Data manufacturer=NEC
memory type=RAM content=Data manufacturer=NEC
oscillator
board: NEC-LOROM-RAM
memory type=ROM content=Program
map address=00-1f,80-9f:8000-ffff mask=0x8000
memory type=RAM content=Save
map address=70-7d,f0-ff:0000-ffff
necdsp model=uPD7725
map address=20-3f,a0-bf:8000-ffff mask=0x3fff
memory type=ROM content=Program manufacturer=NEC
memory type=ROM content=Data manufacturer=NEC
memory type=RAM content=Data manufacturer=NEC
oscillator
board: NEC-LOROMEX-RAM
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff mask=0x8000
memory type=RAM content=Save
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=70-7d,f0-ff:0000-7fff mask=0x8000
necdsp model=uPD7725
map address=60-6f,e0-ef:0000-7fff mask=0x3fff
memory type=ROM content=Program manufacturer=NEC
memory type=ROM content=Data manufacturer=NEC
memory type=RAM content=Data manufacturer=NEC
oscillator
board: NECEX-LOROM-BATTERY
memory type=ROM content=Program
map address=00-7d,80-ff:8000-ffff mask=0x8000
necdsp model=uPD96050
map address=60-67,e0-e7:0000-3fff
memory type=ROM content=Program manufacturer=NEC
memory type=ROM content=Data manufacturer=NEC
memory type=RAM content=Data manufacturer=NEC
map address=68-6f,e8-ef:0000-7fff mask=0x8000
oscillator
board: OBC1-LOROM-RAM
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff mask=0x8000
obc1
map address=00-3f,80-bf:6000-7fff mask=0xe000
map address=70-71,f0-f1:6000-7fff,e000-ffff mask=0xe000
memory type=RAM content=Save
board: RTC-HIROMEX-RAM
memory type=ROM content=Program
map address=00-3f:8000-ffff base=0x400000
map address=40-7d:0000-ffff base=0x400000
map address=80-bf:8000-ffff mask=0xc00000
map address=c0-ff:0000-ffff mask=0xc00000
memory type=RAM content=Save
map address=20-3f,a0-bf:6000-7fff mask=0xe000
map address=70-7d:0000-7fff
sharprtc
map address=00-3f,80-bf:2800-2801
memory type=RTC manufacturer=Sharp
board: SA1-RAM
sa1
map address=00-3f,80-bf:2200-23ff
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff mask=0x408000
map address=c0-ff:0000-ffff
memory type=RAM content=Save
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=40-4f:0000-ffff
memory type=RAM content=Internal
map address=00-3f,80-bf:3000-37ff size=0x800
board: SDD1
sdd1
map address=00-3f,80-bf:4800-480f
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff
map address=c0-ff:0000-ffff
board: SDD1-RAM
sdd1
map address=00-3f,80-bf:4800-480f
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff
map address=c0-ff:0000-ffff
memory type=RAM content=Save
map address=00-3f,80-bf:6000-7fff mask=0xe000
map address=70-73:0000-ffff mask=0x8000
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
board: SGB-LOROM
memory type=ROM content=Program
map address=00-7d,80-ff:8000-ffff mask=0x8000
map address=40-7d,c0-ff:0000-7fff mask=0x8000
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
icd revision=2
map address=00-3f,80-bf:6000-67ff,7000-7fff
memory type=ROM content=Boot manufacturer=Nintendo
oscillator
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
gameboy
board: SPC7110-RAM
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
spc7110
map address=00-3f,80-bf:4800-483f
map address=50,58:0000-ffff
map type=MCU address=00-3f,80-bf:8000-ffff mask=0x800000
map type=MCU address=c0-ff:0000-ffff mask=0xc00000
memory type=ROM content=Program
memory type=ROM content=Data
memory type=RAM content=Save
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-3f,80-bf:6000-7fff mask=0xe000
board: SPC7110-RTC-RAM
spc7110
map address=00-3f,80-bf:4800-483f
map address=50,58:0000-ffff
map type=MCU address=00-3f,80-bf:8000-ffff mask=0x800000
map type=MCU address=c0-ff:0000-ffff mask=0xc00000
memory type=ROM content=Program
memory type=ROM content=Data
memory type=RAM content=Save
map address=00-3f,80-bf:6000-7fff mask=0xe000
epsonrtc
map address=00-3f,80-bf:4800-4842
memory type=RTC manufacturer=Epson
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
board: ST-LOROM
memory type=ROM content=Program
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=00-1f,80-9f:8000-ffff mask=0x8000
sufamiturbo
rom
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=20-3f,a0-bf:8000-ffff mask=0x8000
ram
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=60-6f,e0-ef:0000-ffff
sufamiturbo
rom
Update to v106r08 release. byuu says: Changelog: - Game Boy: fixed RAM/RTC saving¹ - Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype with a functionally identical ICD1) - Sufami Turbo: removed short-circuiting when loading an unlinkable cartridge into slot A² - Super Game Boy: the 20971520hz clock of the SGB2 is now emulated - Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory cartridges; and can make use of them³ - Super Famicom: fixed a potential for out-of-bounds reads with BS Memory flash carts ¹: I'm using a gross hack of replacing `type: ` with `type:` so that `memory(type=...)` will match without the extra spaces. I need to think about whether I want the BPath query syntax to strip whitespace or not. But longer term, I want to finalize game/memory's design, and build a higan/emulation/manifest parser that produces a nicer interface to reading manifests for all cores, which will make this irrelevant for higan anyway. ²: I don't think it's appropriate for higan to enforce this. Nothing stops you from inserting games that can't be linked into a real Sufami Turbo. I do short-circuit if you cancel the first load, but I may allow loading an empty slot A with a populated slot B. I think the BIOS does something when you do that. Probably just yells at you. ³: I know it's emulated correctly now, but I still don't know what the heck changes when you load the SD Gundam G Next - Unit & Map Collection BS Memory cartridge with SD Gundam G Next to actually test it.
2018-02-21 09:53:49 +00:00
map address=40-5f,c0-df:0000-ffff mask=0x8000
ram
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
map address=70-7d,f0-ff:0000-ffff
board: SUPERFX-RAM
superfx
map address=00-3f,80-bf:3000-34ff
memory type=ROM content=Program
map address=00-3f,80-bf:8000-ffff mask=0x8000
map address=40-5f,c0-df:0000-ffff
memory type=RAM content=Save
map address=00-3f,80-bf:6000-7fff size=0x2000
map address=70-71,f0-f1:0000-ffff