vidak

I think it is an amazing technical feat, but the gameplay is waaaay too hard - I feel like I wanna hack it in order to make it more playable. I think someone above in the thread said someone already has...

Could you include some cycle counting in your code? I think you may be running into timing issues, like tokumaru says...

Personally I don't see the point of multiple cores because I love 80s single core technology so much :'D

You should check out the Spectre and Meltdown vulnerabilities in all the Intel CPUs since 2006 - hardware and CPUs are just as vulnerable to security exploits as software. The way Intel CPUs have been botched in their construction allows you to hack them at a very low level and get complete control of them. I agree about clock speeds. The way forward is RISC. We have many cores but very little industry effort put into parallel processing. Anyway this is getting off topic isn't it... My fault! Personally I think the PC metaphor is terrible, and the Microsoft/Intel/Apple monopoly is ruining everything hahahab

I was born in 1991 - my dad had always used Intel and IBM together. He had an IBM PC with a 8088. Personally I find the x86 Intel platform ugly and unparsimonious. The design philosophies of the Ataris and the Amigas were much more beautiful. The reason why we have enormous critical failure points and security weaknesses in Intel CPUs goes right back to the design concepts Intel used in the 70s. I wish the 68000 had become the ancestor of our CPU hardware because it was a very beautiful design. I have always hated PCs despite their fame and wide use. The reason they are widely used is not because they're any better but because the effort of training yourself to use a different system is too high. Microsoft and Apple both rely on the affective familiarity people have with their systems. Personally, I would like to see more hardware diversity, less monopoly, and more cooperation.

OKAY FIXED. What I am uploading here is the final version for this stage of the game's development! What I still need to do is: - Create a network of screens for Che to move through. - Create the logic for the movement through this world: (i.e. when Che moves off the left side of the screen, he appears on the right side of the next screen to the left of that screen) - Create movement routines for the peasants and the batista soldiers, maybe simple AI to this effect - Create graphics for the peasants and the soldiers - Create graphics for the jungle environment - Perhaps add more tasks for the kernel, seeing as I am only using 43-44 cycles for the entire kernel. This is only 58% of the maximum cycles needed for the kernel. So I think I may add in playfield graphics. THEN - Create the kernel and logic for the "Lock and Load" portion of the game, after I have completed the above portion of the game, the Overwold portion. Guerrilla32_bin_FINAL.zip coloured_guerrilla032.asm

Okay I have completely fixed up all the pointers - I am basically finished with this stage of development. The only thing I have to figure out now is why the vertical controls are reversed. I think I can figure this out pretty quickly. guerrilla31_bin.zip coloured_guerrilla031.asm

OKAY. It turns out I was decrementing the scanline counter AFTER I was loading the next line of graphics, and not before, when I should have! The colours of GRP0 are no longer shearing!! guerilla30_bin.zip coloured_guerrilla030.asm

Okay I have rejigged the kernel. It is now a lot faster, even though it doesn't allow GRP1 to touch the left side of the screen. The whole kernel takes 41 cycles now, instead of 53 cycles. I am loading the colour table for GRP1 synchronously with the graphics, and this fixes the indexing issues for the colour of GRP1. PROBLEM ONE IS SOLVED. Here is another improvement: now the colour table for GRP0 is CONSISTENTLY off by one line. This means there must be a static indexing issue. To the Stella Debugger to see what the problem is! coloured_guerrilla029.asm

Okay changing the temporary enemy graphics colour table from this: BatistaSoldierClr ds 15, $00 .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE <- 23 bytes of $FE To this: BatistaSoldierClr ds 14, $00 .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE .byte $FE <- 24 bytes of $FE Fixes the issue. Which leads me to believe that I am right about COLUP1 being written to out of sync. So instead of doing this in the kernel: .KernelLoop sta WSYNC lda CheGfxTemp sta GRP0 lda EnvGfxTemp sta GRP1 <kernel code> ... sta COLUP1 ... dec SCANLINE_COUNTER bne .KernelLoop I think I will have to do this: .KernelLoop sta WSYNC lda CheGfxTemp sta GRP0 lda EnvGfxTemp sta GRP1 lda EnvClrTemp sta COLUP1 <kernel code> ... sta EnvClrTemp ... dec SCANLINE_COUNTER bne .KernelLoop I think this will fix the sync issue, at the cost of a less efficient kernel. coloured_guerrilla028.asm

Alright it's the weekend here in Sydney, so I have time to work on the game! I will do a live-update debugging for anyone who is interested. I find this method of debugging is the best for me because I can track EXACTLY what I did after every compile. I have fixed the colouring problem of the enemy characters by manually copying over the graphics pointers from EnvGfxPtr and EnvClrPtr: lda EnvGfxPtr sta EnvGfxPtr+2 sta EnvGfxPtr+4 sta EnvGfxPtr+6 sta EnvGfxPtr+8 lda EnvGfxPtr+1 sta EnvGfxPtr+3 sta EnvGfxPtr+5 sta EnvGfxPtr+7 sta EnvGfxPtr+9 lda EnvClrPtr sta EnvClrPtr+2 sta EnvClrPtr+4 sta EnvClrPtr+6 sta EnvClrPtr+8 lda EnvClrPtr+1 sta EnvClrPtr+3 sta EnvClrPtr+5 sta EnvClrPtr+7 sta EnvClrPtr+9 I can identify two problems: Number One The colour of Che seems to shear on the right side of the screen. The graphics shape of GRP0 is correct, but the graphics seem to be applied one line BEFORE they're supposed to on the right side of the screen. I will use the Stella Debugger to have a look at this. Number Two This is very confusing. The last line of the GRP1 graphics loads properly, but seems to have the colour $00 applied to it, instead of $FE, like it is supposed to. I checked the Stella debugger, and the colour that is being loaded is definitely $FE, which is bright yellow, but it seems to show up as black. This is very confusing. My best guess for why this is happening is that I am setting COLUP1 earlier on in the kernel before i WSYNC lower down in the kernel, and then I am drawing GRP1 right after the WSYNC at the top of the kernel. I thought these two TIA register writes were in sync, but maybe the colour for GRP1 is being written again after I have drawn it. As always, if there are any people reading this before I update again, feel free to jump in and give your opinions. coloured_guerrilla027.asm guerilla27 bin.zip

It looks amazing. You are 100x the programmer I am.

Ahhhh okay

I had a similar problem! I think it's -v2 and not -v5 See Kirk Israel's beginner Atari 2600 programming guide.

Thank you so much for making the software and games free <3

I think I may dabble a bit in batari BASIC, because of this! If you need some help debugging, I'm here!

Looks amazing! I'm really jealous!

Very nice!

I'm not sure if you can pin posts to the front of your blog on AtariAge, but that could be one way to share your collection. Making your own spreadsheets is fun! I do know people do it, and it can function sometimes like a "wishlist".

I like homebrew clones and ports having different names...

I would heartily recommend Anguna!

What an awesome story