Sohl

@Stephena: I started working on a new 2600 game recently. I'm not too far along in development, but I am having an issue in Stella 6.4 with the disassembly view that is making debugging difficult. The disassembly seems to stop fairly early in the code, then just shows the raw bytes (see below). If I re-arrange my code, I can see different parts disassembled to about the same point. I don't think my code is all that unusual. I started with an early step of a Darrell Spice tutorial and have been replacing parts of it to have a more fancy score and status area. Do you have any ideas what could cause this and what I should do to get a full disassembly so I step through my code more effectively? I tried the right-click "Disassemble @ current line" command, but it does not do anything. I don't see any errors on the main console or the System Log. The last statement to disassemble in my current build is at address $F08D: Thanks for any suggestions! -- Mike

I have the Taiwan-built Heavy Sixer that my family received at Christmas 1980. My mother still had it up to this year, but she passed away quite recently and my two younger brothers were OK for me to take and keep it. It's in great shape and I finally got the proper RF-to-coax connector to test it today. It seems to be working perfectly well, along with most of the controllers. Some of the many joysticks we had assembled are not working very well at this point (probably cracked switch plunger or maybe the contacts are worn or corroded). Serial Number T 0037469. Channel selection switch on the bottom (quite hard to reach, I must say).

Congratulations Matt on the positive coverage in the ZeroPage Homebrew Twitch show! I did create a fork and pull request in Github for the macro idea above if you care to use it.

Matt: I did some quick experiments and found that my code will not work as I suggested earlier. My indirection through at table clobbers the X register value, which you are keeping for a longer scope than I realized. To fix this, I'd need to use a zero-page byte or something, which likely ruins the advantage I thought it would have. To help me in the experiment, I did find an opportunity to define another macro to organize your source code: ; Assume A is cleared by prior code ; and X has terrain offset .macro SET_RABBIT_HOLE_PF_GRAPHICS sta PF2_R lda level1_terrain,x sec ror rol PF2_R sec ror sta PF1 sta PF1_R rol PF2_R lda PF2_R sta PF2 .endmacro This can then be used in the multiple places you prep the PF graphics, including after each use of LEVEL1_LOOP_INC_OFFSET and other places too.

In 2016 I went back to grad school and took some engineering courses. At the time, I tried the Xilinx FPGA suite in Linux but it was not working, so switched over to Windows. Later I did one class with Octave instead of Matlab and it worked fairly well (a few small changes needed in syntax and functions). For another class I just got Windows Matlab because the student license was really cheap and there was some existing code from the professor that I didn't want to worry about porting to Octave. I started a personal project for the FPGA but have not gotten very far with it.

I hope everyone here in the United States had a good Thanksgiving holiday! I think that carry flag bug bit me too in my first (and only so far) homebrew's early code! I will see if I can tune into the ZPH Twitch steam tonight! Matt: Sure, the +32 trick requires favorable alignment by design or luck. It's could be an easy win, but I didn't notice that it's in a less time-sensitive part of the code. The terrain PF pixel table I suggested does take some ROM (18 bytes or more if the shapes are expanded), but remember you are calling the current code sequence something like 8 times. If my version sequence is shorter machine code, the net effect could be positive. I can check. Yeah, I did dig in a bit since I like your project idea and have been meaning to get back into some 2600 and/or C64 coding for fun through the holidays this year. I have some ideas for my own games but this is a good opportunity to "warm up". But these are very personal kinds of projects, so if my code style or other ideas don't fit or work for you, I will totally understand. If I try the table idea and it seems to work, I can try to make a branch as you suggest in Github. Not sure if it will be worthwhile! Maybe the cake sprite line duplication is a slight timing issue. If the PF graphics setup work is taking too long sometimes, could it be impacting the player 1 sprite update? Maybe I will switch back to Linux for 2600 work soon if not right away! I've used Linux a lot for professional work in the last 15 years. I have no love for Windows, but I had been doing some other work in Matlab and I also started to dabble in some FPGA stuff in the Xilinx tools, and generally both of those work better in Windows. ?

I was able to build the current version (Release 0.1) in Windows with cl65. Just for fun, I tried to make more round-looking cakes in the rabbit hole (2nd level). However, I noticed a slight distortion of the cake sprite, where either the last line is not visible, or last line is duplicated as the 2nd-to-last line. I'm not sure why there are two versions of the sprite data in the .asm source code file, one vertically-flipped compared to the other, but I modified the bits for both versions. In the image below, I have copied parts of two screen caps to show the two distorted versions I see. In the yellow box is the intended shape (blown up bigger). Not sure if I'm uncovering an issue that is hard to notice or introduced an error somehow. ? -- Mike L. Is the current cake supposed to be a "petit fours" type?

Hi Matt. I loaded up the .bin in my copy of Stella (v 6.4) on Windows. I do find level 2 tricky with the cursor-key joystick. Maybe I'd do better with a physical joystick. When I load Alice I see initially weird player sprites for Alice and the White Rabbit. I will try to attach a screenshot. After I move Alice to the area below the first potion bottle, she appears normal. I've been starting to look at the code for level 2 (alic_bank1.asm) and the corresponding parts of the alice.ods worksheets. I only understand only some of the code, but I have two suggestions for consideration so far. First, the bit of code after the label "@movement_set" has code to add 32 to the data address conditionally to index the proper version of sprite data. If the sprite data is aligned where its address has a 6th bit as zero, the +32 operation is equivalent to just setting the 6th bit to a one, so a single OR operation should do it. That could save a few bytes and cycles. Second, for the rabbit hole playfield graphics, you have 8 different levels of intrusion from the left that have a complementary amount of space on the right that you take care of by inverting the PF bits before the 2nd field bits are needed, which is a great example of "racing the beam". However, I think the initial setup of the playfield data in the RAM variables could be optimized. Since there are only 8 levels of intrusion, you can have a compact table of the the bitmaps for both PF1 and PF2 (16 bytes). The shape of the hole can then be a series of even-numbered offsets into this table, where the first (even) byte is PF1 data and the second (odd) byte is the PF2 data. So maybe the bit of code you have as Lda #0 sta PF2_R lda terrain,x sec ror rol PF2_R sec ror sta PF1_R rol PF2_R rol PF2_R could be something like ldx OFFSET ; where along hole lda level1_terrain, x ; shape (lateral displacement) of hole at this point tax ; now look up PF bits for this shape lda hole_shape_pfbits, X ; get PF1 bits sta PF1_R inx lda hole_shape_pfbits, X ; get PF2 bits sta PF2_R If Y register is free to use, it could help with one of the indexes and avoid the "TAX". ? The "hole_shape_pfbits" table would look like part of your worksheet: hole_shape_pfbits: .byte $C0, $0, .byte $E0, $0, .byte $F0, $0, .byte $F8, $0, .byte $FC, $0, .byte $FE, $0, .byte $FF, $0, .byte $FF, $01, .byte $FF, $03, (Actually I'm not sure if ca65 allows doubling up like this, but you get the idea). So the terrain_table would need to be adjusted to have the offsets into the hole_shape_pfbits data: level1_terrain: .byte 8 .byte 8 .byte 6 .byte 4 .byte 4 .byte 6 .byte 6 .byte 8 .byte 10 .byte 10 .byte 12 .byte 14 ... (etc.) ... I've not tried to alter and build your code like this, but if you'd like me to try it out and report back, I will give it a shot! It think the table approach could be more flexible if you'd want to try to split the hole as I mentioned on YT or add some more variation, at the cost of a longer table perhaps. Hope you find this helpful! I am currently working in Windows, but I'm pretty sure I used Linux five years ago when I made my VCS 2600 version of the sliding puzzle game "2048". -- Mike L.

Hey Matt! Michael Losh from YouTube here. Glad you joined! There's a lot of great homebrew devs and fans in these forums.

That’s a great-looking title screen!

Oh, I belived you before, but I'm not sure how that happened yet! It's really hard to reproduce. Could be a subtle timing bug in my game reset code. Or if you are running on an emulator, perhaps you bumped the mouse/touchpad at the same time you hit reset? If that is the reason, I suppose I could ignore the joystick input for the first second after a reset or something.

I have cleaned up the assembler source code, and maybe fixed a small issue during the "win" effect when you get a 2048 or higher tile. Here are the assembler and binary files. The wording for the best score screen is formed with playfield graphics I compile with a special tool I wrote in C, and the file extension I use (.pfg - "play field graphics") for the input file is not allowed here, so I will just post the output .inc file. I will probably post the source code for the play field assembler in another thread someday. The input .pfg file looks like this: # Playfield Graphics source file for 2048 game bestscore screen ; Label for best score revplayfield BestLabelGraphics ; label above the best score seen so far ; graphical content goes here ; pfad = playfield asysmetric, duplicated order # Guideline # "-123456789-123456789-123456789-123456789" pfad " XXX XXXX XXX XXXXX " ; pfad " X X x X X " ; pfad " X X x X X " ; pfad " XXX XXX XX X " ; pfad " X X X X X " ; pfad " X X X X X " ; pfad " XXX XXXX XXX X " ; pfad " " ; playfield-end revplayfield LastLabelGraphics ; label above the last game's score # graphical content goes here # Guideline # "-123456789-123456789-123456789-123456789" pfad " X XX XXX XXXXX " ; pfad " X X X X X " ; pfad " X X X X X " ; pfad " X XXXX XX X " ; pfad " X X X X X " ; pfad " X X X X X " ; pfad " XXXX X X XXX X " ; pfad " " ; playfield-end revplayfield AgainLabelGraphics ; A bit of encouragement! # graphical content goes here # Guideline # "-123456789-123456789-123456789-123456789" pfad "XXX XXX X X XX XX XX X X X XX " ; pfad " X X X X X X X X X X X X XX X X X" ; pfad " X X X X X X X X X X X XX X X" ; pfad " X XXX X XXXX X XX XXXX X X XX X " ; pfad " X XX X X X X X X X X X XX X " ; pfad " X X X X X X X X X X X X X " ; pfad " X X X X X X XX X X X X X X " ; pfad " " ; playfield-end playfield RestartBar ; pfm = playfield, mirrored # "-123456789-123456789-123456789-123456789" pfm " " ; 0 pfm " XX" ; 1 pfm " XXXX" ; 2 pfm " XXXXXX" ; 3 pfm " XXXXXXXX" ; 4 pfm " XXXXXXXXXX" ; 5 pfm " XXXXXXXXXXX" ; 6 pfm " XXXXXXXXXXXX" ; 7 pfm " XXXXXXXXXXXXX" ; 8 pfm " XXXXXXXXXXXXXX" ; 9 pfm " XXXXXXXXXXXXXXX" ; 10 pfm " XXXXXXXXXXXXXXXX" ; 11 pfm " XXXXXXXXXXXXXXXXX" ; 12 pfm " XXXXXXXXXXXXXXXXXX" ; 13 pfm " XXXXXXXXXXXXXXXXXXX" ; 14 pfm "XXXXXXXXXXXXXXXXXXXX" ; 15 playfield-end I'm releasing 2048_4vcs for non-commercial private/educational rights usage. I hope you enjoy it and can perhaps learn something useful from it, as I have learned from the many examples posted here in AtariAge. In the unlikely event someone wants to package and sell this as a cartridge or something, please contact me to work something out. In the event you have code suggesions, please reply here and I can try to learn from you! -- Mike 2048_4vcs_beta4.asm 2048_4vcs_beta4.bin 2048_bestscore.inc

@Arenafoot: Thanks, glad to hear that!

Thanks for the suggestions Thomas. I have a lot of conditional logic in both the code that checks to see which of the four move directions is allowed as well as the code that moves/merges tiles during a move. Depending on the occupation of grid spacing, some of this logic has "early out" and runs faster. Unfortunately, the worse case for these is too long. I think I can further break up the logic over more video frames. Tedius, but should still play fairly well.

OK, "Beta 3" (http://atariage.com/forums/topic/237836-my-first-homebrew-2048-4vcs/?p=3230881) has the VSYNC control modified based on Omegamatrix's first sample code above. I still have some timing overruns when the game logic gets busy (usually when the grid is at least moderately full and a new move is processed), but there has not been any "easy" fixes for that so far. I may need to refactor my code a bit more to spread out the processing related to each move.

Thanks to Omegamatrix's help in my programming question thread, I have updated the VSYNC/VBLANK code to hopefully provide a more stable VSYNC signal. It can still sometimes miss the VSYNC timing when it gets too busy and generate an extra scan line or two, but until I can figure out a way to prevent that, you can work with this copy, "Beta 3". (Hmm, maybe I should not have started "Beta 1" as a beta release...) 2048_4vcs_beta3.bin

@Arenafoot: I think I have seen the tripple starting tiles happen at least once too. Perhaps a timing issue reading the switches. Thanks for reporting. I will see if I can prevent in a future release.

@Chesterbr: That sounds like a really useful tip. I can already see where I'm violating that scanline limit. In my version, I wanted tiles relatively big and square to look close to Gabriele's web/mobile app version. I was mostly done developing the main playscreen kernel before I looked in detail at Thomas Jentzsch's Three.s kernel, but it seems like I arrived at a similar method. SvOlli's youtube presentation on the 48-bit sprite and some associated posts here at AtaruAge on that topic provided a real breakthrough for me. I've tried to make the color of the numbers on each tile vary in the same way as Gabriele;s web/mobile app (2 and 4 are black on a light background, all higher number tiles white on a more colorful background), but have not managed to figure out a way to update the player graphics, player colors, and playfield (tile) colors every scan line... maybe its possible alternating "window blind" style or something, or using special cart accelerator features, but I wanted to see what I could do with an ordinary 4K cart. In the end I just made the 2 and 4 tile number bitmap "thicker" to look darker, and to my eyes seems to give a similar visual appearance to the "real" version. Yes, I'll get my source cleaned up a bit and posted soon, hopefully within a week or so.

@RevEng, @Omegamatrix: Thanks, you've given me some good stuff to consider and try out!

Here is an updated binary (Beta 2), that should at least fix the garbled title screen issue with Omegamatrix's suggestion. It also defers updating the score display right after a move, which could help the bad jitter after some moves. I don' think it will help the main jitter issue reported by accousticguitar. I have a request for debugging advice in the main programming subforum (http://atariage.com/forums/topic/237892-advice-to-debug-jitter/) to help me sort that out. 2048_4vcs_beta2.bin

Hello 2600 programmers! I hope you can offer some advice. Over in the homebrew subforum, I posted my debut game: http://atariage.com/forums/topic/237836-my-first-homebrew-2048-4vcs/. User "accousticguitar" loaded my .bin into a cart and tried it on a real console, and reports significant jitter of the main play screen. I don't have a real console currently, and test and debug with Stella and z26. z26 reports consitent 262 scan line screens. Stella reports consistent 19912 CPU cycles per screen each time I do +Frame in the debugger. So the report of jitter puzzles me. Do any of you have advice on how I might debug this? Especially using Stella? Is there some other timing check I can make that would help me zero in on this problem? Thanks if you can help! Here is a copy of the current "Beta 2" version of my game if any of you would like to poke around yourself with a debugger. 2048_4vcs_beta2.bin

@Omegamatrix: Oh, OK, that makes sense. Rookie mistake! Will fix. @accousticguitar: Thanks for clarifying. I will look into figuring out the cause.

@Arenafoot: Yes, when I run Stella, I often see that kind of garbled appearance at the start too, but other runs I don't. I have no idea why. On z26, I never see that. I wonder if anyone else has some idea why that happens. Is that on Windows? I'm running z26 and Stella on Xubuntu Linux. @accousticguitar: Hmmm. I was hoping that if I make sure to output 262 lines and have it stable on both Stella and z26, it would work on a real console. I suppose I could try to generate a few fewer or more lines and see if that helps. Or is the jitter only in one part of the screen, such as the score, or the tile numbers, or the tile positions? I just might have to get a real 2600 console again.

@accousticguitar: Thanks for trying it out. It works! (sorta) Just to be clear, is it jittering all the time in that play screen (when you don't touch the joystick), or just when you make a slide movement?

Hey Chester, I discovered your version of 2048 just as I was starting to make my own version. After several weeks, I've gotten my version pretty well ready for outside testing, so I've gone public here: http://atariage.com/forums/topic/237836-my-first-homebrew-2048-4vcs/. Thanks for your impressive version of 2048. It inspired me to see how I could do it a bit differently. I also liked your programming overview presentation slides. Best of luck in future projects! -- Mike