Any Documents on FDS bankswitching?
Moderator: Moderators
- Hamtaro126
- Posts: 786
- Joined: Thu Jan 19, 2006 5:08 pm
Any Documents on FDS bankswitching?
There are almost no docs on FDS bankswitching stuff, How is it done?
-Hamtaro126
-Hamtaro126
- Hamtaro126
- Posts: 786
- Joined: Thu Jan 19, 2006 5:08 pm
How does Doki Doki Panic or any other game do the copying then?tepples wrote:FDS doesn't use bankswitching. Instead, it copies data from the disk to the PRG RAM ($6000-$DFFF) and CHR RAM ($0000-$1FFF).
EDIT: Found a resource for the registers used for copying/writing and reading. I found it in the main page. (It is by Brad Taylor)
Everything you need to know is included in the .fds file. The registers used and whatnot aren't as important.
FDS images are a collection of "files". Each file has a header which tells where it gets loaded to and how big it is.
For Side A, files start at offset 0x0004A, and for Side B they start at offset 0x10026.
Files are layed out like so:
If you have DDP handy... you can look at its Side A for an example. It has these files:
I just happened to have this info handy since I'm currently working on something DDP related ^^
FDS images are a collection of "files". Each file has a header which tells where it gets loaded to and how big it is.
For Side A, files start at offset 0x0004A, and for Side B they start at offset 0x10026.
Files are layed out like so:
Code: Select all
--------------------
03 <-- value to identify section as file header
xx <-- file number (largely unimportant)
xx <-- I forget, but again, unimportant
8-character ASCII string <-- name of file
xx xx <-- 2 byte address that file gets placed
xx xx <-- 2 byte size of file
xx <-- value to indicate whether file is PRG/CHR/NT data (unimportant, since that can be inferred from the target address)
04 <-- value to identify start of file data
... <-- file data
-------------------
Code: Select all
0-00.bin: dst: 2800 siz: 00E0 name: KYODAKU-
0-01.bin: dst: 6000 siz: 0600 name: EN-SND-D
0-02.bin: dst: 6000 siz: 8000 name: MAIN-PRO
0-03.bin: dst: B800 siz: 1900 name: ENDING-2
0-04.bin: dst: 0000 siz: 1FF0 name: TITLE-C
0-05.bin: dst: 0E00 siz: 0C00 name: ENDING-C
0-06.bin: dst: 6600 siz: 0006 name: SAVE-DAT
I just happened to have this info handy since I'm currently working on something DDP related ^^
- Hamtaro126
- Posts: 786
- Joined: Thu Jan 19, 2006 5:08 pm
What about loading and putting specific disk binaries with the certain places described above in RAM. I looked in the RAM viewer and it puts certain PRG from the loaded disk in the places to the PRG-RAM in the above destination.Disch wrote:Everything you need to know is included in the .fds file. The registers used and whatnot aren't as important.
FDS images are a collection of "files". Each file has a header which tells where it gets loaded to and how big it is.
For Side A, files start at offset 0x0004A, and for Side B they start at offset 0x10026.
Files are layed out like so:
If you have DDP handy... you can look at its Side A for an example. It has these files:Code: Select all
-------------------- 03 <-- value to identify section as file header xx <-- file number (largely unimportant) xx <-- I forget, but again, unimportant 8-character ASCII string <-- name of file xx xx <-- 2 byte address that file gets placed xx xx <-- 2 byte size of file xx <-- value to indicate whether file is PRG/CHR/NT data (unimportant, since that can be inferred from the target address) 04 <-- value to identify start of file data ... <-- file data -------------------
Code: Select all
0-00.bin: dst: 2800 siz: 00E0 name: KYODAKU- 0-01.bin: dst: 6000 siz: 0600 name: EN-SND-D 0-02.bin: dst: 6000 siz: 8000 name: MAIN-PRO 0-03.bin: dst: B800 siz: 1900 name: ENDING-2 0-04.bin: dst: 0000 siz: 1FF0 name: TITLE-C 0-05.bin: dst: 0E00 siz: 0C00 name: ENDING-C 0-06.bin: dst: 6600 siz: 0006 name: SAVE-DAT
I just happened to have this info handy since I'm currently working on something DDP related ^^
Looks like bankswitching to me. But as you said: It has no bankswitching
If you ever looked at DDP in a hex editor: What puts the PRG and CHR stuff in the PRG-RAM and/or CHR-RAM?
The game tells the BIOS which files it wants loaded and when by JSRing to a specific routine, and the BIOS copies those files to PRG/CHR when told to do so. I'm unsure exactly which routine(s) in the BIOS perform this task, as I haven't looked into it in all that much detail.Hamtaro126 wrote:If you ever looked at DDP in a hex editor: What puts the PRG and CHR stuff in the PRG-RAM and/or CHR-RAM?
BT's doc (the one you mentioned before) has a partially commented disassembly of the BIOS. Maybe skim it for things that look like / are described as file loading routines.
It should also be noted that loading files takes a significantly long time (as opposed to bankswapping which occurs virtually instantly). Loading a single file can take several seconds... which is why whenever an FDS game wants to load a new file, you're stuck with that "Now Loading" screen.
Experience with this is why Nintendo stayed with cartridges for a generation longer than everyone else did.Disch wrote:It should also be noted that loading files takes a significantly long time (as opposed to bankswapping which occurs virtually instantly). Loading a single file can take several seconds... which is why whenever an FDS game wants to load a new file, you're stuck with that "Now Loading" screen.
-
NotTheCommonDose
- Posts: 523
- Joined: Thu Jun 29, 2006 7:44 pm
- Location: lolz!
Until I started working on my emulator I always assumed it had its own file system and the games just somehow loaded files when they wanted. After seeing how (most) games behave, I think it makes sense and is simple enough to use. Now if only it weren't so terribly slow.
Bankswitching is when you "switch" a bank with another bank. But with FDS, you only have one "bank". So instead you load new data into your bank. Now it would have been cool if FDS had more PRG-RAM and/or more CHR-RAM to actually have bankswitching capabilities. If they had made provisions to upgrade RAM or something like that it would probably have helped it stay alive with falling costs of bigger ROM chips. That and a newer faster disk drive.
Bankswitching is when you "switch" a bank with another bank. But with FDS, you only have one "bank". So instead you load new data into your bank. Now it would have been cool if FDS had more PRG-RAM and/or more CHR-RAM to actually have bankswitching capabilities. If they had made provisions to upgrade RAM or something like that it would probably have helped it stay alive with falling costs of bigger ROM chips. That and a newer faster disk drive.
I don't know, looks vague. We have "emulators emulating empirical things", and so on. What about the BIOS? Is required for such thing?
Zepper
RockNES author
RockNES author