vidak

Hmm... then the bizarre oscillating that GRP0 is displaying must be because the horizontal movement register for GRP0 is not zero when I set the HMOVE for GRP1. That sounds like that would fix that problem. I will have to do some thinking about this. I do a HMOVE for GRP1 every band, but a HMOVE for GRP0 every FRAME. I suppose I better look at your Stay Frosty a bit more...

Okay! I figured out why I was not drawing enough lines. I was counting the cycles in the kernel for when both GRP1 and GRP0 were being drawn. When both are drawn on a scanline, the cycles add up to 76. When neither are drawn, the unconditional JMP back up to the top of the kernel was returning at cycle 40-46, which is waaaay too early. So I economised some code and forced a WSYNC at the start of each line. Now we're drawing 263 lines - much better. There are still problems: GRP0 doesn't move properly vertically OR horizontally. Every band of the screen GRP0 moves vertically it seems to shear left when moving up, and shear right when moving down. When moving horizontally, GRP0 seems to be "glued" between horizontal bands on the screen, and oscillates between them. My best guess as to why this is happening is that the HMOVE for GRP1 seems to be interfering with the HMOVE for GRP0. There are strange artifacts for GRP0 occuring on every band of the screen. *** If anyone would like to help debug, I would be very grateful! I like to post the work I finish at the end of the day here just anyone feels like they want to help out : ) guerrilla19 binary, lst and sym.zip coloured_guerrilla019.asm

I think it might have something to do with the fact this version is drawing WELL under the proper 262 scan line limit. I'm glad it seemed to compile okay for you! I will step through everything in the Stella debugger tomorrow. I recommend you get Stella 5!

Okay! I have prepared something which compiles. This version 18 does not draw 262 scanlines. It draws between 192 exactly and 197-198. I think it may have something to do with the offset of the pointers and the heights of the different sections of the bands of the kernel. Take a look if you feel like it, or don't! This source file definitely compiles, I just don't have enough effort today to completely debug it. I suppose I like to be really verbose on this thread to show I am working through the different problems as they crop up. *** Any debugging would be very appreciated. coloured_guerrilla018.asm

Oh! Thanks for noticing that. The code was never in a buildable state! I'm going to try and get it to a buildable state today... Anyway thanks so much for taking a look in any case!

Here is the updated kernel with the proper timing. The guts of the kernel are now so finely timed, I would need to completely rewrite it if I wanted to put something else in. the unconditional jump back to the top of the kernel now finishes exactly as a new scanline starts. coloured_guerrilla016.asm

I think I am moving into the final version of the kernel of the first part of the game! Please find the inline code for my current MACRO for a single band of the screen. This kernel allows each GRP1 to be independently positioned within each band of the screen. This will allow me to animate some of the GRP1s within their respective bands on the screen. I will have Cuban peasants, and Batista soldiers. I will also have non-animated graphics such as trees. The GRP1 graphics will have to be 3 scanlines shorter than the height of the band of the screen, due to timing constraints caused by the need to strobe HMOVEat the beginning of the first scanline. I am using Manuel Rotchkar's FlipDraw for this kernel, because it means I don't have to use a scanline counter for the graphics Y offset when I don't want to. FlipDraw is the slowest method for drawing graphics on any individual scanline, but it completely removes the need to juggle line counters, which makes it faster overall when you compare it to other drawing methods WITH line counters. I have counted the LDY instructions in the FlipDraw as 2 cycles, when they are in fact 3. I think I'm still within the goal posts, though - I'll fix up that counting issue later. (Actually I've just looked over this, there are a lot of counting issues... Could I fit the calculation for line 2 of GRP0's graphics in after HMP1?) Anyway it is my hope that this macro will enable me to draw as many as FIVE bands of multicoloured GRP1s down the screen. I am about to develop a 2LK for the "Lock and Load" part of the game, the second part, which will feature: 2 coloured sprites 1 missile a coloured asymmetrical playfield *** If someone would like to look over my work, I'd be very grateful. *** ;--------------------------------- ; ; KERNEL MACRO ; ;--------------------------------- MAC SCREEN_BANDS .BAND SET {1} ;================================= ; ; Preload GRP0 (Che) Graphics ; ;================================= lda #P0_HEIGHT ; 2 dcp Player0Offset ; 5 bcc .p0FlipPre0 ; 2 (3) ldy Player0Offset ; 2 lda (Player0Ptr),y ; 5 tax ; 3 lda (Player0Clr),y ; 5 tay ; 3 (27) .p0FlipPre0 ;(3 XX) ;( XX) - Longest way ;================================= ; Position GRP1 independently for ; each band of the screen. ; ; Accumulator holds X value. ;================================= .PositionGRP1 lda EnvObjectX+.BAND sec sta WSYNC ;----------------------------------------------------- ENTER FIRST SCANLINE stx GRP0 ; 3 3 sty COLUP0 ; 3 6 DivideLoop1 sbc #15 ; 2 8 bcs DivideLoop1 ; 2 10 eor #7 ; 2 12 asl ; 2 14 asl ; 2 16 asl ; 2 18 asl ; 2 20 sta RESP1 ; 2 23 <- set object position sta HMP1 ; 3 26 ; Could I fit the below second scanline precalculation here? sta WSYNC ;------------------------------------------------------ ENTER SECOND SCANLINE sta HMOVE ; 3 3 ;================================= ; We haven't had time to preload ; any graphics, so now we have to ; rush and try and make sure we have ; something to draw on this line ;================================= lda #P0_HEIGHT ; 2 5 dcp Player0Offset ; 5 10 bcc .p0FlipPre1 ; 2 12 (3 10) ldy Player0Offset ; 3 15 lda (Player0Ptr),y ; 5 20 sta GRP0 ; 3 23 lda (Player0Clr),y ; 5 28 sta COLUP0 ; 3 31 (28) <-- delayed. So we'll have to restrict ; Che's movement on the left of the ; screen? .p0FlipPre1 ;(3 10) ; (35) ;================================= ; Preload Che Graphics for THIRD ; scanline. ;================================= lda #P0_HEIGHT ; 2 37 dcp Player0Offset ; 5 42 bcc .p0FlipPre2 ; 2 44 (3 45) ldy Player0Offset ; 3 47 lda (Player0Ptr),y ; 5 52 sta CheGfxTemp ; 3 55 lda (Player0Clr),y ; 5 60 sta COLUP0 ; 3 63 (27) .p0FlipPre2 ;(3 45) ;( 63) - Longest way ; Load the scanline counter ldx Heights+.BAND ; 3 66 - This variable equals the band height - 2 ; Prime the NUSIZ1 register with the right copies/sizing data lda EnvCopies+.BAND ; 3 69 sta NUSIZ1 ; 3 72 ;================================= ; ; Start of the actual kernel ; ;================================= .KernelLoop sta WSYNC ; 3 75 ;----------------------------------------------------- ENTER THIRD SCANLINE ;================================= ; ; Draw Che Graphics in time for left-most ; side of the screen. ; ;================================= lda CheGfxTemp ; 3 3 sta GRP0 ; 3 6 lda EnvGfxTemp ; 3 9 sta GRP1 ; 3 12 ;================================= ; ; Decrement line counter, and ; branch out if we're at zero. ; ; Even though we're using FlipDraw, ; we still need a scanline counter ; to keep track of which section ; we're in. ; ;================================= dex ; 2 14 beq .EndKernel ; 2 16 (3 17) ;================================= ; ; Calculate Environment Graphics ; ;================================= lda EnvHeight+.BAND ; 3 19 dcp EnvGfxOffset+.BAND ; 5 24 bcc .p1FlipDraw ; 2 26 (3 27) ldy EnvGfxOffset+.BAND ; 2 28 lda (EnvGfxPtr+.BAND*2),y ; 5 33 sta EnvGfxTemp ; 3 36 lda (EnvClrPtr+.BAND*2),y ; 5 41 sta COLUP1 ; 3 44 (28) .p1FlipDraw ;(3 27) ;( 44) - Longest way ;================================= ; ; Calculate Che Graphics ; ;================================= lda #P0_HEIGHT ; 2 46 dcp Player0Offset ; 5 51 bcc .p0FlipDraw ; 2 53 (3 54) ldy Player0Offset ; 2 55 lda (Player0Ptr),y ; 5 60 sta CheGfxTemp ; 3 63 lda (Player0Clr),y ; 5 68 sta COLUP0 ; 3 71 (27) .p0FlipDraw ;(3 54) ;( 71) - Longest way ;================================= ; ; We branch out of the kernel at the ; beginning of the last scanline AT ; THE TOP. So if we are allowed to ; reach this part of the kernel, ; we unconditionally jump back to the ; top! ; ;================================= jmp .KernelLoop ; 3 74 ;================================= ; END OF THE KERNEL. ; Here we "fall into" the next band ; of the screen! ;================================= .EndKernel ; (3 17) ENDM coloured_guerrilla015.asm

Oh no, I flew 4000km, and then drove another 400km!

(I also use Arch linux, and I love it)

Just checking in here after a really exhausting 48 hours after arriving back in my home town of Perth, 4000km away from Sydney, where I live now. I think I can finally relax after driving 200km yesterday and then another 200km today. We were meant to be staying in Collie, 200km south of Perth, in the country. That's where my sister in law lives. It turns out their dogs hated my dog, and we couldn't stay there, so we had to drive another 3-4 hours back up to Perth. It was very stressful. Anyway I can get back to work on the Che Guevara game tomorrow. Just thought I'd check in, because I feel a great connection to this community.

Hmmm... I think it may be possible to repair it!

This is fantastic!!

The new Star Wars movie is amazing. It has inspired me so much. I felt like I was getting tired of programming, but seeing Luke Skywalker really picked me up and made me feel so energised. It is such a good movie. I enjoyed it IMMENSELY.

I am learning a lot by lurking on this thread B-)

I am moving onto the next phase of the development of the game. This phase of the development is writing a kernel which will draw multiple bands of GRP1 down the screen. Find inline below the code for one of the 5 kernels of the overall screen. I am using an approach to SpiceWare's Stay Frosty, except I am not using a mask to blank out the Player0 character on the lines it is not supposed to appear. I am using FlipDraw to prevent myself from having to juggle between two scanline counters. This way I can set the Y offset for GRP0, and it will draw somewhere throughout the 5 kernels as the kernels go about drawing the screen. Also, because the Y offsets for all the different GRP1 graphics are "local" (relative to the number of scanlines within their respective kernel), I do not need to adjust them relative to a global scanline counter. FlipDraw is the slowest method of drawing graphics down the screen, but for the fact that it does not need a scanline counter, which is what was pushing me over 76 cycles while I was using DoDraw. I will have to readjust how all the pointers are set, but I am lead to believe FlipDraw allows for much easier setting of pointers. Let me know if something doesn't seem right. ;--------------------------------- ; ; SECTION 4 KERNEL ; ;--------------------------------- ;================================= ; ; Preload GRP0 (Che) Graphics ; ;================================= Kernel4: lda #P0_HEIGHT ; 2 18 dcp Player0Offset ; 5 23 bcc .p0FlipPre ; 2 25 (3 26) ldy Player0Offset ; 2 27 lda (Player0Ptr),y ; 5 32 sta CheGfxTemp ; 3 35 lda (Player0Clr),y ; 5 40 sta COLUP0 ; 3 43 (27) .p0FlipPre ;(3 26) ;( 43) - Longest way ; We will not be showing Player1 on the first line of the section. lda #0 sta EnvGfxTemp ldx Heights+4 dex ;================================= ; ; Start of the actual kernel ; ;================================= .KernelLoop4 sta WSYNC ; 3 72 ;------------------------------------------------------------------ ;================================= ; ; Draw Che Graphics in time for left-most ; side of the screen. ; ;================================= lda CheGfxTemp ; 3 3 sta GRP0 ; 3 6 lda EnvGfxTemp ; 3 9 sta GRP1 ; 3 12 ;================================= ; ; Calculate Environment Graphics ; ;================================= lda EnvHeight4 ; 3 15 dcp EnvGfxOffset4 ; 5 20 bcc .p1FlipDraw ; 2 22 (3 23) ldy EnvGfxOffset4 ; 2 24 lda (EnvGfxPtr4),y ; 5 29 sta EnvGfxTemp ; 3 32 lda (EnvClrPtr4),y ; 5 37 sta COLUP1 ; 3 40 (28) .p1FlipDraw ;(3 23) ;( 40) - Longest way ;================================= ; ; Calculate Che Graphics ; ;================================= lda #P0_HEIGHT ; 2 42 dcp Player0Offset ; 5 47 bcc .p0FlipDraw ; 2 49 (3 50) ldy Player0Offset ; 2 51 lda (Player0Ptr),y ; 5 56 sta CheGfxTemp ; 3 59 lda (Player0Clr),y ; 5 64 sta COLUP0 ; 3 67 (27) .p0FlipDraw ;(3 50) ;( 67) - Longest way ;================================= ; Even though we're using FlipDraw, ; we still need a scanline counter ; to keep track of which section ; we're in. ;================================= dex ; 2 69 bne .KernelLoop4 ; 2 71 (3 72) coloured_guerrilla014.asm

Looks great!! I have been following the development!

Ahhhh, it's central to the story... I get it now.

Very impressive!!

I'm down to help set this up!

I don't know why they couldn't have just put an old 90s console...

I have almost finished reading and taking notes on the Stella Mailing List, I think I might be able to put some time into documenting down all the Atari homebrew games. Can't take more than a few months... right?

There's a bit of discussion about random number generation on the Stella Mailing List - check out my Commo Dig and ctrl+f the web page with the word "random"

I second the suggestion for the use of sockets - easy extraction of ICs can pay off big time in the long run.

I am in the process of making an Atari 2600 game. I have been given a lot of support and shown a lot of kindness, even at this very early stage. So I wanted to give back in a small way. In this blog post, I will make five arguments for why you, someone who has never done programming before, should get started in making homebrew games for the Atari 2600. This also applies to the 5200, and the 7800 -- and perhaps even to the Atari 8-bit home computers. Development is Easier Than It Has Ever Been You should get involved in making games for the 2600 because it is actually quite easy. Before 2005, you were forced to learn assembly language, the machine language of the Atari 2600 in order to make games. This is not the case anymore. There is now a high level language for programming 2600 games called batari BASIC, and it takes care of most of the difficult issues you will come across if you were forced to learn assembly. Many people who had never learned a computer language before picked up batari BASIC and made their own games. You can find many of these games in the Atariage store. BASIC is one of the simplest programming languages that exist. It is designed to teach beginners how to program. Don't let the simplicity of the language fool you, however. batari BASIC possesses a suite of very advanced features which many programmers back in the 70s and 80s would have paid a great deal of money to use. There also exist new kernels for batari BASIC that enable you to go beyond the limits of what the Atari 2600 can do alone. There exist the DPC+ kernel, which enhances the graphics of your games and allows you to make games which are more complex. A long-time member of this forum, Random Terrain, also keeps an enormous encyclopedia for both batari BASIC and assembly language which you can use and reference free of charge. This is an invaluable source of information for beginners and experienced programmers alike. It's Cheap to Get Started Another reason you should strongly consider starting to make homebrew Atari 2600 games is that it is very cheap to do so. Your entire development environment for making 2600 games is most likely to be composed of freeware. This means all the components you need in order to develop, test, and finish the software version your game can all be found for free. Take my development environment for instance. I use the standard 6502 assembler program that everyone else on Atariage uses: DASM. DASM is free to download. I use the powerful linux text editor Kate for all my coding. Kate is a part of linux, so it too is free. Kate is, by definition, "Free Software". Finally there is the 2600 emulator everyone on Atariage uses, Stella. Stella is donationware. This means you may download it for free, but the project survives on donations from users in order to stay active. Stella is an invaluable tool for testing and developing games because it has a "debugger" mode, which allows you to step through your code line by line and watch exactly what is being executed. That is the sum total of my development environment right now, and all of it was obtained free of charge. There is no need to "rent" the tools you need to develop 2600 games. You do not need to pay for any licences for software packages at all. There also exists the batari BASIC compiler, which will transform high level BASIC into binary ROMs Ataris and the Stella emulator can run. This is likewise also free. There is also an Integrated Development Environment program called Visual batari BASIC, which is a powerful tool for simplifying a great many repetitive tasks which crop up while developing Atari games. This is also free. However, it only runs on Windows. Aside from the actual tools you need to make Atari games, there is an entire encyclopedia of educational information all available free of charge online for your to peruse. All of this information on the internet will form the backbone of teaching you how to program for the Atari. Online there are: MOS 6502 assembly language tutorials on YouTube Many books teaching the fundamental concepts of BASIC on the AtariArchives The "live" development environment of 8bitworkshop.com Kirk Israel's Atari Programming 101 Andrew Davie's Atari Programming for Newbies (can be found in the forums and on Random Terrain's website) SpiceWare's Collect tutorial on his blog As mentioned above, Random Terrain's batari BASIC encyclopedia The History of 2600 Homebrew is Well Established People have been developing homebrew games for the Atari 2600 for a long time. Many people who developed new games for the Atari in the 1990s are still with us in the Atariage forums today. I'll leave it up to you to go and find out who they are! It won't be very difficult to complete such a task, because all you would have to do is read the Stella Mailing List. This mailing list is archived as far back as 1996. I have read and documented almost all of it. You can find my "Dig" of it on my blog. Many people developed homebrew games (some as complete beginners!) on the Stella Mailing List, resulting in titles such as Thrust!, Oystron, INV, Gunfight!, and so on. The Stella Mailing List is the bible of the homebrew community because it contains all of the solutions you will ever need to the biggest problems in coding for the Atari. Some of the biggest programming tricks in the community were developed during the years of the mailing list. Like the giant interleaved image trick, the 48 pixel sprite trick, a whole suite of sprite drawing routines (like FlipDraw, SkipDraw, SwitchDraw...), and multi-sprite tricks. 8-bitworkshop.com has transformed many of these tricks into programs which can be viewed "live" through its javascript interface. As I just described, there are well-established solutions to many of the biggest challenges for creating a 2600 game. Most of the time you will not need to come up with your own solutions for, say, the horizontal positioning of objects, because there is aleady an establised "community standard" for how to solve such a problem. Finally, there are a whole suite of disassemblies of famous original Atari games, as well as the source code to many of the most popular homebrew games. Learning to read through these disassemblies will teach you skills and ways of thinking which will improve your games. The Community is Large and Very Active The Atariage forums is very large and very active! You can always always ask for help when you are stuck on programming your game. I know I do, and someone usually always replies to a request for help within 24 hours. This is the best thing about learning to program Atari games. There are many many experienced people on the forum who dedicate their time to helping others finish their games. These truly are wonderful people, because they do it for absolutely nothing. It is for these people that I wanted to write this blog post and bring attention to the fact that the Atari homebrew community is so fantastic. There is no lack of people who are able to play test and debug your games! Simply posting the latest source code and binary to your games on a blog post or forum thread is enough to have someone potentially download your game and give you feedback. It's a wonderful feeling to have someone else check your work and appreciate it. You are also able to turn your finished games into real Atari cartridges which you can play on real Atari 2600s. They can even be sold through the Atariage store! If that isn't a goal worth striving for, I don't know what is!

I found this video to be really helpful in explaining exactly how to make cartridges for the 2600: It goes a bit beyond just the normal 4KB cartridge as well, it shows you how to change a 32 x 2KB multi-bank cartridge into a 16 x 4KB multi-bank cartridge.I am not sure what EEPROMs are compatible with the 2600 and the 2600 binaries. I'm pretty sure there is some information floating around here somewhere. I feel like your answer could be reached by doing some forum searching and some googling.