FDS homebrew ?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
Xious
Posts: 189
Joined: Sun Oct 11, 2009 5:21 am
Location: Sol 3 in Mutter's Spiral
Contact:

Post by Xious » Mon Mar 15, 2010 3:11 am

I meant save, then continue later...

FYI, if you hit Death with the holy water, it both stuns and does heavy damage to him and you'll beat him in a hurry.

Bregalad wrote:


For example, I would love to see an FDS version of Castlevania: Chorus of Mysteries (on top of the Akumajo Dracula FDS diskette) so that you can save three files and have continues.
I just wanted to point that there IS infinite continues in Castlevania - they just whiped the save out, which wasn't really necessary since you can finish the game in ~45 minutes (for those who are good enough to kill Death, unlike me). No matter if I have saves or not I'll always be stuck at Death, the only way to pass it for me is to have savestates.


The FDS also has its own sound chip, so it would be neat to see new games that make use of it, but if you want to run them on real HW, you'll have to figure out how to write to a disk from an image, which is something I brought up on the hardware forums a while back.
You are right that if I use the sound hardware, it may act differently on the PowerPak that on a real FDS... so I'd have to buy a twin famicom or a working FDS + ask my 60->72 adaptater back from my bro in law + find a way to make the cart fit in my NES, and in all cases buy at least 1 disc and find a way to rewrite it, which sounds tedious, although I'd love to be able to do that.

Also how common are 72->60 adapters ? If I ever go trough the trouble to import a rare twin famicom, I'd be able to at least play games from my Power Pak in NTSC mode !
The other consideration for FDS homebrews is file size: If you want your game to exceed 128K, you have to span multiple disks, and the PowerPak, as of the time of this post, does not support multiple-disk games.

-Xious

User avatar
Memblers
Site Admin
Posts: 3890
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers » Mon Mar 15, 2010 8:51 am

Earlier in the thread I said I'd be cool to do an FDS release, but the more I considered it the more it sounds like a horrible idea. Just imagine all the "fun" it would be to send copies of your game out only to have some drives not read them because of drives going out of alignment after 15 years, or any other very common disk failure modes. Even after calibrating your own drive somehow you'd have to deal with everyone else's bum disks and bum drives. Sounds like big fun, not.

Not to mention the loading times.

tepples
Posts: 22220
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Tue Mar 23, 2010 7:39 am

The wiki article about FDS states that the BIOS verifies 224 bytes in VRAM against corresponding bytes in the BIOS before executing anything, and the KYODAKU- file is supposed to populate them with a trademark notice. This has been ruled ineffective in Sega v. Accolade, 977 F.2d 1510, 24 USPQ2d (BNA) 1561 (9th Cir. 1992). But does the BIOS clear out or verify anything else in the VRAM between loading the initial files and displaying the screen? Specifically does the BIOS do anything to thwart these workarounds?

Workaround #1: Use a nametable file loaded into $3F00 to blank the text.
Workaround #2: Use a CHR file to scramble the text.
Workaround #3: Make the KYODAKU- file 160 bytes longer, much like the opening screen of Bleemcast:

Code: Select all

  CORRECTION: THIS PRODUCT IS
  NOT LICENSED BY NINTENDO OR
  ANYONE ELSE FOR THAT MATTER.
  IGNORE WHAT IT SAYS ABOVE.

User avatar
Bregalad
Posts: 8007
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Tue Mar 23, 2010 10:53 am

Nintendo were careful, and all these workarounds won't work. After loading the boot files, the first nametable is cleared and the second part of the second nametable uses palette #2 which is entirely black (the attribute table is written after the boot files load of course). The palette is rewritten, and from ROM directly. The tiles $00-$23 of second pattern table are backed up in system RAM, and overwritten by the FDS BIOS font for the approval screen, and are restored after the approval screen is shown.

The only "workaround" that might work would be to load a 1-byte file at $101 to give IRQ control to your program (assumed you loaded it BEFORE of course). I have no idea how well it'll work tough and I have no idea how the powerpak would react to this.

EDIT: The FDS BIOS refuses to load any data from disk to $000-$1ff so no way to transfer IRQ control to the main program nor to modify the return adress on stack, like some C64 games did to skip the "ready" prompt. It will ALSO refuse to load data into $800-$9ff, $1000-$11ff and $1800-$19ff. Nintendo REALLY thought of everything.

I guess this is a non-issue, there is probably no way this screen can be skipped or even somehow effected.
Useless, lumbering half-wits don't scare us.

User avatar
Memblers
Site Admin
Posts: 3890
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers » Tue Mar 23, 2010 1:21 pm

I thought I remembered running some strange FDS images on emulators a long time ago that had changed the boot screen to show something else. It might have been Hacker International. I may be remembering something else though.

User avatar
Hamtaro126
Posts: 775
Joined: Thu Jan 19, 2006 5:08 pm

Post by Hamtaro126 » Tue Mar 23, 2010 2:53 pm

tepples wrote:The wiki article about FDS states that the BIOS verifies 224 bytes in VRAM against corresponding bytes in the BIOS before executing anything, and the KYODAKU- file is supposed to populate them with a trademark notice. This has been ruled ineffective in Sega v. Accolade, 977 F.2d 1510, 24 USPQ2d (BNA) 1561 (9th Cir. 1992). But does the BIOS clear out or verify anything else in the VRAM between loading the initial files and displaying the screen? Specifically does the BIOS do anything to thwart these workarounds?

Workaround #1: Use a nametable file loaded into $3F00 to blank the text.
Workaround #2: Use a CHR file to scramble the text.
Workaround #3: Make the KYODAKU- file 160 bytes longer, much like the opening screen of Bleemcast:

Code: Select all

  CORRECTION: THIS PRODUCT IS
  NOT LICENSED BY NINTENDO OR
  ANYONE ELSE FOR THAT MATTER.
  IGNORE WHAT IT SAYS ABOVE.
According to Lost Levels, Sunsoft had Hacker International's Hex editor, it's a relationship that nintendo did not know of even of now.

In Sunsoft's Nazoraa Land (Puzzler Land) Series, The FDS BIOS was rearranged after the BIOS shoed, Scattering and Rebuilding the word ''SUNSOFT'', Then boots up.

This also had something in common in Hacker International's FDS games.
AKA SmilyMZX/AtariHacker.

User avatar
Bregalad
Posts: 8007
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Wed Mar 24, 2010 1:09 am

Memblers wrote:I thought I remembered running some strange FDS images on emulators a long time ago that had changed the boot screen to show something else. It might have been Hacker International. I may be remembering something else though.
Oh my god you are right.
The trick is surprisingly simple : The trick is that FDS BIOS write $c0 to $100 giving NMI control to vector #3 ($dffa-$dffb) by default, and just change it when it exept a VBlank to fire, and restore it again. They load something into the PPU registers, and enable NMIs (which are supposed to be disabled) that way. Eventually an NMI fires and the main program can boot from here - without displaying Nintendo's screen.

EDIT :
Here is a hack of Chris' demo so that it skip Nintendo's screen : http://jonathan.microclub.ch/dummy/DiskTest.FDS
Useless, lumbering half-wits don't scare us.

tepples
Posts: 22220
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

KYODAKU (256 bytes)

Post by tepples » Thu Nov 19, 2020 7:58 pm

This post in November 2020 ten years later brought this old topic to mind, and I wanted to make readers who find this topic through search aware of subsequent developments as well as explore one (admittedly academic) option I had missed at the time.
Bregalad wrote:
Tue Mar 23, 2010 10:53 am
Nintendo were careful, and all these workarounds won't work. After loading the boot files, the first nametable is cleared and the second part of the second nametable uses palette #2 which is entirely black (the attribute table is written after the boot files load of course).
In May 2017, rainwarrior described a stable technical bypass: point the NMI vector at a cleanup routine, overwrite the NMI enable bit at $2000 in the last file loaded at boot, and increase the disk's file count in block 2. I'm just curious what other near-bypasses are possible.

The 7-line notice occupies VRAM $2800-$28DF, or rows 0-6 of the nametable, and as you mentioned, the attributes of the rest of the nametable (rows 8-29) are set to an all-black palette. Yet each row of attributes can blank or not blank 2 rows at a time. This leaves row 7 at $28E0-$28FF, which I imagine could be one line of text that can be manipulated even more convincingly than I did in my Game Boy and Genesis TMSS spoofs. What would the BIOS do with a 256-byte KYODAKU whose last line forces the reader to recontextualize "THIS PRODUCT" as the console itself and "OTHER COMPANY" as Twin Famicom maker Sharp?

Code: Select all

         NINTENDO ®
     FAMILY COMPUTER TM

THIS PRODUCT IS MANUFACTURED
AND SOLD BY NINTENDO CO;LTD.
OR BY OTHER COMPANY UNDER
LICENSE OF NINTENDO CO;LTD..
THE INSERTED DISK IS NOT.

User avatar
aquasnake
Posts: 187
Joined: Fri Sep 13, 2019 11:22 pm

Re: KYODAKU (256 bytes)

Post by aquasnake » Tue Nov 24, 2020 10:45 pm

tepples wrote:
Thu Nov 19, 2020 7:58 pm
This post in November 2020 ten years later brought this old topic to mind, and I wanted to make readers who find this topic through search aware of subsequent developments as well as explore one (admittedly academic) option I had missed at the time.
Bregalad wrote:
Tue Mar 23, 2010 10:53 am
Nintendo were careful, and all these workarounds won't work. After loading the boot files, the first nametable is cleared and the second part of the second nametable uses palette #2 which is entirely black (the attribute table is written after the boot files load of course).
In May 2017, rainwarrior described a stable technical bypass: point the NMI vector at a cleanup routine, overwrite the NMI enable bit at $2000 in the last file loaded at boot, and increase the disk's file count in block 2. I'm just curious what other near-bypasses are possible.

The 7-line notice occupies VRAM $2800-$28DF, or rows 0-6 of the nametable, and as you mentioned, the attributes of the rest of the nametable (rows 8-29) are set to an all-black palette. Yet each row of attributes can blank or not blank 2 rows at a time. This leaves row 7 at $28E0-$28FF, which I imagine could be one line of text that can be manipulated even more convincingly than I did in my Game Boy and Genesis TMSS spoofs. What would the BIOS do with a 256-byte KYODAKU whose last line forces the reader to recontextualize "THIS PRODUCT" as the console itself and "OTHER COMPANY" as Twin Famicom maker Sharp?

Code: Select all

         NINTENDO ®
     FAMILY COMPUTER TM

THIS PRODUCT IS MANUFACTURED
AND SOLD BY NINTENDO CO;LTD.
OR BY OTHER COMPANY UNDER
LICENSE OF NINTENDO CO;LTD..
THE INSERTED DISK IS NOT.
Kyodaku text is used as input to participate in a series of encryption and authentication operations. Therefore, any byte of text cannot be added, deleted or replaced. We have to keep this text and cheat the BIOS reset vector from $DFFC in other ways, such as modifying the decision jump pointer or modifying the pseudo register value.

Nintendo does this to protect the software copyright. Once it is copied, even if the kyodaku text is not displayed in the running, it still exists in the software binary data. Therefore, Nintendo has the evidence of taking legal action.

Unless you can generate a piece of text that has the same number of bytes and is checked by the encryption algorithm in the program. Or modify the verification algorithm itself, which may dynamically and randomly distribute around the disk files anywhere
Last edited by aquasnake on Tue Nov 24, 2020 11:02 pm, edited 1 time in total.

User avatar
rainwarrior
Posts: 7977
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: FDS homebrew ?

Post by rainwarrior » Tue Nov 24, 2020 11:50 pm

No, the bypass technique skips the check for KYODAKU. It does not need to be present on the disk.

Post Reply