Spec for HLL targeting NES

[tepples]

Lack of forward declarations is the single most annoying part of C and C++. I write a function, then need to copy-paste the first line somewhere else just so I can call it in code that happens to be before the function. That is absolutely ridiculous.

I thought a prototype like that was a forward declaration. You have to do the same thing in ca65 if you want to call a function defined in another translation unit: a .global or .import statement in the caller, and a .global or .export statement in the callee.

I also hate how there's no real way to include data for the binary to use at runtime, you have to load it from a file and stick it in an array or something. I hate how modern languages work in general honestly. C isn't too bad, but still, could be much better.

The GBA homebrew community adopted two patterns: converting the data to assembly language at compile time ("bin2s"), and my solution of appending the data to the executable in an archive format ("GBFS").

[zzo38]

For multiplication, you could add an option to use MMC5 hardware multiplication if it is available.

Nothing is really wrong with C-style syntax itself, but C itself has some really backwards features in it.

Yes there are some.

Lack of forward declarations is the single most annoying part of C and C++. I write a function, then need to copy-paste the first line somewhere else just so I can call it in code that happens to be before the function. That is absolutely ridiculous.

It doesn't annoy me much, but this is a valid point.

Also, C doesn't have a good way for a function to return multiple values. You can return a struct, but that mainly leads to the compiler throwing it on the stack instead of returning it in several registers.

Yes, I agree; other programming languages do, even though things like Haskell also would return in a structure (or a pair), in Forth to return on the stack, etc.

What else is wrong with C and C++? Assignments in If expression.

I like this feature actually.

Infinite while loops because you accidentally put a semicolon before the open brace.

I like this feature too.

The postincrement operator having undefined meaning when there is more than one use of that variable.

I don't think it is wrong; what else would expected in such cases?

The wrong order of operations makes bitwise arithmetic lower priority than expected (OR should be like addition, AND and bit shifts should be like multiplication), but they are all low priority instead.

This I agree with you; I don't like this either.

Leading zeroes magically make your numbers octal. Tons of annoying legacy crap.

I think it is OK.

I have a note on the whole idea. HLL is a High Level Language, i.e. very abstracted from the low level, the hardware. So there is a dillema - either you target it for effective resulting code, but this brings some hardware limitations back to the abstaction level (like 1D arrays and lack of 32 bit math), thus compicating use of the language, or you target it to simplify programming a lot, hiding all these details, but this leads to not very effective code.

What if you add commands for both purpose, and add only the stuff to the compiled binary in the places needed for adding the extra details?

[rainwarrior]

If noism will make it simpler that CC65 to handle bank switching, it can be really useful. I don't have much experience working with bank switching, but in CC65 you basically have to keep your code small enough to fit in one 16K bank, and use the other one for pure data.

It should be fine to have code in switchable banks in CC65, just make sure the library routines (like stack manipulation) are in the fixed bank. This can be achieved by naming the fixed bank/segment "CODE". Of course you have to manually make sure the correct functions are mapped in the non-fixed bank whenever calling them.

I'm currently trying out AOROM/BNROM mappers with cc65. The 32k banks means it's easier to arrange code, though it mostly precludes having DPCM samples (which I'm fine with).

Currently I'm putting C code in one bank only, and other banks are used for data or assembly code only. I link each bank separately. cc65's debug symbol output uses the PC to identify their location, rather than the ROM location, so to separate these it's best to build banks individually and combine them in a later step.

My ZP/BSS usage for assembly code is in a global include, so the assembly banks won't conflict. C stuff is allowed to use the rest of RAM. I would have to portion each separately if I was to put C in more than one bank; would probably be a bit of a pain. I would also have to make sure do the DATA segment initialization for each bank that has C code.

I dunno, so far I haven't run out of code space in the C bank; putting music/graphics/levels in other banks leaves me with a decent amount of room there.

[slobu]

The OP hasn't posted in a few months and his rapidshare link to the tentative specs are gone. I really wish someone would complete an Atlan/Scratchalan/nBasic-like project :p

[Movax12]

I'm working on and and or in my conditional statements for the IF ca65 macro. It's designed to be as good as raw assembly could be - I'll update it sometime this week. Maybe that will make things highlevel enough for you along with a nice easy to read assignment macro (math could be added..) ? What else are you looking for? ca65 is probably the most flexible solution for coding NES/6502 due to the way it tracks namespaces and segments. Otherwise maybe you should consider cc65.

[slobu]

I'm working on and and or in my conditional statements for the IF ca65 macro. It's designed to be as good as raw assembly could be - I'll update it sometime this week. Maybe that will make things highlevel enough for you along with a nice easy to read assignment macro (math could be added..) ? What else are you looking for? ca65 is probably the most flexible solution for coding NES/6502 due to the way it tracks namespaces and segments. Otherwise maybe you should consider cc65.

I should definitely consider NESICIDE/cc65. That's as good as it gets. I'm still a little perplexed that batari BASIC for Atari 2600 is still a one hit wonder though
http://bataribasic.com/

The basic premise seems to be a generic kernel with some conversion of subroutines and mathematical statements to asm - which in turn get compiled. I almost never go over CPU cycles and it's BASIC.

[qbradq]

batari Basic looks pretty cool. Anyone have experience using it and could give some impressions?

[thefox]

cc65's debug symbol output uses the PC to identify their location, rather than the ROM location, so to separate these it's best to build banks individually and combine them in a later step.

Are you talking about the VICE label listing file that can be generated? In the generated debug file of the snapshot version, you can get the ROM location from any symbol, too, but you have to (or should) use the dbginfo C library to parse that file (this is included in the CC65 source package).

[rainwarrior]

cc65's debug symbol output uses the PC to identify their location, rather than the ROM location, so to separate these it's best to build banks individually and combine them in a later step.

Are you talking about the VICE label listing file that can be generated? In the generated debug file of the snapshot version, you can get the ROM location from any symbol, too, but you have to (or should) use the dbginfo C library to parse that file (this is included in the CC65 source package).

I've been using the last release, never tried the snapshot. Glad to hear that more info is getting into the debug output in newer versions. I wrote a short python script to parse the VICE label file into FCEUX debug files.

So, I guess whenever the next release is it'd be more reasonable to put everything into one link, which would make it easier to keep the RAM usage consistent across the banks (wouldn't have to manage space explicitly for each one; everything could link its variables into the same BSS segment). You'd probably be able to get C in multiple banks in mapper with a fixed bank that you can put the CRT into. One of the problems with AxROM is the you can't link the CRT in two different banks without a conflict (at least, not in one link). Anyhow, still hasn't come up-- I'll consider it whenever I actually exceed 32k of C code.

[strat]

batari Basic looks pretty cool. Anyone have experience using it and could give some impressions?

I tried it once awhile back (While looking into vcs dev) and really just screwed around with some example code. Attempting to increase the granularity of the playfield "pixels" caused the rom to crash. But it should be really good if you can think of something to do with it. One game made with batari is a homebrew release.
http://www.atariage.com/software_page.h ... areID=4107

[strat]

The OP hasn't posted in a few months and his rapidshare link to the tentative specs are gone. I really wish someone would complete an Atlan/Scratchalan/nBasic-like project :p

I got distracted by another pet-project, but what's really eating my free time of all things is the PS1 "classic" Xenogears. But with this topic coming back up, I feel a little push now.

One big snag was how to circumvent a software stack, because that will make the project a bit redundant with C. What I'm going to try is a function tree that allocates bytes for parameters and local vars to a set of functions that do not share the same call chain. This means function pointers can't be passed to other functions (But they can be used locally like a switch statement). If a function is only called once or only global vars are passed to it, no extra bytes for params are used.

The tentative specs had some goofy stuff anyway, so once the compiler gets further along new specs will go up. A new plan is to incorporate signed and unsigned types since I now understand the 'overflow' flag. Data types will be 8-64 bits wide (including 24-bit). 2D arrays are still unlikely, though.

[slobu]

Glad this project isn't indefinitely stalled

I see that most successful projects parse a relaxed language into assembly:
batari Basic http://bataribasic.com/
BasiEgaXorz http://devster.monkeeh.com/sega/basiegaxorz/
ZX Basic for SMS http://www.smspower.org/forums/viewtopic.php?t=12902

Regardless if it has a software stack or not it wouldn't be redundant to C if programmers could focus on functional code rather than syntax and formatting.

[lidnariq]

Have you ever heard of JAL? It's a vaguely-pascal-like language that targets the PIC16 line fairly efficiently, despite PIC16's lack of particularly useful addressing modes and only having a single first-class register.

edit: make link point to wikipedia page instead of 7-years-stale CVS repository

[slobu]

JAL looks alot like batari Basic. VERY, very cool. As a side I wish they'd just make it compatible with an Arduino Uno instead of trying to make yet another sorta-Arduino.

[lidnariq]

It's a good ... 10? 15? years older than the arduino