Famicom Disk System Development

Started by aguerrero810, September 24, 2015, 07:36:29 pm

Previous topic - Next topic

P

Yes it's supposed to be like that, Famicom games never ends unless you cut the power so it only makes sense to end the RESET handler in an infinite loop.

It may be a bit confusing that I call that loop the main loop even though it's totally empty, and all code are instead either before the loop or in the NMI. But I aimed for a minimal working template so there was never any need for code in the main loop.

A more complicated game may divide it's code between the main loop and the NMI (graphic updates, music and other things that needs to run at 60Hz in the NMI, and game logic in the main loop for example).

aguerrero810


chowder

Thanks for posting this aguerrero810, very interesting.  I'm not sure I understand the logic behind that (pretty nasty IMO) assembly syntax though...

aguerrero810

yeah, it's taking some getting used to. Brad Taylor made all the 6502 language statements into macros in his TASM assembler. So instructions are followed by an underscore. Then you just have to specify the addressing mode of the instruction, and the operand. $XXXX doesn't work, so you have to specify hex as XXXXh. Immediate instructions don't require a # because the addressing mode is specified. It's kinda time consuming, but I think this is the best bet for now. Until loopy makes asm6 play with FDS a little nicer. ;)

P

I bet it's not hard to do in asm6 with some macros or something (or is that reason he used TASM instead of a real 6502 assembler?). But I never really got into the macro language so I'm not sure how to solve the problem.

aguerrero810

So I was emailing him about some problems I was having with the software, during that he told me why he used tasm
Quote from: Brad TaylorYou should know that last time I used ASM6, it did some things wrong (like doing x=x-1 in macros/repeat blocks seems to assign x the wrong value, and you can not ORG to an address backwards in memory).

I much prefer ASM6 for NES development, mostly because I don't really use macros that often, but making an FDS file kinda requires a lot of that...

chowder

Quote from: aguerrero810 on October 31, 2015, 10:09:04 pm
So I was emailing him about some problems I was having with the software, during that he told me why he used tasm
Quote from: Brad TaylorYou should know that last time I used ASM6, it did some things wrong (like doing x=x-1 in macros/repeat blocks seems to assign x the wrong value, and you can not ORG to an address backwards in memory).

I much prefer ASM6 for NES development, mostly because I don't really use macros that often, but making an FDS file kinda requires a lot of that...


I wonder if .base would work instead, .org-ing to a "backwards" address doesn't make sense.  For NROM based NES development I just use .org $C000 or $8000 at the start then .org $FFFA before the interrupt vectors.

.base lets you have multiple banks designed to be located at the same address, for example if you were using a mapper to swap PRG banks:


; program bank 0
.base $8000
.include "bank_0.asm"
.org $C000

; program bank 1
.base $8000
.include "bank_1.asm"
.org $C000
...
etc


Maybe I'm barking up the wrong tree entirely here :)  I'd really like to use asm6 though if possible, I'll keep working on it!

P, I discovered a couple of things regarding the disk end marker and some file size stuff I wouldn't mind discussing with you.  Maybe we could take it to email to avoid clogging this thread up and then share any results back here?


P

November 01, 2015, 09:05:58 am #37 Last Edit: September 20, 2017, 05:42:13 am by P
So something like this maybe?

;MAINGAME file:

 .base FDS_PRAM ;($6000)

 ;...

 .org $DFF6
;Interrupt vector table here


I wonder if the .org $0000 in the header-file is also causing trouble, since $0000 is CRAM location?

Quote from: chowder on November 01, 2015, 04:42:46 am
P, I discovered a couple of things regarding the disk end marker and some file size stuff I wouldn't mind discussing with you.  Maybe we could take it to email to avoid clogging this thread up and then share any results back here?

Sure! We can take it via PM.

Post Merge: November 03, 2015, 04:46:35 pm

Thanks to chowder we got it to work!

Enjoy! :)
Famicom Disk System image template :diskkun:


It's a simple program that initializes some graphics (but never really draws anything) and plays a note on the square1 channel to show that it actually works. Three files are included: KYODAKU-file, the program file and a CHR file.

Instead of trying to get asm6 to put the correct addresses with .org and stuff, we simply assembles each file separately and then links them all to one FDS image file. This probably means that some stuff needs to be moved around (like constants and variables).

Oops looks like a comment ended up in the wrong place:
"  ;Since it's a small file we put it at $A000 instead of the beginning of CRAM."
This comment is supposed to be under the MAINGAME file and it's beginning of PRAM and not beginning of CRAM.
Edit: Fixed

aguerrero810

Wow guys, this is great! I will definitely try this out! Although, may I suggest putting the Vectors in a separate file so load times are fast no matter where the main file is located in ram? I'm pretty sure commercial games do this.

chowder

Here's some code I've been working on as a test, it just displays a nametable to the screen (a single line of text in this case).  Not terribly useful, but it's a starting point :)  Note that I'm not doing anything with the NMIs, but by default nmi3 would be used.

https://drive.google.com/file/d/0B1Yh8r7sMuwtdTVINDlRZFRaUFU/view?usp=sharing

Compiled code for the curious :)

https://drive.google.com/file/d/0B1Yh8r7sMuwtTlpUYjV0WjB2Vk0/view?usp=sharing

I didn't bother with the FDS_HOOK routine that P posted as I couldn't understand the logic behind it - all the values written there are the defaults initialised by the FDS BIOS, are they somehow overwritten at times?

Quote from: aguerrero810 on November 10, 2015, 08:34:11 pm
Wow guys, this is great! I will definitely try this out! Although, may I suggest putting the Vectors in a separate file so load times are fast no matter where the main file is located in ram? I'm pretty sure commercial games do this.


I'm not sure what you mean by separate file, just load the vectors as their own disk file to $DFF6?  The load time doesn't seem that bad considering it's not bypassing the "kyodaku" text :)


aguerrero810

So, I've finished High School, and started College. Now I'm interested in doing this again. What I meant by this was exactly what you said, make the vectors on another separate disk file that gets loaded to $DFF6. For some reason, load times were awful for me, but when I tried your example just now, they were fine. I'm going to look at your source to see why that is in a sec. I'm very excited to get going again!

PS: P's tinyupload link expired. If you want to fix that, that'd be great!

P

I re-uploaded my template. Tinyupload hosts your files forever, but apparently forever means 100 days after the last download.
Looking forward to see what you will make! :)

Quote from: chowder on November 11, 2015, 06:14:52 am
I didn't bother with the FDS_HOOK routine that P posted as I couldn't understand the logic behind it - all the values written there are the defaults initialised by the FDS BIOS, are they somehow overwritten at times?

I didn't really understand it either, I just did what Chris Covell recommended me to do. I guess the values could change somehow, so this reinitializes them in that case.

chowder

Quote from: P on August 04, 2016, 01:50:37 am
I didn't really understand it either, I just did what Chris Covell recommended me to do. I guess the values could change somehow, so this reinitializes them in that case.


I guess it's probably best to be sure in case something overwrites them.

I haven't touched this stuff in a long time, I hope you find it useful aguerrero810 :)

zxin

I wasn't aware people really made games for the FDS anymore.
Would it actually be possible to get one of these new games on to a FDS diskette?
Thanks for your time,<br />~zxin

P

Yes there is no difference between these homebrew from commercial games. If you are able to rewrite disks, you should be able to write any FDS program on them.

There's debate, however, of how many people will be able to play your rewritten disks, depending on your FDS disk drive you use to rewrite it with.