Jump to content

mzxrules

New Members
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

35 Excellent

About mzxrules

  • Rank
    Combat Commando

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Still plugging away at this. It took me way too long to figure out how to add in random item drops, but once I had a plan, coding it wasn't too bad. One thing I haven't figured out is why the audio seems to cut out randomly.
  2. It's quite a bit outside the scope of what you really need to know about Atari 2600 programming, but hardware interrupts are a mechanism in pretty much all programmable CPUs that makes it possible for a CPU to respond to events external to itself in a timely fashion. It gives a CPU the means to handle more than one task at once, and is part of how threading is implemented at the low level. To respond to events quickly, hardware is designed to allow code execution to be halted immediately at an arbitrary point, and jump to a different subroutine in such that the CPU is able to return where it left off later and continue execution. There are two core interrupt types, Maskable and Non-Maskable. Maskable interrupts are interrupts that can be temporarily ignored by the CPU. This allows the CPU to finish up a system critical task like modifying a variable that different threads need to access. Non-Maskable interrupts are interrupts that can't be ignored by the CPU, like the system being turned on, a reset button being pressed, or a critical hardware fault. Lastly, the Interrupt Vector table is a hardwired table that lets you assign a different handler for each type of interrupt supported by the CPU.
  3. Progress has been a bit slow. Been just doing minor refactoring and tweaked my world kernel so that ball sprites can be drawn on grid: I've also been trying to implement different enemies. I've got two more enemy types mostly implemented: Wallmasters and Like Likes (both rather annoying to deal with). I've also got Octoroks walking around, but haven't implemented their attack yet. I've also implemented dying: One thing that's kind of got me struggling is figuring out how best code enemies to maximize code reusability, while also being able to tweak minor stuff like health/enemy color.
  4. I'm definitely not doing it manually, that's for sure. But for my project, I'm using Python 3 instead of DASM to generate the final data that will be included in the rom. It offers me so much more flexibility with regards to how I manage my game's data than DASM does. The first one is rather clever. I can't use it in my own game though because I use the extra bits not used by the index to store other data. For the second one, I already have it written as tax/txa in my own code, but you do bring up a good point; I hadn't realized that pha/pla take more cycles than tax/txa, presumably because pha/pla require memory access.
  5. not sure if it counts as a killer hack, and maybe this has been thought of before but I'll post it anyway. My game is structured such that I have a world composed of 256 rooms, and then the playfield of each room is composed of up to 64 page-aligned 8x16 sprites, which comes out to 4 pages of sprite data. Instead of storing an index from 0-63 in the world data, and then multiply it later by 16 to build the 2 byte room sprite pointer, I swap the first 4 least significant bits with the 4 most significant bits and store that in my world data. For example, let's say my sprite data is at F000, and say I want to store an index to sprite 0x2D, which is located at F2D0. If I store the index as 0xD2 instead, then I can generate the room sprite pointer without needing 2 byte multiplication: ldx roomId lda roomSpriteIdx, x pha and #$F0 ; a is now lower half of the pointer sta roomSprPtrL pla and #$0F clc ; These two lines can also just be adc #$F0 ; ora #$F0 sta roomSprPtrH
  6. i split up my main asm file (it was 2.7k lines) and it's helped me get out of my funk:
  7. A short story: A few years back I was browsing r/speedrun when I stumbled on the Dragster drama. Someone looked at the assembly of Dragster and created a sim in an attempt to figure out if a certain someone's world record time was actually achievable. Having done quite a bit reverse engineering of Ocarina of Time, and dabbled for a day or so reversing The Legend of Zelda for the NES to figure out the heart container glitch, I figured I'd might try my own hand at it despite never having played an Atari game in my life before. Though I never got too far into understanding the code, I was amazed at how you can print the entire game on only a few pages of paper, and finally understood how it was possible to do animated sprites with so little ram. Fast forward to this year. I'd just replayed The Legend of Zelda on the switch (both quests of course), and I got it in my head that I wanted to make an Atari 2600 port. So here's how far I've gotten: The game is written in 6502 assembly. To create the sprites I use a GCS program called MegaZeux, which has a pretty nice built-in 1 bit sprite editor. I also coded my world editor in MegaZeux, using it's "robotic" language. "Robotic" can be fairly esoteric at times, but it's the first programming language I ever learned and it was the easiest thing I could think of to use without rolling my own rendering code. I also use Python 3 for data manipulation purposes. For example, in order to save rom space I use a superstring algorithm to pack the sprite data for the text kernel tighter. Additionally, the music sequence data is completely generated by Python, so that I could write music using proper notes instead of numbers. I can't say for sure that I will continue working on it, as I hit a bit of a wall and decided to switch gears to a different thing I'm working on. But I don't think I'll stop working on it for good just yet.
  8. By splitting the string into two strings, and alternating which string i initialize: ; Print A to X text__example1 .byte __A, __B, __E, __F, __I, __J, __M, __N, __Q, __R, __U, __V text__example2 .byte __C, __D, __G, __H, __K, __L, __O, __P, __S, __T, __W, __X text24_modified.asm
  9. I think I figured out a way to eliminate StartFrame1Text and reduce the ram requirements of text24.asm The only difference that I see between ____frame0_text and StartFrame1Text aside from the alternating Text indices is that ____frame0_text has a sleep 4, while StartFrame1Text has a sleep 6 To fix this, I use the overflow flag along with this macro to alternate between a 4 and 6 cycle delay: MACRO VSLEEP bvs .j0 .j0 bvs .j1 .j1 ENDM
×
×
  • Create New...