It is currently Thu Oct 19, 2017 12:32 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 291 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 20  Next
Author Message
PostPosted: Fri Jan 31, 2014 11:03 am 
Offline

Joined: Thu Oct 05, 2006 6:29 am
Posts: 911
Quote:
Although it doesn't seem WLA gets updated much

Ville has (de facto) abandoned the project long ago. The version I use is 9.5, and whichever version is included with SNESC.
Anyway, it's good that there are other assemblers for people to choose from. The reason I use WLA-DX is mainly because it supports a lot of target CPUs, so I can develop for several different systems with one assembler suite and only learn one set of directives, one macro syntax, etc. But to each his own.


Top
 Profile  
 
PostPosted: Fri Jan 31, 2014 11:04 am 
Offline

Joined: Wed Jul 09, 2008 8:46 pm
Posts: 234
Bregalad wrote:
@KungFuKirby : How did you end up having edianness problems with BRRTools ? Did you recompile it under a big endian system ?

That's exactly what I tried to do. My main computer is an iMac G5, and it uses a PowerPC processor, so it is a big endian system. Right off the bat, I determined endianness was responsible for the wrong sample address being loaded, as I was getting glitched results. I didn't have this problem with the Java version (however, I don't have the latest Java version)... after recompiling because I was running an earlier version of Java.

Part of the reason I'm interested in the SNES is that I can pull off some features the NES can't. Especially Mode 7. And if I wanted to add some modifications (or just make a brand new one), I can use pitch modulation (this one is rarely used, although I know of a few examples, and I've been using it myself recently via a modifed version of SNESMod) and noise generation.


Top
 Profile  
 
PostPosted: Fri Jan 31, 2014 11:44 am 
Offline

Joined: Sun Aug 11, 2013 6:07 am
Posts: 57
I like it how there's always someone bashing wla with hearsay in every thread on this sub. :roll:

Bregalad wrote:
Quote:
And open yourself to a lawsuit just as much as if you had ripped the Mario sprites out of Super Mario World.

As far I know, fonts are not copyrightable, so logically sound fonts would follow the same rule.
However, if you're smart enough you'll rip each sample from a different game from a different company so nobody will even notice. That'll work better than having every letter from a different font (which will likely be very ugly).

I've seen so many games using Roland SC-55 samples for some of their instruments. Did Roland ever lawsuit game companies ? Or did they pay a licence ? Or is buying Roland hardware considered good enough ?

I don't know if you're joking but that's some pretty poor reasoning, a soundfont is not a text font.

The majority of samples used in SNES games were not made by game companies, it's all ripped from various samplers/sample packs. Every hard-/software sampler I've ever encountered is perfectly legal to use for whatever (except ripping and selling the samples as a new sample pack), so long as you paid for the unit/didn't pirate the software. What tepples said about licensing samples sounds plausible too.
I don't think you can use samples ripped straight from Nintendo games even if you do own the unit those samples originated from since Nintendo must've converted the samples to brr and likely processed them too.
Making your own samples for the snes isn't hard anyway, I'll try to make a tutorial at some point.

tepples wrote:
Except at the start of vblank, which bites you if your NMI handler didn't have much to copy this frame and you immediately start to run your next frame's game logic. Then you're back to loops to wait for the automatic reading to finish.

Auto-joy takes about 3 scanlines iirc, if you've got no DMA or calculations to perform during that time I don't think your game logic would be particularly stressed. Doesn't hurt to have a loop in place as a precaution.

nocash wrote:
but the 8bit/16bit mode switching is just insane.

It is a pretty annoying feature, I agree. Something that all of the open assemblers are missing that I saw in the psygnosis 65816 assembler is being able to assert accumulator/index size. This would eliminate many bugs caused by forgetting to change the size before calling a subroutine or using a macro with the wrong acc/idx size. That's about the only big inconvenience in my opinion, and you can sort of solve it with macros in ca65 (or by writing safer but slower code, ew).

nocash wrote:
Anything wrong with no$sns?

Breakpoints for main cpu bug out sometimes, it's impossible to remove one without clearing all breakpoints. It rarely happens and I haven't been able to observe a pattern yet.

My wishlist for no$sns features:
  • Being able to set breakpoints on ROM/VRAM/WRAM/etc reads/writes (basically the entire memorymap + isolated stuff like vram and aram) would also be useful.
  • A way to view the contents of VRAM/CGRAM/OAM in hex.
  • A better organized I/O map window, or perhaps even just a simple list view like the debug window interface with the data next to each register, this way you could also map in additional registers easily like GSU and SA-1 mmio.
  • Being able to set breakpoints on coprocessor execution would be nice.
  • Support for .sym files. WLA can generate them but no$sns always complains about corruption (I tried all sorts of modifications but no dice). It'd be really convenient to have symbolic debugging.
Of course no$sns is already great as it is, I use it all the time for debugging and testing. I really appreciate the effort you've put into it so far

Also while I'm at it did anyone ever figure out how to get the WLA macro ARGS to work? Macros start looking unnecessarily cryptic once you get to \5 or so. Been thinking about giving it another shot, even if it's abandoned at this point.


Top
 Profile  
 
PostPosted: Fri Jan 31, 2014 11:52 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
Wow, I never thought someone still used those old machines ! Unfortunately I don't have a big endian machine to test on it, but I'll have to find a way to fix it somehow, so you can use the new BRRTools on your machine. I imagine I'd need a wrapper routine for every fread/fwrite call so that the byte order is reversed on big endian machines.

As for Java, I don't think the version of Java has any impact on the functionality of the program. The Java version is no longer supported, because, well, Java was starting to really annoy me. Compiling and running program is so complicated and it's so inefficient at runtime, it's a huge price to pay for the cross-platform compatibility.

Quote:
I like it how there's always someone bashing wla in every thread on this sub. :roll:

I'm not bashing it, I just said that i had problems with the SPC700 version. I had no problems with the 6502 version (or the 65816 version, but I used it very barely, and only used 6502 instructions, as I don't know 65816 assembly).

Quote:
I can use pitch modulation (this one is rarely used)

As far I know, Squaresoft was the only company to ever give Pitch Modulation some love, and that on both the SNES and PS1 machines.

Quote:
I don't know if you're joking but that's some pretty poor reasoning, a soundfont is not a text font.

I'm not that dumb you know ? But there's definitely some kind of analogy behind this (despite the word "sound font"). I have several sound fonts lying on my PC (most of them were available for free, some came with an old sound card) and 2 synthesizers, so I'd have a very large source of samples not ripped from games anways.


Top
 Profile  
 
PostPosted: Fri Jan 31, 2014 11:53 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6280
Location: Seattle
Bregalad wrote:
As far I know, fonts are not copyrightable, so logically sound fonts would follow the same rule.
Fonts are not copyrightable in the US. In the UK, and Ireland they are. In much of the EU they're covered by design patents.

In any case, it's not clear that soundfonts necessarily follow the same rule. In the manual for my old synthesizer, I think I remember finding an explicit licensing clause allowing the use of the samples for commercial products without separate royalties, and AIUI something equivalent is very common in the EULA of most commercial softsynths (You're buying a royalty-free license, not just the software). Conversely, this is part of why CreativeCommons-Sampling license was formed, because this surface wasn't explicitly clear in legal code nor in case law.


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 12:50 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
Quote:
Has, or had? I seem to remember higan gaining and losing the debugger as it goes through different front ends. And is it present for all platforms supported by higan, or do I have to run Wine for debugging the way I have to with FCEUX?


When replacing the entire toolkit, it mostly eliminates all the work done on any GUI. Went through a few revisions: raw Win32 [bsnes v013] -> Windows/GTK+ wrapper (hiro) [bsnes v040] -> Qt [laevateinn] -> Windows/GTK+/Qt/Cocoa wrapper (phoenix).

Current debugger for phoenix is called loki: http://byuu.org/images/loki/loki-20140130.png

As nice as GUIs are, they're just too much of a hassle. So this one is terminal-based. Haven't posted a downloadable version yet, still adding features.

Quote:
Anything wrong with no$sns?


It doesn't run on my operating system (Debian Wheezy), and it's closed source so I can't extend it as needed.


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 6:49 am 
Offline

Joined: Wed Jul 09, 2008 8:46 pm
Posts: 234
I've had some experience with text-based debuggers for other consoles/computers, so that's acceptable as long as the command list is available.

Pitch modulation is rarely used in music, if at all (There is one song in Jurassic Park 2 where this pops up). The most unusual implementation of pitch modulation by far for music is Packy and Marlon.

I myself use soundfonts (at least in part) for the music, although I edit them manually so that they can be transformed into SNES samples. It's less painful for me to edit those than fooling around with samples already made for the SNES (especially when ripped from .spc files... those loop points are already perfected, and sometimes they have no room for further adjustments) However, I have caught on to what sample packs are used by what companies, and some of them are really unique (Rap Jam: Volume One comes to mind... or even Universal Soldier!). So be careful what you pick... I can recognize a bunch of them, especially the ones that sound much more unique. It helps that I've invented music modifiers for at least a hundred SNES games. :D


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 7:01 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19099
Location: NE Indiana, USA (NTSC)
The text-based debugger reminded me of the iconic debugger from the Apple II Monitor.


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 10:30 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
I will try and allow for nice things like an IPC layer for talking to the debugger (so you could have your own GUI-based tools on top of it), a user-made command alias so you can short-hand anything you want (the defaults are going to be verbose instead of single-letter commands), command history, execute-last-command quickly, a codebase that makes it easy to add your own monitoring windows to it, etc.

Appreciative that some of you won't mind the text-based interface, but I do fully expect it to be much less popular than the traditional GUI style, and that's fine. Like with higan, I make my stuff for me now, and I understand that it's niche. It is, however, sadly the only choice for a Linux SNES debugger. ZSNES' is DOS only (and discontinued), Geiger and no$sns are both Windows only. (DOSbox and Wine are hard enough, let alone on a 64-bit system with no ia32libs.)

I've always personally felt that the absolute most powerful debugger is the one where you are writing code right into the emulator itself. No debugger, GUI or text-based, is going to allow you the power to eg set a breakpoint when pixel 216,37 is set to BG3 when the screen is in mode 0. Or a breakpoint that breaks after the 37th hit while A=0x0153 after reset. But that's a five-second breakpoint to setup when you're working with the C++ code directly.


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 10:54 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19099
Location: NE Indiana, USA (NTSC)
byuu wrote:
I will try and allow for nice things like an IPC layer for talking to the debugger (so you could have your own GUI-based tools on top of it)

If you use gdb protocol, these GUI front ends will already exist.

Quote:
a codebase that makes it easy to add your own monitoring windows to it

With a scripting language like FCEUX has?

Quote:
No debugger, GUI or text-based, is going to allow you the power to eg set a breakpoint when pixel 216,37 is set to BG3 when the screen is in mode 0.

Let me express it in a pseudo code similar to that of WarioWare DIY, which uses a "when" clause as an action trigger followed by several "while" clauses to narrow it:
When hcount becomes 216
While vcount = 37
While screen mode = 0
While frontmost layer at raster is BG3
Pause machine

Quote:
Or a breakpoint that breaks after the 37th hit while A=0x0153 after reset.

When (other condition)
While A = $0153
Add 1 to event_count1
When event_count1 becomes 37
Pause machine

See also what I wrote about breakpoints in NESICIDE.


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 2:44 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
ARM9 wrote:
nocash wrote:
but the 8bit/16bit mode switching is just insane.

It is a pretty annoying feature, I agree. Something that all of the open assemblers are missing that I saw in the psygnosis 65816 assembler is being able to assert accumulator/index size. This would eliminate many bugs caused by forgetting to change the size before calling a subroutine or using a macro with the wrong acc/idx size. That's about the only big inconvenience in my opinion, and you can sort of solve it with macros in ca65 (or by writing safer but slower code, ew).

This is being discussed here, and I maintain my stance that this is just crying/whining. Referenced thread mentions assemblers that follow rep/sep bit changes (there are multiples and for different platforms -- I have used all of the ones I mentioned), ditto with having pseudo-ops to tell the assembler what's going on. Use of a macro to do both (ex. .force16a would both tell the assembler "we're using 16-bit accum" and issue rep #$20 inline) is fine too, but isn't always desirable (it depends all on what you're doing in your code).

For all the years I did 65816, I ran into register size vs. assembler register size problems maybe once or twice, and it was easy to diagnose once generating a listing (one of the many reasons why that feature exists). Simple rep/sep following takes care of 90% usage cases; other scenarios are exactly why assemblers have pseudo-ops to tell the assembler how it should be treating register sizes within that piece of code, making it the programmers' responsibility to know what is going on (and I fully agree with this belief). Nothing pisses me off more than computers (e.g. assemblers/compilers) thinking they can make decisions on my behalf. My mistakes = my fault, my program = my responsibility.

I'll end with a verbatim quote from the ORCA/M manual, with relevant part bolded:

Quote:
The 65816 CPU is capable of doing sixteen-bit operations involving the accumulator and memory; it is also capable of performing eight-bit operations the same way the 6502 and 65C02 do. The size of the accumulator and the amount of memory affected by instructions like LDA, STA and INC are controlled by a bit in the processor status register. At assembly time, the assembler has no idea how that bit will be set at run time – it is the responsibility of the programmer to tell the assembler using this directive.


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 2:59 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Use 16-bit X/Y and 8-bit A as the standard size for routines. 16-bit X and Y let you loop over more than 256 bytes of memory easily, or use them as general pointers, and I don't believe that 16-bit indicies are any slower than 8-bit ones (obviously initializing them is). 8-bit A lets you manipulate registers and bytes easily, and you can do 16-bit operations as two 8-bit operations. They are also useful for 16-bit increment/decrement. This covers most needs. You pretty much have to keep an 8-bit register around to deal with hardware registers. Use 16-bit A/8-bit X and Y where it makes a significant speed difference, and be wary of any routine calls while in this mode.


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 3:49 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
I've never done "real" 65816 code, but wouldn't letting A, X and Y 16-bit in most situations be the more sane choice ? It's supposed to be a 16-bit processor after all. You can temporary turn A to 8-bit when dealing with memory mapped I/O, and then revert to 16-bit.


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 4:01 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
You'd have to switch to 8-bit A every time you wanted to deal with any 8-bit piece of data. That means basically all I/O registers, most of your variables (since 8-bit is enough for almost everything), most tables in memory. It's a pretty obvious choice if you're coding for the SNES.


Top
 Profile  
 
PostPosted: Sat Feb 01, 2014 6:31 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Some of the memory-mapped registers are 8-bit, others are 16-bit. The reality of programming on the SNES/SFC specifically is that you do end up using sep/rep a lot, which really isn't that big of a deal since they only take 3 cycles. When it comes to memory-mapped registers, depending on what was desired by the programmer, folks tended to do things in "sections", i.e. rep #$30 then do necessary 16-bit stuff, then sep #$20 (8-bit a, 16-bit x/y) and do necessary 8-bit stuff there. I'm going to bow out of this subject from here on out, as it's starting to get into sperglordland. :-)

It just pisses me off when I see people crying/whining over this shit. The 65816 was designed to be backwards-compatible with the 65c02, which means 256 opcodes, and having dynamically-sized registers (thus applies to some operands, which is what the is complaint is about) means you only need 2 opcodes to control that (unless you wanted to rely entirely on plp, ha) while giving you the benefits of 16-bit registers. The crying is often done by people who did 68K or were spoiled by processors which had 16 bits worth of opcode space (i.e. 2-byte opcodes) -- sure, that might make things "easier for you" (and anyone disassembling), but that would mandate a new CPU that wasn't backwards-compatible with the 65c02. Reality check!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 291 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 20  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group