Tom

Can't really tell, someone else made the music, not I. And I don't really know Franz Ferdinand. Personally I always found the tune sounded very similar to Sepultura's War for Territory.

I don't know wether that bug is fixed by now. I can't test on a real 7800, and input/output emulation is quite buggy on emulators (that is, works in cases it shouldn't. can't remember which emu this was, but one totally ignored what you wrote to the port direction registers...). Nor can I imagine why all the joystick directions except up would work...

I've seen that sort of people stepping through the same piece of code again and again, without getting anywhere. Quite fun to watch actually

Certainly! Many awesome games are programmed in C for the Colecovision. 864432[/snapback] What I find more interesting is that they use a CP/M based compiler *. I don't know much about the free "modern" Z80 compilers...what's wrong with sdcc or z88dk ? *) At least that's what I see on http://www.geocities.com/newcoleco/framesen.html

The thing is, more often than not the components stuffed into your typical IDE are not half as good as the dedicated separates that do only one job but well. The typical example are the builtin editors. They're far away from being as powerful as Emacs or vim. Each of them works a bit different, and I don't feel like adapting constantly to such toys, which is what they are. I rather use the same editor for everything. Same for build tools. Why would I want to find out how to tell a particular IDE that in order to build file x among other things file y must exist which is generated by running script z, if I simply can write a makefile that does the job ? Oh, I could rant on forever... Actually it's the other way round. I wonder how I ever did with them. You know, the first thing I saw were specialized IDEs.

Somehow I don't see what would be so incredibly useful about an IDE with builtin assembler and emulator. I mean, what would it give you that you can't have with the Visual Studio solution described by Andrew ? You don't like Visual Studio ? Use another editor. I'd suggest Emacs =) You aren't happy with the existing 6502 assemblers ? Write a better one, but again, why would it need to be part of a specialized IDE ?

It's waiting for a bug to be fixed (some problem with joystick input, reported by mitch). iirc the video bug apparently wasn't a bug at all, just the wrong kind of ROM on the wrong kind of console. Oh, and there's the Megahyperdeath patch...

Relocatable code (as long as you don't use far calls/jumps) was just a lame excuse to have a memory model as braindead as the 8086's Actually, if you do know your way around assembly programming, you should be fine with these tutorials on the 6502: http://www.6502.org/tutorials

I've fiddled around with this once. My approach worked somehow like this: 1) Parse the NTSC and PAL RGB values from the TIA color chart 2) Say we want to find the PAL color that is closest to NTSC color # 66: Find the RGB value for color # 66 3) Find the RGB value of the PAL color that is closest to the RGB value of NTSC color # 66. I did this by calculating the distance of the RGB color triplets in the RGB color cube: d = sqrt((rn-rp)^2 + (gn-gp)^2 + (bn-bp)^2) (rn = red component of NTSC color and so on). The PAL RGB triplet for which d is the smallest is the closest color. 4) Find the PAL color number that corresponends with the PAL RGB triplet found in the previous step. This kind of worked, but not perfectly.

Yes. It's really just a matter of getting the address onto the bus. Has anybody ever come across code that used a load instruction to switch banks and relied on the value read during the bankswitch ?

However, if you modify an existing ROM to use lda instead of sta, you might break the ROM if it still needed the value in the accumulator.

Actually it's only the address that shows up on the bus that's important. The opcode (lda/sta/whatever) doesn't matter for the bankswitching logic.

Yes it does. I wasn't talking about cc65 only. My main point was why volatile exists in the first place, and that just because one uses it doesn't mean one could by writting everything in assembly aswell.

C works fine on the 7800, and constructing display lists with the help of arrays containing structures (for the headers) is kind of convenient. You'll run into problems if you need to update large parts of the display list during vblank, though. The time you have is already limited enough, and cc65's code isn't exactly fast. But you can always code non-time critical code (like setting up a display list skeleton) in C and do the time critical stuff (like updating the display list during vblank) in assembler. Has anybody ever tried out or used at work the 6502 C compiler from Avocet ?

That should be R_VCNT and not VCOUNT in the second code sample above

Seems to me more a like problem of badly written code than like a problem of C itself. C is usually very suitable for hardware bashing. The follwing is taken from HAM, a development kit for the GBA: #define R_VCNT *(volatile u16 *)(MEM_IO + 0x06) MEM_IO is the base address of the hardware registers. Now you can access the GBA's VCOUNT register like this: while (VCOUNT != 160); volatile ensures that the compiler generates code that reads VCOUNT every loop iteration.

You know, a C runtime library itself can be generic too. Modern libs are mostly written in C itself, and you simply compile them with the very same C compiler you're going to use to write your C program with. cc65 is a C compiler for the 6502. Its C runtime is written in assembly, but even that can be pretty generic: It runs on a wide range of 6502 based systems, all you have to do is to provide a few interface functions to the underlying OS (such as functions to allocate memory or to do file I/O) I used cc65 to port robotfindskitten to the 7800. I didn't even bother to compile a special runtime library for the 7800. I just took the C64 library. As long as I don't do things that would pull in C64 specific stuff (such as calling printf), the program compiles and runs fine. Of course I had to write a linker script and startup code tailored to the 7800. Anyway, cc65 is totally unsuitable for 2600 development, since it's too resource hungry for the 2600. For instance, it requires quite a bit of zpage RAM, which it uses as additional "registers". You use volatile to force the compiler not to buffer reads/writes on certain variables. For instance, if you poll a memory location that's actually a hardware register which might change, you don't want a compiler to optimize away repeated reads because it thinks the data can't have changed since the last read. Trying to write a kernel in C is totally futile for another reason: A halfways advanced kernel requires operations to happen at specific clock cycles relative to the beginning of the scanline. With a high level language you have absolutely no control over that.

Why shouldn't it be possible ? You can hack anything, given enough time and knowledge.

http://en.wikipedia.org/wiki/Latency Basically in this case it's the amount of time a packet needs to get from one machine to the other. If I ping atariage I get a time of 142 ms, and if you assume the message from my machine needs roughly as much time as the message from aa back to me, the latency would be 71ms.

Yeah, right. Here you go. srecord_1_12_bin_install.zip

Here you go. It's an older win32 version, but will do the job fine.

Check the number of scanlines the ROM does. If a PAL game does an odd number of scanlines, the TV won't be able to display colors. You can check the # of scanlines with z26 (supply the -n switch).

Oh, apparently they don't provide binaries. If you can't compile it yourself, I can probably dig up an older version and upload it.

There are tons of utilities on the net for that. Try srecord for instance: http://srecord.sourceforge.net

If you make a built-in GUI, make sure one has still the possibility to launch ROMs via the command line. The 08:15 user might not use it, but developers certainly will.