Sknarp

That feeling when... you've literally had the answer staring you in the face the whole time. who would have thought that previously commented out align 256 was what was meant to be there in the first place. In retrospect I should have realized it a lot sooner. Here is the kernel,with all the score vars freed up (score as well as scorepointers) It should indeed be leaner, but I'm in no way saying it's been made as small/fast as it possibly can. I believe there are some stubs of code in there that can still be stripped out without throwing off any timing. noscore_multisprite_kernel.asm

I can replace the quoted in the above post with to free up the scorepointers variables, but I feel like this is a really inefficient way of doing it. Could really use some ASM god to chime in here please.

It does free up the three score vars for whatever use you want, unfortunately it does not free up the 6 scorepointer vars because that's the one part I have yet to figure out (see below). As far as cycles are concerned, about 3-4k of asm is being completely removed, and while some of it was conditional (such as if const debug was set) a lot of it just always was executed. I replaced all of that with something like 3 WSYNCs over the course of the kernel, not entirely sure what the effect on cycle count would mean (should be faster?) Not sure how to measure it. All that remains of the score code (with my added comments, sorry if they aren't 100% accurate) if someone can figure out how to skip all of this (Sleep? WSYNC again?) then those 6 additional vars could be free space in the mem map as well. Best I can figure this is what allows for the tens places in each section of the score?

Yeah I can see a couple of things, when you use lda you're undoing the prior randomization stored in the accumulator . Also, the jsr's all loop to one another. Even if your randomization works the program flow could theoretically end up looping forever. It would be better to have a routine with a predictable execution time, like any of the examples already posted.

Saved another 124 bytes by replacing 10 if-then statements with 1 on-goto and shortening labels in the part of the code that changes the playfields. This was something I had been meaning to do for a while, but got sidetracked with trickier optimizations. I still have to program the second game mode, win conditions, and reset switch support. Right now there are 10 screens (not counting the title), I'd like that number to be 20 or 30 so I have a lot more pixel drawing to do. Currently at 960b free. Title screen, shows how CTRLPF manipulation can be used to get around MSK limitations.

Reclaiming bytes via kernel 558b free 814b free So that saved some bytes, but here's another idea, which DOES NOT save any bytes, but this shows how I went about testing it. Reclaiming bytes via RAM sprites So the second and third example both work just as well as example one, and I was willing to remove "LDA #255" since it would have sped up the routine and would only have caused there to have been two dots in the middle of the arrow, I could live with that. The problem was simply that doing this doesn't save any ROM at all... I believe this is because of the images being stored as bytes that need to be page aligned, so this doesn't circumvent that requirement. I scrapped this idea because it's not useful in this application.

SUCCESS! I figured out what the problem was, the scorepointerset and setscorepointer routines are either required by or factored in to the screen drawing. I was able to remove everything else and ended up with a working scoreless multisprite kernel. As far as I'm aware, any options will have no effect on this kernel, so you don't need to set noscore, and setting something like debug will do nothing. This is a savings of 64-86 bytes! noscore_multisprite_kernel.asm

This was really interesting, not ashamed to say I sat down and read this disassembly like it was a book. Comments very clear and the original code being so tight means it's a good learning exercise. Thank you for posting this.

Final version and source above. Might still have alignment issues that need to be fixed, but this is the most complete version as far as I know. ATAX-ATAX is my newest project. I've been working on it for about 8 days so far, so I figured I should try to keep track of my development. I still have quite a lot to do. This is going to be a 4k game, but I'm confident that that won't be a limiting factor in this project. If you're curious why I think 4k will be plenty of room: So anyway, I've got the sprites displaying correctly, I have a good chunk of game logic in place, and at this point I'm up to ten screens and have 558b left. I am sure I can reclaim more bytes, and that i can fit plenty more in. I'll try to keep updating as things happen instead of as a retrospective.

Immediately made me think of the Addams Family set

Just make sure you dim p0dir to a variable first, something like dim p0dir = a

I think I just messed up some of the re positioning using HMP0. if you search for the label cycle74_HMCLR and change the preceding line from lda #$80 to LDA #0 then it only gets offset by -4 (x) at 2 (y) positions, which makes me think I'm close

fixed multisprite with no options: 748 b free fixed multisprite with noscore defined: 728 b free " " with debug cyclescore: 558 b free scoreless multisprite: 938 b free

What I think orange808 meant was if I am not using the score at all that I should remove all the score code from the multisprite asm so I can gain back the bytes that it wastes (I think this is what they meant anyway and it is a good idea) I attempted to do this, but now I have an issue where sprites, ball, missiles all have a strange x offset problem (worse the closer to the bottom of the screen it gets). If this can be fixed then a completely scoreless kernel could save about 70 bytes on one where the code is just being skipped.(not to mention the parts of the mem map that could be freed up) Here is what I have, right now you have to use const noscore=1 and since score is completely removed you can't use this kernel for debug or cyclescore either. multisprite_kernel_scoreless.asm

Sorry, I thought since it's an asm question it belonged with other asm questions. I'm a little confused... There's no mention anywhere of what "the fix" is that I could find- except a different post that as I mentioned said to add two PLAs before the jmp. Is this all the fix is, or is the fix something else completely? I'm not using any modifications here, I've reverted back to stock when the above mentioned (pla) fix didn't change anything. Sending you a PM with the files you requested. EDIT: Thank you Karl G for reviewing this and sending me a fixed asm- I also think I probably forgot at some point to move the newest modded include into the same directory *facepalm* so it wouldn't have changed anything anyway.

Hello, I've been looking for a solution to this for over a day- const noscore =1 in multisprite kernel This is documented as being broken, I found a post where Karl G said he "found a fix" but the only other mentions are one suggestion to modify multisprite_kernel.asm with 2 pla's, which I tried and did nothing, and a custom multisprite.h, which I downloaded and tried and did nothing. Description for those unfamiliar: When setting const noscore in multisprite kernel games you end up with screen rolls, playern's flying off the screen, general chaos. obviously something is very wrong with the noscore jump in the MSK. There are a million little nuances to this kernel, I can deal with/work around/fix most of them, but this one is stumping me. I'm currently using a 4k rom, so no need for bankswitching stuff, if that makes a difference in how this can be fixed. Any help? EDIT: I ended up removing all the score related code from the kernel. I have managed to free up the roughly 70bytes (86 bytes) Also frees up 10 vars (score and scorepointers) also you do not need to use const noscore so that saves you a few bytes itself. (Roughly 108 bytes in total savings) The ASM on THIS post is the most recent version SansScore_multisprite_kernel.asm

If I have the option, I'll go physical. It's nice to hold something in your hands and not just have your physical money disappear into digital content. Besides that there are usually limitations on digital copies, like only being able to have them on so many different platforms, requiring an internet connection despite already having the full game, etc. Even if those aren't an issue, the simple fact that console companies keep trying to kill off the second-hand games market is a sore spot for me. I like being able to trade disks with others, something digital copies deprive us of. If I don't have the option, digital is fine. I own several digital games because the physical version was simply too difficult or too expensive to acquire. It's also the most reasonable way to share indie/homebrew games (my games.niche website is all digital only for this reason, no cost for media overhead). I was tempted to select "don't care" because if digital is the cheapest/easiest/only way to get a game, it's perfectly fine. Streaming? I think you'll have a hard time finding anyone who's excited to stream games, unless they work for google stadia. One possible reason is that streaming a game makes it feel like you don't own it at all, but that's just speculation.

Chiming in with some specific incompatibilities on the Atari FB9 w/ composite outputs. I did a search and saw this requested in several places but not actually posted. Here's some of the ones I've found. Demos seem to run slower than intended: 4kra VCS Sphaera stellarum Games that (I assume use multipsrite kernel) have a syncing issue that causes problems: Bit Quest Halo 2600 Games that just don't run at all: Alien Pinball FNAF 2600 Gizzle Wap and the.... blizzard Reindeer Rescue Stay Frosty Stratogems_DX Toyshop Trouble Pitfall II Lost Caverns Zippy the Porcupine Probably anything over a certain file size... Games that function oddly: SC games like SC Space Invaders (I believe this is a known glitch, haven't tried patched versions) Princess Rescue (The enemy AI stops working at a seemlingly random point during play) AVGN the game (The title screen is off sync, otherwise fine) Cosmic Ark and any game that uses the "starfield effect" (Plays fine, but the starfield effect isn't present- instead the stars just appear as long strips)

fighting a boss Collecting a gem Official Website

This was exactly what I was looking for, I used it in the game I just finished, CRT: Link to post and game that uses this

CHANGELOG Original WIP (alpha): Beta: Final: Final version added to first post.

This is a great question, agree it's probably different for everyone but the OP did seem to only ask for personal opinions. I would be willing to call anything that you can't just go and buy at a store today to be retro, but if that's way too inclusive then I'd say that in this particular case, bits would make the most sense to go by, as in essence, at it's lowest level, the number of bits available determine how much can be done at any given time. That being said, it's still super fun to mess around with limited older consoles because the limitations are what force creativity.

Hello, setting up an IDE is usually the first big hurdle, so I'll offer some points to go over: 1. Directory: I always like to keep programming stuff as close to the C dir as possible to limit on long directory names, for example I use for visual BB C:/Atari2600/Visualbb bb itself I have in C:/Atari2600/bataribasic I've always found this practice helpful in the long run 1b. Directory spaces: As mentioned visualbb doesn't seem to like spaces anywhere in the file path, so when you label your folder try to avoid uses spaces anywhere. 2. Follow the installation guide- I just set up visualbb recently and as I recall you had to: install an emulator, install bb, possibly move a few specific files, run an installation file (presumably to set registry values), set paths within visualbb itself, and THEN you can start using it. (There's also warnings everywhere not to cheap out and use the tinkernut installer- it's outdated and will cause issues) 3. When you start, start with some extremely simple, small program, like just drawing a specified screen. 4. If you start running into errors that make no sense (like blank characters being marked as syntax errors- which they are NOT actually the error almost assuredly) then rem out or take your code and drop it into a text file, then go back and refer to point 3 and add code back in one small section at a time, when the compilation finally breaks again you can then focus on the last chunk that you added and you'll find where the mistake is a lot easier that way. 5. It's okay to add one line or change one variable and do a recompile, this way you can see right away when something breaks, and if it's not an easy fix, you can just delete it and be back to having a working program again. 6. invisible binaries? If your file path has a space in it somewhere, sometimes visualbb will SEEM to be working fine, you can even compile and test run code, but when you go to the bin directory nothing will be there. It seems like this is because when you click the run button from the IDE it actually compiles and runs a temporary file, which is deleted the moment you close it. So refer to point 1b to make sure that the compile actually works as intended.

Help CRT, the chromatic alien life form, to find his way through 255 levels of increasing difficulty. Collect Rainbow Gems for power, defeat Evil Things that want to suck all the color out of existence, and bring color to the universe. Thank you to Zeropage Homebrew for giving me some ideas on things I could fix, and thank you Karl G for providing the statusbaronly mini-kernel. Final Version: Gem rooms: 25 points each, restore HP (40% chance) Mob rooms: 100 points each, chases player (40% chance) Boss rooms: 500 points and full HP upon kill, uses a beam attack (20% chance) level 2: pfpixels flip randomly each new level level 4: permanent wall 1 (right) level 6: permanent wall 2 (right) level 8: permanent wall 3 (center) level 10: permanent wall 4 (left) level 16: rainbow strobing playfields level 18: 1 pixel reverse scanline level 20: 2 pixel reverse scanline level 22: 4 pixel reverse scanline level 24: playfield flashes visible/invisible Enemies: 1 to 3 + (level/4) enemy spawns Gems: 4 + (level/4) gem spawns Bosses: 4 to 5 + (level/2) Boss HP Main screen: select level from 1-255 using up/down, start with fire or select. Game: move with up/down/left/right, shoot with fire, collect gems, kill enemies, advance to the next room when the north wall opens up. Reset switch returns to title screen. Left Difficulty Switch toggles the constant HP drain. Game Over: use the Reset Switch to return to title *Not Recommended for people with photo-sensitive epilepsy* CRT_Final.bin

That would be awesome, and thank you for the info about noscore, I was hoping it took close to as many cycles as the lives mini kernel since it suggests disabling score when using it to free up cycles.