best 8-bit system to program for?

[5233]

Besides programming on a modern PC, I wanted to get the opportunity to try programming for an older 8-bit console or computer like NES, C64, SMS, GB, etc. that would require some form of ASM. But I'm wondering what the best 8-bit machine for homebrew is, hopefully one that isn't too obscure. Any advice?

[tomaitheous]

Besides programming on a modern PC, I wanted to get the opportunity to try programming for an older 8-bit console or computer like NES, C64, SMS, GB, etc. that would require some form of ASM. But I'm wondering what the best 8-bit machine for homebrew is, hopefully one that isn't too obscure. Any advice?

Depends on how much of the "community's" support you're looking for on these systems (for leaning on/learning). NES, C64, SMS, Speccy, MSX, and A8 all have fairly good size and active community for homebrew and such coding/development. I personally thought the GB and GBC were very easy to pick and start coding for (a very clean architecture), but sadly nowadays there doesn't seem to be any community anymore (like 12-13 years ago).

[Chilly Willy]

SMS is a good choice - the Z80 is a great 8-bit CPU to work on, the SMS hardware isn't too complex, and the community over at SMSPower is very good. There's lots of docs and tools over there, and if you can't find something, the forums have lots of good threads. There are excellent emulators for the SMS, and a couple good flash carts for use on real hardware.

The Nintendo systems get really complicated due to the lockout chips and multitude of mappers, and the A8/C64/Speccy/MSX are all older 8-bit PCs and not as powerful as the NES/GB or SMS. If you don't mind the older hardware, the A8 is a really good platform to work on, having a very active and helpful community over at AtariAge. It's harder to find a good, active community for the C64/Speccy/MSX.

So that's my two reccs: SMS or A8. They have the best, most active communities, with the best/most available tools and docs and examples.

[Kamahl]

SMS or GB since they both have easy to understand architectures and have a Z80 which is really easy to program. The GB scene is kinda dead now though...

[sasuke]

I would recommend either SMS for the simplicity of the hardware or the NES for its more active community. It seems like Nesdev has something going on every day, and that website and SMSPower have plenty of documentation on their respective systems.

[slobu]

Wouldn't it really boil down to which system has the best ASM IDE and compiler?

[Kamahl]

Wouldn't it really boil down to which system has the best ASM IDE and compiler?

Nope, since you'll still need to deal with the architecture, which can be simple in design and easy to program or a total nightmare.
Having a community where you can ask questions and find documentation and tutorials obviously makes everything easier too.

[tomaitheous]

Wouldn't it really boil down to which system has the best ASM IDE and compiler?

Only if a certain system had an extremely poor assembler. But that's just not the case and mostly you're down to two CPUs; z80 and 65x. There are plenty of assemblers for both. You don't need a fancy IDE for this kind of development. Matter of fact, you'll probably be developing your own tools and converters anyway. So, yeah... no.

As for compilers, meh. If you're serious about dev on these old consoles - bite the bullet and deal with ASM. C (assuming that's the compiler in mind) is just really for novelty. Try to get anything more out of it and you're working against yourself - really (in this context). Unless all you plan to do is pretty simple stuff. Not saying it can't be done, but you'd need to be familiar enough with the arch and ASM to get any real speed out of it for these old 8bit systems. And if you're that knowledgeable in asm, why even bother IMHO (I'm sure others will disagree and that's fine. To each their own).

My two personal choices would be SMS or NES. NES has a more active community (as has been said), but the arch is much more complicated and has more limitations graphically that can be quite challenging. But then again, there's nesdev forum where quite a few experienced members hang out and help out as well. NES has some decent debuggers too; more advanced than what I've seen for the SMS. A good debugger is worth a lot IMO. But the graphic freedom of 4bit pixels for sprites and tiles on the SMS is really hard to ignore (a very nice plus on the SMS side).

[Chilly Willy]

Only if a certain system had an extremely poor assembler. But that's just not the case and mostly you're down to two CPUs; z80 and 65x. There are plenty of assemblers for both. You don't need a fancy IDE for this kind of development. Matter of fact, you'll probably be developing your own tools and converters anyway. So, yeah... no.

As for compilers, meh. If you're serious about dev on these old consoles - bite the bullet and deal with ASM. C (assuming that's the compiler in mind) is just really for novelty. Try to get anything more out of it and you're working against yourself - really (in this context). Unless all you plan to do is pretty simple stuff. Not saying it can't be done, but you'd need to be familiar enough with the arch and ASM to get any real speed out of it for these old 8bit systems. And if you're that knowledgeable in asm, why even bother IMHO (I'm sure others will disagree and that's fine. To each their own).

We use SDCC and asm on the SMS Myth menu. SDCC is a nice compiler... if you just loathe asm, you could probably get by with SDCC for your z80 programming. If you went with the 6502, you'd probably use cc65.

My two personal choices would be SMS or NES. NES has a more active community (as has been said), but the arch is much more complicated and has more limitations graphically that can be quite challenging. But then again, there's nesdev forum where quite a few experienced members hang out and help out as well. NES has some decent debuggers too; more advanced than what I've seen for the SMS. A good debugger is worth a lot IMO. But the graphic freedom of 4bit pixels for sprites and tiles on the SMS is really hard to ignore (a very nice plus on the SMS side).

That was exactly my thoughts on it - the SMS is a much more straightforward architecture, and the community is fairly active. The NES community may be more active, but the NES is probably a bit much for many folks. I think the flash cart situation is also better for the SMS than the NES as well. I know people have asked for a NES flash cart from both NeoFlash and KRIKzz.

Speaking of which, I'm looking forward to KRIKzz's TG16 cart. I really want to get into TG16/SGX programming at some point... that is why I got an SGX, after all. Just too busy with other things right now. I'll get to it eventually.

[tomaitheous]

Speaking of which, I'm looking forward to KRIKzz's TG16 cart. I really want to get into TG16/SGX programming at some point... that is why I got an SGX, after all. Just too busy with other things right now. I'll get to it eventually.

Ohh that's right, you got an SGX. I guess you're looking to do more than what your Neoflash card can do? Osman (tailchao of Zaku on the lynx) has a new mapper built and working for the SGX/PCE. Pretty nice configuration. Supports up to 64+megs and has the options to include two mapped devices in two separate 256k locations (one of his setup as 256k sram ram and 8k sram in the other). PCE hucard stuff/projects definitely needs more ram, but I guess the 32k on the SGX should be decent enough.

A little off topic and since you brought up SGX, flashcards, etc (which reminded me of you testing out megaman for me); I just found out this morning that someone is selling copies of my Megaman... thingy: (here and here). Two different people/sellers with two different versions. What the hell??? Guess I should make some sort of boot message saying something about not for sale or such, in any future versions.

Back on topic...

[Chilly Willy]

Ohh that's right, you got an SGX. I guess you're looking to do more than what your Neoflash card can do? Osman (tailchao of Zaku on the lynx) has a new mapper built and working for the SGX/PCE. Pretty nice configuration. Supports up to 64+megs and has the options to include two mapped devices in two separate 256k locations (one of his setup as 256k sram ram and 8k sram in the other). PCE hucard stuff/projects definitely needs more ram, but I guess the 32k on the SGX should be decent enough.

A little off topic and since you brought up SGX, flashcards, etc (which reminded me of you testing out megaman for me); I just found out this morning that someone is selling copies of my Megaman... thingy: (here and here). Two different people/sellers with two different versions. What the hell??? Guess I should make some sort of boot message saying something about not for sale or such, in any future versions.

Back on topic...

This could be on topic... some folks might consider the PCE the best 8-bit system to program for.

My main complaint about the NeoFlash PCE card is you have to use the PC client and SLIV to write the game to flash - there's no SD card slot. That makes it a big pain for checking stuff... I gotta fire up the old laptop, copy the file via USB drive, connect the cart to the SLIV, run the client software, flash the game, disconnect the cart, try it on the SGX. I'm hoping that KRIKzz puts a microsd slot on his flash cart... if not, I won't be getting it. Running stuff off an SD card is fine for testing stuff. A little more work than a direct connection, but not nearly as much as burning flash carts. I figure the main testing would be with an emulator for best speed, but at some point, you always have to try it on real hardware. That's my main complaint about a lot of SMS homebrew - the authors don't try the game on real hardware, so they miss things like writing too fast for the VDP during the active part of the frame.

Finally, people who sell repros of homebrew without permission from the author really are contemptable, aren't they. It would be one thing if it was old homebrew where no one knew who made it and no way of contacting the author, but that's not the case here. Oh well, there's ALWAYS going to be that element in the world. You can't let that keep you from working or you'll wind up doing nothing.

[tomaitheous]

Yeah, technically you could say the PCE is an 8bit system to code for. Though to me that just kind of feels like cheating to me since the power potential is inline with the 16bit era consoles. When I think 8bit systems, I definitely think of 8bit limitations. You might be able to make the argument on the PCE single BG layer, but then were does the SGX fall in? Or should I say PC-Engine SuperGrafx. Sometimes I forget that it has the PC-Engine wording in the title.

Yeah, I've had some time to think about it today and I've concluded that... I'm not really pissed about it. If some other stuff that I'm working on got that treatment, then yeah. But meh. Not just auctions, but I found a site that just straight out sells it (no auction). I'm not gonna post the link to it, since I don't want to advertise for him - for free :P Anyway, I hope KRIKzz does the extended Street Fighter 2 mapper (68megabit) for the cart.

[Chilly Willy]

Yeah, technically you could say the PCE is an 8bit system to code for. Though to me that just kind of feels like cheating to me since the power potential is inline with the 16bit era consoles. When I think 8bit systems, I definitely think of 8bit limitations. You might be able to make the argument on the PCE single BG layer, but then were does the SGX fall in? Or should I say PC-Engine SuperGrafx. Sometimes I forget that it has the PC-Engine wording in the title.

Well, it all goes into how you define the console. IS the Jaguar 64 bits? Just like the TG16, they claim more bits due to the video processors (blitter and object processor) as opposed to the cpu. Most programmers and engineers tend to define it by the main cpu, not sub/co-processors. So by that definition, the Jaguar is 32 bits, and the PCE 8 bits. The Jaguar COULD be argued as being 16 bit due to the 68000 in it, but the 68000 is not necessarily the main processor. The RISC making the gpu in the Jaguar was always meant by Atari as the main processor - it was only troubles making a bug-free compiler and jump opcode issues in main ram (which have since been figured out) that made Atari include the 68000 in the first place. The RISC in the gpu is 32-bit.