Thoughts on Higher Level Language Design for 6502 Systems

mrm78 · Post by **mrm78** » Tue Jan 03, 2012 8:25 pm

Hmm... sure i need to make some video tutorial for it.
Its easier for making simple makes for people that dont know the NES system. Its a starting point for bloody beginners.
Not usefull for coder that know how to code for this system.

haroldo-ok · Post by **haroldo-ok** » Wed Jan 04, 2012 7:59 am

It looks impressive, so far.

I do agree with Shiru: from an experienced programmer's perspective, this coding environment looks... well... inefficient. On the other hand, most people aren't experienced programmers, and Scratch was designed not for productivity, but ease of use; even a child can code on it (it was designed for that).

In other words, while it won't make much of a difference for elite coders, a NES-targetted version of Scratch has the potential to introduce a whole slew of people into NES homebrew development.

Again, it's a very interesting project, and a cool achievement. Keep up the good work.

cpow · Post by **cpow** » Wed Jan 04, 2012 8:17 am

mrm78 wrote:Its a starting point for bloody beginners.

When I see the UI I don't think "this is a great tool for a beginner", I think "this reminds me of the Lego Mindstorms my seven year old plays with". If he were to express an interest in creating a NES game, I sure as heck wouldn't tell him "Well, first you'll have to learn this weird language called Atalan, then you'll have to learn this weird pseudeo-programming environment called Scratch which hides so much from you you'll never be able to create anything more polished than something you'd find on Action52. Good luck with that!"

Also, it seems something's missing from your package? NESST runs fine by itself for me, but not when I try to "Paint" a background from your tool:

mrm78 wrote:Its easier for making simple makes for people that dont know the NES system.

No. A good IDE with a set of easy-to-follow-and-modify tutorial projects could be that. Even I'm not there yet...probably never will be.

mrm78 wrote:Not usefull for coder that know how to code for this system.

I don't see how it'd be useful for coder that doesn't know how to code for this system? What am I missing? How would I know what "when I receive Update" means? NMI? IRQ?

mrm78 · Post by **mrm78** » Wed Jan 04, 2012 9:44 am

@haroldo-ok
tnx... maybe its was the wrong place to post this..

@cpow
tnx u2 to for feedback & good luck with your IDE.

The tools auto generates a atalan file.
So why must the user learn atalan then?
We just wanted to telp playpower.org with coding some simple learning games for it..
and i think its possible to make maybe games that are better than action52.

I know that this forum seems to be a wrong place to talking about it.

Me had much fun coding for the NES

and do little bit 6502 stuff.

For example the sprite flickering seems better then the original game.
game needs 6k cyles for running..

see u

cpow · Post by **cpow** » Wed Jan 04, 2012 10:29 am

mrm78 wrote:@cpow
The tools auto generates a atalan file.
So why must the user learn atalan then?

I've never had good experience with autogenerated code. The firebreather example has a lot of warnings when compiling...are those from the autogenerated code? If so, the autogenerator is degenerated to the point of uselessness because I can't tell whether a warning is my fault or not.

To Shiru's point in another post, if there's no debugger available that can step through code at the Atalan level [or at the Scratch level?] then it's not much help. How easy is it to get from a 6502 machine address to a line of Atalan code or to a block in Scratch? If your IDE supports that it isn't obvious.

mrm78 · Post by **mrm78** » Wed Jan 04, 2012 5:03 pm

hi, at the moment there are some problems with the atalan compiler.
but rudla is on it. After this the warnings should go away.

i know, autogenerated code bears problems.
scratch doesnt allow to debug stepwise, but it will be possible to add variable watching to Fceux with some lua scripting.

Shiru · Post by **Shiru** » Wed Jan 04, 2012 7:18 pm

If the code is always autogenerated and user never work with it, what's the point to use Atalan then? Why not generate 6502 code directly?

haroldo-ok · Post by **haroldo-ok** » Thu Jan 05, 2012 7:49 am

Well, I can see one advantage of generating Atalan instead of plain 6502 code: The Atalan developers seem to be porting the language to the Z80 processor (There's even a small ZX-Spectrum demo on their SVN repository); they even changed their description to "Programming language compiler for 8-bit processors"; just imagine where it could go from there.

Shiru · Post by **Shiru** » Thu Jan 05, 2012 7:57 am

To very limited and not really useful portability? Game logic could be portable, but other differences would force to redo everything else for every platform. For example, NES HW 8x8 three color sprites and typically 60 FPS update vs. ZX software 1.5 color sprites (monochrome with masks) of arbitrary sizes and update rates more like 16 FPS, that also require more memory than NES sprites due to need of pre-shift and pre-flipping.

Post by **tepples** » Thu Jan 05, 2012 8:29 am

haroldo-ok wrote:Well, I can see one advantage of generating Atalan instead of plain 6502 code: The Atalan developers seem to be porting the language to the Z80 processor

In other words, for the same reason that early C++ compilers emitted C.

Shiru wrote:Game logic could be portable, but other differences would force to redo everything else for every platform.

In other words, something like a model-view-controller paradigm. This works only when all platforms can be programmed in the same language. I guess that's one of the reasons Microsoft chose C# for XNA: games can't be easily ported from any non-Microsoft platform to Xbox Live Indie Games, encouraging developers to make their games exclusive to Microsoft platforms. C and C++ need P/Invoke, and Python and friends need Emit, neither of which is present in XNA on Xbox 360 or Windows Phone 7.

slobu · Post by **slobu** » Thu Jan 05, 2012 1:24 pm

Just as Tepples noted advantages using Atalan over bare metal ASM I also see Scratch having similar merits.

If the GUI based development environment can be separated from the underlying language it wouldn't matter what platform used what compiler. I could think of:

Scratch -> BasiEgaXorz -> Genesis binary
Scratch -> BatariBASIC -> 2600 binary
Scratch -> DragonBASIC -> GBA binary and so on..

cpow · Post by **cpow** » Thu Jan 05, 2012 2:53 pm

slobu wrote:Scratch -> BasiEgaXorz -> Genesis binary
Scratch -> BatariBASIC -> 2600 binary
Scratch -> DragonBASIC -> GBA binary and so on..

CC65 seems to be already there...so all you have to do is learn C. I *guarantee* you that is more rewarding and resume-enhancing.

CC65 comes with libraries to build binaries that will run on:

NES
C=16
C=64
C=128
PET
Vic-20
Apple][
Atari
...

slobu · Post by **slobu** » Fri Jan 06, 2012 3:13 pm

I guess the one other factor in choosing a high/low language is support and or community. All but one of the BASIC compilers has a pretty dead community. Atalan has a *very* nice developer but who knows when an active development crowd forms around it.

C is looking better every day.

Dwedit · Post by **Dwedit** » Fri Jan 06, 2012 3:59 pm

cpow wrote: CC65 seems to be already there...so all you have to do is learn C. I *guarantee* you that is more rewarding and resume-enhancing.

Problem is that NES C wants you to do weird things to help optimize your code, like using global/static variables instead of local variables.

Post by **tepples** » Fri Jan 06, 2012 5:09 pm

Dwedit wrote:Problem is that NES C wants you to do weird things to help optimize your code, like using global/static variables instead of local variables.

This is largely an artifact of the 6502's 8-bit stack pointer and its lack of the 65816's d,s and (d,s),y address mode, which makes stack-based local variables practical on the 65816 but not on the 6502. (C has problems throughout the 6502 family, due in part to no hardware multiply for indexing into big arrays.) It's also an artifact of the compiler's assumption that all subroutines are potentially recursive. Otherwise, the compiler could allocate local variables on zero page based on call depth, as kevtris explained to me: leaf functions' local variables start at $00, and an outer function's local variables start after those of the functions it calls.