30 replies to this topic

[GroovyBee]

philipj, on Fri Feb 25, 2011 6:23 PM, said:

What kind of hardware do you use to program the 7800?

Mainly my CC2 and PAL 7800 for initial testing. I'll fire up the game on my NTSC console if I think VBLANK time is going to be tight and to choose colours. All my games auto-detect the TV type and configure themselves correctly for display lines, colours, animation frame display times etc. It means I only have one lot of code to maintain.

[andym00]

EricBall, on Fri Feb 4, 2011 12:32 PM, said:

Metal Ghost, on Fri Feb 4, 2011 10:08 AM, said:

Are more tools necessary than CC65 is able to provide in order to facilitate coding in C??

It all depends on what "coding in C" means. Obviously the 7800 doesn't have I/O which would fit stdio.h, so that's kinda out. The C compiler would also have to do the following (off the top of my head):
1. Provide a peek & poke to modify the TIA, MARIA and RIOT registers. (Although I guess this could be done with pointers.)
2. Handle the 7800 memory map (zero page $40-$FF, RAM space, ROM space)
3. Put code & data on the correct ROM addresses (for holey DMA)

But it's certainly possible to use C to develop for the 7800. Much of 7800 code is basically data movement. And it's certainly possible to describe the Display List as a C structure.

Of course, it's tough to match the space & speed of hand coded assembly.

Handling the hardware registers and regions of specific memory are simple and elegant in C, I think For example..

	#define SWCHA(*(volatile unsigned char*)0x0280)
 	unsigned char val = SWCHA;

As for memory areas, same thing:

	unsigned char* zeropage = (unsigned short*)0x0000;
	unsigned char* stack    = (unsigned short*)0x0100;
	unsigned char* ram      = (unsigned short*)0x1800;

And as for specific addresses for ROM and stuff, surely that'd be something that would be something you'd handle at link time with stuff being put into specific segments ?

Though I'm sure this kind of stuff is already out there for the 7800

[GroovyBee]

andym00, on Sat Feb 26, 2011 5:52 AM, said:

Handling the hardware registers and regions of specific memory are simple and elegant in C, I think For example..

	#define SWCHA(*(volatile unsigned char*)0x0280)
 	unsigned char val = SWCHA;

That's pretty much how its done on CC65 except it ignores the volatile keyword.

Quote

And as for specific addresses for ROM and stuff, surely that'd be something that would be something you'd handle at link time with stuff being put into specific segments ?

Yep! Segments are handled by the linker. I have config files for a variety of ROM sizes. My set-up also handles malloc, initialised data etc.

[Metal Ghost]

If I'm looking to download DASM, do I want the latest general 'all-purpose' version? or the 2600 Console specific V.?

[GroovyBee]

The one from here :-

http://dasm-dillon.sourceforge.net/

Is fine.

[Metal Ghost]

Thanks!

I'm trying to get software onto my old, re-purposed PC (probably 8 years old....XP SP3, 512 RAM). It was hillarious.....I don't know what speed CD-Rom drive I have in the thing, but I kept getting errors when trying to load Creative Suite onto it. So I figured I'd dump the files from disc and install from HDD. 16 hours to get the files from both CD-ROMS onto the hard drive. But in any event, the box itself is actually pretty speedy. I'm not sure what all got loaded onto the thing over the years, but it was basically unuseable, so I did a clean install of XP Professional and PRESTO - now she's purring! Once CS was on HDD, installed in less than 10 minutes, no problems.

Edited by Metal Ghost, Wed Mar 2, 2011 2:40 PM.