Tom
-
Content Count
446 -
Joined
-
Last visited
Posts posted by 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
-
- Have a red colored 48 pixel wide playfield block centered in the middle of the screen and have it overlayed with a green six-char display.For the start you should probably best research about 6 char displays in the [stella] archives. We'll probably also need one for the title screen, so understanding this technique is very essential. (Hm... actually, the title Screen might probably look way more impressive using the PF... let's think about this...)
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 =)
-
Because the location $80 is relative to the bank your in. (taking a guess here
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.
-
I agree that on 650x (or any other 8 bit CPU) words are 16 bits. But, the same cannot be said if you are talking about the x86...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.
-
I wondered how Surrond would have looked if Allen would have used the ball and PF to animate the snake. It would have made for smoother movements.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)
-
This would give you some advantage for jumping over larger gaps or reaching higher platforms, but you'd have to hurry, because that advantage is reduced with every bounce.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 ?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
robotfindskitten 7800
in Atari 7800
Posted
cpuwiz suggested that i post this in the 7800 forum aswell, so here we go
http://www.atariage.com/forums/viewtopic.php?t=46375