Talk:Family Computer Disk System: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(→‎Heel lifts: new section)
m (Reverted edits by 1.161.136.76 (talk) to last revision by Zzo38)
Line 27: Line 27:


Do you have information of Famicom Disk System pinout? --[[User:Zzo38|Zzo38]] 11:43, 28 September 2012 (MDT)
Do you have information of Famicom Disk System pinout? --[[User:Zzo38|Zzo38]] 11:43, 28 September 2012 (MDT)
== Heel lifts ==
heel Lifts really are a great way to introduce additional height in a much less apparent manner than the usual fixed heel Lifts
shoe lifts

Revision as of 03:00, 15 January 2013

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)