spca65

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: spca65

Post by Near »

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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: spca65

Post by blargg »

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.
doppelganger
Posts: 183
Joined: Tue Apr 05, 2005 7:30 pm

Re: spca65

Post by doppelganger »

I'm gonna guess that you're not happy with WLA, blargg. What kinds of bugs does it have?
Be whatever the situation demands.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: spca65

Post by Bregalad »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: spca65

Post by tepples »

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).
Personal computers, be they x86-based or 6502-based (like Apple II, Commodore 64, and Atari 800), are like the SPC700 in that all code runs in RAM other than the IPL. Toolchains targeting x86 and x86-64 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?
Last edited by tepples on Sat Nov 16, 2019 8:01 am, edited 1 time in total.
Reason: Not all personal computers use x86
doppelganger
Posts: 183
Joined: Tue Apr 05, 2005 7:30 pm

Re: spca65

Post by doppelganger »

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?).
Be whatever the situation demands.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: spca65

Post by Bregalad »

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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: spca65

Post by blargg »

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

spc-ca65-0.1.0.zip

Then, 65C02 syntax for SPC-700:

spc65-0.1.0.zip

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

spc-chord.zip

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:

Code: Select all

    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:

Code: Select all

    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:

Code: Select all

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:

Code: Select all

lda #$12
tsx
pha
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
Last edited by blargg on Fri Nov 29, 2013 10:14 am, edited 1 time in total.
User avatar
Movax12
Posts: 541
Joined: Sun Jan 02, 2011 11:50 am

Re: spca65

Post by Movax12 »

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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: spca65

Post by blargg »

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

Code: Select all

.myinclude "file.inc"
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.
ARM9
Posts: 57
Joined: Sun Aug 11, 2013 6:07 am

Re: spca65

Post by ARM9 »

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?

Code: Select all

ZP: start = $10, size = $E0; # leave $10 free at each end
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: spca65

Post by blargg »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: spca65

Post by tepples »

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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: spca65

Post by blargg »

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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: spca65

Post by blargg »

Doc on ca65 linker files:

ca65-linker-doc.md

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