Kylearan

It allows you to extend an addition beyond 8 bits. You can carry over any overflow from the lower 8 bits to the higher 8 bits of a 16 bit addition. For example, if you want to add 100 to a 16 bit number, you can do this: clc lda lowByte adc #100 sta lowByte lda highByte adc #0 sta highByte If the first addition (adc #100) overflows the lower 8 bits, i.e. the result is >255, the carry bit will be set and the second addition will actually add 1 instead of 0 to the high byte.

That looks like a very nice solution, thanks a lot! I think I'll put in a safeguard for SIZE_OF_DATA so that it throws an error if it gets too big and then make a macro out of it, and will be reconciled with dasm once again.

How can you specify "align" with an offset in dasm? Take a skipDraw routine for example, where you have to make sure the graphics data starts at least n bytes after a page boundary. How can you do this in dasm without resorting to a hard-coded "org" address?

Yeah, that was a bit of hyperbole on my part, but I guess you get my point.

Yep, that's more or less how I do it. However, I have to do that only once every four scanlines (it's a four line kernel and I store the result also in RAM for re-use in the other three lines, where I then only need to do a "lda tmp_pf1; sta PF1"). I have to admit I don't understand your suggestion. I can have 256 possible values for PF1 and 256 possible values for the AND mask; how can I precompute something in that situation? But in any case, even if it worked I would "only" save a couple of cycles every four lines while I'd need more cycles at least every two lines to add something useful. No extra RAM, no extra computing chip, only some more ROM (16K probably). See my stance on this issue here. To sum it up, if I'd use extra RAM and DPC+, I could simply use a C64 instead and play Space Taxi on that machine.

Inspired by the recent Space Taxi thread, I've started to work on a game with the working title "Air Taxi". It won't be a faithful port of Space Taxi but heavily borrows from it, meaning the gameplay will feel very similar, but level design and several details will be different. There will be two different kernels: One for asymmetric levels, unable to display hi-res objects apart from the taxi and the passenger, and one for symmetric levels with an intelligent object multiplexer allowing for more hi-res objects like bullets, snowflakes etc. with minimal flicker. Both are designed to have no empty scanlines and to be able to display dynamically changing playfield graphics, i.e. levels with moving walls or doors opening and closing. I've finished a proof of concept of the asymmetric kernel. Note that the graphics and level design are only a placeholder. For those who don't want to run it in Stella, the opening in the vertical wall is moving, and the top of the ring where the passenger is in alternates between open and closed. You cannot yet move the taxi around; it's only my first experiment if the kernel works as intended. Features of the kernel: The interior of a level has a resolution of 32x40. Blocks can be switched on/off at a resolution of 32x20 during the game, and the level exit can be anywhere on the top. The taxi will be drawn every scanline, the passenger (or the target pad if he's already on board the taxi) every second scanline. The background and the playfield colors can be set every 4 scanlines. Also every 4 scanlines, the missiles can be enabled or disabled. Right now they are used to mark the fuel pad in the lower right corner. I've already created some python scripts that convert PNG images into level data and color data. That allows me to use GIMP (with the VCS palette loaded) to design levels, although changing the level during gameplay (like opening doors etc.) will require custom code for each level. Basically I hold a buffer of AND mask values in RAM that the kernel applies on the fly before writing to PF1/2. The kernel has some downsides however. As already stated, it doesn't allow for additional hi-res objects. In addition, taxi and passengers only have a single color, and I'm not very happy with how the fuel pad gets displayed. But my main design goals were to be able to draw the taxi each scanline and to have an asymmetric level design which is not static, which together is pretty limiting with regards to instruction cycles left for other stuff. Hence the second kernel for symmetric levels which I will do later, but first I'll add the ability to actually fly around with the taxi. taxi_170203.bin

New version 1.2 released: Added an option that allows patterns to have different tempo values. While using this option costs some extra bytes in the VCS player routine, it can help to make shorter patterns and thus save bytes overall. Added a keyboard shortcut for "Insert pattern after..." action On export, the tracker now checks if goto commands are valid. The target of a goto command has to be <128, and for targets in channel 1, the number of patterns in channel 0 gets added to the target number. This constraint is due to size optimizations in the VCS player routine. Added two new example songs by Glafouk: A Bomb the Bass Megablast remix called "Miniblast" and a song called "Beside", both from Flush's demo "rotor" (http://www.pouet.net/prod.php?which=68494) Minor UI fixes I've edited the first post with the new downloads. Enjoy!

Ah, thanks a lot for that comment! The last sentence made me realize I can simply do two different kernels, one for asymmetric playfield more where no sprite multiplexing happens, and one for mirrored mode that allows for multiplexing. Having some symmetric level designs that in turn will be able to have more moving hi-res objects should enhance the experience a lot. I'm still working on some helper scripts (for example one that converts a 32x40 .png image to .asm level data), after that I'll create a WIP thread and showcase the proof of concept kernel.

Thanks for the info! I realize I have worded that poorly (or probably more precise: Never thought that through completely ). I don't want to emulate the conditions of a certain time period, let's say 1982. I never owned a VCS back then (my first computer was a C64 in 1985), so that holds no meaning for me anyway. Instead, I'd like to preserve what makes the VCS special in comparison to other home computers. What I mean by that is that the lack of RAM, the lack of a framebuffer and the weird sound chip in combination with only having 76 cycles per scanline is the main challenge that attracts me to the VCS, that makes programming for it so special. If I add more RAM, ARM support or a special music chip, I feel like I could simply move to the C64 instead and have a similar, but more "original" experience. To me, adding a moderate amount of ROM is different however. All this allows is more data for levels, graphics, and music, but the fundamental way of how to make use of that data stays the same. (The exception is that more ROM also allows unrolling loops which gives you more computing power, but I'll stay away from that in this game.) I hope that makes sense.

Oooh, if there are bankswitching methods that allow me to combine a 1 or 2K slice containing my kernel with a different 2K slice containing level data, this would be sweet! Thanks for the hint, I'll have a look into that.

True. But I think that an intelligent flicker kernel would make compromises in other places necessary that would diminish the overall experience too much for my taste. Updating the taxi sprite on every scanline is a must IMHO, or otherwise the feeling of fine-grained control which is very important in a gravity game gets lost. I'm also not a fan of playfield graphics with empty scanlines inbetween, which would almost certainly be needed for repositioning objects. And that doesn't leave much room for more hi-res objects. What I'm trying to say here is that my game will not be a true remake of Space Taxi, more a game heavily inspired by its game mechanics. I'd rather concentrate on the abilities of the VCS and try to make a game that looks and feels good on its own than trying to recreate a game faithfully while making too many compromises along the way. That means some levels like the one with the shooting cannons at the bottom might shoot lo-res PF pixels instead, and some levels like the raining snowflakes might not make it at all, or only in spirit (raining blocky hail instead of hi-res snowflakes ). I know people who'd like to have a true port of Space Taxi on the VCS will be disappointed (maybe BNE Jeff succeeds in that!), but it also means I can add completely new level ideas, free of the original's constraints - and I know I will have a lot of fun letting my creativity run wild.

My current version of the kernel has no flicker at all. It displays the taxi updated each scanline (for smooth vertical movement) using P0. If the passenger is waiting for the taxi, he gets displayed using P1, updated every other scanline. If he's on the taxi already, P1 displays the target pad instead. The refuel pad is shown using M0, M1 and the ball, but this is updated only every 4 scanlines - but then the refuel station doesn't need a very high resolution. Playfield and background color can be changed every 8 scanlines. The playfield is used to display the rest (the maze and obstacles, moving walls, blinking gates, magnets that pull the taxi closer, whatever). The playfield gets updated every 4 scanlines, for a playing area resolution of 32x40, where individual blocks of size 1x2 can be masked for the moving walls etc. I think a lot of interesting levels will be possible that way even without using player sprites for high-resolution objects. I hope I'll be able to showcase the kernel this weekend, for a less abstract discussion. Besides the extra ROM (32K), right now I'm aiming for no extra RAM, DPC+ or whatever - at least there I'd like to stick to the original, for the challenge.

Alright, I would appreciate some input from those of you who have already published a game. I have a kernel more or less working now (will show that soon) that displays a level, taxi, passenger or target pad, a refuel pad and which can set a new playfield color and background color every 8 scanlines. There are two versions: A small one which displays the level at a resolution of 32x20, similar in looks to Tanks (but with varying colors vertically), and a bigger one where levels have a resolution of 32x80. The latter allows for better level graphics, but obviously requires much more ROM per level as well. There are different ways I could go forward now: A 4K game with low resolution, no speech and a medium amount of levels (about 16) An 8K game with low resolution, speech, and more levels (about 25?) A 16K game with high resolution, speech, and a medium amount of levels A 32K game with high resolution, speech, and more levels I would strongly prefer variant 4, as I can be much more creative with level designs and more levels means more fun for the player. However, I have no idea what this means for a potential cartridge release, if it ever comes to that. Would a 32K cartridge be more problematic production-wise than a 16K, 8K or 4K? Is there a difference in acceptance among the player base? Are there any other problems that I've missed? Since the kernel architecture has such a big impact on the rest of the development, I'd really love to hear back from more experienced people. (Damn, looks like I'm going make my first VCS game, yay! )

Damn, this thread really got me thinking... I don't think a true port of the original game is possible. There are just too many objects (taxi, passenger, fuel pad, target pads with numbers, level-specific objects), or it would look really ugly (15 Hz flicker or even worse...). But a game heavily inspired by Space Taxi would of certainly be doable, with its own level design tailored to the VCS' strengths and weaknesses. This is what I have in mind: Restrict the playing area to PF1 and PF2 and use PF0 only for the enclosing border. That gives you 32 blocks = 128 pixels horizontally for level design of the interior area, and you'd only need to update PF1 and PF2 twice per scanline (in mirrored mode, that would need perfect timing, but it's doable). Restrict the height of the playing area to ~20 blocks (each block being 8 scanlines high), again without the enclosing border. This allows for an 80 bytes framebuffer to keep in RAM making dynamic levels possible, with gates appearing/disappearing, walls moving etc. Not sure yet, but might be possible to use the framebuffer as an AND mask, allowing for higher resolution graphics stored in ROM where whole blocks can be switched on/off. P0 would be the taxi. P1 would be either the passenger (if he's waving or walking), or the target pad (in quadruple mode) if the passenger is on the taxi. That means not all possible landing pads would be visible normally, only the current target would be, but that way you avoid flicker. To compensate, and give the player an idea where all possible pads are, the game will cycle through and show them during the initial "new level!" melody. The refuel pad I'm not yet sure how to display. I'll probably have to construct it with M0, M1 and the ball somehow, as it has to be wide enough, but that's an ugly solution (visually and technical). I'll have to think more about that. To make visuals more interesting, it would be good to be able to set a new color each block, either for the playfield or the background. Might be doable. For fine-tuned controls and a good feel of gravity, ideally the resolution for the taxi's y position should be so that it could be on any scanline. I already have some ideas how to make that work within what is basically a 2-line-kernel inside an 8-line-loop, but I'm not sure yet if it will work. Speech would cerainly be possible if the game will be bigger than 4K. Which most certainly it would be in any case if I want to have enough interesting levels, which would need individual blocks of code (moving walls, having different gravity, ...). During speech, the game might show a more simplified version of the level (without colors for example, or without some objects), but it should be doable without having to switch the screen off. Right now I'm working on a prototype kernel for this and will report back if it works.

I have made a new sound routine and accompanying PC tracker for the Atari 2600: http://atariage.com/forums/topic/250014-tiatracker-a-new-sound-routine-and-sequencer-application/ Several musicians and demo creators have used it successfully already.

@sunofman, look here for another new computer language that makes 6502 code, also with full control over the 650x instructions, which sounds a lot like what you are trying to do: http://devkk.net/wiki/index.php?title=K65 It has been used for the VCS for several large demos already (http://devkk.net/wiki/index.php?title=Projects_using_K65) and also for C64 stuff (and I think for other Atari models, not sure). Maybe it can give you more ideas.

Without looking deeper into the code: Have you made sure the time-sensitive loops (.graphicLoop, DivideLoop) don't cross a page boundary, which would make the respective branch instructions cost an extra cycle and mess up your timing?

I especially like how you managed to let the varied melody not sound too much off-tune, good work!

That made me laugh.

Tjoppen has done some great work on samples on the VCS, for example here (source code with encoder is included in the download). That is certainly not usable during a game, but might give you some ideas. There's also a thread somewhere on these forums about this topic, but right now I'm not sure how to find it. Playing samples during a game kernel doesn't seem very viable though. Not only do you usually need every cycle to display the game and will have a hard time spending instructions on audio; there's also the problem of where to store the audio data. It has to be in the same bank as the kernel and the gfx data it uses, and you cannot really afford two bank switched every second scanline on top of the audio register updates.

Oooh, very nice. I really like the original, and I'm looking forward to see how well it can be converted to the VCS! Will this be a 4k game? Or more, porting the original intro as well? If Shadow or you need any (custom) modification or feature in the player or tracker, just contact me and I'd be happy to help!

I don't know anything about batari and don't have the time to dig deeper, but if someone who knows more tells me what I have to do to add batari support, I'd be happy to do that.

If after editing keymap.cfg the shortcuts no longer work then that means that the structure of they .cfg file is no longer valid and TIATracker fails to parse it. (Right now TIATracker fails silently and does not alert the user to this; I've now made a ticket to change that. ) The " character is a special control character which you have to escape. Either use "\"" or "Shift+3" to make it work.

I've just realized that I don't need to add that feature after all - you can already do this in the current version via other means. (My brain works very slow when I'm on vacation. ) Simply model the envelope you want to hear once in the attack/decay phase instead of the release phase, and set the volume in the sustain and release phases to 0. That way, the envelope gets played immediately and exactly once. There's actually an example instrument in the "instruments" folder called "Pizzicato bass.tti" that implements this idea. You can see how it works there.

Alright, will add that when I'm back from vacation, first week of August. This should require no change in the VCS player code and only small changes in the tracker and so should be quick to add. (Famous last words...)