mzxrules

Not much I wanna say at the moment, other than I've been picking up the pace on development and focusing on getting core gameplay things completed. I'd like to show more soon, but there's a lot I want to fix up first.

yea. one way to compromise would be to break down the game into multiple views. You could have one view that only renders 2 stacks per frame that you can scroll between the stacks left and right, and another view for rendering the deck, top cards, and fountain cards. I think it'd be pretty doable, just end up being like 8 or 16K

doing some quick math, the game state for klondike could be stored in about 86 bytes, leaving 42 bytes left over for other things 52 bytes to shuffle the deck. We can use this memory to not just store the deck, but also the cards dealt to each stack such that e.g. index 0-23 is the shuffled deck, 24 is stack 1, 25-26 is stack 2 etc. 1 byte for the deck cursor. The deck has a maximum 24 cards, so this would be 5 bits. 3 bytes for the hidden card cursor for stacks 2-7. Since hidden card stack length caps at 7 cards, only 3 bits are needed to store state, so you could store 2 stacks in one byte. 2 bytes for the 4 suit foundations. Since they increment sequentially, you only need 4 bits to store each suit. 28 bytes to store each of the 7 stacks. For each stack, 1 byte will store the top card, 1 byte will store the stack length, and 2 bytes will store the "run" pattern as a series of up to 12 bits. Since cards can only be stacked in an alternating black and red sequence in descending card value order, only 1 bit is needed to determine a card's suit (i.e. determine if a red card is a diamond or heart, black card is spade or club).

Zelda is 64K now

Still making progress. Not a whole lot gameplay wise, mostly just behind the scene stuff being rewritten/reorganized. But I'm at a point where I feel like I should be able to get a lot of content done soon. Hopefully I can get a "completed" level 1 soon.

From my perspective, if your intent is only to write your own code, 6502 assembly itself isn't super hard to learn. There are only 56 official opcodes to learn, and 2-3 unofficial ones with practical applications, and it doesn't take very long to read through the instruction list and get a base understanding of what the important ones do. From there you learn how to load/store memory, control flow, manipulate the program stack, add and subtract, and do comparison checks. Those things cover 95% of what you're going to do in ASM in one form or the other. Of those, comparisons are the most complex aspect of 6502 ASM simply because the hardware gives you so many different instructions to do different kinds of checks, both numerical and binary. Personally, I always have to look up how CMP (compare) instruction works because I never remember how to compare two numbers numerically in the way I need. The challenging thing in in my opinion is coding specifically for the Atari 2600 itself, learning what the hardware registers do from the Stella docs, and reading tutorials on guides on how to get the best out of the system.

it isn't strictly necessary to know python. I just personally find that once you know a bit of python, can be a very powerful tool for mangling data into different forms. The interleaved data problem can be solved in a few lines like so: #!/usr/bin/env python3 sample1 = [ 0b0001, 0b0011, 0b0101, 0b1101, ] sample2 = [ 0b0010, 0b0100, 0b0110, 0b1000, ] interleaved = zip(sample1, sample2) for s1, s2 in interleaved: print(f'.byte %{s1:08b}, %{s2:08b}') with open(f'interleave_samples.asm', 'w') as file: file.write('interleave_samples_label:') for s1, s2 in interleaved: file.write(f'.byte %{s1:08b}, %{s2:08b}')

I personally use the Python 3 programming language. This way I can store data in a sane format and write a script that converts it into whatever format is most optimal for my needs. For example, all of my NPC dialogs are stored right here in a very simple, straightforward python structure, very easy to modify unless you want to use the letter J. In my final output, the data for every message is split across 4 rom banks. Each character is converted into offset location of that character's left or right sprite sheets, where each sheet crams in 43 different 5 byte character sprites into 128 bytes using a "superstring" algorithm to pack them in.

The first reason your program crashes because you haven't set up the vector table that tells the 6502 where to start execution. The vector table starts at memory address $FFFA. $FFFA/$FFFB stores the NMI pointer $FFFC/$FFFD stores the RESET pointer $FFFE/$FFFF stores the IRQ/BRK pointer Easiest way to fix this is to just set all three pointers like so, with "ENTRY" being changed to the label you want to jump to as your program start. ORG $FFFA .WORD ENTRY ; NMI .WORD ENTRY ; RESET .WORD ENTRY ; IRQ/BRK If you want to make a smaller rom, I believe ORG $F3FA works for 1K roms and ORG $F7FA works for 2k roms bc of address mirroring. When that's resolved, the program will stop screeching at you, but will not draw anything meaningful for a number of reasons, the biggest of which being your misunderstanding of what is necessary for draw things to the screen. I highly recommend reading and re-reading spiceware's Atari 2600 Let's Make A Game! to understand why your code won't work.

Been thinking about implementing this one for far too long, so I decided to just do it today.

Still plugging away at it slowly. Flute actually sounds like the flute now. Next big milestone I'm working towards is getting enemy missiles and the shield functional.

I'm not sure how feasible this would be but I personally feel like a lot of my problems on this front would be solved if the assembler allowed mapping symbols to a 32 bit address space, instead of being limited to a 16-bit addresses and having everything overlapping one another.

I've beaten SMB numerous times. With the A+Start trick you can eventually brute force your way to the final level, though personally I find it much easier to complete if you go into 8-1 with a fire flower. The bigger issue I have playing it now is that the movement mechanics are simply less refined when compared to Mario Maker 2 or Super Mario Bros. 35

Each room is 8 bytes of data, so the overworld, dungeons 1-6 and dungeons 7-9 are 3 banks of 0x400 bytes. This does not include sprite data or the logic needed to unpack the level data. Using extra ram to store playfield data is essential to the approach I use... it's not just for making the environment destructible, it's also to allow the walls using the same base sprite have different patterns, leading to more complex and interesting rooms on the overworld.

The problem was two things; the game is designed for a genesis controller so the hud kept constantly opening, which was easy to fix. The other thing is that I think this bit of code is the problem: https://github.com/DirtyHairy/UnoCart-2600/blob/master/source/STM32firmware/Atari2600Cart/src/cartridge_3ep.c#L21 The rom built by everyone else isn't an even 32 KB, there's a couple of bytes extra to it, so the number of banks is undercounted, and you end up swapping in bank 0 instead of the last bank. I've hastily made an updated build for the ZeroPage stream that addresses this and hastily adds some new things. There's a chance it might run out of cycles in some cases, I didn't do extensive testing but I think I avoided it for now. zelda.bin zelda_PAL60.bin