Talk:Family Computer Disk System
Typo?
I think there was a mistake in the document, it said that GetDiskInfo was at E23A, and that makes no sense since it overlaps with another function. Another document said it was E32A (not E23A), so I changed it. --Dwedit 21:37, 11 October 2010 (UTC)
Yes, it was a typo. Thank you for correcting it Bregalad 11:14, 12 October 2010 (UTC)
$eb13
Given a few minutes of analysis, the routine at $eb13 appears to read the Family basic keyboard state into $00-$08. --Quietust 13:31, 13 October 2010 (UTC)
Great finding Q ! What about completing the article about it ? Now only $e8b3 and $e94f are still somewhat obscure. Bregalad 21:03, 13 October 2010 (UTC)
VRAM Buffer
I'm trying to learn how the FDS works (hence my efforts to tidy up descriptions and such), and I'm a little confused. There's a buffer at $3xx which is what the various PrepareVRAMString routines and such copy to/from, but it doesn't support fills and doesn't support 32-byte increment? WriteVRAMBuffer is what you use to actually copy the $3xx buffer into VRAM, correct?
That seems a little less useful than just simply using VRAMStructWrite, pointing to $0302, and gaining access to the extra features like fill and 32-byte increment. --Drag 17:27, 26 February 2012 (PST)
You are correct. The missing future are fill, 32-byte increment, but also sub-structures. The advantage, however, is that the second routine (WriteVRAMBuffer) is way faster than the first (VRAMStructWrite), as it doesn't have to check for those flags (which aren't available any longer), and uses direct addressing $302,X instead of indirect addressing to access the buffer. So the second routine is more suited to do VRAM updates during VBlank, while the first routine is more suited to do bulk updates during forced blanking, although technically both can do both.
BTW thanks for fixing/correcting my work.Bregalad 12:33, 27 February 2012 (PST)
- VRAM updates during VBlank like writing a column of a horizontally scrolling background? --Tepples 12:38, 27 February 2012 (PST)
Well....... Then you either upload it a tile at a time or call the slow routine (both will be slow) or write your own (fast).Bregalad 13:18, 27 February 2012 (PST)
Thanks! I wanted to see if it would be better to use the one in the BIOS first, before I went straight to just using my own. Thank you for clearing that up for me. :D --Drag 18:01, 27 February 2012 (PST)
Pinout
Do you have information of Famicom Disk System pinout? --Zzo38 11:43, 28 September 2012 (MDT)
QDI format
I want to mention this here in case someone finds it useful. A .QDI file is a raw disk image for a single side of a single disk (including gaps, checksums, full size, etc). In order for an emulator to support it, I recommend the following:
- If loading a .NES ROM image with mapper 20, it should treat it as a BIOS ROM and start the FDS with no disk inserted. If a hard or soft reset is requested, and any .QDI is inserted, it should boot that disk side; if none is inserted, it should boot from no disk.
- If loading a .FDS disk image, it should enable the "insert disk 1 side A" and so on, and treat it as it already does. (Some emulators may make a private copy in the user's home directory for saving (maybe even converting to .QDI upon first loading!); others may overwrite the existing .FDS instead.)
- If loading a .QDI disk image, it should boot from that one, and have a "insert .QDI" option.
- If possible, the emulator should use the underlying filesystem's read-only flag (or otherwise determine if it is read-only) to determine how to set the write-protect flag in the FDS registers.
