Are High SNES Homebrew Expectations Justified?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: Are High SNES Homebrew Expectations Justified?
Ah sorry I totally misunderstood what you were trying to do. I tought you were trying to stream music in real-time in the SPC using HDMA ; instead you're using it to bypass the SPC700 entierely and write to the S-DSP registers using the ROM bootloader. My bad.
Since the release of Super Jukebox I've been wanting to write my own SNES sound engine but yeah... it's been a long time.
Since the release of Super Jukebox I've been wanting to write my own SNES sound engine but yeah... it's been a long time.
Useless, lumbering half-wits don't scare us.
- Señor Ventura
- Posts: 177
- Joined: Sat Aug 20, 2016 3:58 am
Re: Are High SNES Homebrew Expectations Justified?
I think the snes scene has a lack of sharing libraries and developed tools in comparison with another platforms. An engine that allows transfer high quality samples sounds quite hard to carry out, but once done, there is nothing more to do tan copy & paste (well, you know).psycopathicteen wrote: ↑Sat Nov 07, 2020 12:58 pmMusic-wise it's pretty hard getting something as good as existing games. I think an HDMA engine would actually make it easier on me just because I find the 65816 much easier to work with.
Using HDMA for samples is a good boost, but you lose everything else.
How donkey kong country manages its music?.
-
- Posts: 2980
- Joined: Wed May 19, 2010 6:12 pm
Re: Are High SNES Homebrew Expectations Justified?
What do you mean by you lose everything else?Señor Ventura wrote: ↑Sat Nov 07, 2020 3:18 pmI think the snes scene has a lack of sharing libraries and developed tools in comparison with another platforms. An engine that allows transfer high quality samples sounds quite hard to carry out, but once done, there is nothing more to do tan copy & paste (well, you know).psycopathicteen wrote: ↑Sat Nov 07, 2020 12:58 pmMusic-wise it's pretty hard getting something as good as existing games. I think an HDMA engine would actually make it easier on me just because I find the 65816 much easier to work with.
Using HDMA for samples is a good boost, but you lose everything else.
How donkey kong country manages its music?.
Re: Are High SNES Homebrew Expectations Justified?
Probably talking about the DMA channels being taken up by HDMA.psycopathicteen wrote: ↑Sat Nov 07, 2020 7:00 pmWhat do you mean by you lose everything else?Señor Ventura wrote: ↑Sat Nov 07, 2020 3:18 pmUsing HDMA for samples is a good boost, but you lose everything else.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
-
- Posts: 2980
- Joined: Wed May 19, 2010 6:12 pm
Re: Are High SNES Homebrew Expectations Justified?
I'm not planning on using the bootloader. I'm using my own loop. The bootloader routine is too convoluted.Bregalad wrote: ↑Sat Nov 07, 2020 2:41 pmAh sorry I totally misunderstood what you were trying to do. I tought you were trying to stream music in real-time in the SPC using HDMA ; instead you're using it to bypass the SPC700 entierely and write to the S-DSP registers using the ROM bootloader. My bad.
Since the release of Super Jukebox I've been wanting to write my own SNES sound engine but yeah... it's been a long time.
I could actually do both stream music and dsp writes with this approach.
-
- Posts: 1080
- Joined: Tue Feb 07, 2017 2:03 am
Re: Are High SNES Homebrew Expectations Justified?
if you can code the 65816, then you can code the SPC-700 to do what you directly. Its just a 6502 with hardware mul and I think div. Having it run in parallel is a huge speed boost. Since the SPC-700 is out of sync with the SNES's clock, you want to avoid direct contact as much as possible, its just more pain.
-
- Posts: 1080
- Joined: Tue Feb 07, 2017 2:03 am
Re: Are High SNES Homebrew Expectations Justified?
-
- Posts: 1080
- Joined: Tue Feb 07, 2017 2:03 am
Re: Are High SNES Homebrew Expectations Justified?
rebuilding the DKC render to sprites tech might make things easier, doing a bunch of nurbs in blender vs piles of pixel art would probably reduce dev effort a fair amount.
Re: Are High SNES Homebrew Expectations Justified?
A sequel should not be a hack, it should innovate.
And I don't mean cheap gimmicks, I mean actually try to meaningfully improve upon the previous game.
Also, nice double post m8.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.
Re: Are High SNES Homebrew Expectations Justified?
Excactly. Actually the hardest part is the communication between SPC-700 and 65816 so it sounds like he actually coded only the hardest part of a sound engine !Oziphantom wrote: ↑Sat Nov 07, 2020 11:28 pmif you can code the 65816, then you can code the SPC-700 to do what you directly. Its just a 6502 with hardware mul and I think div. Having it run in parallel is a huge speed boost. Since the SPC-700 is out of sync with the SNES's clock, you want to avoid direct contact as much as possible, its just more pain.
Useless, lumbering half-wits don't scare us.
Re: Are High SNES Homebrew Expectations Justified?
I guess, if you are more comfortable making 3D models than pixel art anyway. Pre-rendered graphics does give an impact to the art style of the game though.Oziphantom wrote: ↑Sat Nov 07, 2020 11:35 pmrebuilding the DKC render to sprites tech might make things easier, doing a bunch of nurbs in blender vs piles of pixel art would probably reduce dev effort a fair amount.
-
- Posts: 2980
- Joined: Wed May 19, 2010 6:12 pm
Re: Are High SNES Homebrew Expectations Justified?
I'm making a music program, so I need as much communication as possible.Bregalad wrote: ↑Sun Nov 08, 2020 4:05 amExcactly. Actually the hardest part is the communication between SPC-700 and 65816 so it sounds like he actually coded only the hardest part of a sound engine !Oziphantom wrote: ↑Sat Nov 07, 2020 11:28 pmif you can code the 65816, then you can code the SPC-700 to do what you directly. Its just a 6502 with hardware mul and I think div. Having it run in parallel is a huge speed boost. Since the SPC-700 is out of sync with the SNES's clock, you want to avoid direct contact as much as possible, its just more pain.
Re: Are High SNES Homebrew Expectations Justified?
All these SNES discussions piqued my interest in picking up SNES homebrew again. I reused code from previous failed attempts years ago but switched assembler to WLA-DX, and finally got everything to work as expected. One problem of SNES development for me has been about finding a good 65816 assembler and an SPC-700 assembler. And WLA-DX got both those covered. I take back anything bad I've said about it in the past, it's a wonderful assembler. Optiroc's tools superfamiconv and superfamicheck also makes SNES homebrew much easier nowadays.
In the past I was turned off by the fact that WLA-DX tries to be smart and do way too much for you, including the header, vector tables, banks and that weird slot system. But reading the readme I noticed that only the memory map and banking directives are actually mandatory. And those are done with some brief code at the start, the rest can be done manually using classic .org, .orga and .base directives, while the possibility of more advanced sections is still there but optional. The header and vector tables can also be done manually using .db and .dw directives as the header directives are not mandatory. Direct page addressing and such things doesn't seem to be a problem either as it can easily be manually set to assemble like you want. It makes sure to stay out of your way.
Before I tried WLA-DX, I made an attempt with 64tass. It seemed to work fine, but this assembler seems to just love PETSCII way too much. I can't for the life of me get it to assemble strings as ASCII properly, and the manual is very brief on explaining how these things works.
In the past I was turned off by the fact that WLA-DX tries to be smart and do way too much for you, including the header, vector tables, banks and that weird slot system. But reading the readme I noticed that only the memory map and banking directives are actually mandatory. And those are done with some brief code at the start, the rest can be done manually using classic .org, .orga and .base directives, while the possibility of more advanced sections is still there but optional. The header and vector tables can also be done manually using .db and .dw directives as the header directives are not mandatory. Direct page addressing and such things doesn't seem to be a problem either as it can easily be manually set to assemble like you want. It makes sure to stay out of your way.
Before I tried WLA-DX, I made an attempt with 64tass. It seemed to work fine, but this assembler seems to just love PETSCII way too much. I can't for the life of me get it to assemble strings as ASCII properly, and the manual is very brief on explaining how these things works.
-
- Posts: 1080
- Joined: Tue Feb 07, 2017 2:03 am
Re: Are High SNES Homebrew Expectations Justified?
WLA-DX is a horrible assembler for 65XX ( best in class for Z80 ). It will send you insane. The problem is the linker can't modify the code. This works fine for Z80 which it was designed for, but on 65816 it can cause you lots of random bugs.
LDA #someLabel
now if someLabel is in the DP, you want the DP version of LDA but its in another bank you want the long version. Problem is this then changes the number of bytes the instruction needs to use and the linker can't do it. So it will just put ABS. Which may or may not be what you want. Leading you to write code along the lines of
It also has a lot of issues getting the :Bank of labels, to the point you just start hardcoding them.
64tass docs are top of the line, and while the docs on cdef may seem brief it really is that simple. Basically from the manual
which basically this says for each character in the range starting with " " ( ascii code 32) to ascii letter ~ (126), map start from 32. thus " " = 32, "!" = 33, "'"' = 34 ... "}" = 175 "~" = 176
Since the text file ( remember to assemble with the -a option) is in ascii mode that will magically convert the whole printable set. If you want to do new lines etc you would then expand it to be
LDA #someLabel
now if someLabel is in the DP, you want the DP version of LDA but its in another bank you want the long version. Problem is this then changes the number of bytes the instruction needs to use and the linker can't do it. So it will just put ABS. Which may or may not be what you want. Leading you to write code along the lines of
Code: Select all
LDA.B MyVar
STA.W MyOtherVar
LDA.L LongVar
STA.W Register
64tass docs are top of the line, and while the docs on cdef may seem brief it really is that simple. Basically from the manual
Code: Select all
.enc "ascii" ;define an ascii encoding
.cdef " ~", 32 ;identity for printable
Since the text file ( remember to assemble with the -a option) is in ascii mode that will magically convert the whole printable set. If you want to do new lines etc you would then expand it to be
Code: Select all
.enc "ascii" ;define an ascii encoding
.cdef " ~", 32 ;identity for printable
.edef "\n", 13 ;one byte control codes
Re: Are High SNES Homebrew Expectations Justified?
Okay, but like, what about CA65? Does it suck or something?
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.