Page 2 of 4

Author:  byuu [ Wed Nov 27, 2013 11:03 am ]
Post subject:  Re: spca65

That's unfortunate, I'm going to start programming the spc700 soon enough so I think I'll give bass v13 a shot. The only emulator I know of that has spc700 debugging is no$sns, you can switch the view in one of the menus.

I do still need to produce a classic SPC700 mnemonic table for bass; for right now I only have the 6502-like syntax. Of course you can make your own mnemonic table, but I'd like to offer a classical one anyway so you don't have to.

As for the debugger, many versions of bsnes have had that when the debugger was around. I'm currently working on a new debugger that'll be console-based. The hope is to avoid the inevitable GUI crunch that bogs down every debugger I try and design (eg trying to keep track of twelve window states at the same time so that you can't do certain things while another action is taking place.)

Will be a few months, though.

Author:  blargg [ Wed Nov 27, 2013 12:20 pm ]
Post subject:  Re: spca65

I think tepples' idea for a 6502 syntax for the SPC700 is so code can literally be moved between the two without any changes in logic, only interface at the edges.

I've used wla for spc700 and gb-z80 and will be extremely happy to never touch it again. Every turn I was encountering bugs, inconsistent behavior, and counter-intuitive design (often it was hard to tell whether it was intentionally broken or a bug). I will also welcome being able to use a common set of assembler features across those platforms. I don't care that you like wla. Those of you who use it have taken plenty of opportunities to make it clear. Use it. I'm not trying to stop you. But please don't try to tell me that I didn't encounter tons of bugs or that I shouldn't work on a better assembler for anyone who wants it.

My experience with wla is one reason I'm so amazed that ca65's macro package has stood up to reimplementing another instruction set without throwing up every step of the way. I figured tepples would encounter several show-stopping bugs in trying to do so, ones that would require days or more to fix, and require major design changes to the assembler.

EDIT: strolled through my collection of wla bugs. Oh yeah, will be soooo happy to never touch it again.

Author:  doppelganger [ Thu Nov 28, 2013 9:56 am ]
Post subject:  Re: spca65

I'm gonna guess that you're not happy with WLA, blargg. What kinds of bugs does it have?

Author:  Bregalad [ Thu Nov 28, 2013 11:57 am ]
Post subject:  Re: spca65

doppelganger wrote:
I'm gonna guess that you're not happy with WLA, blargg. What kinds of bugs does it have?

I already answered to this question, just read my previous post.

Author:  tepples [ Thu Nov 28, 2013 12:07 pm ]
Post subject:  Re: spca65

Perhaps doppelganger was asking for clarification on your previous post. I am too:

Bregalad wrote:
First you have to define ROM and RAM sections despite the fact that the SPC700 only has RAM (and a small IPL ROM that you can't program anyways).

PCs are like the SPC700 in that all code runs in RAM other than the IPL. Toolchains for PCs use the same model as ca65 with code, rodata, data, and bss sections. I imagine some of this has to do with memory protection, where some segments are writable and others trigger a segfault upon accidental write. In fact, some operating systems even disallow execution of any writable page to prevent an attacker from running arbitrary code through a buffer overflow in the stack or heap.

Bregalad wrote:
it will randomly generate garbage instead of the instructions you told it to generate.

Test cases would be appreciated.

You mentioned byuu's spcas. A Google search for that led me to the page for bass, which appears oriented more toward patching than toward creating original work. Is spcas part of bass now the way bsnes is part of higan?

Author:  doppelganger [ Thu Nov 28, 2013 12:48 pm ]
Post subject:  Re: spca65

I was seeking clarification specifically on the bugs that blargg found, as I've noticed blargg goes a bit more technical than the average nesdevver (sp?).

Author:  Bregalad [ Thu Nov 28, 2013 3:03 pm ]
Post subject:  Re: spca65

Yeah sorry. You should have asked for clarification directly.

ROM section is no huge issue, I agree, but the main problem is with the name itself. "Read-only RAM section" would be more appropriate. In the SPC700 you're always producing a 64kb file so the WLA model works, but for the C64 you'd want the size of the file to be equal to the size of the program, and this is simply impossible with WLA.

If you want to produce an actual .bin size to include in a SNES project (where the SPC code will be updated from the main CPU through the IPL ROM progam) then WLA's model would fail, as you'd also want the .bin size to be equal to the size of the program, not the max size you reserved for it.

As for the bugs triggered in WLA, well I lost the source code of my sound engine, I only have the SPC file left, but I remember that something like adding an instruction could make the program crash because it would suddently add a dozen of dummy bytes in the binary file which have nothing to do with the instruction you wrote. This was a very chaotic behaviour, not something consistent. Something you really don't wan to see when you're developing code.

Author:  blargg [ Fri Nov 29, 2013 12:29 am ]
Post subject:  Re: spca65

Finally ready to post what I've got. First, SPC-700 assembly using ca65:

Then, 65C02 syntax for SPC-700:

And, a buildable source code example using it that plays a chord using the SPC-700:

These use cc65-2.13.3, the last stable release I could find. Both include scripts to run full instruction tests. There are lots of notes with them, so I'm just summarizing the points worth discussing. The SPC-700 macros include an option to use ca65-style addressing, where it defaults to absolute rather than direct-page (< gives direct-page). ! can also be used. The one addressing mode I couldn't get to work as specified is memory.bit, where bit must be in parenthesis if it uses a named constant, as ca65 thinks it's a . directive otherwise:
    mov1 c, $1412.7   ; OK
    bitnum = 6
    mov1 c, $1412.bitnum   ; error
    mov1 c, $1412.(bitnum) ; OK: workaround

I hope I got the syntax right for these addressing modes:
    CALL !abs  ; ! really required even though it only supports abs?
    TCALL $x    ; 0-15
    PCALL $xx   ; 0-$FF, calls $FF00 + $xx
    MOV1 C, mem.bit
    AND1 C, /mem.bit ; the slash for AND with complement of memory bit?

The 65C02 macros coexist with the SPC-700 instruction syntax, for easy use of both styles of code in the same progam, as when including SPC-700 libraries and using 65C02 syntax in your code:
and ($12),y    ; OK
and a, [$12]+y ; OK

I consider automatic use of direct-page addressing an optimization issue, since you can use < where it's critical, thus haven't looked at the patched ca65 yet.

PLA, PLX, and PLY don't set status flags. Perhaps we should have these do a compare or inc/dec (to avoid modifying carry) afterwards?

It's quite novel to be able to code 65xx assembly for the SPC-700. Even things like stack access work:
lda #$12
lda $100,x ; A=$12

Thanks again tepples for paving the way for this! I'm eager to do GB-Z80 in the near future.

EDIT: added spc-chord code example I forgot to link when I posted.

Edit: how about sp65c02? Heh

Author:  Movax12 [ Fri Nov 29, 2013 1:20 am ]
Post subject:  Re: spca65

blargg wrote:
The one addressing mode I couldn't get to work as specified is memory.bit, where bit must be in parenthesis if it uses a named constant, as ca65 thinks it's a . directive otherwise

You may want to explore if .feature leading_dot_in_identifiers could help with that. I'm guessing it could still be difficult to extract the name without the dot however.

Author:  blargg [ Fri Nov 29, 2013 12:06 pm ]
Post subject:  Re: spca65

Yep, I just tried but had to stop when I saw there was no way to remove the . from the identifier formed (e.g. get the identifier bitnum from .bitnum). Identifier->string->identifier, but no way to remove characters from a string.

I guess the leading dot support is so you can define your own macro-directives, perhaps to support others some ported code might have used
.myinclude ""

As for sp65c02, I think I'm going to make PLA etc. set the proper flags (e.g. preserve carry) and then run some code through the 65C02 and this that tests the instructions, to show that the set supported is solid. Further, I think I'll have this test code assembled for 65C02 and SPC-700 in the same source file, with the SPC-700 version then whisked off to the SPC-700 by the same code.

Author:  ARM9 [ Fri Nov 29, 2013 2:03 pm ]
Post subject:  Re: spca65

Very nice blargg, native spc700 syntax works great so far, definitely giving ca65 another shot now.

One question, documentation says zeropage is 0000 - 00EF, why did you do this in the config?
ZP: start = $10, size = $E0; # leave $10 free at each end

Author:  blargg [ Fri Nov 29, 2013 2:07 pm ]
Post subject:  Re: spca65

People like to hardcode <0, <1 <$f and I don't want those overlapping with named zero-page variables. The space from $E0-$EF is for further hardcoded variables that you don't want potentially moving around between builds, e.g. for runtime things. I believe I've used this with multi-file tests, where they can all share the same runtime variables (and communicate through them to the test runner) even if they use different sets of named zero-page variables.

The example code isn't really polished; I'm hoping tepples will be working on something more substantial.

Author:  tepples [ Fri Nov 29, 2013 2:13 pm ]
Post subject:  Re: spca65

A common convention in my coding style (and possibly others') is to leave $0000-$000F open for a subroutine's local variables.

EDIT: Got ninja'd, so i'll add something. If you want $E0-$EF to be free for hardcoded variables, you'll need size $D0.

Author:  blargg [ Fri Nov 29, 2013 2:46 pm ]
Post subject:  Re: spca65

ARM9, thanks for the critique of the linker config file; I've started experimenting again with them and am about to break down and document how all they work, since I'm having success making a nice one for the SPC and would like to share the clarity for others building their own linker files.

Author:  blargg [ Fri Nov 29, 2013 5:21 pm ]
Post subject:  Re: spca65

Doc on ca65 linker files:

I'm working on some good examples of SPC-700 config files.

Page 2 of 4 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group