Tom

Seen on a swiss auction site (the seller states it runs some BASIC, doesn't know what it is exactly or wether it works):

Are these articles available somewhere?

When do you people finally learn that it's written together and all in lowercaps, like so: "robotfindskitten"? Yes, I'm responsible for rfk7800 (and soon a bunch of other rfk ports), and Harry Dodgson wrote Combat 1990. Hi Tom Sorry for my mistake;but i like your game.And believe me,i know,that Harry made Combat 1990,because i own the very special number 1.Because it seemed,that i was the first,who wanted to order a copy and so i got a special thing from Video 61.But another thing;how a bout an RFK version for the Atari 2600 and 5200? greetings Walter The comment about Combat 1990 was geared at PacManPlus, and in fact I love it when people misspell robotfindskitten, because I can correct them then with a loud sigh. Someone is working on rfk for the 2600 (although I recently asked about its current state - more or less dead). I might be wrong but I think there exists a version for some 8 Bit Atari, so there's not much work to do there. I've got other platforms to catch at the moment

When do you people finally learn that it's written together and all in lowercaps, like so: "robotfindskitten"? Yes, I'm responsible for rfk7800 (and soon a bunch of other rfk ports), and Harry Dodgson wrote Combat 1990.

I've no interest in this machine at all. Its games library sucks, its graphics architecture sucks, its music architecture sucks. It's one of histories dead branches I've no interest to revive. And it holds zero nostalgia value for me - I thankfully never owned one back in the day. That was harsh! But true. I really can't believe that people here would stoop this low and insult the homebrew and hacks coders who've created some great games on the 7800 who post here. Blah, I for one tinkered with the 7800 around aswell, and Maria is just that: an odd piece of junk. Unlike the TIA it's not even fun to write code for. Nobody insulted homebrewers or hack coders.

I've no interest in this machine at all. Its games library sucks, its graphics architecture sucks, its music architecture sucks. It's one of histories dead branches I've no interest to revive. And it holds zero nostalgia value for me - I thankfully never owned one back in the day. That was harsh! But true.

romnation hosts rfk7800. Of course only the ROM, without the license or the source, so they're violating the GPL, those idiots Complaining would most likely be a waste of time, though. I guess it is possible to talk to the guys over at pdroms, though. I met Coyote briefly once at a Swiss demo party, friendly guy.

One could do quite a lot of cool stuff for the 7800 with much less than 128KB of ROM, if only the damn thing had a bit more than 4KB of RAM.

Ist this available somewhere?

I'm porting a particular zen simulation over to the colecovision. It will be pretty rare, as I don't intend to produce cartrigdes. On the other hand it's GPL'd and already hosted on sourceforge, so anybody can produce his own batch limited to 1 cart. Oh, the joys of free software.

That wasn't refactoring. Someone just blindly removed a typedef which interfered with another one in the Linux or glibc system headers - "Now it compiles, therefore it must be OK".

But exactly that wasn't needed in older versions, was it? I think one could write lda #-1 Without getting these kinds of errors. Some operators need you to discard high bits, though (depending on the values of its operands)

Yes, but you need that vcs.h anyway, as I said, you're having at least two different problems. Post the source of the original disassembly. I actually think 2.20.7 should still be ok... Oh yes...also post the binary you're expecting to get.

Unable to open'vcs.h': I don't think this is a bug. dasm just can't find vcs.h, which is needed by your source code. Search the zip archives on the DASM website, it must be there somewhere. Then the simplest way to solve this is to put vcs.h in the same directory where RiverRaid.asm resides. About the errors: This is a problem with a typedef that got accidentally changed from signed to unsigned but never fixed. Use a previous version of DASM.

Well, the point is, displaying anything halfways interesting eats up virtually all CPU time during the display period, leaving you with a ridiculously small remainder of CPU time during overscan/vblank. (Edit: Bob was a bit faster. I had to stop typing and hold a video chip's hand).

Pkk, I finally gave your libraries a real try. Setting up some test screens after looking at the cv/cvu headers and quickly looking at http://bifi.msxnet.org/msxnet/tech/tms9918a.txt was a no brainer, and the great thing was, I didn't even have to worry about actually accessing the VDP myself. Cool stuff. If only sdcc was less smart on the command line side...no way, you can't link with "sdcc -o output.ihx ...", you have to write "sdcc -o output ..." to get a file output.ihx. Took me a while to figure out that one. Damn amateurs

I use modded 2600/7800 cartridges with a ZIF socket sticking out of them and a bunch of EPROMs. This IS a painful way to test software, but the emulators available for many systems are pretty good, so I need only few tests on real hardware. Knowing the flaws of the emulators (like having a too fast CPU, as VBA has or used to have) helps.

The stack page resides in the zeropage. It is shared with the RAM (variables), 128 bytes in total. Since each JSR costs you two bytes, you can theoretically (no variables) do 64 nested JSRs. Depends on how you look at it From the 6502's point of view the stack IS in page 1. That is, when it uses the stack pointer for addressing, the address it generates consists always of the stack pointer (lower 8 bits) and 0x01 (upper 8 bits). Because the 2600's 128 bytes of RAM are mapped into the zero page and page 1, the effect is as if the stack was in page zero.

That's why this programmer's so simple. EEPROMS don't need any special programming voltages. They're expensive, though. On the other hand, in the companies I've worked so far they throw away the EPROMs and the burners/erasers because they aren't much used anymore.

The GBA has 240x160 square dots. It's an odd resolution, often too small to directly "port" over graphics from other platforms. Additionally the top and bottom few lines are way too dark and shouldn't be used to display anything important.

You know, bitness *alone*, very much like clock rates, means nothing, really.

I'd love to play around with FPGAs aswell. I've got a Spartan-3 Board from Digilent with an XC3S200, the thing is just, I have absolutely no idea what's possible with an FPGA of this size...the board itself is neat. It has switches, LEDs, four 7 Segment LED Displays, VGA/RS232/PS2 plugs (only plugs...logic would go into the FPGA) and 1MB SRAM.

DASM is GPL'd so you may do anything with it that doesn't violate the GPL. In your case this boils basically down to the following: * Your DASM port to Aros must the GPL'd too * If you distribute binaries, you must distribute the source code to build these binaries too (not necessarily together in one archive with the binaries) (*) * You only need to distribute those sources that are needed to build the binaries you're distributing - no need to ship DOS or MAC or whatnot executables or sources specific to those platforms with your Aros port. If anybody wishes to incorporate your Aros port back into some other DASM package, he can always do so. Because you must release the sources of your port. But you cannot be held responsible for doing that work yourself. Now, Aros is not GPL'd, but (anybody correct me if I'm wrong) that shouldn't really matter, even if the Aros license wasn't compatible with the GPL - you're not mixing Aros and DASM code, after all, right? (*) Btw, vice versa this isn't true: If you distribute GPL'd software in source form only, you don't need to distribute binaries.

Out of curiosity, what are you guys using to write Channel F software now? dasm with F8 support or f8tool or what?

No. Not more than software that was assembled using DASM or any other random development tool should be marked. Of course, it's up to the tools' author(s) to put whatever in ther licenses they want.