kenfused

The graphics routines are in the OS so I really don't why Graphics 11 wouldn't work if Graphics 8 works. Error 135 also seems like a really weird error to get from a Graphics call. Does graphics 8 work? Are you running Action from a cartridge? in a emulator?

It's very important what the last 6 bytes of the cartridge are set to. Is the generated binary 16384 bytes? RAM should probably start at $600 but if you don't use any routines that use the floating point routines you might be ok on that. --Ken

Yes, if the code is going in a 16K cartridge it would start at $8000. Run address will be somewhere in the cartrridge space (it could be $8000 if the code starts with the first byte). I have used the assembler/linker for cc65 more than the c compiler. I think it probably sets some symbol to point where code execution should start. --Ken

if you are trying to make a cartridge you only want to write the ROM to the file and you want the size of the file to end up being 16384. You do not want the file header on a cartridge. You want to make a 6 byte segment at the end of the rom (so 16378 bytes for code, a 6 byte segment for vectors/flags) Be sure to set the option on the code part of the ROM to pad (you always want it to be 16378 bytes) BFFA,B Run Address BFFC set to zero. BFFD Option byte. Cart type normal/diag and if cassette or disk boots are allowed BFFE,F Cartridge initialization address. Can just point to a RTS or you can point this to the run address Option byte info from mapping the atari: If BIT 0 equals one, then boot the disk (else there is no disk boot). If BIT 2 equals one, then initialize and start the cartridge (else initialize but do not start). If BIT 7 equals one, then the cartridge is a diagnostic cartridge which will take control, but not initialize the OS (else non-diagnostic cartridge). Diagnostic cartridges were used by Atari in the development of the system and are not available to the public. Diag cart option can be useful to prevent the blue screen flash when reset is pressed, but you have to initialize the whole system yourself.

Are you trying to make an executable or a cartridge image?

16K RAM runs from $0000 to $3FFF (with some of the low RAM being used by the system) on both the 5200 and 400/800 and 600XL The $2000 start for the 8-bit computers is allowing room for most DOS's so the program can load in RAM from DOS (not an issue for a cartridge where the start can be much lower $600 or lower, non dos boot disk could start around $700). ROM on the 5200 can run from $4000-$BFFF for a 32K cart (16K can be $8000-$BFFF or on older carts with 8K chips may be split $6000-$7FFF/$A000-$BFFF) ROM on the computers can run from $8000-$BFFF for a 16K cart or $A000-$BFFF for a 16K cart. The end address being $A000 is probably more than likely to allow for OS supplied graphics modes on a 48K machine. You will use around 1K for a text screen or close to 8K for a hi res graphics screen. With the 5200 ( and for anything needing speed on the computers) you will more than likely build your own display list and graphics routines.

Technically a 7800 trackback should have extra circuitry (I am sure this one probably does not): http://www.atarimuse...0/7800trakball/ This was to allow the the trackball itself to track the position some (I don't remember if it was a full 8bits or not) so it was not necessary to read the trakball in code so often. The 7800 centipede source code has some code to actually support a trackball scheme like this. I don't know if the released version has the code, and I don't know if the code in centipede works with this circuitry but might be something interesting to build and try sometime. One of the schematics at the Atari Museum link has patches that can be applied to one of the normal trakballs. To make the trakball version of centipede I had to add DLI's every couple lines to do the position counters in memory that kind of simulates the atari 7800 trakball so much of the existing code that handles the movement was then unchanged. --Ken

will it run with the run command afterwards? If I remember correctly, if it beeps and you don't see any errors, then it compiled ok.

try graphics(1+16) +16 = no text window at bottom +32 = no screen clear from previous +48 = both

You might also be able to declare it static within the function.

You are using nmemtop before you calculate it. --Ken

I have always used Virtual Box. I still use the same XP Pro disk image on windows 7 home premium i was using under Ubuntu before.

Memory coming back a little. I thought at one point I had found a page that gave the different randomizers used by different versions but I cannot find it now. Searching now I can't find anything definitive, but at least a couple hits seemed to say that Atari arcade and tengen NES are memoryless which I think means random. Note: IIRC one thing I did do (need to double check), is that in a two player game, both players get the same pieces in the same order which is true for the arcade (but have to check how that works in all cases since in the arcade the other player can join in at any time (but may have to wait for next level -- which I don't do yet). Never the less, I do think it would great to have options for other piece generation algorithms since they allow for some different strategies. Currently the scoring follows the atari arcade (or at least I attempted to make it do so following what I found on the internet) except I don't have the level clearing logic in there yet (and also I may have an option to not do the level clearing, random blocks, and other things the arcade does). Colors currently match the atari arcade version, spin/kick rules work like the atari arcade (or at least should be close I hope) The arcade also seems to maybe update POKEY more than once a frame. I am guessing a TIA mixer would need to do this too. I don't know if I would be able to update sounds more than once a frame because allowing all 20 rows of the playing areas to have a unique palette per block along with the other graphics pretty much has MARIA consuming most of the available cycles on the playfield lines.

Actually from what I have read on some pages and FAQs the randomizer depends on the version of the game. I don't remember if the arcade version this is based on just does random or if it was one of the other randomizer versions. (I know if can go quite a while before giving you a piece you want sometimes or give you many of the same pieces in a row) I may offer some options in randomizers in settings. I also hope to offer color and piece settings (squares vs. outline). At some point I hope to give it a proper title page with configurable options that it would start up in and go back too after both players are done playing. I may work on the highlighting to highlight each line in sequence and not all at once as I am doing now. Just doing it how I am now because it was easiest to implement. Things are a little complicated since the other player can be playing while lines are being cleared on one so almost everything requires using a state machine of sorts. The sound I want to be fairly close to the arcade but I am trying to do the effects with TIA leaving POKEY for music. The arcade had two POKEYS and used combined channels some so I don't know how feasible to port the music. I do have dumps of the POKEY register writes by timestamp I created with a slight hacked version of MAME for each of the tunes if someone wants to try and port them into something I can use. The arcade clock rate is pretty close to the 7800 normal clock rate. Thanks for your feedback.

DIM and clear another string before that one big enough that the second one will not exceed 32767. Or just DIM and clear a second string with what is left.

Added a couple sound effects. blocdrop20130310.zip

A minor update for this evening. Reworked button press logic and left/right logic. Haven't tested yet on a real console but now seems to work as originally intended in emulation. Holding button will rotate piece at a fixed rate but you can press and release to rotate at a desired rate. Same thing for moving left and right. blocdrop20130306.zip

You can always borrow the version of the tune from the Atari 7800 version but be sure to include ear plugs with the cartridge

Atari 7800 or Atari 2600 Donkey kong?

Where are they today?

The controllers with the original flashback (that looked like a small 7800) will NOT work on the 7800. They are closer in operation to NES controllers.

Oh duh, I didn't catch that.

Is this being run on 400/800 or XL/XE?

The most important thing will probably be adding some blank lines to the top and bottom. I don't remember and have access to the required number for ntsc and pal at the moment. Essentially u need to add some display list list entries the point to an empty display list entry (0,0). I am guessing more than likely maria is executing things at the end of the current list which can lead to garbage and wasting some clock time or even cause dli execution. Beyomd that the game may need some speed tweaks and possibly color adjustments.

Depending on how much data you need to save you could potentially use a savekey/atarvox to save data. I don't know about the availability of savekeys but they were probably cheap enough you could devote one to the game and maybe include it with the cart. Or if you are doing your own cart board, put a serial eeprom, eeprom, or nvram (as you mentioned) on the cart.