What do I need to start developing games for the Famicom Disk System. I have minor knowledge on making programs for the NES. Is it similar? Are there build tools i should be aware of? I have FDSLOADR for testing and development and I would like to eventually write programs to disks to play them on original hardware.
Thanks!
Anthony
As long as you don't deal with loading files or changing disk side, it's pretty much the same except you need file headers for each file. You have three NMIs you can use. More details here: http://wiki.nesdev.com/w/index.php/Family_Computer_Disk_System.
Here is an example I made which loads without errors but I couldn't get my program to load for some reason:
Edit: Got it to work at last: http://www.famicomworld.com/forum/index.php?topic=12209.msg166113#msg166113
;Famicom Disk System Program Template v0.7
;By Pokun
;
;Assembles in ASM6
;FDS Disk Image
;Games are stored on one or multiple disk sides (every disk has 2 sides).
;The FDS BIOS is used to load data from disks to PRG RAM or VRAM,
;and games can execute from there.
;===============================================================================
; Constants
;===============================================================================
;Header constants
REVISION = $00 ;revision number used in the header (starts at 0)
SIDE_COUNT = $01 ;number of disk sides (1, 2 or 4)
FILE_COUNT1 = $02 ;total number of non-hidden files on disk side 1
FILE_COUNT2 = $00 ;total number of non-hidden files on disk side 2
FILE_COUNT3 = $00 ;total number of non-hidden files on disk side 3
FILE_COUNT4 = $00 ;total number of non-hidden files on disk side 4
;FDS defines
FDS_CRAM = $0000 ;where CHR-RAM starts
FDS_PRAM = $6000 ;where PRG-RAM starts
FDS_BIOS = $E000 ;where the BIOS resides
;FDS BIOS calls
FDS_Delay132 = $E149 ;132 clock cycle delay
;===============================================================================
; Variables
;===============================================================================
;Zero Page ($0000-$00FF)
.enum $0000
.ende
;Page 1 ($0100-$01FF)
;(Stack)
;Page 2 ($0200-$02FF)
;(Shadow OAM)
;Page 3-7 ($0300-$07FF)
.enum $0300
.ende
;===============================================================================
; fwNES FDS header
;===============================================================================
;16 byte header for the .FDS Quick Disk format
;This header is optional as newer emulators may not require
;it. Number of disk sides can be figured out by looking at the
;FDS image file size.
.org $0000
; .db "FDS", $1A ;identification of the fwNES header
; .db SIDE_COUNT ;number of disk sides
; .pad 16, $00 ;clear the remaining bytes
;HEADEROFFSET = $ ;add this to compensate for the added header.
;Note about blocks
;Each disk side must be structured into blocks as follows:
;First a disk header block and a file amount block then one file header block
;and file data block for each file on the disk. Finally the disk sides ends
;with an end of disk side indicator. Each block has a block code:
;$01 = Disk Header Block
;$02 = File Amount Block
;$03 = File Header Block
;$04 = File Data Block
;$FF = End of Disk Side Indicator
;From the last file, fill the side with zeroes so that the disk side gets
;exactly 65500 bytes.
;On real disks there are also gaps and CRCs not present in
;FDS images. These must also be considered when calculating true
;disk capacity. The actual disc capacity in bytes is:
;65500 - 28300/8 - (2*N + 1)*(16 + 976)/8
;N = number of files
;===============================================================================
; Disk Side 1 (65500 byte)
;===============================================================================
;Disk Header Block
.db $01 ;Block code (1 = disk header block)
.db "*NINTENDO-HVC*" ;Used by BIOS to verify legitimate image.
;If the string is wrong the disk will fail to boot.
.db $00 ;Maker code (similar codes as in Game Boy headers)
;$00 is unlicenced, $01 is Nintendo $08 is Capcom...
.db "HMB" ;3-letter ASCII code for title (e.g. LNK for Zelda no Densetsu)
.db " " ;Game type
;$20 = " " -- Normal disk
;$45 = "E" -- Event (e.g. Japanese national DiskFax tournaments)
;$52 = "R" -- Reduction in price via advertising
.db REVISION ;Revision number (starts at $00, increments per revision)
.db $00 ;Side number
;$00 = Side A, $01 = Side B. Single-sided disks use $00
.db $00 ;Disk number (first disk is $00, second is $01, etc.)
.db $00 ;Disk type
;$00 = FMC ("normal card"), $01 = FSC ("card with shutter")
.db $00 ;Unknown
.db $0F ;Boot read file code (file code/number to load upon boot)
.db $FF,$FF,$FF,$FF,$FF ;Unknown
.db $00,$00,$00 ;Manufacturing date
;Stored in BCD, subtract the Shouwa starting year 1925 from the year
;Example: 1988-11-28 becomes $63 $11 $28
.db $49 ;Country code ($49 = Japan)
.db $61 ;Unknown
.db $00 ;Unknown
.db $00,$02 ;Unknown
.db $00,$00,$00,$00,$00 ;Unknown
.db $00,$00,$00 ;"Rewritten disk" date (supposedly by the Disk Writer)
.db $00 ;Unknown
.db $80 ;Unknown
.db $00,$00 ;Disk Writer serial number
.db $07 ;Unknown
.db $00 ;Disk rewrite count (value in BCD, $00 = Original (no copies))
.db $00 ;Actual disk side ($00 = Side A, $01 = Side B)
.db $00 ;Unknown
.db $00 ;Price
;.db $00,$00 ;CRC - Not used in the .fds file format.
;Disk sides note
;If the FDS is started with a disk whose side number and disk number
;aren't both $00, it will be prompted to insert the first disk side.
;However, some games make this number $00, even for the second disk
;to make it bootable too.
;File Amount block
.db $02 ;Block code (2 = file amount block)
.db FILE_COUNT1 ;Total number of files recorded on disk (side?)
;If more files exist on disk they will be considered hidden and the
;BIOS will ignore them. A loading routine on disk is required to
;load them.
;File codes note
;All files with IDs smaller or equals to the boot read file code
;will be loaded when the game is booting.
;-------------------------------------------------------------------------------
;File "KYODAKU-"
;The first file on the disk must be the "KYODAKU-" file (approval in Japanese)
;that contains the message that scrolls up on screen ("THIS PRODUCT
;IS MANUFACTERED AND SOLD BY NINTENDO...") at boot, and must match
;the same data in the BIOS at $ED37. It's a nametable type of file that is
;loaded into VRAM address $2800.
;File Header Block
.db $03 ;Block code (3 = file header block)
.db $00 ;File Number
;must go in increasing order, first file is 0
.db $00 ;File ID
;ID specified at disk-read function call
;This is the number which will decide which file is
;loaded from the disk (instead of the file number).
;An ID smaller than the boot number means the file is
;a boot file, and will be loaded on first start up.
.db "KYODAKU-" ;File Name (8 uppercase ASCII characters)
.db $00,$28 ;File Address (16-bit little endian)
;the destination address when loading
.db $E0,$00 ;File Size (16-bit little endian)
.db $02 ;File Type
;0:Program (PRAM)
;1:Character (CRAM)
;2:Nametable (VRAM)
;File Data Block
.db $04 ;Block code
.include "KYODAKU-.650" ;file data
;If this file doesn't match the 224-byte text aproval data in the BIOS the
;disk won't run.
;-------------------------------------------------------------------------------
;File "MAINGAME"
;File Header Block
.db $03 ;Block code
.db $01 ;File Number
.db $01 ;File ID
.db "MAINGAME" ;File Name (8 uppercase ASCII characters)
.dw FDS_PRAM ;Where to load file to (16-bit little endian)
.dw (MainGameEnd - MainGameStart) ;File Size (16-bit little endian)
.db $00 ;File type
;0:Program (PRAM)
;1:Character (CRAM)
;2:Nametable (VRAM)
;File Data Block
.db $04 ;Block code
MainGameStart:
.include "MAINGAME.650" ;file data
MainGameEnd:
;This file contains the main program and data.
;-------------------------------------------------------------------------------
;End of Disk Side 1
.db $FF ;End of disk side indicator
.pad 65500, $00 ;zero out rest of disk
;-------------------------------------------------------------------------------
;Next disk side goes here. A header for this side is needed but no KYODAKU-file
;unless it's bootable I think.
And the "KYODAKU-.650" file needs to contain this:
;"KYODAKU-" file
HEX 24 24 24 24 24 24 24 24 24 24 24 17 12 17 1D 0E
HEX 17 0D 18 24 28 24 24 24 24 24 24 24 24 24 24 24
HEX 24 24 24 24 24 24 24 0F 0A 16 12 15 22 24 0C 18
HEX 16 19 1E 1D 0E 1B 24 1D 16 24 24 24 24 24 24 24
HEX 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24
HEX 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24
HEX 24 24 1D 11 12 1C 24 19 1B 18 0D 1E 0C 1D 24 12
HEX 1C 24 16 0A 17 1E 0F 0A 0C 1D 1E 1B 0E 0D 24 24
HEX 24 24 0A 17 0D 24 1C 18 15 0D 24 0B 22 24 17 12
HEX 17 1D 0E 17 0D 18 24 0C 18 27 15 1D 0D 26 24 24
HEX 24 24 18 1B 24 0B 22 24 18 1D 11 0E 1B 24 0C 18
HEX 16 19 0A 17 22 24 1E 17 0D 0E 1B 24 24 24 24 24
HEX 24 24 15 12 0C 0E 17 1C 0E 24 18 0F 24 17 12 17
HEX 1D 0E 17 0D 18 24 0C 18 27 15 1D 0D 26 26 24 24
;Translates to this in SMB/Zelda encoding:
;" NINTENDO R "
;" FAMILY COMPUTER TM "
;" "
;" THIS PRODUCT IS MANUFACTERED "
;" AND SOLD BY NINTENDO CO,LTD. "
;" OR BY OTHER COMPANY UNDER "
;" LICENSE OF NINTENDO CO,LTD.. "
The "MAINGAME.650" file I haven't got to load yet so there's not much point in posting it. But it should look like something like this I believe:
;File "MAINGAME" data
;-------------------------------------------------------------------------------
NMI1:
jsr FDS_HOOK
rti
NMI2:
jsr FDS_HOOK
rti
NMI3:
jsr FDS_HOOK
;NMI code here
rti
;if you are not using all three NMIs you can have them share the same label
;-------------------------------------------------------------------------------
RESET:
;init code (although I believe the BIOS does most of the init at boot)
jsr FDS_HOOK
main:
;main program loop here
jmp main
;Subroutines:
FDS_HOOK:
;Prevent the program to suddenly reset to
;the FDS menu on NMI, IRQ, or RESET.
pha
lda #$C0
sta $0100 ;set NMI
lda #$80
sta $0101 ;set IRQ
lda #$35
sta $0102 ;set RESET vector
lda #$53
sta $0103 ;set boot type to "reset by user"
pla
rts
IRQ:
jsr FDS_HOOK
rti
;===============================================================================
; Interrupt Vector Table
;===============================================================================
.org $DFF6
.dw NMI1
.dw NMI2
.dw NMI3
.dw RESET
.dw IRQ
;-------------------------------------------------------------------------------
The FDS_HOOK I learned from Chris Covell. Just call it at the start of each interrupt handler.
This is great! Thanks! Although I noticed that some pirate software like Disk Hacker II and Brad Taylors Graphics Demo, don't have the KYODAKU file, as they don't display that message. Is this file even necessary for booting?
It's normally necessary. I have no idea how those programs tricks the BIOS. I think some Super Pig games also display another message there or skips it entierly so there's definitely a way around it.
Oh interesting. Maybe i'll write for the fds for my next project.
So trying your program files out.
I found that once the file loads it constantly uses
PC OP ARG
------------------------
$0000 JSR $0000
it just jumps to the same line it jumps from. no matter what i put in MAINGAME, that's all it does.
You forgot about IRQ and NMI
I was under the impression that FDS programming was basically like any other ASIC mapper, only significant difference is having to manually load and save data on the floppy disk, whereas on a cartridge game, addresses can easily be requested.
I'm under that impression too.
I tried adding a CHR data file and see if it loaded at boot and it did. So there's either something very wrong with my MAINGAME file or there something small in the header that isn't quite right. Maybe I misunderstood something about file IDs or something.
address to start?
What address? I start the image at .org $0000 and the interrupt vector table is at $DFF6. Is there something I missed?
The MAINGAME file is set to load to beginning of PRAM in the RAM Adapter.
Quote from: P on October 03, 2015, 12:48:48 pm
What address? I start the image at .org $0000 and the interrupt vector table is at $DFF6. Is there something I missed?
The MAINGAME file is set to load to beginning of PRAM in the RAM Adapter.
And PRAM is $6000.
Yes it is. Do you mean the image file start address should start at $6000 as well, using .org?
I read wiki page about FDS BIOS subroutines, but can't see clear howto start loaded file. If there is no info in the header(address to start), there might be two ways to start loaded programm.
1. Jump to the first loaded byte.
2. Use interrupt handler. NMI or IRQ.
How would I jump to the first loaded byte or use NMI/IRQ handlers? I can't jump since my code never starts in the first place. I tried adding a jmp RESET as a first thing in the MAINGAME file but it doesn't work.
I assume that the program starts executing where the reset vector at $DFFC points at, but my program never seems to start. It gets stuck at a JSR $0000 as Aguerro says.
1. BIOS subroutine do.
2. Same as above with more flexibility.
You should check your code AND setting interrupt handlers.
Usually loading subroutines do
a) loading data from start address to end address. return.
b) loading data from start address, specified amount of bytes(words). return.
c) a or b AND jump to the start address(or first adress, where data was loaded).
d) a or b AND jump to the specified address.
We have three handlers
RESET - set to beginnig of your code to avoid go back to FDS menu
IRQ
NMI
or now i miss something :(
1. Not sure how to load a subroutine when my code never loads.
2. Same as above.
The BIOS loads all files that have an ID that is the same or lower as the Boot Read File Code value.
I have three files:
"KYODAKU-" ID: 0
"MAINGAME" ID: 1
"CHRDATA1" ID: 2
And my Boot Read File Code is set to $0F so all these files should load at boot automatically. The KYODAKU- file successfully loads since the message comes scrolling up. And the CHRDATA1 file also loads according to the PPU debugger in my emulator. But the MAINGAME file never loads, or at least it never executes.
I tried moving up the RESET handler to the beginning of the file but it doesn't change anything.
Same. I also noticed that on the FDS page on NesDev. It says you should write $C0 to $0101 to use your own IRQ routine.
Quote from: NesDev Wiki
A few important notes :
After loading the boot files, $102 is set to $35 so that the ($DFFC) vector is used and the BIOS is skipped.
$103 indicate reset type : $AC = first boot of the game, $53 = the game was soft-reseted by the user
To use your own IRQ routine, you must manually write $c0 to $101
There is 3 possible NMI vectors, #3 is used by default.
On first start, the mirroring is set to horizontal, the stack pointer is $ff, and the I flag is clear. System RAM is filled with values used by the BIOS, and PRG RAM is uninitialized, except for parts of it which has files loaded in.
But in your FDS_HOOK code you are writing $80. Although you aren't doing much in IRQ except for jumping to FDS_HOOK. I changed it to $C0 but nothing different happened.
You only need to write $C0 if you are using IRQ, which I'm not (I just put an FDS_HOOK jsr there for the sake of it). After boot-up, $0101 is set to $80 by the BIOS (so IRQs are turned off by default).
I also found in Brad Taylor's Technical Reference (http://nesdev.com/FDS%20technical%20reference.txt):
Quote
Booting a disk game
-------------------
Once a disk's boot files have been loaded successfully into memory (more on
this later), ($0102) is assigned $AC35, and the BIOS data area (and their
respective ports) are set to the aforementioned reset values. Finally,
interrupts are enabled, and program control is transfered to the ($DFFC)
vector.
Program control is transferred to the $DFFC vector. Which is exactly right. It should be loading my code:
main:
ldx #$00
inx
jmp main
I looked at the hex and everything. :- This is puzzling.
Post Merge: October 04, 2015, 01:13:53 pm
Using the Hex Editor in FCEUX i can confirm that the code in MAINGAME is not even loading into PRAM. Very Puzzling.
I double checked the header file again and I can't find anything wrong with it. I bet the problem is in the MAINGAME file, or there's something there we don't understand properly.
/sarcasm mode on/ Sorry, can't help you much, my mind occupied by greediness of making bootleg repros /sarcasm mode off/
The best you can do is disassemble BIOS to figure out, how exactly it is working. Or check Enri's page, maybe info already there.
There are documents out there with parts of the BIOS disassembled I think. It's just that they get a bit too technical for a simple layman like me. I need a working example, and tried making it myself since there is none AFAIK.
Chris Covell is one of few people that has already successfully made some FDS homebrew (http://www.chrismcovell.com/creations.html) but I can't make head or tail out of his source code.
So i got it to work after emailing Chris, and the solution is kinda silly.
When you make the files in the FDS image, the vectors themselves don't go in to the disk at $DFF6. They are going to be loaded into PRAM which is at $6000. This means you must position your vectors on the disk so that when they are loaded, they land at $DFF6. This can be tricky and I had to hand code most of the label-work to get it to boot my code.
EDIT:
And another reason it wasn't loading was that the file was too big. When you
.org DFF6
then you are making that file really big. Too big actually. For my test, I set the MAINGAME file to go into PRAM at $DFE0 so that loading would be quick. Then It was a matter of setting the vectors to go in the right places. I still need to figure out a way for the assembler to find the values for my JMPs and vectors, so I don't have to manually type them in.
I see, that explains why I ran out of disk space when I tried to add more data although I only had three quite small files.
Brad Taylor has released his Development Kit that he uses for FDS Development. It's pretty cool and makes writing programs a lot simpler. His assembler format is a little weird.
Stuff like
LDA #$00
turns into
lda_ imd,00h
but if you can tolerate that, it's pretty nice.
Another tip on fast game loading, if you put the Reset, NMI, and IRQ vectors in a seperate File on the FDS image, and have it load at $DFF6, it is a lot faster than loading a bunch of 0's from $6000 to $DFF6 until you hit the vectors in your program.
Also, skipping the KYODAKU- is something Brad Taylor has talked about before. All you need is a one-byte file that loads into $2000 and contains $80. This sets the NMI to fire on vblanks. Then you load a file that is at least $100 large that loads into a useless space in PRAM. This way, the BIOS doesn't have time to complain on missing the KYODAKU- file. Do this after loading your MAINGAME file. In the MAINGAME file, you then need to reinstall the vector for some reason.
Here's something I made using Brad Taylor's assembler:
model small
codeseg
org 0
include ..\fds.inc
include ..\6502.inc
start: ret
;----------------------------------------------------------------------------
; DECLARE TILE SET
FDSchr 'MARIOCHR',0000h,endchr
db 8192 dup(?)
endchr:
;----------------------------------------------------------------------------
; Constants
SPEED = 5
;----------------------------------------------------------------------------
; RESET & INIT
FDSprg ' EXAMPLE',6000h,endprg
;disable video(bg+obj), VINT, disk system
reset:
sei_
cld_
lda_ imd,27h
sta_ abz,4025h; shut down disk system
ldx_ imd,-1
txs_
;install NMI handler (required, due to avoiding the KYODAKU copyright screen)
lda_ imd,<(nmi-start)and 255>
sta_ abz,0dffah
lda_ imd,<(nmi-start)shr 8>
sta_ abz,0dffbh
;clear memory
ldx_ imd,0
clrmem:
lda_ imd,0
sta_ abx,0000h
sta_ abx,0300h
sta_ abx,0400h
sta_ abx,0500h
sta_ abx,0600h
sta_ abx,0700h
lda_ imd,11111110b
sta_ abx,0200h; clear all the sprites
inx_
bne_ clrmem
;load palette
lda_ abz,2002h; reset the write high/low latch
lda_ imd,3fh
sta_ abz,2006h
lda_ imd,00h
sta_ abz,2006h; set the ppu address to $3f00
tax_
paletteloop:
lda_ abx,colpal
sta_ abz,2007h
inx_
cpx_ imd,20h
bne_ paletteloop
;load sprites from DBs
ldx_ imd,0
spriteloop:
lda_ abx,sprites
sta_ abx,0200h
inx_
cpx_ imd,10h
bne_ spriteloop
;turn on screen
lda_ imd,10000000b
sta_ abz,2000h; enable NMI
lda_ imd,00010000b
sta_ abz,2001h; enable sprites
lp: jmp_ abz,lp; infinite loop
;----------------------------------------------------------------------------
; Color Palette
colpal:
db 0fh,31h,32h,33h,0fh,35h,36h,37h,0fh,39h,3ah,3bh,0fh,3dh,3eh,0fh;bg
db 0fh,0fh,10h,30h,0fh,01h,21h,31h,0fh,36h,16h,0fh,0fh,29h,1ah,0fh;fg
;----------------------------------------------------------------------------
; Initial Sprite DBs
sprites:
; vert,tile,attr,horiz
db 70h,32h,03h,70h; sprite 0
db 70h,33h,03h,78h; sprite 1
db 78h,34h,03h,70h; sprite 2
db 78h,35h,03h,78h; sprite 3
;----------------------------------------------------------------------------
; VBLANK
NMI:
;sprite dma from $0200
lda_ imd,0
sta_ abz,2003h
lda_ imd,02h
sta_ abz,4014h
;controller handling
lda_ imd,01h
sta_ abz,4016h
lda_ imd,00h
sta_ abz,4016h; strobe buttons to latch positions
lda_ abz,4016h; Player 1 - A
and_ imd,00000001b
bne_ read1adone
lda_ zpg,00h
clc_
adc_ imd,01h
sta_ zpg,00h
read1adone:
lda_ abz,4016h; Player 1 - B
and_ imd,00000001b
bne_ read1bdone
lda_ zpg,00h
sec_
sbc_ imd,01h
sta_ zpg,00h
read1bdone:
lda_ abz,4016h; Player 1 - Select
read1seldone:
lda_ abz,4016h; Player 1 - Start
read1stadone:
lda_ abz,4016h; Player 1 - Up
and_ imd,00000001b
beq_ read1updone
x=0
rept 4
lda_ abz,0200h+x
sec_
sbc_ zpg,00h
sta_ abz,0200h+x;
x=x+4
endm
read1updone:
lda_ abz,4016h; Player 1 - Down
and_ imd,00000001b
beq_ read1dwndone
x=0
rept 4
lda_ abz,0200h+x
clc_
adc_ zpg,00h
sta_ abz,0200h+x;
x=x+4
endm
read1dwndone:
lda_ abz,4016h; Player 1 - Left
and_ imd,00000001b
beq_ read1lftdone
x=0
rept 4
lda_ abz,0203h+x
sec_
sbc_ zpg,00h
sta_ abz,0203h+x
x=x+4
endm
read1lftdone:
lda_ abz,4016h; Player 1 - Right
and_ imd,00000001b
beq_ read1rgtdone
x=0
rept 4
lda_ abz,0203h+x
clc_
adc_ zpg,00h
sta_ abz,0203h+x;
x=x+4
endm
read1rgtdone:
rti_
;----------------------------------------------------------------------------
endprg:
FDSend reset,reset; irq
ends
end start
All it does is put mario on the screen, and let you move him around with different speeds.
Hope this Helps!
I guess it's this one https://sites.google.com/site/digilogistist/fds-devkit--raster-demo. Hadn't seen that one.
Quote from: P on September 25, 2015, 12:00:45 pm
main:
;main program loop here
jmp main
man, it looks like an endless loop. Main goes to main again and again. Was it intentional?
have you tried to put some more code into 'main' loop?
Quote from: famifan on October 26, 2015, 07:28:01 am
Quote from: P on September 25, 2015, 12:00:45 pm
main:
;main program loop here
jmp main
man, it looks like an endless loop. Main goes to main again and again. Was it intentional?
have you tried to put some more code into 'main' loop?
It's probably supposed to be like that, with NMIs set to fire on VBlank the NMI functions will run in parallel to that loop.
:( nvm, sorry for confusing
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).
Quote from: P on October 26, 2015, 02:32:56 am
I guess it's this one https://sites.google.com/site/digilogistist/fds-devkit--raster-demo. Hadn't seen that one.
Yeah, he just released it not too long ago.
Thanks for posting this aguerrero810, very interesting. I'm not sure I understand the logic behind that (pretty nasty IMO) assembly syntax though...
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. ;)
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.
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...
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?
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 (http://s000.tinyupload.com/?file_id=97096330637195521366) :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
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.
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 :)
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!
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.
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 :)
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?
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.
When's someone going to develop an NSF player? ??? Is anyone planning or working on one?
Do I need to throw money? Here: :coin: :coin: :coin: :coin: :coin: :coin: Here's some more: :coin: :coin: ;D
Yeah an NSF player for FDSStick that supports NSFs with FDS expansion sound would be awesome!
Is it possible to read the memory on FDSStick and load NSF-files from it?