I'm wondering because it would be cool to see new releases built from the ground up for either system. I just want to know how hard it would be to do that, and if you can only program for it in ASM.
I'm wondering because it would be cool to see new releases built from the ground up for either system. I just want to know how hard it would be to do that, and if you can only program for it in ASM.
In my experience, the 65x 8bit family of processors (NES) don't work great in C. Such processors get their speed from hand optimized Assembly. Not sure how well the z80 handles C, but imagine it's the same situation (I've only used Assembly with z80 variants).
As far are dev, NES has an active scene -> http://nesdev.parodius.com/bbs/
You want to use ASM when you're going to do something serious... you can get away with C if you'll just be doing some stuff requiring no real performance (like a board game).
Z80 has very pleasant ASM, beats the crap out of pre-386 ASM easily, cannot really comment on 6502 and alikes, but all my friends except Tomaitheous hate it :P
I've tried both Z80 and 6502. I could say that the 6502 could be more C friendly than the Z80, since its index registers can act as an entry in an array.
I'd say I prefer the Z80 mostly for its multiple registers (6502 only has 3 general purpose ones, Z80 has around 7, 11 if you count the index registers) and syntax. I like the 6502's "zero page" addressing and the index registers, though.
I you want a really difficult processor to program for, try the 65816. :?
It's funny how MOS-technology created the 6502 to be the simplest easiest cleanest chip design ever, but the WDC who later got the rights to the 6502, created the 65816 to be the 16-bit successor to the 6502, but ironically made it the most complicated, confusing, and dirtiest cpu archetecture ever. Somebody obviously did not get the point.Quote:
I you want a really difficult processor to program for, try the 65816.
The 6809 is a perfect example of what the the 65816 should have been.
A little bit off topic. So I've been reading other programming threads on other forums and it made me wonder, am I the only programmer who doesn't push and pull every register on and off the stack in all the subroutines I use? It just looks like a total waste of time to me.
On 65x series, I almost never use the stack. There's no real reason too. Especially speed wise. Well, with the exception of interrupt handlers. On the 68k, I use the stack more often. Still not a lot though. Depends on the subroutine and what code is calling it.Quote:
Originally Posted by dragonboy
I'm wondering is it possible to create high-level languages specifically optimized around individual cpus so that the cpu can run something higher than assembly yet wouldn't be as slow as C or BASIC.
FORTRAN? Then again mostly used for large computing like for genome and whatnot.Quote:
Originally Posted by dragonboy
http://www.cc65.org/
C compiler for the 6502, with library support for the NES among other systems. :cool:
It's not a FULL C compiler... more like Small C with extensions, but it's not assembly.
I love both the 6502 and the Z80. They're completely different, but both have their pros and cons. And I've never pushed all registers just for the hell of it. Look at my 68000 code in Wolf32X and you'll see I push as few registers as possible. The idea is to write your subroutines to use registers you KNOW are free at the time so that you don't have to push the registers. That makes your code much faster, but more prone to bugs if you don't keep track of your register usage.
I worked on HuC for a few years on and off. Digging through the library code, compiler source, etc.
It's a Small C compiler for PCE, but was built from an open source Small C compiler floating around on the net (the date of the original source was 1984, IIRC). I suspect that its origins are the same as CC65. Which, IIRC, CC65 is an upgrade from the original Atari Small C compiter.
Anyway, working with HuC is/was frustrating. Not that I use the language personally, but I was trying to get some speed out of it so more down to earth/less serious hobbyist programmers would use it. The nice thing is that the library is in ASM, and with a pragma fastcall setup - was able to write my own extensions to the lib. The other nice thing about pragma function setup was that I had full control about how the arguments were passed (registers,zp,etc) - and that I could do argument overloading. I.e. same function name but with different number of arguments. I was able to add support for additional hardware and/or more effective hardware interfacing. The biggest downside to HuC (besides the lack of a real optimizer) is that it's crippled for any type of array (const pointer) access. It treats it as far data and that macro for fardata read/writing is insanely slow. Even static mapped near data. That's the insane part. That's pretty much makes HuC almost worthless for anything approaching a moderately serious project.
I'm not sure how CC65 is in comparison, but I no doubt assume that it's better. Considering it has a much larger user base, support group, crosses multiple platforms. Anyway, that's my experience with a high level language for 65x. I like C quite a bit. I use it for PC all the time. But ASM is where my heart is. And I dread using C for consoles with such CPUs. I can see using C for 68000 consoles, but why when assembly is just soo much more fun ;)
Yeah, I can't see using anything but assembly on an 8 bit CPU. Even old BASIC games on 8 bit systems like the Atari used lots of assembly user subroutines for speed. Also, hand-made assembly can't be beat for size.
I had Deep Blue C for the Atari years back when I was still programming on it, but I can count the number of times I actually used it on one hand. :)
What I'm wondering is how did programmers keep up with their own scheduel. This week I've been working on the jump/fall/tilecollision part of my game, and everytime I do it, it malfunctions in some new way.
Take a look at this:
Funny thing, just saw this posted over at SMSpower -> http://www.z88dk.org/forum/ . C compiler for Z80.
Hehe. The joys of annoying bugs squashing. Once you've got it working though, building completely new engines/routines that still have similar/related requirements, becomes much easier. I.e improving/expanding upon it or modifying the requirements, etc.Quote:
What I'm wondering is how did programmers keep up with their own scheduel. This week I've been working on the jump/fall/tilecollision part of my game, and everytime I do it, it malfunctions in some new way.
Nifty, but not much use on the Genesis with only 8K of RAM for the Z80. I suppose you COULD make 32K of code in the ROM and set the bank to it, but the Z80 would have to contend with the 68000 for bus cycles while executing the code.Quote:
Originally Posted by tomaitheous
Still, if all you wanted was a Z80 program in C, you could use the MD as a test bed that way.
Yeah, definitely wouldn't use it for MD. Would be fun to mess around with for a SMS project. Actually, if this compiler is efficient enough - I'm hoping this brings some attention to the SMS coding scene. SMS graphics are pretty easy to work with and easier (than say NES), and pairing that with this compiler would be a great asset for the SMS dev scene. Here's hoping ;)Quote:
Originally Posted by Chilly Willy
On a side note, I keep forgetting that I can do SMS dev with my Genesis consoles. I'd want to do an SMS dev project sometime in the near future.