It is currently Tue Feb 19, 2019 3:36 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 4:37 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3866
Location: A world gone mad
rainwarrior wrote:
Nobody in this thread has anything to say about limitations of the ca65 assembler, only the C compiler. Perhaps you could be a little less vague about what it is you think is wrong with it?

Subject has been discussed before on this forum. I will try to find the posts/threads when I can edit: viewtopic.php?p=140305#p140305 (see footnote) and viewtopic.php?p=140698#p140698 (I'll note that this is a great example of why 9-page megathreads covering several topics suck).

The short of it is that ca65/ld65 has no comprehension of direct page, only zero page, which can cause complications if using tcd (a fairly commonly used opcode on 65816). Maybe this doesn't matter with cc65, since it itself is handling declaration and organisation of variables.

And ca65 was mentioned in calima's post, so that's why I mentioned ca65. Seems cc65 also doesn't implement 65816 things like long addressing or 16-bit code (going off of what calima says), which is sad. It doesn't mean "cc65 sucks", it means "the compiler is going to generate 6502/65c02 code, which happens to work on 65816, but really isn't optimal". Hopefully this acts as justification for my statement "... predominantly uses "8-bit everything" ...".

rainwarrior wrote:
And if there is some other assembler you think is a better alternative, why did you not even say which one that is?? You just came here to say "ca65 sucks, bye"??

Because that is not what the OP came here for. The toolsuite choice is being imposed on him/her (quote: "I'm asked to do it in cc65") so I stick with what's being discussed; no point in saying "try {WLA DX, or x816 if you're willing to run DOSbox/DOS}". If C is an absolute requirement then I really don't know what to recommend because there really aren't any "feasible" C compilers for present-day systems that can cross-compile to 65816. Toshi Morita's (edit: Toshi did a port of LCC that output 65816 code, which I think isn't the same thing as this, but I'm not sure.; tcc816 is done by Fabrice Bellard) tcc816 is the only one I know of and that's gotten some bad reviews apparently, and I can't talk about WDC's compiler because I've literally never used it.


Last edited by koitsu on Mon Jan 28, 2019 5:34 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 5:22 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2210
Location: Fukuoka, Japan
@dougeff

I may make a C library for my needs someday once I finish my current nes project but at my current pace of 1 project every 10 years... It make take some time before it materialize :lol:


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 5:39 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7212
Location: Canada
Well, to paraphrase how I read the OP's question:
Quote:
We have a cc65 NES game that we want to port to SNES. Is it reasonable to use cc65 for it?

koitsu, your reply was that suggesting this deserves "shame", and that cc65 is not appropriate for SNES development. Then you suggested they could "get some actual work done" if they did... something else, but you didn't say what. So... you give this air of a very strong opinion, but then had no information to offer, and it's a real drag to read.

I'm not trying to say your opinion is invalid. I want to know why you feel that way about it, but also I want to make sure we're getting a clear explanation too.


So... unclear whether OP's game is ca65 or cc65, people use that interchangeably. When you decided to specifically break it out into "cc65/ca65", I had to read your statements as applying to both. These are two different things, that I don't think can be painted with the same brush. cc65's obvious limitations here are not at all equivalent to ca65's, so for the sake of the question the OP is asking, I was hoping you could explain anything about where your strong opinion is coming from, instead of just admonishing people for even suggesting it.

Like if you think it would be more practical to port a cc65 NES game to some other C compiler on the NES, why don't you say so? Why don't you suggest a compiler? What's the alternative? I don't think ever seen you actually say that you prefer to use a particular assembler, just that so and so does it wrong. It'd actually be nice to know what you think is the good stuff!

BTW as an alternative, taking a C program and "hand compiling" / porting to assembly can be practical, I think. That's basically what I did for Lizard. That's another option that doesn't depend on any existing C compiler to be sufficient, but does require a lot of methodical assembly work.


Specifically about the direct page on ca65... yeah I agree that's a feature it would be nice to have, but I don't think of it as a terrible flaw for this assembler. So far in my use of it for SNES (admittedly I haven't made anything yet I am willing to share publicly, hope to share stuff later this year), I haven't really found it to be much of a problem. It's mainly just a little bit of extra organization to keep track of via comments etc. I initially tried to automate it with macros before deciding it wasn't enough of a problem to justify a complicated solution like that... but assembler support with another control directive for DP would be more ideal.

...and ca65 could always grow this feature. calima added that mentioned trampolines feature, and it's definitely useful. That's another reason I want your opinion, because it's nice to know what things people think would improve a tool like this that is open to new things. ...and knowing your recommendation for an assembler that has a good implementation of DP support would be great reference to have in designing such a feature.


And, not a correction of you koitsu, but just to clarify, ca65 does support long addresses, and I believe even the cc65 output can support them in limited ways, but that's through taking advantage of some of its address-size-agnostic behaviour, and I'm sure has some hairy details / caveats that need to be carefully navigated.


Edit: I see you added some more information about C compilers in an edit to your post. Thank you for that part.


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 6:50 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3866
Location: A world gone mad
This is getting off-topic from the original thread, so if tepples et al want to edit my earlier posts and split this off into a thread called "koitsu being an old codger", that's fine.

My strong opinion comes from familiarity with the fact that the 65xxx architecture is badly-suited for C. This was a commonly-accepted reality in the Apple IIGS community, which had ORCA/C (commercial at the time, and generally expensive). I was taught repeatedly by people significantly smarter than me that other architectures tend to work better with C (ex. 68K, x86, PIC), mainly due to a wider variety of opcode and addressing mode capabilities and compounded by having substantially more common-use registers. It's "doable" on the 65816, but a lot of CPU time is wasted due aforementioned architecture limits.

Slight divergent story but semi-relevant: when GNOME came out for the IIGS (that was a UNIX-like environment for the IIGS, written in both C and assembly), one of the very first things people wanted was a C compiler for it (e.g. porting gcc to the IIGS/65816); nope, ORCA/C was it. If you've never heard of GNOME, here's the old FAQ; Sections 10 and 11 are relevant to this discussion. I remind readers that this was an environment/sub-OS written in the early 90s (91-96), and likewise ORCA/C was from that time as well, so today's C programmers might not like its limited capabilities.

I am not here to say "SNES games in C cannot be done" -- there is evidence in the past of some actual commercial SNES RPGs being written in a very C or C-like language, which was developed by and for the company who made said games -- but rather to say: there really isn't a good C compiler for the 65816 that's available for present-day platforms (i.e. writing C code on x86/x64 that cross-compiles into 65816).

cc65, in my book, falls into that category. It was designed with 6502/65c02 in mind. Could it be enhanced to do a better job with 65816, such as supporting 16-bit operations, comprehending direct page, and making use of 24-bit addressing? Certainly. But my wishful thinking doesn't help improve the situation at all; I don't write compilers, a highly complex topic way above my mental pay grade. I just feel this reality (of the state of tools/compilers for said CPU architecture) is often ignored, trumped by idealistic dreams. Maybe I'm weird: when I look at developing software/programs/whatever for an older architecture/platform, the first thing I do see is what tools/PLs/etc. were used at the time of its inception and try to use those, because odds are they were chosen for a good reason. SNES games were predominantly written in pure assembly; IIGS things were predominantly written in pure assembly or assembly combo'd with Pascal or BASIC, else (yikes) Hypercard; the few things done in C on the IIGS were often a surprise.

And yes, I'm obviously aware of several NES games being done in C with cc65. I still find that amazing/incredible. But to my knowledge, every single game that's used cc65 has had a substantial amount of assembly involved in the process (read: ca65 is involved) given the nuances and realities of the NES architecture. SNES is no different in this regard.

I'm fine with someone having a different opinion than me, I just come off as candid and brash when it comes to this subject because I come from a IIGS background. I'm often asked to justify my opinion, and my justification lies in the fact that there really aren't many C-based games/titles/anything on the 65816 for reasons covered earlier. If someone wants to be the first to do it, great, but I happen to think it's strange how people want to use a PL on older architectures/platforms that really don't cater well to said PL, rather than just do assembly. It's always C, too -- I never hear of people wanting Fortran or COBOL or Lisp or Forth or ML or Modula-3, it's always C.

Anyway, circling back to C compilers that output 65816: the only alternatives I know of are at this point:

  • ORCA/C -- only works on the Apple IIGS, and might not be suitable for other platforms (read: SNES). In other words: I can't say for certain that this compiler could output anything that might run/work on the SNES, given the *tremendous* platform differences between the IIGS and the SNES; I don't know how critical the crt is to it, for example. This compiler used to be commercial. Binaries are for the Apple IIGS, not PC/etc., and compiling the compiler requires ORCA/Pascal (Pascal for IIGS) and ORCA/M (assembler for IIGS). In contrast, I do know factually that there were some SNES programmers back in the 90s who used ORCA/M to do some code for the SNES. But that's not C. ;-)
  • lcc-816 -- apparently not so great from what earlier posts. I trust calima's review.
  • Toshi Morita's port of lcc 1.9 -- this takes C code and generates assembly intended for the IIGS ORCA/M assembler. I haven't used it; looks to be intended for *IX (ex. Linux, BSD) operating systems, or maybe even GNOME. Certainly could be modified to output code for another assembler (ex. ca65), but it requires the person understand how the DAGs work. Like I said: not for the faint of heart. Worth reading is this thread between a user and Toshi himself.
  • Western Design Centre's C compiler -- I haven't used it

I'd urge anyone who has used a C compiler on the SNES to talk about their experience openly and honestly. If you used C for the "general chunk" of your main game, but resorted to assembly for substantially more important bits, please don't omit that, as that's very important.


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 7:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7212
Location: Canada
That doesn't look off topic at all, to me. Thanks for the elucidation of what you meant.


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 7:52 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2210
Location: Fukuoka, Japan
@koitu

You're not an "old codger" but maybe "yoshi" is doing a comeback? :lol:

On a serious note, when doing C for such platform, the CRT is never used: it's not worth it. This means, you have to create your own library for your current needs and only use the C as a "language" to convey what you want to do on the machine. Many time you have to write "no so clean" C code to avoid bottleneck (i.e set zp variables before calling a function to reduce the cost of passing parameters to it).

Right now I have 0 experience on the SNES compared to the NES but I'm sure the first thing I would explore is what do I need to make in ASM to access what I can't in C and just call it from C when necessary. If even that is not possible then in that case I would be less inclined to use ca65/cc65 combo for snes then. As long you can program in ASM what can'y be done in C and the C part helps reduce the complexity for part like intro, menu etc, I would be more than happy to use it. As long ca65 doesn't limit the access to the 65816 then I would be fine with it.


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 7:57 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3866
Location: A world gone mad
BTW, on the subject of PLs on 65xxx, I was just pointed to this absolutely wonderful web page by a friend of mine: https://dwheeler.com/6502/

It goes over PL offerings that are both focused and semi-focused on the 6502 series, as well as some unique languages you might not have heard of. For me, the "sort-of assembler" section, Atalan, and PLASMA all caught my interests.

It's actually a great read in general, and a wonderful compilation of 6502-stuff that could probably be extended or enhanced to benefit from 65816, especially those which were designed with the 6502 in mind.


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 7:59 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7212
Location: Canada
koitsu wrote:
every single game that's used cc65 has had a substantial amount of assembly involved in the process (read: ca65 is involved) given the nuances and realities of the NES architecture. SNES is no different in this regard.

I think there's almost no games that were written only in C for most game platforms until relatively recently. On PC platforms is was viable a bit earlier than others, but on consoles I think significant assembly was still usually expected even as far as PS2 and often on PS3, though this has been a gradually decreasing need over time. Assembly was just part of the deal for high performance code for a very long time.

The only remedy for this is good libraries that already have the assembly you need written for you, which is kind of what cc65's runtime library is, but you need NES/SNES specific libraries as well.

Even with good libraries, there will be performance problems that aren't generic. You will probably need to those in assembly.


Though WRT the OP's question... if the game already works in cc65 for NES, I don't see why it shouldn't still be viable on SNES? The bar of "is cc65 good enough for this game" has already been met. Even the non-hardware-specific part of the assembly could be reused too.


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 8:08 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21101
Location: NE Indiana, USA (NTSC)
GNO/ME... that name brings back memories. I was initially confused when I read about the GUI included with Red Hat Linux 6 or so, as I had heard of the operating system for the IIGS but not the similarly named X11 desktop environment.

But anyway: In case a compiler that runs on a IIGS turns out to be a suitable cross-compiler to target 65816-based platforms other than the IIGS, what's the best way to integrate a IIGS emulator into a build process? Is it practical to put GNO/ME in your GNOME so you can UNIX while you UNIX?


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Mon Jan 28, 2019 9:42 pm 
Offline

Joined: Tue Nov 20, 2018 9:23 pm
Posts: 3
My best advice is to ditch 65cc as koitsu mentioned the 65816 is awkward for c compilers. If you have to use C, use the one that WDC made.
https://wdc65xx.com/WDCTools
I have some example code on my github for the snes that should compile out of the box.
https://github.com/Phillip-May/snes-homebrew
That being said it still dosen't generate very efficient code but it does work and even supports software floating point. It's still ways ahead of assembly for easily making homebrew.
As far as working in it goes, it's been fine. I think arm9 tried writting some libraries for it a while ago adapting his register header file and fixing a few typos was quite easy. I created a few example hardware functions to interact with VRAM and OAM. They worked in every case I tried them. I haven't set the compiler up to use hardware mul and div but I'm sure it's possible, I'm developing in C and using software floating point, my performance is going to be shit no matter what I do. Maybe hand coded assembly functions that use hardware mul and divide could be used to help performance. The only real problem is that C dosen't provide any way to access registers so you need to cast an int to a pointer and then de reference it. All pointers are 32 bit for simplicty in my examples but you can distinguish between 16 bit and 32 bit pointers with different compiler options if you want more optimal code, again I don't need performance. I included files by using a simple bin to c utilities to include graphics as const data. The compiler runs flawlessly on windows 7 and 10 which is surprise given how old it is. My hardware library is far from complete and the optimizer is pretty bad so the code it generates is slow but never fails to work. You use compiler build options or pragmas to manually control where code and data gets placed and the compiler knows how to reference it correctly. Because of the snes's weird memory map, I broke traditional rules of heap and stack sharing ram. static/global variables, heap and stack all use completely separates banks and blocks of RAM which breaks a bit from the C standards but is kind of fun. I think some of build scripts still use linux commands but it's not hard to patch them to run on windows without linux tools. One of my minor gripes is that hard coded uint8_t functions give warnings even if the value passed is smaller than 8 bits and I have another warning about pointer to int typecasting that I needed to do in order for the DMA functions to work but besides those two cases the warnings and errors are quite helpful and the manual provided a more detailed explanation of the error if you don't understand.

If you to try and make something useful for the snes it might be worth the effort of porting RTOS to further ease people into easy snes homebrew. At the very least it's a good tool combined with a good debugger for showing how C works and a low level and exactly how your code gets assembled.

Another snes C compiler I did try is alekmaul's pvsneslib but there was so many quirks to using combined with not really being able to control where data and memory get placed in addition to other stupidities like never having more than 127 bytes on the stack in any given scope and lack of good errors/warnings meant I dropped it for wdc816cc.


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Tue Jan 29, 2019 3:34 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 894
I have some bad experiences with libsfx and snesmod; pvsneslib uses tcc-816, the terrible compiler. Koitsu, I haven't tried the lcc you linked, which is a different compiler from tcc.

dougeff wrote:
I keep expecting shiru to come swooping in on a rope and drop all the tools I need, and disappear again like Keyser Söze.
Shiru prefers tcc-816 and WLA-DX for his SNES work. Those are what his SNES GSS sound system is for, too. I ported GSS to ca65 for these projects.

koitsu wrote:
But to my knowledge, every single game that's used cc65 has had a substantial amount of assembly involved in the process (read: ca65 is involved) given the nuances and realities of the NES architecture.
This is not true, unless you mean neslib, which is reused and hardly changes. Such a library doesn't count in my opinion as you don't have to write it, game-specific asm would; and there is far less of that than you think.
Quote:
If you used C for the "general chunk" of your main game, but resorted to assembly for substantially more important bits, please don't omit that, as that's very important.
A say 10-line collision check against a level is something that would usually be asm, for speed. It's important for high performance. But being a 10-line function, it's a very tiny part of a game's codebase, and even beginner asm coders can write that. Beginner asm coders can't write an entire game in asm, and even experienced asm coders will take an eternity to do so. I've estimated before that writing asm takes 10x longer vs writing C.

@hibber22
Hm, kinda disappointing to hear that WDC's compiler still produces slow code. Plus has some bad warnings. Can you give some example of the slow code it generated?


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Tue Jan 29, 2019 6:52 pm 
Offline

Joined: Tue Nov 20, 2018 9:23 pm
Posts: 3
@calima
Alright so after figuring out to correctly enable the optimizer, the code looks pretty good. Keep in mind the use of 24 bit pointers to access 8 bit registers is my fault at compile time and has nothing to with my code or the compiler.
The code without the optimizer is awful but the optimizer fixes it pretty well. The only kind of optimization it doesn't do that I would like is when writing to hardware registers next to each other gcc will merge two 8 bit writes into one 16 bit write to save one cycle. My other problem with it is that it treats 24 bit pointers as 32 bit wasting 1 byte on every single pointer, probably a worthwhile trade off in given it supports the full 65816 memory map. You could also minimize the damage of this by only using 24 bit pointers when needed and fine tuning build options if needed.
For example look at the following code

REG_BGMODE = 0x08;
REG_BG1SC = 0xFC;
REG_BG12NBA = 0x00;
REG_TM = 0x01;

REG_BG1HOFS = 0x00;
REG_BG1HOFS = 0x00;
REG_BG1VOFS = 0x00;
REG_BG1VOFS = 0x00;

Just setting hardware registers where their macros are defined as:
typedef volatile uint8_t vu8;
#define REG_BGMODE (*(vu8*)0x2105)
All of these are 8 bit registers.
028252 sep #$20 A:0000 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvmxdIZc V: 98 H:255 F:58
028254 lda #$08 A:0000 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIZc V: 98 H:260 F:58
028256 sta $002105 [002105] A:0008 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIzc V: 98 H:264 F:58
02825a lda #$fc A:0008 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIzc V: 98 H:274 F:58
02825c sta $002107 [002107] A:00fc X:0000 Y:0000 S:1fc8 D:1fca DB:7e NvMxdIzc V: 98 H:278 F:58
028260 lda #$00 A:00fc X:0000 Y:0000 S:1fc8 D:1fca DB:7e NvMxdIzc V: 98 H:287 F:58
028262 sta $00210b [00210b] A:0000 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIZc V: 98 H:291 F:58
028266 inc A:0000 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIZc V: 98 H:301 F:58
028267 sta $00212c [00212c] A:0001 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIzc V: 98 H:304 F:58
02826b dec A:0001 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIzc V: 98 H:314 F:58
02826c sta $00210d [00210d] A:0000 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIZc V: 98 H:317 F:58
028270 sta $00210d [00210d] A:0000 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIZc V: 98 H:326 F:58
028274 sta $00210e [00210e] A:0000 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIZc V: 98 H:335 F:58
028278 sta $00210e [00210e] A:0000 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIZc V: 99 H: 5 F:58
02827c rep #$20 A:0000 X:0000 Y:0000 S:1fc8 D:1fca DB:7e nvMxdIZc V: 99 H: 14 F:58

You can even see the optimizer decided to use inc instead of load accumulator to get 0x01 for
REG_TM = 0x01;
because it's slightly faster than accessing RAM.

Another more complex example
int initOAMCopy(unsigned char *pSource){
uint16_t i;
for (i = 0; i < 128; i++){
*pSource = 0x01;
pSource++;
*pSource = 0x00;
pSource++;
*pSource = 0x00;
pSource++;
*pSource = 0x00;
pSource++;
}

for(i = 0; i < 32; i++){
*pSource = 0x55;
pSource++;
}
return 0;
}

The assembly file generated for this function isn't super great
~~initOAMCopy:
longa on
longi on
tsc
sec
sbc #L24
tcs
phd
tcd
pSource_0 set 4
i_1 set 0
stz <L25+i_1
bra L10030
L10029:
inc <L25+i_1
L10030:
lda <L25+i_1
cmp #<$80
bcs L10031
sep #$20
longa off
lda #$1
sta [<L24+pSource_0]
rep #$20
longa on
inc <L24+pSource_0
bne L27
inc <L24+pSource_0+2
L27:
sep #$20
longa off
lda #$0
sta [<L24+pSource_0]
rep #$20
longa on
inc <L24+pSource_0
bne L28
inc <L24+pSource_0+2
L28:
sep #$20
longa off
lda #$0
sta [<L24+pSource_0]
rep #$20
longa on
inc <L24+pSource_0
bne L29
inc <L24+pSource_0+2
L29:
sep #$20
longa off
lda #$0
sta [<L24+pSource_0]
rep #$20
longa on
inc <L24+pSource_0
bne L10029
inc <L24+pSource_0+2
bra L10029
L10031:
stz <L25+i_1
bra L10033
L10032:
inc <L25+i_1
L10033:
lda <L25+i_1
cmp #<$20
bcs L10034
sep #$20
longa off
lda #$55
sta [<L24+pSource_0]
rep #$20
longa on
inc <L24+pSource_0
bne L10032
inc <L24+pSource_0+2
bra L10032
L10034:
lda #$0
tay
lda <L24+2
sta <L24+2+4
lda <L24+1
sta <L24+1+4
pld
tsc
clc
adc #L24+4
tcs
tya
rtl
L24 equ 2
L25 equ 1
ends
efunc
Here is that same functions disassembly from visual studio
011A1500 push ebp
011A1501 mov ebp,esp
011A1503 sub esp,0CCh
011A1509 push ebx
011A150A push esi
011A150B push edi
011A150C lea edi,[ebp-0CCh]
011A1512 mov ecx,33h
011A1517 mov eax,0CCCCCCCCh
011A151C rep stos dword ptr es:[edi]
37: uint16_t i;
38: for (i = 0; i < 128; i++){
011A151E xor eax,eax
011A1520 mov word ptr [i],ax
011A1524 jmp initOAMCopy+32h (11A1532h)
011A1526 mov ax,word ptr [i]
011A152A add ax,1
011A152E mov word ptr [i],ax
011A1532 movzx eax,word ptr [i]
011A1536 cmp eax,80h
011A153B jge initOAMCopy+7Bh (11A157Bh)
39: *pSource = 0x01;
011A153D mov eax,dword ptr [pSource]
011A1540 mov byte ptr [eax],1
40: pSource++;
011A1543 mov eax,dword ptr [pSource]
011A1546 add eax,1
011A1549 mov dword ptr [pSource],eax
41: *pSource = 0x00;
011A154C mov eax,dword ptr [pSource]
011A154F mov byte ptr [eax],0
42: pSource++;
011A1552 mov eax,dword ptr [pSource]
011A1555 add eax,1
011A1558 mov dword ptr [pSource],eax
43: *pSource = 0x00;
011A155B mov eax,dword ptr [pSource]
011A155E mov byte ptr [eax],0
44: pSource++;
011A1561 mov eax,dword ptr [pSource]
011A1564 add eax,1
011A1567 mov dword ptr [pSource],eax
45: *pSource = 0x00;
011A156A mov eax,dword ptr [pSource]
011A156D mov byte ptr [eax],0
46: pSource++;
011A1570 mov eax,dword ptr [pSource]
011A1573 add eax,1
011A1576 mov dword ptr [pSource],eax
47: }
011A1579 jmp initOAMCopy+26h (11A1526h)
48:
49: for(i = 0; i < 32; i++){
011A157B xor eax,eax
011A157D mov word ptr [i],ax
011A1581 jmp initOAMCopy+8Fh (11A158Fh)
011A1583 mov ax,word ptr [i]
011A1587 add ax,1
011A158B mov word ptr [i],ax
011A158F movzx eax,word ptr [i]
011A1593 cmp eax,20h
011A1596 jge initOAMCopy+0A9h (11A15A9h)
50: *pSource = 0x55;
011A1598 mov eax,dword ptr [pSource]
011A159B mov byte ptr [eax],55h
51: pSource++;
011A159E mov eax,dword ptr [pSource]
011A15A1 add eax,1
011A15A4 mov dword ptr [pSource],eax
52: }
011A15A7 jmp initOAMCopy+83h (11A1583h)
53: return 0;
011A15A9 xor eax,eax
54: }
011A15AB pop edi
011A15AC pop esi
011A15AD pop ebx
011A15AE mov esp,ebp
011A15B0 pop ebp
011A15B1 ret
So the moral of the story is don't forget to use the optimizer. C still has overhead with calling functions and passing parameters that optimized assembly doesn't have but the compiler and optimizer looks pretty good and even competing with gcc. This also leads me to the question of why am I one the only people trying to use this compiler for snes development and why did arm9, the only other person who seems to have tried, give up on using it? At the very least I think this should break the conceit that most games on snes where coded mostly/purely in assembly since this was available to snes developers and at least some of them must have used it. Using it does require some assembly but I hardly think it's enough to warrant the term "mostly".


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Wed Jan 30, 2019 3:18 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 894
I'm not looking at it for it being proprietary and requiring Windows, and IIRC the license requires $$ for commercial use too.


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Thu Feb 07, 2019 3:53 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 1064
Location: Hokkaido, Japan
rainwarrior wrote:
Specifically about the direct page on ca65... yeah I agree that's a feature it would be nice to have, but I don't think of it as a terrible flaw for this assembler. So far in my use of it for SNES (admittedly I haven't made anything yet I am willing to share publicly, hope to share stuff later this year), I haven't really found it to be much of a problem. It's mainly just a little bit of extra organization to keep track of via comments etc. I initially tried to automate it with macros before deciding it wasn't enough of a problem to justify a complicated solution like that... but assembler support with another control directive for DP would be more ideal.

...and ca65 could always grow this feature.
I was told the ca65 assumes DP to be 0 in a fundamental way, so that large portions of it might have to be rewritten if it's going to be able to properly handle the direct page. This is supposedly why this feature haven't been added for years. This is also the reason why the PC-Engine CPU HuC6280 support is lacking in ca65.


Top
 Profile  
 
 Post subject: Re: Snes cc65
PostPosted: Sat Feb 16, 2019 7:37 am 
Offline

Joined: Sat Apr 07, 2018 7:39 pm
Posts: 22
I'd like to say that I use LibSFX (which is ca65) for my projects, and I find it better to use than I found WLA-DX when starting out, as it has various macros to help with memory organization, and rep/sep commands, and even dpo() to help with moving the direct page around. It also comes with an image converter, and can compile GSU and SPC.

calima wrote:
I have some bad experiences with libsfx and snesmod...
However, on the other hand, it appears to not be for everyone...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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