Tom

shouldn't that be *updatable* microcodes ? afaik it's common for cisc cpu's to have their more complex instructions (multiplication/divison etc) implemented with microcode. but usually there wasn't way to *change* those codes.

http://www.6502.org in particular, have a look at http://www.6502.org/tutorials

BIT is the only logical instruction that affects the V flag: It copies bit 6 of the operand to the V flag. Ok, depends on wether one sees BIT as a logical op or not. I do.

just for the fun of it i wrote a version of the damage bar with the RESMP0 method i described above. saved one scanline. now on to the sixchar version. dmgbar2.zip

so you might want to wait with integrating that code in the game. i have started with a sixchar approach before i completed this code, but it's not yet finished. with a sixchar routine it will be more difficult to calculate the data to be displayed from an energy value between 0 and 48, but it could be done pretty fast with a lookup table containing 48 entries for each of the six characters. so this would need 6*48 = 288 bytes of tables + another 6 bytes for each scanline for graphics data (if i use the same sixchar kernel for the bar as for the status display i'll have to repeat the graphics data for the damage bar for each scanline...) but it's probably ways faster, so if rom isn't a problem, i'll try this approach too.

i guess i could get rid of one scanline of setup time by using a triple copy player + its missile...with RESMP0 i could attach the missile to the player and have to call PosObject only once. after the call to PosObject i'd do a wsync/hmove, which positions the player and the missile, and then i'd need another wsync/hmove to move the missile where it actually belongs => 4 wsyncs instead of 5. but then the damage bar is limited to 48 pixels, but since that's what it was intended to be in the original design i don't think this is a problem. gotta try this out somewhen =)

ah yes...the yellow area above the bar shows the amount of time needed to set up everything for the bar.

hello. i've been busy a bit with other stuff lately (among other things i built an f6 eprom cart / eprom simulator adapter for the 2600, learnt 7800 coding and created rfk7800). anyway, here's some first damage bar code. i didn't do it with a sixchar kernel, i found a different way (not necessarily a better one, though): the background is used to draw the red part of the damage bar. P0 and P1 (quad sized) form the green part of the bar and are moved to the left the more the ship is damaged, thus revealing the red background. a reflected black playfield with priority over the players is used to mask out the players as they move to the left out of the damage bar. this approach needs quite some cpu time to set things up (two objects need to be positioned), and perhaps we might be better off with a conventional sixchar kernel. this way the player setup also needs to be done only once where the damage bar is over the torpedo display. but there are two nice things about this method: - while the bar is actually being drawn, the cpu is totally free for other things. - the bar can be up to 64 pixels wide. dmgbar2.zip

kirk: no, i just looked at this because a) happy_dude brought it up and i was bored b) i'd like to have a native win32 build of distella, because i hate it when you're working on the windows console (having long pathnames displayed in the prompt) and then you start a dos application and after that the path names are screwed up with that stupid ~ notation about ++/-- operators: while they can greatly obfuscate code, mixing them with all kinds of other statements often won't give you any performance gain. a good compiler will generate exactly the same machine code from the following three bits of code: strcpy(file,*++argv); argv++; strcpy(file, *argv); ++argv; strcpy(file, *argv);

i found the bug (sort of, haven't fixed it yet). the problem is in the code that parses the command line (starts around line 127) it doesn't have anything do do with command line stuff differences between linux and dos, it's rather that dos can't detect memory violations (how should it, being a bloody real mode operating system). and by a perverse chance the bug doesn't make the dos version crash while (--argc > 1 && (*++argv)[0] == '-') while (c = *++argv[0]) switch(c) { case 'a': aflag = 0; break; case 'c': cflag = 1; i=0; while (*++argv[0] != '') config[i++] = *argv[0]; config[i]=*argv[0]--; fprintf(stderr,"Using %s config filen",config); break; case 'd': dflag = 0; break; case 'o': oflag = *++argv[0]; switch (oflag) { case '1': strcpy(orgmnc," ORG "); break; case '2': strcpy(orgmnc," *="); break; case '3': strcpy(orgmnc," .OR "); break; default: fprintf(stderr,"Illegal org type %cn",oflag); break; } break; case 'p': pflag = 1; break; case 's': sflag = 1; break; case 'i': intflag = 1; break; case 'r': rflag = 1; break; case 'f': fflag = 1; break; case '7': a78flag = 1; break; case 'b': bflag = 1; break; case 'k': kflag = 1; break; default: fprintf(stderr,"DiStella: illegal option %cn",c); exit(1); } strcpy(file,*++argv); if (argc != 1) { fprintf(stderr,"DiStella v3.00 - February 8, 2003n"); fprintf(stderr,"nUse: DiStella [options] filen"); fprintf(stderr," options:n"); fprintf(stderr," -7 Use Atari 7800 MARIA equates and file sizesn"); fprintf(stderr," -a Turns 'A' off in accumulator instructionsn"); fprintf(stderr," -c Defines optional config file to use. (e.g. -cpacman.cfg)n"); fprintf(stderr," (see distella.txt for additional information)n"); fprintf(stderr," -d Disables automatic code determinationn"); fprintf(stderr," -f Forces correct address lengthn"); fprintf(stderr," -i Process DMA interrupt Vector (7800 mode)n"); fprintf(stderr," If 2600 mode, enables -b optionn"); fprintf(stderr," -b Process BRK interrupt Vector (2600 and 7800 mode)n"); fprintf(stderr," -k Enable POKEY equates (7800 mode only, auto-detected if a78 file)n"); fprintf(stderr," -o# ORG variation: # = 1- ORG $XXXX 2- *=$XXXX 3- .OR $XXXXn"); fprintf(stderr," -p Insert psuedo-mnemonic 'processor 6502'n"); fprintf(stderr," -r Relocate calls out of address rangen"); fprintf(stderr," -s Cycle countn"); fprintf(stderr,"n Example: DiStella -pafs pacman.bin > pacman.sn"); fprintf(stderr," Example: DiStella -paf7ikscball.cfg ballblaz.bin > ballblaz.asmn"); fprintf(stderr,"n Email: [email protected] or [email protected]"); fprintf(stderr," Version 3.0 updates, email [email protected]"); exit(0); } while (--argc > 1 && (*++argv)[0] == '-') argc is decremented first (prefix --). if the command line was empty (in this case argc was 1) argc is now zero, and the loop terminates. argv isn't touched, because of short circuit evaluation: as soon as the first expression is false, the && expression can never be true, and the argv stuff isn't executed. fine. so the loop exits, and continues with the strcpy() after the loop: strcpy(file,*++argv); here, argv is first incremented (prefix --), then dereferenced and the resulting value is passed to strcpy() which tries to read from that location. i debugged it under win32, where *argv (after argv is incremented) is 0, so strcpy tries to read from 0x00000000 => boom, segmentation fault. dos has no way to detect that, and strcpy will happily copy garbage to file, until it encounters a terminating zero. file is a character array on the stack, so strcpy might be screwing up main's stack frame, but apparently this doesn't lead to a crash because after that (and a few fprintf calls) exit() is called. it's also possible that strcpy stumbles over a terminating zero before it stomps over the end of file. who knows =) i'd say the bug can be fixed by moving the strcpy call after the if statement that terminates the program. edit: it would fix that particular bug, but you're still relying on the user not to enter a filename longer than 49 characters (file is defined as "char file[50]"). blah. neat how you can shoot yourself in the foot with c, isn't it ? (and yes, the distella code is butt ugly:)

nah, return values are passed through registers in c, on compilers for 80x86 architecture usually in al/ax/eax. now if you don't have a return statement in a function that should have one and your function terminates, the caller will get as return value whatever garbage was in eax when the function terminated. this is certainly not the reason why distella coredumps, because in the case of the main() function the return value isn't really important (eh...sort of=). when main() terminates, it will return to the startup/cleanup code of the c runtime library which called main() (main is actually not the real program entry point for the operating system, it's just the entry point from a c programmer's point of view). the runtime library in turn doesn't care about that return value neither, it simply passes it to the operating system which doesn't care about it neither. (the user or parent process that spawned the program might care about it, though). anyway, in any case, not returning a value in a function that is declared to return one is of course an error and one should set the error level of a compiler strict enough so that it treats this as an error, rather than only printing a warning. this reminds me, i should find out to do that for cc65 aswell...

on my pal jr. the image occasionally jumps and then quickly stabilizes again. i can't tell exactly when it happens, though.

Of course you can. Btw: read the whole text here: http://www.pbm.com/~lindahl/real.programmers.html

yes. usually these turn out to be the most embarassing errors, like this one (not a coding problem, though): last night i was working on a self-made f16 cartridge (put it together on a breadboard). well. that beast simply didn't want to work. i checked all the connections, checked my schematic i'd drawn, everything was correct. so finally i thought that one of the parts must be defect. so i removed an inverter, looked at it a bit more close and...hmm...7474...huh ?...errr...that's not an inverter, that's a d-flipflop

thanks for that link

hello i noticed that people are coding their a78 headers by hand into their 7800 roms. isn't there a tool that can do that ? i myself are currently using some ruby script to add the a78 headers. if there's interest i could polish it a bit (so that it gets more user friendly) and release it...

i regularly play missile command, river raid II bored me to death. i actually don't care about rarity =)

uh. it will be simpler for me to list the carts i *have*. - missile command - lock n chase - grand prix - summer games yep, i own exactly four carts =) oh, i also had river raid II, but i slaughtered that one to build an adapter for an eprom simulator.

no, of course not. shadowing means that certain parts (be it ram or hardware registers) appear at several places in the address space, due to incomplete address decoding. so writing for instance to 0x30 has the same effect as writing to 0x00 (both locations are the VSYNC register).

for instance like this: (anyway, at some point things like this get tedious and one might want to do some awk wizardry to extract that information from the listing file. or modify dasm to output a list of all segments with their location and size) processor 6502 USEDRAM set 0 seg.u commondata org $80 var1 ds 3 COMMONDATA_END = . USEDRAM set . seg.u bank0data org COMMONDATA_END foo ds 3 if USEDRAM < . USEDRAM set . endif seg.u bank1data org COMMONDATA_END bar ds 1 if USEDRAM < . USEDRAM set . endif seg code org $f000 reset sei sta.w 0 brk .echo "ROM used:", .-reset, "bytes" .echo "RAM used:", USEDRAM-$80, "bytes" org $fffa .word reset .word reset .word reset

No, that doesn't make a difference (as far as i can tell). You see, right at the beginning the game launches the 6532 timer, and as soon as you start the first game it takes the timer's value and seeds the generator with it. Since a human isn't able to hit the joystick button always at exactly the same time (the timer runs so fast...), you get a different seed each time (out of 256 possible seeds). To make sure the user doesn't press fire before he powers up the console the input code always waits until the fire key is released and pressed again. I use this technique on the GBA all the time. So, to sum it up, you don't have to burn an EPROM =) thanks for testing !

raindog: i'm also responsible for a gp32 version =) http://members.vantage.ch/killer/rfkgp32.html mitch: sorry for asking again: the rng itself works fine, i know that, but is it seeded so that everytime you *boot* up the console and start a game the objects are distributed differently ? also, even with mess 0.8 i can't see the garbage at the bottom of the screen (i can see it with the PAL emulator, but i think this is normal, since the display list list contains only enough scanlines for an NTSC TV). well, perhaps we have to wait until i can get my hands on the code again and publish it, so that eric can have a look at it =)

eric: it's written in cc65. after all, that whole project started out as a linker configuration file and startup code for cc65. i didn't bother to compile a library, i just link to the c64 library. that's ok, since all the different libraries contain the same code. as long as you don't attempt to do any platform dependent stuff like file i/o, which would pull in c64 specific stuff, this is ok. i might make a separate library anyway, so that you don't have to worry about not calling any c64 specific functions. this wouldn't be a lot of work, basically i just have to add a new target to the library makefile that calls ar65 and includes only the platform independent object files. i will release the source code soon, but i wanted to clean up the makefile a bit and in the meantime my pc crashed on me (fortunately i do have a backup of the latest version), so i have to fix that first. some notes about the linker script/startup code: unlike for other platforms i've written code for with c (gba/gp32) i find it hard to write such stuff for the atari 7800 that will work fine for anyone. on the atari 7800 you have some constraints where and how you have to place your gfx data. this is tedious to do in c, assembler works better there. one might perhaps want to introduce another read only data section where all gfx data is placed, and only put data into that section using ca65. or so. one might also want to adjust the data/bss/heap/stack stuff. in this setup i use the lower 2112 bytes for data/bss, the middle 64 bytes aren't used at all and the upper 1.5k are for the parameter stack, and there's no heap.

oh well, perhaps i should try v 0.8 too...i've been messing around with v 0.78. thanks for testing, mitch.

you mean, you can't move up ? neither in the menu nor during the game ? can you take a picture of this ? does this occur always or only when you're moving around or so ? when testing it on mess i noticed that my code to seed the random number generator doesn't work. i don't know wether it's my code that's broken or mess. if you replay the game on a real 7800 (you have to switch the unit on and off), does the game display always the same objects ?