Tom

hello here's some preview of robotfindskitten for the 7800 =) this is the ntsc version, a pal version is underway. does anybody have the possibility to test this on real hardware ? [edit: use the latest version from from http://sourceforge.net/project/showfiles.p...ckage_id=152194] cheers thomas

yes, that's the basic approach i chose. the problem is i end up getting a red line (from the playfield) above the actual damage bar, which i can't get rid of. here's how i do it: - set up pointers and sprites positions,size etc for the damage bar - set the playfield data for the red background - wait until PF2 isn't displayed anmore - set the PF color to red - jump to sixchar routine the problem is that one of the first things the sixchar routine i'm using (it's the stock sixchar routine i found in the atari 7800 devkit) is a WSYNC. before that it does some initialization stuff, and the WSYNC happens just right AFTER the start of the next scanline, so i get a scanline with just the red area, before the sixchar routine actually kicks in and draws the green area. hope that makes sense =) perhaps i could rework the routine so that the PF color is set inside the kernel. first i tried to do a generic sixchar routine that can be used for the damage bar and the torpedo display and the title screen, but it might be better (or at least simpler) to use an adapted version for the damage bar: since every line of the damage bar is the same, the usual lda (gfxptr),y instructions could be changed to something like lda gfxptr which would free up way enough cycles to set the PF color inside the kernel. it would probably free up so many cycles that one could change the sprite color too and have some nice color gradient in y direction on the damage bar =)

nah, the ram is always at 0x80, no matter which bank is switched in.

cool. i've toyed around a bit with a damage bar, but it's far from being any good yet. something else: we're doing f8 bank switching, and the adresses that trigger the bankswitches are 1ff8/1ff9. so why do you reserve 4 bytes from 1ff6-1ff9 ? as a reserve in case we run out of rom space, so that we can change to a 16k game ? and again something else: SEG.U vars ORG $80 ; Both Banks: gameState ds 1 bcdScore ds 1 frameCounter ds 1 rnd ds 1 tempVar1 ds 1 tempVar2 ds 1 tempVar3 ds 1 tempVar4 ... SEG.U variables ORG $80 ; Both Banks: gameState ds 1 bcdScore ds 1 frameCounter ds 1 rnd ds 1 tempVar1 ds 1 tempVar2 ds 1 tempVar3 ds 1 tempVar4 so this are variables that are needed by both banks. but why do you duplicate them in the source code ? imo this shouldn't be necessary, i mean, the ram doesn't have to do anything with bankswitching, that is, it's always there, no matter which bank is switched in... wouldn't something like this be better (since no code is duplicated) ? ; variables for both banks seg.u commondata org $80 gameState ds 1 bcdScore ds 1 frameCounter ds 1 rnd ds 1 tempVar1 ds 1 tempVar2 ds 1 tempVar3 ds 1 tempVar4 COMMONDATA_END = . ; variables for bank 0 seg.u bank0data ORG COMMONDATA_END ; define variables for bank0 here ; variables for bank 1 seg.u bank1data ORG COMMONDATA_END ; define variables for bank1 here as you can see, the segment commondata starts at 0x80. then we have two segments, bank0data and bank1data. those start both at COMMONDATA_END (right after commondata), and they share the same address space, so it's actually an overlay. that's btw the mechanism i use in my own 2600 coding experiments to create overlays. so far it has always worked fine for me =) probably you can't have it more convenient with dasm, but with ca65/ld65 you could of course write yourself a neat linker script and let the linker sort it out for you. (note that i'm NOT suggesting to switch to ca65, i just said it could be even more convenient)

cybergoth: sounds good to me

well, i think i give it a try. at least for learning purposes or whacking together prototype code it's certainly neat to have a c compiler.

hello just wondering, has anybody ever thought (or even tried) about using cc65 to write atari 7800 software ? tom

hello i startet 2600 coding last year. i had some own ideas for games, but i simply don't have the time right now to code a whole game by myself. i'd, however, have the time to do for instance #5 =) tom

hello can anybody explain me what the 2600's TIMINT register (address 0x285) does ?

your trying to cram your whole program into the ram. change SEG variables ; Program into something like SEG code org $f000 ; Program after this it displays something that might be a ship, but it's still buggy. your timing is totally screwed up, run it with z26 with the -n switch and you'll see.

to make the confusion complete: actually on the x86 16 bits are called a word aswell, even on the newer cpus that have 32 bit registers. for arm cpu's, a word is 32 bits, and 16 bits are called a halfword. sorry, couldn't resist =)

rodnay zak's books certainly are bibles =) i don't know the 6502 book, but the z80 books are great.

that's one of the things i have in mind with it =)

i've been thinking about doing some simple snake/nibble/however you want to call it game. nothing is done yet, i just thought about how i would do it and wether it would be possible.

the new physics are quite cool. now i always try to jump from high platforms down to low platforms to get higher jumps, which can save you bounces =) btw, when i said the game was hard to play i meant the version 0.96 (the one that was running always at hardest level)

Yes, this might be a good idea, the new version became somewhat hard to play, higher jumps would make it a bit more playable. Yet it wouldn't make the game too easy if you lose height the longer you bounce around.

...so here's something i've done after reading andrew's tutorials. it's unfinished, and i've uploaded only the pal version for now. http://members.vantage.ch/killer/files/dopeclock.bin cheers tom

EricBall: yeah, that cleared everything up, thanks

one thing i don't really understand is how you get all the vertical timing stuff *correct*: according to the stella manual, you do it like this: - generate 3 lines of vsync, by setting VSYNC to 2 for the duration of 3 scanlines - generate 37 lines of vblank, by setting VBLANK to 2 for the duration of 37 lines - draw your image (192 or 242 lines) - 30 lines of overscan what confuses me is the vblank stuff: in the tutorials, VBLANK is set to 01000001b during overscan, vsync and vblank period. so what's correct now ? or doesn't it matter at all ? and why is bit 6 of VBLANK set ?