Kylearan

I understand your point of view; it's a matter of taste. I however would like to concentrate on coding actual effects or game logic. Manually aligning code and data, sometimes with a needed offset, and manually searching for code caves when ROM gets full and then shuffling around routines and data blocks is something I've done extensively before and already know how that works. Now the computer scientist in me demands that my PC should do that chore for me. It's an optimization problem perfectly suited to computers, so it can do it better anyway! So I broke down and actually started to develop my own assembler/linker. It will support align with offset and nocross sections, optimize placement of sections in ROM and yet still allows full control of everything, if needed. It also does away with stupid white space rules and other annoyances. Hopefully with Boost Spirit it won't take very long to have a usable prototype.

From a quick glance over the assemblers you listed, none of them seems to support the "nocross" declaration in conjunction with a linker. Which is really odd, as that is often needed and would be much more powerful and easier to use than manually fiddling around with "align" and "org" statements.

Can you recommend a better alternative? You'd instantly become my personal hero! Apart from a lot of minor gripes I have with dasm, the main feature I'm looking for is to have a linker where I can mark sections as aligned or parts of a section as "nocross" (i.e. that part must not cross a page boundary) and then let the linker optimize placement in ROM. KK's k65 more or less has such a linker, but it doesn't use standard 650x mnemonics and has lots of other minor annoyances and inconsistencies.

Haha, that's funny - or sad, I'm not sure. It looks like we are using different versions of dasm. In line 72 in the subroutine "FinePosObject", my source says sta.w RESP0,x which according to Stella my dasm compiles to STA.wx RESP0,x and yours to STA.w RESP0 which of course is not what I want, as it's missing the x indexed mode. (I repeat myself, but dasm is REALLY annoying and outdated. No modern tool should silently discard the ",x" without saying anything to the user.) I'm using DASM 2.20.11 20140304 by the way. So for your version of dasm, I guess changing the line in the source to "sta.wx RESP0,x" should probably fix it.

It does? Looks good to me here. What exactly does the ball do which it shouldn't?

No problem! I've attached a source file where I stripped out everything else except the lightning. I don't know how readable it is though, as it's from after size-optimization. There's a table called "LightningSeeds" which contains 8 seeds for the pRNG that I think look good and which I've found by trial and error. It loops through these seeds. I'm sure there are more good-looking seeds, but also a lot that don't work well - just experiment. lightning.asm

Haha, great name! Gameplay lacks variety IMHO. Right now I simply move in the general direction below the germ, then just hold fire and wait until the germ flies into me. More challenge and/or variety would be nice.

Actually the order was different: First enthusiasm, then hope, then despair.

Nice bait!

Because the real world isn't only rainbows and roses as well. I know the concept won't appeal to everyone, but I hope at least the technical side can still be interesting.

I have released a new demo at the Revision 2017 demoparty, this time in 4k because people kept telling me you have to do a 4k to become a "real" VCS developer. Here's the Pouet link: http://www.pouet.net/prod.php?which=69681 I've also attached the binary to this post. The dasm source can be found here: https://bitbucket.org/kylearan/catharsis_theory/overview But caution, due to a lot of heavy optimization, it might not be very readable. The readme contains a technical write-up though, in case you are interested. Now I can go back to developing Air Taxi. catharsis_theory.bin

You're loading and storing frequency and duration values based on NoteCounter before testing if it has reached #72. That means your routine will use values #72 and #73 from your table as well, which are no longer valid tune values but in fact are the values of the "sta WSYNC" immediately following the table (which is $85 $02, resulting in a frequency value of $85 played for 2 frames). Check for #70 instead and it should work. Or better yet, do the check before you fetch tune data and you should be able to get rid of the two leading 0 bytes in your data as well. (Or so I think. Haven't tested it. :-))

Use "Export complete player to dasm..." in the menu to generate several .asm files. Then use dasm to compile <songname>_player_framework.asm to a .bin file you can then open in Stella or put on a harmony cart. See also Section 5.1 in the manual for a more thorough explanation, including how to compile the .asm files using dasm.

The idea is to use the 4 bits auf AUDV0 (and maybe adding a 5th bit by using AUDV1 as well) to play back digitized samples. With some tricks (and sacrificing quality, which for speech should be okay), I hope to be able to stuff some very short samples into one 4k bank. Tjoppen did some great pioneering work here, sources included.

I'm glad you like it so far! Actually my current plan is to include speech even without the need for AtariVox+. Since I'm going for 32k, I will have the ROM space to add "Hey taxi!", "Thanks!", "Up please!" and similar samples directly. While such a sample is played, visuals will be reduced to a minimum however, probably only showing the border of the playing area, the taxi, and the passenger. Air Taxi is a bit on the back burner at the moment because I'll have to finish my 4k demo for the Revision Easter demo party first, but I will start development in earnest after that. I am slowly refactoring the code for NTSC right now however, and will probably ask some stupid questions about PAL, NTSC and PAL60 for cartridges on this forum soon.

http://www.dafont.com has pixel/bitmap fonts. Also, http://kofler.dot.at/c64/ has a big collection of 8*8 charsets that could be used/adapted.

Great thread, thanks! So it looks like I will have some leeway, which is good. I don't have a good feeling yet for the amount of computation needed in overscan and vblank, but will try to aim for 200 visible and 262 total scanlines for the moment and see how far that will take me.

Oooh nice, I can totally see people contributing ideas! They could design levels with GIMP or Photoshop using my template, and I could implement the custom code. Of course we would have to discuss if the custom code will be possible beforehand, but that wouldn't be a big problem. First things first, but I'll definitely keep that idea in mind!

That's actually a very nice idea! I could show the fare only when the passenger is on board and the total score at all other times. That might work! Let's see how much scanlines I have to cut out to be able to fit it into an NTSC screen, maybe I can make it work with all three rows. I couldn't make the playing area bigger anyway (not enough RAM for the AND mask for the dynamic changes). Unfortunately I need several scanlines between the individual rows to construct the pointers for the digits etc.; I cannot do this in overscan or vblank as I don't have enough RAM. There's some room for optimization left though, and if it doesn't work out, I'll use your idea. Speaking of NTSC screen space, how many scanlines can I use for the visible area? Tutorials say 192 lines, but can I use, say, 200 if I keep the total at 262, or will this be problematic for some TV sets?

Adding a status bar turned out to be more complicated than I thought. Several things need to be displayed: The score (i.e. the total sum of money already earned), the fare for the current passenger, the number of lives and a fuel meter. Unfortunately three of those things (score, fare and lives) need player objects to look good, so I ended up with three rows that take up a lot of screen space. I guess I could have used a decreasing bar similar to the fuel meter and crammed it into the score row instead of showing the amount of dollars, but I like how in the original game you see the dollars dwindling away while you bring the passenger to his destination; it relates to your score better than just a bar. So I went with three rows instead. There's also a small icon next to the fare that displays the current state: A waving figure if a passenger waits for you to pick him up; a sitting figure if he's on board; an up arrow if he wants to leave the level, and nothing if you just delivered a passenger and are waiting for the next one to appear. The graphics is there already, but in the test rom only the waving passenger animation is shown. The three kernels posed a greater challenge than I had anticipated. I wanted to have a dot between the dollars and the cents without having to define two different fonts (one with dots, one without). In addition, I wanted the score to be able to go over $1000.00. After a couple of false starts, now the dollar sign disappears as soon as you have four digits of dollars, and the dot is added on the fly during the 48 pixel sprite display. The fuel row was tricky as well. Per scanline, I need to update GRP0 and GRP1 for the number of lives, use a missile for the "F" next to the fuel meter, and show the fuel meter in a different color with hi-res precision (not just with 4 pixel playfield granularity). The display uses a mirrored playfield, updating PF2 at eactly cycle 45, and uses COLUBK for the bar color, resetting it to black again before the background shows again on the right side. Note that the status bar is a bit narrower than the full screen to hide the ugly HMOVE bars. The last row with the fare was straight forward to do after I got the score row right. In the attached demo, the taxi uses up fuel but you cannot refuel yet; also, the fare doesn't cound down yet, only test numbers are displayed. Next thing on my list is to convert the game to NTSC, as I think I have to cut down on real estate to fit it in the smaller display (current version is PAL). In addition, I have to optimized for RAM, as my naive implemetation already uses up all of it. For the curious, I've set up a Bitbucket repository for Air Taxi here. Note that this is heavy work-in-progress, i.e. unoptimized and ugly in places. taxi_20170222.bin

Whoa, that's one of the coolest and most devious bugs I've seen in a while. Awesome.

All right, thanks Thomas. I don't care about reduced sales either, but didn't know how the AtariAge store would think about that - I guess they have an interest in more carts sold (and rightfully so). But if other people shared their sources without any complaints, I will do so too. I'll probably set up some bitbucket repositories for my VCS stuff (demos and Air Taxi).

Yes, I... think so. I guess. I usually publish source code. But: The thing is, if the game turns out to be fun, I'd love to sell real carts through AtariAge. Not because I want to earn a lot of money, but because I'd like to call myself a "commercial game developer". But I have no idea what that entails. What are the technical requirements? And can I still share source code? The full .bin, or only a short demo? After a quick glance at the AA website, I couldn't really find anything on what steps are necessary to publish a game through AA, or what requirements have to be met. It's way too early in the project to seriously think about it, but at one point I'd appreciate input on that from people who have successfully published a game like that.

I've made some progress, yay! \o/ A considerable amount of time went into cleaning up and refactoring the existing code, turning the proof of concept into a structured project that will last me all the way - or at least I hope so. Things like splitting up the source into smaller files, replacing magic numbers with #defines, abstracting the way I parse level data etc. The most satisfying thing for me is that I now have a fully automated build process that I can trigger out of my editor of choice (atom) that will convert all kinds of graphics and level data into source code before compiling. For example, this is what the test level looks like in my graphics program: The starting point of the taxi is marked with a red dot, the fuel pad by a green line and the landing pads by blue lines. The left wall defines the color gradient to use for the playfield. During the build process, a python script reads in the PNG file, parses it and converts it to "dc.b" data, including level structure, positions and sizes of all pads etc. Another script converts a sprite sheet PNG file into the graphics data for the taxi, and yet another scripts creates color gradients (for the background, for example). This allows for very short turn-around times: I can quickly change something in the level design, hit "build" and can try it out in Stella almost immediately without any manual steps inbetween. It's fun to battle oldschool hardware with modern tools! I also implemented my first ever attempt at physics. You can fly around with the taxi now, including visual and audio clues while thrusting, and even move out or in the landing supports (and lose the ability to accelerate horizontally while they are out)! You cannot land yet, but why would you want to do that anyway, seeing that the silly passenger is still floating in mid-air... I've attached the current binary if you'd like to try it out. The parameters (gravity and thrust values) are a first test and still need fine-tuning. I have to play the original Space Taxi some more to get a better feel for its controls. I probably should implement placing the passenger on a random pad and the ability to land next, but I think I'd rather go for the fuel/lives/money display at the bottom first. That will help getting a better impression of how the game will look in the end, which should be very satisfying. (That will also bring me closer to the PAL vs. NTSC question, but I refuse to go there just yet...) air_taxi_20170213.bin

It's a general microprocessor thing, not limited to the 6502. You'll find a carry flag and its equivalent use in addition (and subtraction) instructions on all micro processors.