Leaderboard

The line counter is active at all times. The (9-bit) line counter is increment by 1 in progressive mode, and by 2 in interlaced mode. In progressive mode a line IRQ is produced when the 9-bit line number matches the 9-bit line irq register. In interlaced mode a line IRQ is produced when the upper 8-bits of the 9-bit line number matches the upper 8-bit of the line irq register. The video timing has the active portion at 0-479, then 10 lines of front porch, 2 lines of v-sync and 33 lines of back porch, for a total of 525 lines. Rendering is started one line earlier, so at line 524. Composing the outputs of the renderers (2 layer renderers and 1 sprite renderer) is performed while outputting the pixel data. Eg. the line buffers rendered at line 524 are displayed (and composed) on line 0. Hope this helps.

For the demo of the technique, see this post (not mine): https://www.facebook.com/groups/CommanderX16/?post_id=617425515675213

There is a line IRQ feature, and you can scroll tile and text layers, which can produce the effect I believe you're describing. That said, line IRQs are broken on r37. You can build the current source code yourself, though, and get the fix.

You definitely don't want to draw the road in bitmap mode. Just create a fixed tile map for the road, a central perspective of the road and make it pretty wide. In the default position (road in the center, a long straight ahead) there will be some amount of horizontal scroll. Then it's just (hehe, just! ) a matter of calculating the right scroll offset for each screen line, depending on the position on the track. For instance, if the road ahead is turning to the left, the top line of the road will have the smallest x scroll offset, with the scroll offset increasing each line until it reaches the default position at the bottom of the screen. If you're feeling particularly bold, you can also simulate terrain elevation. It's all just a matter of choosing the right line of the tile map with the right scroll. Also, you can simulate texturing either by modifying the palette on each line or (a simpler method) create multiple tile maps with different colored tiles and change the tile map per raster line. You can do all the calculations in vsync interrupt handler. Of course, this all requires a raster interrupt for each line where the road is drawn, but since you've already calculated the scroll, it's only a couple of LDA's and STA's per line. As for the background (mountains, sky, etc.), you can use another layer, or you can reuse the same layer as for the road, you just need to switch tile maps on the right raster line. Everything else (cars, signs, trees and bushes) should be done with sprites.

Remember, you can always use BIT instead of AND if you want to keep the original value in the accumulator.

Actually, it's possible to get some decent-sounding chiptune music out of the VERA PSG alone. You get 16 channels each with 67 waveforms (64 selectable pulse-wave duties, sawtooth, triangle and noise), 64 logarithmic-scaled volume levels, and simple stereo panning. This sounds like the C64 SID chip but in an alternate universe where it was designed differently. Here's a demo of what you could do with just 3 of the 16 channels (which was made shortly after the PSG was implemented in the emulator).

I could talk at length about what I'd like to see in the final sound design and am quite excited about all the possible options! Folks have quite the diverse opinions there! But the question is not so much about that and more about what can be reasonably assumed as being in the final hardware at this point so I know what is reasonably safe to start using. It sounds like the consensus is the YM2151 is a safe bet, given it is in the emulator and programs have already been written that use it; and given there is a tracker solution, albeit not a native one, to use it. It would be nice to see it clarified in the FAQ though since, as it reads, it does imply the sound design is a lot more up in the air than that.

VERA + YM2151 + SAA1099 is perhaps what the final design of the X16P is going to have. I have a feeling this sound hardware in question is way too overkill for an 8-bit system, by essentially having 16+1+8+6=31 channels. This kind of reminds me of the 16-bit C256 Foenix with its cluster of sound chips (FPGA SID + SN76489 + YM2612 + YM2151 + OPL3 + 192KHz 24-bit stereo DAC + 3KHz piezo beeper). Even the ZX Spectrum Next has a more-plausible sound hardware, with three AY-3-8912 chips for a total of 9 channels (or 10 if the ZXS 1-bit beeper is included). One of my suggestions for the X16 is to remove the SAA chip entirely, as the VERA PSG makes it redundant, which brings the channel count down to 25. Having a native tracker program work with 31 channels seems pretty hard, meanwhile it's far easier for the C64's 3.

The trick is that even though the X and Y values are technically "unsigned" (i.e. non-negative), you can still get the effect of negative numbers by going ahead and subtracting from 0. The value will "underflow", but you can write the bits to the VERA anyways and it will treat it like a negative number. Another way to look at it is that you've moved the sprite so far off the right side of the screen, that the VERA eventually wraps part of the sprite around to the left edge.

OK, well, thank you. I went ahead and issued a pull request, and hopefully no one will be too offended by my doing so.

There are a couple of people working in C. In particular, folks have been getting X16-specific updates pushed to cc65, a C-compiler and linker that specifically targets 8-bit platforms based on the 6502. cc65 is being used by a few folks for straight-up 6502 assembly programming, since it includes a fully-featured segmented assembler as well. I believe someone is working on a version of Turbo Rascal for the X16, but I can't recall who that is. They've been on the Facebook group somewhere with a tech demo. And then there's @SlithyMatt, who benefits from a seemingly endless well of energy, passion, and time, and has not only already completed a game for the X16, but is working on a high-level game and scripting engine called XCI (eXtremely Compact Interpreter). And is contributing to a JRPG being developed for the X16. o_O I'm not sure what his secret is. I just hope its more along the lines of being excellent and not mysterious transparent pills. I don't know of any assemblers or compilers that run directly on the X16 yet.