Tom

*jaw drops* But that defeats the entire point of a DMA transfer! It might as well use the 6502 to do the dirty work if it's going to halt it! Was this some sort of misplaced attempt at multi-processor synchronization, or was there some sort of technical reason introduced that they didn't take the time to iron out? 993568[/snapback] Eh, DMA controllers generally need to halt the CPU, after all they're going to use the bus autonomically, which isn't going to work if the CPU at the same time messes around with it. The reason why one makes DMA devices is that they're still faster because they "know" what to do without fetching instructions from program memory. On the GBA, large memory copies are often better done using the DMA controller. During the copy operation, the CPU is halted, but overall copying memory using the DMA controller is still faster, because for copying with the CPU you'd have to write a loop, and the CPU will spend large amounts of time fetching the same few instructions over and over again. The DMA controller on the other hand reads/writes just data. Or am I getting something utterly wrong here ?

Well, I managed to change the graphics for the walking smurf animation in the disassembly, reassembling worked fine. If you posted an actual modified source code snippet that actually breaks the binary (for you), people might be able to help you.

I can't seem to reproduce it.

Hm, could you also post the changes you made that break the binary ?

Could be a problem with the cartridge type of the particular game you're trying to hack. Maybe you cuold post the original rom image and an (unmodified) disassembly of the game you're trying to hack.

Hello, I think there were several people working on trackers for Paul Slocum's Music Kit 2. Did any of these projects ever reach a state where it was usable ? Cheers Thomas

Then better stop thinking about writing software for...well....any platform. Now. (Was going to say you should read Andrew's tutorials, but that would involve...well...reading)

Sorry, you're doing obviously something wrong, but I really don't know what it could be (the command I posted above is correct) You don't need to put files in specific directories, but you must either pass the full path to the input file to dd, or you change to the directory the input file is in and only pass the file's name, without path information. Iirc Cygwin also doesn't treat filenames case sensitive (Unix systems do so), so it shouldn't matter wether you pass "X.FOO" or "x.FOo" for a filename.

downloaded it and used cygwin and I keep getiing this error message and I don't know why: dd: opening '8kfile.bin' : No such file or directory Any idea's? Do I need to use a specfic directory? I tried copying my 8kfile.bin into the cygwin working directory but no go. 982523[/snapback] You did use the correct filenames, right ? "8krom.bin", "bank0.bin" and "bank1.bin" in my first post were of course only placeholders. You have to substitute them with the real filenames you want to use. If that isn't the problem, post the whole command line you're using.

A standard Unix utility. Everybody running Windows should have a Cygwin or GnuWin32 installation.

Why a hex editor ? All you need is dd. dd if=8krom.bin of=bank0.bin count=4096 bs=1 dd if=8krom.bin of=bank1.bin count=4096 bs=1 skip=4096 Simple and powerful.

Would be a good idea. There are several very good open source Z80 assemblers available, so why bother with rolling your own machine code generation backend.

Not really.

Occasionally I wonder why people bother to program on the real thing if they could be conveniently crossdeveloping on their PC/Mac/Whatever.

This document contains a BIOS listing (original, not a commented disassembly ?): http://www.geocities.com/newcoleco/cv-coding-guide.zip Apparently the BIOS contains among other things sprite multiplexing routines.

Philipp, I think you have some small errors in your crt0.s. I don't think the EI/RETI sequence is correct for RST 8 through 30. The RST instructions are basically calls with an implicit address (0008h, 0010h, 0018h, 0020h, 0028h, 0030h). The BIOS has at these locations JP instructions to the cartridge header, and I think instead of EI/RETI you should put a RET instruction in there. .dw start ; where to start execution of program. ei ; RST 0x08 reti ei ; RST 0x10 reti ei ; RST 0x18 reti ei ; RST 0x20 reti ei ; RST 0x28 reti ei ; RST 0x30 reti ei ; RST 0x38 - spinner interrupt reti jp nmi ; NMI nop Should become .dw start ; where to start execution of program. ret ; RST 0x08 nop nop ret ; RST 0x10 nop nop ret ; RST 0x18 nop nop ret ; RST 0x20 nop nop ret ; RST 0x28 nop nop ret ; RST 0x30 nop nop ei ; RST 0x38 - spinner interrupt reti jp nmi ; NMI nop

Ok, I found a BIOS disassembly. They point to buffers in RAM which some BIOS functions use. If you don't call those particular BIOS functions, the pointers can contain *any* value. (The whole point in this seems to be to let the programmer have control over where these buffers are placed, since they can be fairly large. You could probably even overlay some them.)

Can anybody explain me, what the first four pointers (right after the cartridge identification word) in the cartridge header are good for ? Are these used by BIOS functions ? Is it safe to simply set them to 0 ?

Thank you. What's not entirely clear to me - is the thingy GPL'd ?

Could you post the source ? Or at least compiler/linker command lines, startupcode/linker script ?

It's fairly easy to write a program for the Atari 7800 that supports PAL *and* NTSC (autodetecting the console type). Converting existing games might be more difficult. Basically to convert an NTSC game to PAL you'd have to insert additional empty lines into the display list. If there's not enough RAM left for that or you have to move stuff around in RAM to make space, then things will get really amusing

That's not how Atari BASIC works. BASIC is not directly translated into assembly code, it's interpreted. The BASIC interpreter steps through the program, looks at the commands and calls assembly routines that perform the commands. The BASIC code is only translated into a form that is simpler to read by the BASIC interpreter. This is done during *editing*. If you type in PRINT, what is actually stored in the program being edited is a byte with the value 20h. But this is not a 6502 opcode, it's only a token that tells the BASIC interpreter to call the routine that performs the PRINT command when the program is executed. Here's a description of the Atari BASIC file format :http://www2.asw.cz/~kubecj/afmtbas.htm It doesn't show which routines actually get called for the different BASIC commands. You'd need a BASIC/BIOS disassembly for that.

This is information I got from Al a while ago about EF bankswitching:

It might have made sense to use a more advanced code generator than DASM in the first place (ca65/ld65 come to mind). But what do I care, I don't use bB, I just watch its progress when I'm bored enough at work

DASM can assemble code out of order. It just can't do so for raw binaries (the -f3 switch). As a workaround which neither involves modifying DASM (you don't want to do that, believe me) nor modifying bBasic you could try using RAS mode (the -f2 switch). From the DASM manual: 2 RAS (Random Access Segment) The output file contains one or more hunks. Each hunk consists of a 2 byte origin (LSB,MSB), 2 byte length (LSB,MSB), and that number of data bytes. The hunks occur in the same order as initialized segments in the assembly. There are no restrictions to segment ordering (i.e. reverse indexed ORG statements are allowed). The next hunk begins after the previous hunk's data, until the end of the file. You would have to write a small tool to remove the hunk headers and convert everything back into a raw rom image. This is an ugly hack too, but easy to pull of.