Tom

Hello, I know there are more dedicated Amiga forums, but I keep forgetting my account details in these. I've got an A1200 lying around which I've been wanting to upgrade for quite some time now. Now I've got the option to buy either a 1230 Mk II or Mk IV. The Mk IV is only slightly more expensive, so price doesn't really matter. The thing is, the Mk II is sold with 50 MB of RAM in total, while the Mk IV is sold with 8 MB of RAM only. So, which one would you go for? Cheers Tom

I never made a library. I can't remember in all details what I did years ago. Either I downloaded cc65 binaries or compiled my own. Then I read ist documents and figured out how to build startup code and a linker script. Lazy how I am I figured it wasn't necessary to build a special C standard library for the 7800. rfk7800 links to the c64 library and I simply paid attention not to use any function that actually does C64 specific stuff. That's usually the IO related functions. Also, I didn't set up a heap, so malloc/free won't work either. I don't consider this much of a problem. You just don't want to use a heap on something with as little RAM as the 7800. If you have questions, ask them on the forum. There are People hanging around here who know a lot.

What build process? Do you want to build cc65 yourself or what?

I don't know, today I'm in the mood where words in quotes such as 'deadware' make me mad. I'm pretty sure cc65 was the compiler 'GroovyBee was working on'. Ok, so Ullrich von Bassewitz has stopped maintaining it, but it's still available. That's all you need, as far as the toolchain is concerned. The rfk7800 source is here: http://sourceforge.net/projects/rfk7800/files/rfk7800/. It can get you nicely started. It's using cc65 and gives you startup code and a linker script that produce Atari 7800 ROMs with cc65. I can't remember, but I can't believe GroovyBee didn't make his stuff available. And then there's the technical information made available by people such as Dan Boris, and the official programmer's manual has been available for quite some time as well. Sorry, but that's just the usual whining. Documentation, tools and example sources are available, people just have to make use of them. Instead of crying. Besides, I have no idea what you expect from a 'C development library made for the 7800'. Atari 7800 programming is all about putting together display lists and display list lists. This is all explained in the programmer's manual, which you simply have to read until you understand it. There's no way around this. And then your display management code is highly specific to your game and probably you'll end up writing it in assembly anyway.

devkitPro works fine on Windows 7, I've got it running here. You're just using it the wrong way. devkitPro should come with an msys environment. Use that instead of the plain Windows command prompt. Then use the GBA example sources and makefiles that come with devkitArm as a starting point. That should get you going. You can get devkitArm working in a plain Windows command prompt, but this requires some digging in the devkitArm Makefiles and some gcc knowledge. For starters, devkitPro is designed so that multiple gcc versions can be installed in parallel and be all in the search path at the same time. To make this work they have their target platforms baked into their filenames. Your ARM gcc is called "arm-eabi-gcc", not just "gcc". Actually they might well be using a different prefix by now. Also, I don't think you're setting all of the required search paths. I've figured once out how to get devkitArm working in a plain Windows command prompt with gnuwin32 instead of msys (don't like msys very much), but I'd have to dig up some old source code to see what exactly I'd done. If you just want to tinker with the GBA a bit and don't care much about your build environment, use the msys environment supplied with devkitPro.

ZIF socket, using 27C256s. I think it was a Digdug Cart I slaughtered. EPROM carts are very easy to build, and quite OK to work with. What annoys me most about this is that to burn the EPROMs I have to use a different PC since I can't get my EPROM burner to work with my new notebook. I mean, at some point you rarely need to test on real hardware because you know more and more what you're doing. I do most testing on emulators, occasionally I burn an EPROM, and when I've used up enough of them to fill the eraser I'll erase them.

Well, I'm more waiting for easily available PCBs with EPROM, RAM and a socket for a sound chip (doesn't have to be a Pokey...you could stick in a CPLD or Micro emulating anything, right). That would be quite sufficient for me.

Also, the TIA's sound capabilities suck. While some people have done pretty decent music for the 2600 I don't think I'd want to do a 7800 demo with TIA sound. To be honest, the 7800 is a really ridiculous thing.

I don't know. I can only test 32k ROMs. I can't really think of anything much impressive, not without additional RAM.

Don't know, couple of hours over a couple of evenings. Music is taken from the 2600 version.

Actually I mean this. I enjoy some programming after work, but I don't have the energy to program games in my free time.

No. Too much effort.

scene.org, pouet.net etc. are down today, for whatever reason. In the meantime, grab it from the attachment. Oh yes, fwiw, I coded this. vtg_nyan7800.zip

OK, the A3000 can be jumpered to be PAL or NTSC, so I quickly set it to NTSC and it works fine on my flatscreen, and it doesn't even look as bad as some people claim. At least to me the space savings and no 15khz beeping are worth far more. The battery hasn't leaked yet, so whatever I do with the display I'll certainly try to replace the battery...any recommendations for replacement batteries?

Good point, will check the battery immediately when I get home today...apparently with the Indivision I have to remove or replace it anyway because it's too high. I've heard from people having trouble with A3000's that don't have a battery anymore. Does anybody have experiences with that?