TracMan

The scrolling part using LMS is really not difficult, it is simply CPU labour saving. However, there are different and complex ways of providing and laying out the memory for the scrolling region. Most screens will typically have different regions such as a change in graphic mode in low or hires/ LMS for any non scrolling score panel, so fix the memory and the LMS for that into the display list first. Then at it's simplest lay out the full scrolling region memory based on the number of bytes across the scrolling region x the number of lines. Imagine a simple example, if you were using Antic mode 4 (basic mode 12) instead, since it's also 40 bytes across, if you allow 128 chars per line, you get 128/40 or just over 3 screens horizontally. Say you are scrolling over 16 rows of the screen, that's just 16 x 128 bytes or 2k for the whole lot, not bad when you think 960 bytes (40 x 24) is required normally for one screen. So you would set each LMS instruction at 128 bytes plus the one on the previous line. Each time you want to move the screen fully one character to the right, you just need to clear the carry flag, increment the LMS instructions memory pointer low byte and then if there is a carry, additionally increment the LMS high byte. Bingo, the screen 'view portal' moves across the graphics image. Because, if you already laid out the screen data for several screens wide, you only have to deal with the increment of LMS instructions. There is no requirement for drawing new data to the right hand side of the screen. Best example here is to think of the game Scramble where it scrolls continously. However, when you do this with Mode 7, then you have a lot more mode lines and hence LMS instructions. Any horizontal layed out memory will be 8 times bigger to support each row line. But, see how much simpler it still is to increment only up to 192 LMS instructions using the method above, rather than do a complete move of the screen like other machines have to do. However, there are scrolling games that use bitmap screens that lay out the working screen in a couple of screens width, since you can't afford the memory to layout all of the horizontally scrolling level. The way they work is to allow you to move your view portal across into the 3 screens width where they are 'building' the level and at some point, they jump the LMS back to the left most first screen. So they draw the new screen in two places, on the right where you are moving into and redrawing it on the left behind the area you already scrolled through, so you can jump back to it.

Great story. Showing my age but read this magazine inside out from the very beginning in 1982 and used to keep a stash of magazines. My father had bought an Atari 400 the previous Christmas from the elevated part of the back of a Birmingham store which was either the old Currys or similar brand, the part of the store was called Micro-C. I craved over the Atari 800 with it's superior keyboard and that mystery right hand slot. We were pleased to see a UK Atari magazine coming in so cheap at 50p, since back then we bought imported Antic, Analog and Compute but they were harder to get and they were more priced at an inflated amount because the price in UK often simply matched the pound and dollar pricing, despite the pound being much stronger back then. We had stopped buying the other main UK magazine Computer and Video Games that covered Atari because sometimes the listings didn't work and it had less Atari specific reviews. Page 6 bought in a era of buying a UK specific computer magazine at your local newsagents, plus the pleasures of learning via type in listings and tutorials in programming which your father was successfull at. I have definitely read his stuff. After so much learning, frustration and investment in software, adding an Atari 800xl and later 65XE, why would we move from the Atari branding, refusing to even consider owning a Commodore at my friend's suggestion who had a C64. Why would we want just more games? I read Page 6 until at least late 1990 and also the Atari ST section games reviews avidly so would have certainly read your brother's reviews. We wanted a step up to the new software opportunties that the ST bought with the inbuilt disk drive and design being so alluring and were lucky to get one of the very first Atari STE computers in 1989. I stopped buying New Atari User and was by now an avid reader of the newly split ST format (which on start up used to be for the Amiga and ST). At that point glossy photos, articles on DTP, C etc and double page reviews won the day. I can't even be bothered picking up a PC computer magazine these days or even reading one online so it shows how good these early magazines were.

The Spy vs Spy series. Ballblazer Joust

Seems to be confirmation to me that an Antic Mode 4 mode layout (with character graphic sprites) exploiting the 5th colour can work very well. Very smooth. I wondered what are the different approaches or new software techniques being used (eg. to plotting and preshifting) for sprite manipulation?

I've not downloaded Space Taxi, but exactly, yes, from the screenshots page, the "Game Variations" page looks exactly like what I describe when you print a character from the character set in inverse in Gr. 0 and put a quad sized PMG pixel over the top writing up to 8 vertical PMG lines into the character position. You only need to play around with the brightness of the text pixels (location 709), location 704-707 and 711 can colour the text. It's not very tricky at all. The way they have done IK+ on first few status lines can almost certainly be done the same. Unlike C64 and other machines that have 256 characters in a character set, Atari does inverse automatically when setting bit 7 to 1, but if you are in Gr.8 obviously you'll need a plot character or write text string in inverse routine starting at a screen 0-39/0-23 "cell". G2f can let you "colour" hi res heavily but actually if you look back at the old games 180 (dartboard) and also Druid (top panel), you can see there was even some attempt to colour hi res back in the day. So the generic print text or draw graphics on a line is for each overlayed QUAD size PMG, to put in a 1 in up to 8 of the 8 pixels for each coloured text character, with a bit 0 obviously where there is a blank space in your text or graphics. You could write a generic print coloured hi res text routine to do either the PMG bits 0 or 1 from the text, depending if there is a printable character or a space. A poke of 255 in either a player or the 4x missiles would give you a max length of 8 characters across, eating up 8 characters of the real estate I refer to. Hence, whole lines of the same coloured text are very easy (0-40 characters), if you align all the PMG HPOS exactly 8 text characters across from each other (I believe that's 32 pixels across from each, so HPOS1 = HPOS0+ 32 etc.). Also, when you plot the PMG vertical lines (up to 8 per character cell, my advice for text is to miss off the bottom line and write 7, as there is nearly always a blank line at the bottom of every text character). Back to the real estate, to emulate a ZX Spectrum game might require up to 8 colours on a line, C64 could even do 16 colours on the line. Thankfully games don't need to be that garish. An example of difficulty might be trying to do something like the men on the bottom of the Jet Set Willy game showing the player lives, because you only have those 32 or 40 real estate pixels which are coloured in "batches" of 8 characters due to the width of the PMG... unless you can do mid scanline changes of their positions. When you get advanced and doing an intricate part of the screen, you could try an overlay with selective pixels (see Druid) but that of course eats up the real estate more quickly.

Panel at the bottom is nicer on C64.

Yes, I think with the PMG / GPRIOR limitations in Gr.0 or Gr.8 , what Atari is good at is: 1) What I call "ambient lighting" type games where the ink is ALWAYS black and only the paper changes. As mentioned above, the trick is that Atari PMG on top of the Gr.0 graphics can produce a non black but close to black, which looks so good in games with lighting that are indoors but equally some outdoors, like the light is casting into the screen. What Atari can simulate (without VBXE) is: 2) Some multi coloured hi res text and character graphics like hi score tables, status lines and on screen graphics. The fewer colours on a line, the easier it is. The trick is to print the character set in inverse and add coloured PMG on top in quad "square" pixels on top of each text character. Think of the letter A in inverse character graphics, then put a single coloured block over it, the PMG shines over the whole thing but the "solid" edges round the outside fade to almost black (the halo you refer to) and the "black" part in the centre becomes close to the colour of the PMG. All PMG are set to QUAD size, because on an Atari 8 we have 40 real estate PMG pixels on a scan line ([4 players x 8] + [4 missiles x 2]). Since each low res PMG pixel normally covers 2 Gr. 0 hi res pixels, setting them to QUAD size means they exactly cover 2 x 4= 8 pixels and one Gr. 0 character, hence we can cover either a 32 width screen using the 4 players or a 40 width screen including the missiles. You can of course play around with two shades of the same colour like red. What Atari is not capable of: Two colours per cell, where one is not black or "white" or they are not two shades of the same colour.

Quite simple approach - write a subroutine to move the PMG up and down by one line , similar to any code you would have called by joystick for moving the player. If your game is a downward scroller, additionally in every Vblank where you change vscroll , just call the PMG down one line routine as you used for the joystick.

Zx spectrum travel through time would be awesome.

I know we talking gameplay here but I wonder what it would look like if some levels used the same parallax bottom of screen technique but with the lines in hi res like those C64 games that mix hires parallax. See the ones @10:34 in the video above. Also would like to see the screen "remixed" so the bottom part of the top user interface with the colourful flashing panel lines are instead at the bottom of the screen , the score panel still at top, this might remove the "restriction" feeling of not being able to move up higher on the screen but framing the whole screen vertically.

My bad, I assumed the GRAFP/M registers being loaded already was enough to reduce the DMA. Is that VDELAY the one that moves the graphics down one scanline down to odd or even lines - I only learned about this recently, don't remember it being mentioned in any the COMPUTE GRAPHICS textbooks I had. Wonder if anyone uses it. Thanks for the correction

It looked like there were a couple of optimisations or advice for the future: 1) LDA #$0E , STA COLPF2 seems to appear several times. LDY #$0E at the beginning of your DLI and then STY COLPF2 each time will save you a few cycles. 2) LDX COLRSH - is this necessary? Again, might not have much cycles left if you are changing a lot but just load it with *anything* you have that you load into A several times and STX away without the LDA. Looks like #$86 or #$0E are used several times? 3) Avoid STA WSYNC, if you think about it, the cycles required for STA WSYNC are completely unnecessary if you already near enough the edge of the screen and running late, so you just miss it out on those lines and save the cycles BTW although it won't help the crazy timing critical stuff but does work if you have lots of DLI's with colour changes near to each other, a pro tip I learned off these forums - you can avoid PLA/PHA in your DLI altogether just STX <some zero page location reserved for X> and at the end of the DLI, LDX <zero page location location reserved for X>. Can do this for A, X and Y, eg. 3 locations, I have these save/ restore pairs as macros M_SAVEX, M_RESTOREX etc. Makes it less error prone if you are quickly writing a lot of DLIs in case you type TAX and mean TAY etc.

Guys, some example coding here to show the complexity of Angry Birds but you can see in the event loop that the physics is gonna just be floating point stuff and simple F=Ma equations thats required, which is ok for a few objects but even the graphics libraries can be almost the most complex: https://github.com/yuduozhang/AngryBird#:~:text=GitHub - yuduozhang%2FAngryBird%3A An,(1965 lines of code)

Don't forget if you have turned on PMG with DMA, that will certainly use more cycles at the START of EVERY line. You can use double line resolution rather than single line to reduce it because there is no refetch per line. But like the poster above says, normally there is plenty of time to do what you want. However, perhaps you could simply try turning off PMG DMA via SMDCTL (memory location 559) with bits 2+3 to confirm with no other changes to your code if it is any better. Note: missile DMA is always fetched when player DMA is on for consistent timing. Here's the definite bit values: https://www.atariarchives.org/mapping/memorymap.php As an extra thing to explain DMA affecting timing is that you could in a game turn on and off Player + Missile DMA before the scan lines where the PMG is used, for examples turning it on after the top border and off in the bottom border, you just have to set GRAFPx or GRAFPM registers to 0 in the Vblank and in the last interrupt as they will contain noise. This can be used to speed up the game logic in a game a small amount, if the sprites are limited to an area of the screen, the DMA can be turned on much later.

Oh like put some blank lines in ABOVE the panel and reduce appropriately as the top increases huh

For IK and IK+, the blocky oversized underlays for the player sprites are being used as broad brush stroke colour as opposed to being used for graphic detail, and hence, by design of the game, they are restricted to the bottom of the screen, because, at the top in the background graphics where you need more colour and detail, you allocate the PMG shapes per line to exploit using them for finer colour detail (hence up to a possible 5 extra colours on top of the background four colours). So the two techniques are incompatible and there is the reason for the screen division. Even though I know how this works and could probably easily code it myself, I still find it tricky to visualise exactly what the best method to draw Atari sprites is, that is where I guess G2F comes in really useful as you can trial it out. By underlay, think of a regular patterned house carpet and literally putting say a red coloured underlay underneath it which sits over the top of your solid coloured black floor. Once you start cutting out template shapes from your house carpet, even if your carpet itself contains only two colours, you will get the red colour red through the shape holes and also, if the red underlay was made of regional shapes cut out as well, like the Atari PMG, you could also still get the black floor colour showing, although two limitations being are that you can't get the black floor showing in detail if the underlay itself is blocky and you have to sacrifice the one foreground colour. Also, want to say that I thought Rawel's team IK+ conversion was outstanding at the time and enjoyed the technical discussion on the webpage, the genius of Archer was apparent in pioneering the technique, but he likely had to rush IK to get it done and the Polish developers worked out that IK+ wasn't graphically beyond the Atari 8 either. Shame it wasn't completed.

Started thinking of how Atari design could have been expanded post release of the Commodore C64 in the XL/XE systems to try and bring back some market share. I don't imagine anyone at Atari knew what Commodore was up to in those intervening years between '79 and '82 with the release of the C64, which was a shame. The C64 designers don't credit the Atari at all, yet, the machines have a similar font, C64 has a compatible 160 pixel 5th colour mode, provides horizontal and vertical scrolling registers and the joystick port design is copied. However, this amounted to very little, since what the C64 engineers must have done in those three years was seemingly figure out exactly how to avoid programmatic solutions for the stuff that Atari can do, by adding solutions into hardware. First they settled on 12 pixel wide sprites leading to artists getting good at drawing detailed sprites for the 160 wide screen. Despite all Atari's apparent powers, C64 engineers went on to beat the Atari further on display lines, where it now becomes limited by it's unique hardware. For example, C64 avoids display 'lists' for line based mode selection and can mix hi res and lo res on the same line anywhere within the line. The only other computer being similarly line based restricted to the Atari I can think of is being the BBC micro. However, display lists aren't always the worst enemy, since they can be very powerful when scrolling and different screen sections, but they add the problem of being interrupted on a display line, rather than a screen vertical scan line, something again that the C64 engineers include with raster interrupts. The inclusion of Hires/lores on the same lines keeps the C64 graphics very much alive even today with those hi res parallax type scrolls we see in games like R type, at least until the 320 x 200 screens of the 16 bit machines, where everything can be Hi res or the resolution of the early arcade machines. However, the C64 engineers went on to add colour map (interestingly similar to ZX Spectrum being developed in the UK just around the same time) so that now, there is no need for kernel etc and every C64 colour can now be on the screen. What also is apparent that as time goes on and the competitive demands on the Atari increase(even now), the lack of available RAM in the machine becomes an issue, so much that, using cartridges as a design to avoid adding extra RAM is required. Frustrating. Because the XEGS returned as a cartridge based machine and this kind of design would have lived potentially much longer, like the Nintendo DS did, with cartridges falling in price, but they didn't fix some of the problems that Atari still had. I guess Jack Tramiel turning up at Atari was a great move for the 16 bit machines but they had made too many mistakes (abandoning the release of the 7800 with it's Maria chip and other elite chip designs). Where they could have made improvements to Atari 8: M0 - M3 2nd version. Looking at the PMBASE memory map discussed above, I figured a simple extra bit somewhere in an existing HW register could have enabled a second set of missiles M0'-M3'. Using one of the free spaces in the memory map, these extra 2 bit wide missiles could have automatically appeared at HPOSPM0+2 , HPOSPM1 + 2 etc, eliminating the need for any new HW registers for X positioning. This would have made doing 12 pixel wide sprites in one bitplane colour far more doable. Multiplex existing HW registers. This idea would be to simply allow the spare slots to be full 8 sprites (x 8 pixel wide). Everytime a HW register was written to, a new HW multiplexing register would have had to be written to in advance, to select the correct PMG 'bank' to apply the changes to. So, without more RAM or HW registers, there would have been far more HW sprites to display from within the Antic chip. Using the now limited PMBASE memory map as a new 'display list' instead of a memory map. To preserve backward compatibility, PM memory could still be scanned down by Antic, but in a different mode, instead of copying the data directly via DMA straight into the GRAFPx and GRAFM registers on each line, it would now check for 'load' or other instructions, where there would be an indirection to another memory address, where the sprite image was read from. The graphics chip would then spend the next N scan lines copying from the new location to the GRAFx registers. This allows at it's simplest, the chip to do vertical positioning of sprites and to do a fixed size C64 like sprite (say N=21) which would free up the work needed to be done by the CPU, typically which is in Vertical Blank. A more advanced version as an alternative to method 1 would have been to read 3 bit planes from the same place in a C64 style encoding of (21 x 3 bytes) + 1 byte padding and displayed these here, without using new GRAFx registers, thus, bypassing the limit of 1 byte for the sprite width. Using the PM 'display list' memory further, it could have had 3 independent HW colour values in there which were used for the sprite display (thus eliminating the need for more registers or using the regular display list interrupts) so this could beat the C64 which relys on 2 extra HW registers and fixing the number of colours per sprite to be 1 unique and 2 sprite shared colours. What they might not have achieved on Atari in an upgrade was: Mixed Hi res and lo res Colour map Hi res sprites Still, any revised machine could still have been amazing graphically, ahead of virtually all other competitors and possibly better as a gamers machine of choice. For music specifically, a passthrough cable in the catridge port could have been added like the 7800, while still being backwardly compatible with the existing cartridge port. This would have allowed superior synth chips to be powered from the cartridge port. Clearly, the Atari 8 is still my favourite machine to develop for, but in the end, it takes a lot longer to achieve the sort of things C64 does 'simply', hence sadly, we often think in envy of games that we can see aren't easily convertible from the C64 back catalogue rather than concentrating on whole new graphically stunning designs.

There was a pretty garish version on the BBC micro. Shame there was a lack of titles ported to the Atari that it could handle well back then. Coders clearly didn't cut the mustard for the required skill and complexity 🙂. But... then it might have been the ridiculous deadlines of the Software industry...

Good work. Would love to see a new Donkey Kong which has the correct number of vertical lines as the arcade

Yep. Explaining (for OP mainly, no doubt in my mind that the code I present is kindergarten stuff to the experts here😳😁),if you need five changes per line, three of those changes are easily done, before the start of the line. Goes without saying you should probably set the background/ border colour first 😁

I used to worry about sprite coding a lot which always made me think I should at least document all the "base" routine designs and if an engine was coded, one could be cherry picked for the next individual game. With experience, Atari programming is never simple, ie. there is no ideal routine for many games because people often try to emulate cool graphics that came after it's development (ie. on the C64 or ZX spectrum) and secondly, the only way to compete with those machines is programmatically. Up front design is where programmmers have to spend our time a lot and there isn't much fun for artists until the issues are solved. A programming error that I often used to make was trying to overuse the VBLANK routine for clearing sprites, moving them, drawing them and game logic. An idea just came to me today that in a bitmap mode, you could lock the whole program in a loop, where, if you sort all software sprites vertically, as soon as you knew a scan line you had prepared for in advance had been presented on the screen (via the HW register VCOUNT), you could reverse the work you just did ie. put the saved background bytes for a line back on the line. This works best when sprites are continually moving, but often we generally need to erase and draw all sprites on a line in case they cross each other. Any pointer to the start of the physical line or save buffer for that line is shared across all sprites, so you only have to load those once into a pair of zero pages pointers and you use the Y register as an offset for each Sprite horizontal position on the same line. The hard bit would be having the right offset into the image data for each sprite, so you could possibly use a pair of zero page pointers for each and a different offset for each sprite. You could also in theory suggest the HW changes for each extra color bitplane on the lines ahead eg. work out the PMG positions well ahead of the lines that you were working on as little routines which you call as part of the screen kernel manipulation. If there is a line where the suggested HW changes clash, then you can do just the mandatory ones (for the player's sprite) and skip out both the bitmap screen lines AND the HW change. This is an alternative to flickering whole sprites and just involves flickering sprite lines. When the scan line reaches the bottom of the screen, you can start on all the game logic, before the VBI would have kicked in. Would any of this save much time? Well, you will still require some mechanism for preshifted sprites and especially for the player's sprite, since you can't detect a player movement until the game logic occurs after you have read the joystick. Maybe you could do this 25 fps at the top of the screen as normal, whereas the other sprites movement can be worked out ahead by using tables (assuming the player sprite is always drawn last). It could be a crazy idea though with not having enough speed to do everything you want and as with every idea, only the final implementation decides how much better it really is.

There are shortcuts in programming DLIs, using the stack to push the registers onto and restore them at the end of the interrupt is often too slow in real world DLIs. Advanced programmers use free zero page locations to cache the registers A, X and Y (it's safe to use $80-FF out the box) because the number of cycles are less. See useful guide below for cycles used: http://www.6502.org/tutorials/6502opcodes.html Each PHA + PLA = 4 cycles each = 8 cycles, whereas STA <ZP location> and LDA <ZP location> are 6 cycles between them. As for the original question about changing the colours on every mode line, some of the terminology was a bit mixed up in the first answer, the display list you would want is pretty much just a copy of the exact same mode display list that Basic uses (without the text window), but with the interrupt bit set (bit 7 or +128) on each character line BEFORE you want the colour change (or as someone mentioned on each 8th line in a bitmap mode). For the top line, you can add the interrupt bit on the blank lines or LMS lines, beginners forget this sometimes. When an interrupt occurs, depending on the mode, the beam can be still some way off the edge of the right hand side of the screen. A bitmap mode can be way better to use than a character graphics mode in the cases when you want to do a lot (especially multiplex PMGs) because you have more CPU cycles to make the changes seamless to the user (you just lose the benefits of character graphics and the 5th colour which frustrates inexperienced programmers). In a character graphics mode like Mode 4, the Antic chip has to read the screen memory and go off indirectly to read all the values from the character set to draw, unlike just reading the memory for the bitmap mode so it actually reduces the CPU cycles available for your DLI. Note: in Antic 4, additionally the HW register CHBASE is also reread every line, so you can also easily change character sets which can be very useful for games. In an interrupt, you should actually avoid the STA WSYNC for as long as you can and in some cases, you can avoid it altogether (as when you do it the Antic chip halts the CPU via the interrupt line until the beam is at the left edge). To do many changes, you should load up the registers with 3 of the colours or other HW register changes and use the ZP locations as I mentioned above, to reduce used cycles. Example below: ; Equates SAVEA=$80 SAVEX=$81 SAVEY=$82 SOMEDLI ; Save registers. STX SAVEX STY SAVEY STA SAVEA LDX #100 ; Colour 1 LDA #48 ; Colour 2 LDY #14 ; Colour 3 STA WSYNC STA <HW REG 1> STX <HW REG 2> STY <HW REG 3> ; Restore registers. LDX SAVEX LDY SAVEY LDA SAVEA ; Exit interrupt RTI As to whether you can get more changes in, remember you are only making delta changes for each line, as sometimes one of the colours that you want was in the previous set. You don't have to do all the changes on the interrupt in one line. Try and work out how the colours will be used on the line, if near the end of the line there is only one or two colours with say two other colours not being on the screen, then you can also do the work in the initial cycles before the STA WSYNC as above where you stored the registers. No one will see them as the Antic chip has finished reading from RAM and the HW registers (DMA access) and the CPU can do it's bit ready for the following lines. Similarly, if certain colours aren't used until a bit into the left of the screen on the next change, you can change them well AFTER the STA WSYNC without any issue. You only lock up the CPU in the available time between the beam reaching the end of the previous line on it's own and the STA WSYNC. Even more advanced, if you think about it is that you can even avoid the STA WSYNC altogether as it's unnecessary when you cycle count your code and the CPU execution time is enough for the beam to have already reached the beginning of the next line.

A quick summary that I've learned over the years and from the forum. PMG are always very limited and work in some cases where there is not a lot of vertical positioning clash, eg. perfectly in Shanti's Gacek (version of Bombjack) and his The Last Squadron. I would always just prototype the game using character graphic sprites, so at least you have it moving and can focus on the game and you get tiling and scrolling for the background much cheaper. If you don't believe me, look at many ZX spectrum games like Golden Axe and Atari's own Donkey Kong Junior. This will get you started and running much quicker. So, the best way to think of Atari PMG so you don't get frustrated, is that you get a few objects per scan line that can do extra coloured bit planes which can be individual colours. Instead of splitting them up, join them together with their missile or another player, eg. with a one player/ one missile pairing, you can get an extra 4 x 10 pixel bitplane for four sprites, offering up to 4 extra colours, or with a one player/ two missile pairing, you get an extra 2 x 12 pixel bitplanes in one colour and 1 x 16 pixel bitplane in another colour. In some games, the character graphics mode 5th colour comes in very useful. IMHO you shouldn't fear a small amount of colour clash when using that colour also. Think of the flames of a flamethrower or fireball ie. something that doesn't matter if it illuminates a few extra pixels when passing across the background. Additionally, never underestimate the power of allocating black and white colours to the screen. They look great when mixed with a small amount of colour. Games that have a black background and contain black in the sprites are also easier to do because you have a "free" colour. So even with character graphics sprites, you can still multiplex the PMG vertically and put them on top of the sprites, but it is harder to multiplex in character graphics modes because you can't easily reuse them vertically except on a character line(bad lines). Other methods rely on the screen being in bitmap mode, it is here where you have much finer control over the vertical positioning, hence can reuse freely PMG but you still only have the 4 foreground/background colours per character line. But it's always useful to consider either bitmap or character graphics at the beginning, it's just that it will change the implementation a lot. You can write your engine to use preshifted sprites and expect the game to not necessarily fit in 64k or you can try an implement the elusive just in time shifter which again, I wouldn't concern myself with to get something working. Also, never underestimate the power of PMG underlays. See the Atari version of IK and the IK+ demo. This method is great when you have a foreground colour in your background like the ground and you simply cut out shapes and there is a doubled or quad size PMG block underneath that shines through over the true background colour. This means that the same fighter graphics can be reused with a different coloured shirt, simply by using different colour underlays. Finally, never rule out using a mono character graphics or bitmap mode instead of a colour one, where you position quad size player missile pixels down the screen to colour individual character graphic squares on top of hires graphics. Your sprite colours are no longer restricted to 10 pixel bitplanes. Sprites are often 16 pixels wide. This is kind of similar to a ZX spectrum attribute map. Look at Skool Daze, Saboteur, Way of the Exploding Fist or Light Force for the ZX spectrum. These games often look fantastic when they use a dark pen on the coloured background, I often consider these games to be using a kind of "ambient lighting" as they work especially well with indoor scenes.

For any car game like this, I would use lots of character set graphics shapes simply only in the foreground black colour. Background colour can still be black also. You should optimise routines for drawing character graphic rectangles of different heights, as the trees should be much taller and narrower like the original like they are above the horizon. The trees should also look more like they are alternating left and right. With any black outlines (in the foreground), you can experiment with PMG rectangles in double or quadruple width in various places as underlays (with the correct GPRIOR setting = 4, so that the colour shines through. Don't even blend the character graphics in as masks to make good progress, since at speed it will look fine. Have a look at the later title Turbocharge for the C64 and see if you can see much evidence of blending in. You could always have two versions of the tree tops, one over white and one over blue and these could be distanced by just one bit in the character set (eg. bit 7, so it could be EOR'd in).

Hmm.. cassette version sounds like it would fail for some reason.. memory wise and on a real system... I think Half life 3 will make use of a hard disk of some sort. I certainly wouldn't even know how to load it these days - CLOAD? But I tried your release in Altirra but it didn't work and was then overwhelmed by the number of options I would have to try to get it working including the most simple of adding Basic in case you forgot to mention. So I've decided to wait for the real thing. But let me know if it can be made to work on Altirra?