It is currently Fri Sep 21, 2018 7:12 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 436 posts ]  Go to page Previous  1 ... 25, 26, 27, 28, 29, 30  Next
Author Message
PostPosted: Thu Jul 05, 2018 5:37 am 
Offline

Joined: Mon Jul 01, 2013 11:25 am
Posts: 249
Bregalad wrote:
If they don't want to spend 3 weeks for "hello world", then they probably won't ever spend the time to make a full game for the system. I spent probably well over 3 weeeks when I wanted to do a "hello world" on NES back when I started this activity in 2002 at age 13 without any knownledge of the english language back then.


Because you were truly passionate and you deeply wanted to do it... but that is not the case of everyone.
If the first step seems to be too high then a lot of people will be discouraged even if they had motivations to do it. At the opposite if things seems to be really easy (you can get your first "hello world" working in a couple of hours) then you may gain attention to the system when you weren't in first place, and at the end you may eventually find interests in developing something bigger.


Top
 Profile  
 
PostPosted: Thu Jul 05, 2018 6:30 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 132
Stef wrote:
When i said hardware abstraction, i speak about low level stuffs in general. In the end the library / API still need to fit the hardware design in some ways, but for instance it would be nice to not having to know that the OAM is split in 2 parts. At higher level i would say you won't even need to know you need to fill a OAM.

There's syntax vs. semantics. A higher-level language should be able to translate "a = b;" (or "a := b") to the necessary mnemonic, depending on the current register state and where these variables/values are located. But it shouldn't abstract the SNES-specific hardware features; that can indeed be handled by an API function call.

i.e. the language for the 65c816, a lower-level library for the SNES and a higher-level library for a game engine.


Top
 Profile  
 
PostPosted: Thu Jul 05, 2018 9:59 am 
Offline
User avatar

Joined: Sat Feb 16, 2013 11:52 am
Posts: 314
Bregalad wrote:
Stef wrote:
Starting immediately with very low level and assembly is just too much for a lot of people, we don't want to spent 3 weeks just to understand how to display a simple "hello world" string on the screen.

If they don't want to spend 3 weeks for "hello world", then they probably won't ever spend the time to make a full game for the system. I spent probably well over 3 weeeks when I wanted to do a "hello world" on NES back when I started this activity in 2002 at age 13 without any knownledge of the english language back then.


I'm sorry but you're just showing your prejudice against high level programming. The small-C ish compiler for the PC engine is responsible for all current (and excellent) homebrew available, which despite being completely ignored when posted some pages before it's a pretty strong real-life example of real programmers doing real games for real 16-bit systems. Same with other consoles with varying levels of processing power (even Batari Basic expanded the 2600 homebrew library quite well).

_________________
This is a block of text that can be added to posts you make. There is a 255 character limit.


Top
 Profile  
 
PostPosted: Thu Jul 05, 2018 2:41 pm 
Offline

Joined: Fri Sep 19, 2014 1:11 pm
Posts: 8
Punch wrote:

I'm sorry but you're just showing your prejudice against high level programming. The small-C ish compiler for the PC engine is responsible for all current (and excellent) homebrew available, which despite being completely ignored when posted some pages before it's a pretty strong real-life example of real programmers doing real games for real 16-bit systems. Same with other consoles with varying levels of processing power (even Batari Basic expanded the 2600 homebrew library quite well).



To me, it seems like a form of "gatekeeping." You are only allowed to program for SNES if you learn ASM, and really care to put in the hard work! Who wants more homebrew anyway?

I love the SNES, and I'd love to port my games. While C isn't the be-all end-all, and has it's own caveats, it's the easiest general way to put a game together. I feel like the general people here don't want more homebrew.

I may just port to Genesis, and it's horrid sound chip.


Top
 Profile  
 
PostPosted: Thu Jul 05, 2018 3:08 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7532
Location: Seattle
DarkKobold wrote:
I feel like the general people here don't want more homebrew.
I know I've said nothing else here, but I'd really be happy to see more SNES homebrew. (And yes, I wouldn't care what language it was written in!) I just don't have the correct kinds of skills to help with it.

We do have a few grumpy people, unfortunately.


Top
 Profile  
 
PostPosted: Thu Jul 05, 2018 7:12 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2749
In C compilers, is it common to pad 8-bit variables to 16-bit words? Otherwise it would have to do all kinds of stuff with XBA and REP/SEP if you're adding or subtracting an 8-bit value from a 16-bit value.


Top
 Profile  
 
PostPosted: Thu Jul 05, 2018 8:04 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6809
Location: Canada
psycopathicteen wrote:
In C compilers, is it common to pad 8-bit variables to 16-bit words? Otherwise it would have to do all kinds of stuff with XBA and REP/SEP if you're adding or subtracting an 8-bit value from a 16-bit value.

C structs are often padded, usually just to align to the size of the type of the next variable in the struct. The compiler is allowed to do this if needed for alignment or optimization. It's also common to have #pragma pack directives to disable it, where you need a specific memory layout.

Alignment is the biggest issue necessitating this for the most part. On many modern platforms unaligned access might be a large performance problem, or even cause a crashing fault. It can also help with calculating the stride offsets for an array of structures if it's a power of two.

Similarly, the result of malloc() is usually always aligned to 16-bytes or some other size so that it can be safely used with any primitive types the platform requires alignment for. There are compiler-specific extensions to add alignment requirements to types/structs as well. (C++11 finally created a standard "align" keyword.)

If you're asking if CC65 does it, no I don't think it does (there's not even a #pragma pack), but it also has no aligned types since it only generates 8-bit code, so it doesn't really have any need for it either. Manually padding a struct for power-of-two stride might help a little though.


Top
 Profile  
 
PostPosted: Thu Jul 05, 2018 9:14 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3600
Location: Mountain View, CA
rainwarrior wrote:
Similarly, the result of malloc() is usually always aligned to 16-bytes or some other size so that it can be safely used with any primitive types the platform requires alignment for. (There are compiler-specific extensions to add alignment requirements to types/structs as well.)

And if it's not implied or apparent to readers: this details of how this is accomplished (re: dynamic memory allocation) is complicated, compounded with mass variances between implementations (GNU libc vs. uClibc vs. musl vs. FreeBSD 9.x and earlier libc (uses its own implementation) vs. FreeBSD 10.x later libc (uses jemalloc). Functions like aligned_alloc() (and non-standard MALLOCX_ALIGN() and MALLOCX_*_ALIGN() for jemalloc) can guarantee alignment on some other boundary of your choice.

Off-topic but semi-relevant: what's often unknown to general programmers is that many malloc implementations actually allocate more than what you ask for (ex. malloc(32) will probably allocate 4096 bytes internally, but may pick something larger or smaller depending on all sorts of logic and heuristics), since the malloc implementation itself manages pages into different categories/sizings to greatly minimise memory fragmentation. I believe several implementations also care deeply about cache line size. For jemalloc, the implementation is actually described in the IMPLEMENTATION NOTES section of the man page I linked, ditto with older FreeBSD's libc.

As for compilers (not libc/malloc!) deciding what to pad: depends on compiler. This is especially a problem for structs (it's one of the most commonly-discussed topics). rainwarrior covered that most of its controlled with #pragma, varying per compiler. Usually you'll find someone using something like __attribute__((aligned(XXX),packed)). Wikipedia has an article on the general matter of data structure alignment complexities with lots of C details. Eric Raymond also has a very detailed page on the matter.

Today's C compilers are often focused on portability (which was not a focus of C when originally created in the 70s, but within 4-5 years became a serious focal point that remains today), so there's that trade off too.

It sounds to me like folks complaining about lack of C compiler essentially are saying "assembly is fine but it takes a long time to write + is more tedious to deal with than something like C". And that's very true! Reading between the lines, to me that means an intermediary PL that is 65xxx-series friendly (re: limited registers, etc.), but not as tie-consuming as assembly, would benefit the masses. What's funny about that is in the 70s and early 80s, there were some PLs invented with that sort of thing in mind (given the design of CPUs and systems during that era)... all of which by today have (generally) fallen out of favour in exchange for more commonplace PLs... C being one such PL. :-)

There really isn't something that fills the gap between C and assembly, and definitely even more so when taking the limits of the 65xxx architecture into consideration. As such, the best two things we have right now are: a) cc65, which has had some games written in it (with assembly being required for important bits), and is 6502-centric (read: does not benefit from additional 65816 instructions, addressing modes, and register sizes), and b) Toshi Morita's lcc816, which in its current form won't emit 65816 assembly that's compatible with any present-day 65816 cross assembler.

If I could magically wave my arms and make something happen, it would be to fix/improve 65816 support for cc65 and ca65 (the assembler, which does not cater well to 65816 in its present form (I've discussed this before)), and tell people "if you know C, use this, but you are expected to also know 65816". If said magic happened, I think Stef would probably put in the time/effort to do the dev env/lib/framework to make development easier for folks. But I'm not a magic wizard. IMO, the effort to make TM's lcc816 work with some present-day 65816 cross assemblers (ex. WLA-DX, etc.) would probably take less effort, *unless* the person doing the work is more familiar with compiler internals and compiler theory.

And none of this even begins to touch base on graphical or audio tools. That's a whole other world of hurt that, much like assemblers, had better support back in the snesdev heyday of the early 90s. I could talk about that for hours but it's way off topic. I do remember one thing, though: in the early 90s, there were lots of people who got interested in snesdev, did little doo-dads, then disappeared into the void once the subject of SPC700/audio/music came up. I think the SNES happens to be an incredibly complicated console, probably overly so, but in a lot of ways I still think it feels way, *way* easier to program/work on than the NES. I guess because I started with the SNES and later did NES stuff makes me a bit biased towards the 16-bit console.


Top
 Profile  
 
PostPosted: Fri Jul 06, 2018 5:02 am 
Offline

Joined: Mon Jul 01, 2013 11:25 am
Posts: 249
koitsu wrote:
It sounds to me like folks complaining about lack of C compiler essentially are saying "assembly is fine but it takes a long time to write + is more tedious to deal with than something like C". And that's very true!


Of course, definitely this. I still think that for some people it would be even better to avoid using assembly at all if possible...

Quote:
Reading between the lines, to me that means an intermediary PL that is 65xxx-series friendly (re: limited registers, etc.), but not as tie-consuming as assembly, would benefit the masses. What's funny about that is in the 70s and early 80s, there were some PLs invented with that sort of thing in mind (given the design of CPUs and systems during that era)... all of which by today have (generally) fallen out of favour in exchange for more commonplace PLs... C being one such PL. :-)

There really isn't something that fills the gap between C and assembly, and definitely even more so when taking the limits of the 65xxx architecture into consideration. As such, the best two things we have right now are: a) cc65, which has had some games written in it (with assembly being required for important bits), and is 6502-centric (read: does not benefit from additional 65816 instructions, addressing modes, and register sizes), and b) Toshi Morita's lcc816, which in its current form won't emit 65816 assembly that's compatible with any present-day 65816 cross assembler.


I don't think we really need to create a new intermediate PL, i think it would be better to improve the current available C compilers, standing with C language is definitely preferable as many people already know it and it offers easier portability (at least for some parts of the code).

Quote:
If I could magically wave my arms and make something happen, it would be to fix/improve 65816 support for cc65 and ca65 (the assembler, which does not cater well to 65816 in its present form (I've discussed this before)), and tell people "if you know C, use this, but you are expected to also know 65816". If said magic happened, I think Stef would probably put in the time/effort to do the dev env/lib/framework to make development easier for folks. But I'm not a magic wizard. IMO, the effort to make TM's lcc816 work with some present-day 65816 cross assemblers (ex. WLA-DX, etc.) would probably take less effort, *unless* the person doing the work is more familiar with compiler internals and compiler theory.


To be honest i don't know well these compilers but from what you told here, it sounds that trying to improve LCC816 to make it generate compatible assembly listing would be easier. But i don't really get it, i guess LCC816 is already producing valid binary code right ? what is the problem with it ? it don't allow to mix assembly code with C code ?

Quote:
And none of this even begins to touch base on graphical or audio tools. That's a whole other world of hurt that, much like assemblers, had better support back in the snesdev heyday of the early 90s. I could talk about that for hours but it's way off topic. I do remember one thing, though: in the early 90s, there were lots of people who got interested in snesdev, did little doo-dads, then disappeared into the void once the subject of SPC700/audio/music came up.
...


Yeah but that is something that will come next, first a "usable" C compiler, then a good library with good tools :p
That is just story of developing existing tools / libraries... from what i saw on this forum today things get better, we have sound driver good enough to be usable in game condition. Just need to include them in a SDK with a C API so they become easier to use :)


Top
 Profile  
 
PostPosted: Fri Jul 06, 2018 6:14 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20562
Location: NE Indiana, USA (NTSC)
Stef wrote:
To be honest i don't know well these compilers but from what you told here, it sounds that trying to improve LCC816 to make it generate compatible assembly listing would be easier. But i don't really get it, i guess LCC816 is already producing valid binary code right ? what is the problem with it ? it don't allow to mix assembly code with C code ?

Syntax for directives and expressions varies from one assembler to another. It's not nearly as big as the difference between Intel syntax and GNU assembler's AT&T syntax in i386, between Sony and MOS syntax in SPC700, or between Intel and Zilog syntax in 8080/Z80, but it does mean you can't assemble the same source code file in (say) ASM6 and ca65. My solution when building Action 53 was to write preprocessors to turn a subset of NESASM or x816 syntax into something that ca65 could handle.


Top
 Profile  
 
PostPosted: Fri Jul 06, 2018 8:13 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2749
I think you can make an assembler with new instructions to make it more orthogonal, such as:

ldx long

but that will have to assemble to:

sta shadow_reg
lda long
tax
lda shadow_reg

which can slow it down quite a bit, it would have to use a bunch of variations depending on which regs are available.

if A is available:
lda long
tax

if A is unavailable, but Y is:
tay
lda long
tax
tya

If directly before or after a "sta mem"

sta mem
lda long
tax
lda mem

Just too many variations.


Top
 Profile  
 
PostPosted: Fri Jul 06, 2018 2:13 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3600
Location: Mountain View, CA
Stef wrote:
To be honest i don't know well these compilers but from what you told here, it sounds that trying to improve LCC816 to make it generate compatible assembly listing would be easier. But i don't really get it, i guess LCC816 is already producing valid binary code right ? what is the problem with it ? it don't allow to mix assembly code with C code ?

Toshi's lcc816 outputs assembly, not binary. Its assembly is intended for use with ORCA/M, the Apple IIGS assembler -- which obviously nobody here is using. :-) I still have both my IIGS and ORCA/M (incl. manuals in PDF format); it's a top-grade assembler, so understanding what all the mnemonics and control directives do is very much possible. There are also several bits that apparently output not-very-great code, which were rectified somehow but I believe Toshi lost the macros that improved it. Please refer to the 6502.org thread I linked in a previous post for some details that he himself provides. Toshi's also still around/active -- you can find him on LinkedIn or talk to him on the 6502.org forum -- and is a super friendly guy who did actual commercial SNES games (specifically the Zombies Ate My Neighbours SNES port).


Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 2:51 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 579
what actually is the "difficult" part about the SNES?

The DMA stuff could just be wrapped in a macro, or you make macro that presets the 8 channels to do a thing, then get them to fire each DMA channel off as they want to do Thing X.

How modular is ORCA, it is probably fairly easy to get a 65816 simulator and then enough Apple //gs file system rom mocked enough to give it what it expects and then run the ORCA assembler at ghz speed on a pc without having to go through a whole //gs emulator? That and its probably not that hard to translate the assem output. But having the 65816 simulator would be nice for other debugging tasks such as linking it in with BDD6502 ;)


Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 3:52 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 796
For me, the banking is the greatest PITA.


Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 5:56 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2259
Location: DIGDUG
All this time spent discussing SNES compilers, could have been spent working on a support library. :P

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 436 posts ]  Go to page Previous  1 ... 25, 26, 27, 28, 29, 30  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: ccovell and 3 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