Tom

ca65 (part of the cc65 toolchain).

Of course you can't just go and load flat binaries on an emulator (or a real machine for that matter). You have to create a valid EXE file. Either make the necessary header by hand (description : http://www2.asw.cz/~kubecj/afmtexe.htm) using DASM, or use an assembler that knows about EXE files (for instance XASM)

It's simple: The earlier you release, the earlier you get bug reports, which is imo a good thing.

TXTBUF EQU . . EQU . + BUFLEN the last line reserves BUFLEN bytes of space. kind of pointless with dasm, since it won't actually generate code (or reserve space in the output binary), because it's at the end of the output.

Or you take a 12 character kernel and use it to display 24 (3 pixel wide) characters. One sprite needs then to display two characters. You can either store the graphics for all possible character graphics in ROM, or you generate the the needed character graphics into RAM, which would be feasible, since you only need to display one or two lines of text.

But will these binaries also work on OS 1.3 ? (I think VBCC binaries run only on 2.0 or newer)

Just out of curiousity, what are you using to compile for 68k Amigas ? DICE ?

I'd like to point out that this is very basic unix knowledge, which you mac people should have, since a unix derivate is what makes our operating system tick under the hood.

Then on your system the current dirtectory (.) probably isn't in the shell's search path (on most unix systems it isn't by default, for good reason). Try this: ./dasm game.asm -f3 -ogame.bin

Not really. What makes the chess cart useful for homebrewing is that it has a 3853 which decodes the F8's perverted control signals to standard control/address/data bus signals. So you can remove the chess ROMs and replace them with EPROMs containing your own software. Doesn't have anything to do with VRAM access. See http://www.freelists.org/archives/channelf...4/msg00025.html and http://members.cox.net/seanriddle/lights.asm

-f3 causes dasm to write a flat ROM image without any additional information. There are two other output file formats, iirc one of them has a load address in its first two bytes or something like that.

No, what's really incredible is how tedious and time consuming video RAM access on the Channel F is.

The normal thing would be to distribute the grammar file, but not the generated code. Nothing that can be generated needs to be distributed (or even more silly, put under version control. I've seen people do that before...)

No, of course not. These are not Swiss army knives, only what the rest of the world believes to be Swiss army knives. Also, "officer's" knives don't exist. Everybody has the same kind of knife, regardless of his rank. That knife is, btw, pretty much useless. It has a blade which is too small to cut bread (we usually used the bajonet for that), a can opener (which you don't need, because you don't want to eat the canned meat they, fortunately only rarely, give you), something that can - maybe - be used to poke holes, and something that looks like a large screwdriver and which I used to clean the pipe's head (I don't smoke pipe anymore). The only positive thing about the real Swiss army knive is that it doesn't come in that cheesy red but is chrome colored. Personally I own a Cybertool aswell. It was a gift, I wouldn't have bought one myself. I mostly use it for its screwdrivers, but real screwdrivers with round handles are just better.

Probably you actually have flex/bison (the GNU implementations) installed on your system. I think the best tutorials about these are in their manuals. See http://www.gnu.org/software/flex/manual and http://www.gnu.org/software/bison/manual Okay, but not before next weekend. I'm in the army at the moment.

Would have been a piece of cake to do with lex. You really should use lex/yacc or at least lex. Your grammar is probably simple enough to handcraft a parser without going mad. Personally I wouldn't have used C in the first place but Java and I'd written the scanner/parser stuff with JavaCC. If you want I can help you autotoolize the code, so you don't have to worry that much about makefiles anymore.

Yeah, right. And for the very same reason homebrewers usually don't release source code, because they don't want to give away their knowledge.

I discovered that in the gfx init code, DPPL/DPPH are set during a vblank period, the remaining registers are set during the next vblank (getMachineType returns during vblank in this case). Let's not discuss wether that particular piece of code is stupid, the question is a different one: could this cause those (spurious) lockups some people experience ? /* Set DPP, depending on machine type */ if (MT_NTSC == getMachineType()) { DPPL = (unsigned int) &dll[2] & 255; DPPH = (unsigned int) &dll[2] >> 8; } else { DPPL = (unsigned int) &dll[0] & 255; DPPH = (unsigned int) &dll[0] >> 8; } /* Set up remaining maria registers */ waitVBlank(); CHBASE = (unsigned int)font >> 8; BKGRND = 0x00; CTRL = CTRL_MODEAC | CTRL_KANGOFF | CTRL_BCBLACK | CTRL_CHAR1B | CTRL_DMAON | CTRL_CKOFF;

The binary in the tarball (which Mitch used) and the binary in the zip file are one and the same. Can't really help here, as I don't have a CC2.

Kind of useless now, but I also uploaded a zip file to sourceforge (http://sourceforge.net/project/showfiles.php?group_id=138752)

That was a buggy version. Try the version from here. According to Mitch this one will work.

Did you use the version from sourceforge, or the version attached to this thread ?

Probably MESS doesn't know what to do with a tarball. Unpack the .A78 file (winzip/winrar/winace should be able to read TGZ files) and place it in the software\a7800 directory of your MESS installation. Thanks again for testing, Mitch. It took me over a year to publish the code and wait for someone to find the bug for me, but it was well worth the effort

I put it on sourceforge and released source and binary packages: http://sourceforge.net/project/showfiles.p...ckage_id=152194 Harry Dodgson pointed out a bug in the joystick input code. If anybody could test it on real hardware I'd be incredibly thankful.

Make that debugger scriptable (embed Lua, Tcl or whatever) and let people implement their own features. Sorry, but I had to Seriously, say your debugger core written in C/C++ provides a number of simple functions to the embedded scripting language, for instance: read byte from ram, write byte to ram, send text to debugger console. This would allow users to do all kinds of complex stuff, such as memory dumps* or comparisons of whole memory ranges. Btw, I'm just throwing around ideas here. I don't expect you to make a scriptable debugger just because I think it would be useful. *)Even to a file, if the embedded language is able to do file I/O by itself.