TracMan

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 new 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. They settled on 12 pixel wide sprites as artists got better at drawing for these 160 wide screen. Despite all Atari's apparent powers, they even go on to beat the Atari further, 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. The inclusion of Hires/lores on the same lines keeps the C64 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 kernels 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 RAM in the machine returns as a problem, so much that, using cartridges to avoid the extra RAM returns. 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 C64 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 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 would still be scanned down by Antic, but 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 achived: Mixed Hi res and lo res Colour map Hi res sprites Still, any revised machine would still have been amazing graphically, ahead of virtually all other competitors and even better as a gamers machine of choice, specifically, if a passthrough type cable in the catrridge port could have been added like the 7800, while still being backwardly compatible with the existing cartridge port. This would have allowed synth chips to be powered from on a cartridge. 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 of games that are convertible from the C64 back catalogue rather than whole graphically stunning new 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...