-
Content Count
2,097 -
Joined
-
Last visited
Posts posted by Zach
-
-
Thanks Kirk, it's always nice to hear from established homebrewers (gods or not). I took a quick look at Armor Ambush, and it's an impressive kernel. It appears the terrain is drawn with a clever combination of reflected and transposed playfields instead of complete asymmetry. Yes, there might be some changes to the PF on the fly, but I don't think the Armor Ambush kernel could draw something like this:
-
Remember when the playfields in Combat were limited to symmetrical 40x24 mazes? Thanks to Thomas' Skipdraw, you will soon be able to make an asymmetrical playfield with maximum resolution!
Have you ever seen a 2600 game with two sprites, two missiles, and an asymmetrical playfield in the same scanline? I didn't think it was possible until I learned about Skipdraw. This new version of Combat has a completely redesigned kernel.
The attached binary is still preliminary work. There are issues to work out, most importantly why it won't run on hardware. But I think you'll agree, it looks great in an emulator.
EDIT: May 24 binary attached, where a simple syntax error was fixed.
-
Of course Homestar Runner has numerous Atari 2600 references, but this time it was Marble Craze that made an cameo in Strong Bad's latest email.
http://www.homestarrunner.com/sbemail130.html
:D -
I know it's a long shot, but I hope that Infogrammes made a deal with with Howard Scott Warshaw about his Yars' Revenge sequel.
As for the licensed titles:
a couple of licensed titles (Nope, don't ask, not telling you which ones)I have a hunch they will be Midway games, like Joust and Defender.
-
Switchdraw might work. It's worth a try.

-
Thanks, vdub_bobby. Unfortunately, I'm not convinced that there is time for Skipdraw in this kernel. In particular, the line where the green blocks are drawn requires many color changes. In that line, I use the following:
ldy santa_current_line ;3 iny ;2 ldx santagrp,Y ;4 stx GRP0 ;3
It only takes 12 cycles to update GRP0 on that line. The new value of santa_current_line is saved on the next line. If I counted correctly, Skipdraw takes 17 cycles when the branch is not taken.
-
So by using (ind),Y you mean that Y will represent the current scanline as counted from the bottom? And ind will point to an address within the 256 bytes of sprite graphics? In this case, Would'nt there be a problem with sometimes crossing a page boundary, costing indeterminantly 5 or 6 cycles?
Here is how Santa's sprite data looks now:
ORG $FC00 santagrp .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00 .byte #%00000110 .byte #%00011100 .byte #%01111110 .byte #%01111110 .byte #%01111110 .byte #%01111110 .byte #%01010110 .byte #%01111110 .byte #%01000110 .byte #%01111100 .byte #%00111100 .byte #%01111110 .byte #%01111111 .byte #%01101101 .byte #%11111101 .byte #%11101100 .byte #%01111100 .byte #%01111100 .byte #%00101000 .byte #%01101000 .byte #%00001100 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 .byte $00,$00,$00,$00,$00,$00,$00,$00,$00
-
My method for drawing sprites is a little unorthodox. The data for each sprite consists of an entire 256 byte page filled mostly with zeros. That way, I don't have to determine where to draw the sprite - just draw it on every line. The idea was inspired by an email by Manuel a couple months ago where he explained the fastest way he knew to draw a missile.
Although you stated that this kernel would probably be impossible, Thomas, I'm sure you could have solved the problem in half the time it took me. I'll be wildly impressed if you can squeeze in a missile or something.

Here is the code for the first row.
;----------------------------------------- ; Loop starts on cycle 69 with Y set to santa_current_line ; and A set to 0. loop ldx santagrp,Y ;73 stx GRP0 ;76 ldx santacolu,Y ;4 ; First line updates the pun'kin stx COLUP0 ;7 sta PF0 ;10 sta COLUBK ;13 ldx #%11110000 ;15 stx PF1 ;18 stx PF2 ;21 ldx platformcolor1 ;24 stx COLUPF ;27 ldx jack_current_line ;30 lda jackgrp,x ;34 ldx.w platformcolor2 ;38 stx COLUPF ;41 inc jack_current_line ;46 sta GRP1 ;49 lda #0 ;51 sta PF1 ;54 sta PF2 ;57 iny ;59 sty santa_current_line;62 ldx santagrp,Y ;66 stx GRP0 ;69 ldx santacolu,Y ;73 stx COLUP0 ;76 ldx #%11110111 ;2 ; Second line draws the green blocks stx PF1 ;5 ldx #%00001110 ;7 stx PF2 ;10 sta COLUBK ;13 ldx platformcolor1 ;16 SLEEP 3 ;19 stx COLUPF ;22 ldy #$c3 ;24 ;Green ldx #%00010000 ;26 stx PF0 ;29 ldx #%10001000 ;31 sty COLUPF ;34 stx.w PF1 ;38 ldx platformcolor2 ;41 stx COLUBK ;44 sta COLUPF ;47 sty COLUBK ;50 ldx #$ff ;52 stx PF2 ;55 ldy santa_current_line;58 iny ;60 dec counter ;65 bne loop ;69 assume branch crosses a page boundary ;---------------------------------------
-
I made some recent progress. The sprites are moving now, and the background consists of the row shown previously, plus the row below it (stretched out, of course).
I've got two sprites in the kernel, but the timing is so tight, there is no room for any missiles or balls or anything else. The question will be whether a fun game can be made with just the background and two sprites.
-
I voted for other, as in Shenmue.
-
Golden Axe. It's fun watching your enemies run off a cliff.

-
That's cool. I had just put down April 18, 2004 because I did have a birthday on that date. (Fun with Semantics!)
-
So are the vectrex and gameboy not video game systems?Interesting topic for a debate. I just checked the The American Heritage College Dictionary, third edition.
video adj. 1. Of or related to television, esp. televised images. 2. Of or relating to videotaped productions or videotape equipment and technologyvideo game n. An electronic or computerized game played by manipulating images on a display screenSo this source indicates that the Vectrex et al. are not video technology, but they are video game systems. I do recognize however that this book is not the ultimate authority.
-
New colors have been on my to do list if I were ever to update Combat Redux. One suggestion I have is not to throw away the original colors. Instead put them in the black and white palette so the user can switch to original colors if desired.
-
Thanks Rasty! If anyone else wants to wish me a happy birthday, let's take it to the Gen. Chat forum or PM. I don't want to hijack Lord Helmet's thread (any more than I already have.) Again Rasty, I appreciate your post!
-
Nice presents, and happy birthday! Is it today? We have something in common then.

-
I like your idea, Lord Thag! I'll think about it more when I'm ready to work on Go again.
-
Great work! If you print a screenshot with an "atari", I may just have to update my atari avatar with it!I was wondering if I'd hear from you, 128 bytes! Here's your screenshot.
As for Bruce's comments, I know it will be difficult, but I won't say it's impossible without trying. I'll most likely do a simpler board game first. At the moment, I'm interested in Go-Moku, a.k.a Pente.
BTW, did I mention there is no flickering in the kernel?
-
Thanks, TJ. I think I've got something that can draw sprites. I'll have to see if I can get them moving. The beauty of Retrofan's playfield design is that every other scanline has fewer color changes, so there is time for other tasks.
;;same code as before lda #%11110111 sta PF1 lda #%00001110 sta PF2 lda #$00 sta COLUBK ldx #$3a ldy #$c3 SLEEP 4 stx COLUPF lda #%00010000 sta PF0 sty COLUPF lda #%10001000 sta PF1 lda #$00 stx COLUBK sta COLUPF sty COLUBK lda #$ff sta PF2 ;; new code for drawing sprites ldy santa_current_line lda santagrp,Y sta GRP0 lda santacolu,Y sta COLUP0 stx WSYNC lda #%11110000 sta PF1 sta PF2 lda #0 sta PF0 sta COLUBK stx COLUPF iny lda santagrp,Y sta GRP0 lda santacolu,Y sta COLUP0 iny sty santa_current_line ldy jack_current_line lda #0 sta PF1 sta PF2 lda jackgrp,Y sta GRP1 inc jack_current_line stx WSYNC
-
Just found this thread last night. Couldn't resist the challenge. I picked a scanline from the Santa mock-up that looked like a worst-case scenario.lda #%11110111;2 sta PF1 ;5 lda #%00001110;7 sta PF2 ;10 lda #$00 ;12 sta COLUBK ;15; make background black ldx #$3a ;17; orange ldy #$c3 ;20; green SLEEP 4 ;24 stx COLUPF ;27; make PF orange lda #%00010000 sta PF0 sty COLUPF lda #%10001000 sta PF1 lda #$00 stx COLUBK sta COLUPF sty COLUBK lda #$ff sta PF2 stx WSYNC
-
I'm jealous.

-
So how did you make Trotter's keychain look broken? Maybe it really is?
-
The Ninja Garden title screen looks doable. Not simple, but doable.

-
Just to be clear, what I meant by unreliable was things like driving over packages with forklifts. I understand your point of view Al. I too waited for 3 weeks to receive packages when I lived in Vancouver.


All-Terrain Combat
in Atari 2600 Hacks
Posted
@Bob, yeah Combat uses a two line kernel, if you are referring to the fact the the graphics for each tank are updated on alternate scanlines. When I try to run the binary on a K Cart, I just get a black screen. Sometimes I see the playfield for a split second before the screen goes black. I'll post the code soon to see if anyone has an idea of what's going on. If not, I'll just do a brute force commenting out of code.
@Stan, once it is finished, I think it will fit into the database just fine. We all appreciate the work you put into maintaining the list.