Crazyace

This is just wrong - there are only 4 birds on a line at a time - that's why you see flickering. ( Next you'll be claiming 16 sprites per line @15Hz )

The programmers reference guide was really cool for the C64 ( and the older Vic20 one ) but one problem with the C64 vs the A8 was the support in Basic for graphics and sound. Commodore really skimped by supplying pretty much the same basic they had with the original PET.. ( I read that they had some special deal which saved royalties ) De Re Atari and Mapping the Atari were good references for the A8, but they took a while to come out.

Doing Pacman with software sprites, sounds a little complicated. Sounds like you are using 320x192 mode. Why would you need 8 sprites for the ghosts on a C64. It does have multicolor mode, so you can use 4 with the white&blue eyes. I am wondering if its possible to do the Ms. Pac Man technique with putting a quad width missiles behind the players for the white eyes. Tempest Extreme uses a multiplexer routine the divides the screen into 8 zones and the DLIs set the color, position, and width for each section. When a sprite is between sections, it sets both zones to common values. It cycles through witch sprite it starts with on each frame, so if more than 4 sprites are required in a zone, different ones "sit out" each time. So if 5 sprites are in a zone, only 1 is cycled out. Don't thing blinking becomes noticeable until it gets to 7 or 8. In Tempest Extreme, that mostly happens when you have a bunch of flippers on top of you and you're caught at that point. I had some theories of how do something like this with other hardware like the C64, 7800, NES, etc. Issue with the C64, is lower CPU speed and 3 sound voices. Be hard to make something as intense. Needing 8 sprites is purely because of the width - the ghosts are 14 pixels wide, and pacman 13 pixels - which is bigger than the multicolour width supported by the C64. A monochrome sprite for the ghost body, plus a multicolour sprite for the eyes. ( I'm not actually that interested in coding it for the C64 - it was more a technical exercise to see what I could reproduce on the A8 ) If I had artistic ability I might resize the maze and ghosts - and a sprite multiplex on the a8 would work. But I dont want any flickering at all so I'm using s/w with underlays. The underlays are dual width players which have a coarse outline. I'm not using the missiles at all at the moment though... ( I did work out that if I reduced the map size the sprites would be 10 pixels wide, and then the underlays would match perfectly - but I'd probally switch to a different technique where only the eyes were s/w sprites ) Also Pacman's quite a simple game

I'm using software sprites - mainly because I dont want any flickering , There are 4 ghosts each each 14 pixels wide with 3 colours , and Pacman which is 13 pixels monocolour - too wide for normal h/w sprites, but ok for soft sprites with h/w underlays. Multiplexed h/w sprites are quicker - and better in a lot of cases, but they wont solve the problem of 5 wide sprites on the same line. ( Even on the C64 you would need 8 sprites just for the ghosts )

I think the biggest problem with artifacting is the difference between PAL and NTSC.... One problem with the Apple II was that it didn't work in Europe until a graphics card was added. At least with the standard colours the 8 bit games ran world wide ( 50/60Hz was a different issue )

Good Question. I had a C128 for 2 weeks at home in the 80s for testing (and buying it cheap by interest) and no game was really interesting there. Neither Sanxion nor Test Drive or else.... Wouldn't it be the fact that the C64 was a newer machine? I had one briefly when converting a a8 game - but my finances were very tight, so I never bought one to play - by the time the a8 was dead I'd moved on to the ST ( via a Sinclair QL for a brief time ) Also if the C64 sold 20 million - that's way more than the A8 , so it makes sense that a lower % of C64 owners have an A8

Multiplexors are pretty standard - from the VCS onwards. The real limitations come from the horizontal limitations. To move a multicolour sprite is probally going to take an entire line ( including IRQ overhead and other Antic fetches ) - so realistically you only have the other sprite active on that line. I actually find it interesting that both the C64 and the A8 have quite unique sprite subsystems. Nearly all of the other machines - even going up to the SNES implement 'virtual' sprites .. ie: A large number of hardware sprites that share a small number of 'physical' sprites per line.

To match the mapping of the RAM best - you could have a 8k + POKEY card 4000-5fff POKEY 6000-7fff 8K ram 8000-bfff Banked rom c000-ffff Fixed bank rom ... That should be trivial to add to Mess/Prosystem emulators... I haven't looked at carts.. Does the CuttleCart support Pokey? It should be easy, but there are lots of other people here with more H/W design experience

Head over heels seems to be running quite nicely as an isometric game on the C64

Was the 640x2 mode on the A8 NTSC - how well did it work, I never saw any real 80 col displays ( but I have to admit that 80col wasn't high on my list of priorities at the time )

PMBase and Blanking are not part of the sprite positioning logic - there is no 'start sprite at line Y1 and stop at line Y2' in hardware, so I still say the PM graphics are 1D. There is no Z-axis - TV is only 2D ... the effect is purely horizontal scaling. What do you mean by VBlanking method - you stated that you could multiplex more sprites horizontally - I tend to disagree, as the cycle counts dont really add up. ( Are you talking about flickering sprites by switching on different frames? ) Isn't VDELAY merely a 'disable' for loading grafp registers on odd lines. And how does PMBASE move a player in the Y direction... all it does is point to a different set of graphics. I used VDELAY on the 2600 , as it's essential for the 6 digit score and other similar routines, but I never had a use for it myself on the 8 bit .. It would be interesting if there is some undocumented functionality.

I think that there's no technical reason that stops exactly the same isometric 3D routines being used on a C64. It may have a slower framerate though. One really nice thing is that if the width is limited to 192 hires pixels you could underly the bitmap with a 2nd bitmap made up from multiple sprites - and get an effective 192x200 3 colour graphics mode. Of course update may be in the seconds per frame - but the Amstrad CPC versions of Knightlore etc looked quite nice. Another thing would be to place a sprite underlay on any character ( Maybe using 2 sprites to get 42 vertical lines ) You can combine a visual masking to allow hires with multiple colours. Oswald or someone more familiar with the C64 can comment if there are games that do this already. ( You could also do something similar on the 8 bit, but the PM res is only 160 - so it needs a little more care )

If you set up 12 16 high zones as follows ( using 40 byte wide with 2 sprites to give 160 pixels ) $6000 $7000 $6000+40 $7000+40 $6000+80 $7000+80 $6000+120 $7000+120 $6000+160 $7000+160 $6000+200 $7000+200 Then calculating address from X,Y is pretty simple.. t = Y & 224 address high = (Y &31)| $60 address low = t + (t/4) + (X/4) horizontal spans are consecutive, and vertical go up by 256 in zones - which can be used in line draw routines This works with the standard atari ram cartridge - you also have 2 groups of 16 bytes wide for ram sprites or vars.

also - with a S-VHS connection on the 800 it didn't work at all ( at least not on my TV )

As I said, it didn't work on PAL - there was a very weak 'tinge' but no real colours. And the 8 bit wasn't designed to use artifacting for colour - it had the 160x 4 colour modes already. I remember Threshold and Drol as games that relied on artifacting for colours ( Apple conversions ) - and the first choplifter. However Bandits was converted to A8 using 4 colour graphics ( plus some player graphics ) and looked far better.

Artifacting is an annoyance - and I think the main reason it was used on early games was due to the movement of code from the Apple II - where it was the method for hires colour graphics. It didn't really work on PAL at all - and the standard 160x192x4colour graphics modes were much more flexible. ( This is my opinion - I had a PAL machine, so I'm probally a bit biased... )

The SCV is definitely weaker than the 7800 - all of it's sprites are single colour. Super Mario Bros would be a great game on any platform though - maybe one day there'll be a version for the 7800

I have a problem with your argument.. If we take 1 multicolour sprite, just to simplify things.. Atari is 2 players - so 2 independant colours + 1 mixed colour or black.... that's only 3 colours - with the 3rd colour being very restricted. (The other priority combinations are very interesting - but they also involve playfield, so they almost negate the 'sprite' aspect - I would use them in the number of colours per line argument ) C64 is 1 independant colour + 2 shared sprite colours. - so for a single sprite there are effectively 3 unrestricted colours. For 2 muticoloured sprites things start to go to the Atari side A8 : 4 independant colours + 2 shared/black = 6 C64 : 2 independant colours + 2 shared = 4 so if you stop here ( as you did ) the Atari seems superior... but that's a fallacy.. as you have pretty much exhausted the Atari H/W capabilities here ( missiles could be considers part of the players to avoid any arguments about sprite size ) and the C64 still has 6 more multicolour sprites. If anything the biggest weakness of the C64 sprite system is that there's only 1 unique colour per sprite. You can see it in action in most games and C64 programmers work around the limitation. However even with this limitation the C64 sprites are still more powerfull than the A8... ... Good at least you understood the definition of multicolor. Original argument was for comparing two multicolored sprites and I did agree C64 has more multicolored sprites. So as you state Atari has superior implementation, however you got the priorities thing screwed up. You can get the black even with sprite overlaps without involving playfields. First multicolor sprite has 3 colors + black if it intersects with part of 2nd multicolor sprite. Second multicolor sprite has 3 colors + black if it intersects with first multicolor sprite so its 6+black. This is without considering conflict with playfields. I disregarded the player-player priority as well - as it still involves interaction with playfield. It also isn't really a free extra colour - as you need the other players. ( I think using the missile as an extra colour might be preferrable ) It is a cool feature of the atari priority system though and if the C64 sprite system only had 2 sprites I would count it as an advantage... Yes it would work with the limitation of the C64 sprites ( 21 lines by 24 pixels wide )... If you wanted a single 224 line high multicolour sprite you would need interupts. Saying the Atari sprite hardware renders more pixels per frame is a strawman argument. It is a lot easier to multiplex sprites vertically - and both systems tend to use interupts. In my eyes the PM graphics are 1D sprites , and the C64 sprites are 2D - just because each player is a 224(ish)x8 object with one degree of freedom. The C64 is a 21x24 object with 2 degrees of freedom. How many multicoloured independant objects can you have per line ( not sharing graphics data ) - there are 114 processor cycles per line and you need lda #/sta grafp0/lda#/sta grafp1/lda#/sta colpm0/lda#/sta colpm1/lda#/sta hposp0/lda#/sta hposp1 to change a multicolour sprite completely That's 2+4 cycles * 6 to reposition a single multicolour sprite , and you need another (2+4)*4 cycles to reposition it for the next line ( normal player dma is quicker to refresh graf registers ) - so that's 60 cycles to reposition a single multicolour sprite - in a way that severely limits it's interaction or position. ( and Antic DMA may take most of the rest )

16k of ram is still not enough for anything It would be enough to run a synth - I've done it before with less or if you want a fractal display.. The ram difference is a bit excessive though....

clearly the 2nd one is better. 2x2 pixel and 16k ram is not enough for anything even if the cpu is fast. what I find meaningless is how people are joining discussions finding meaningless, telling everyone its meaningless. its meaningless I think a better comparision would be: RGB data latch, 16k of ram, 1ghz cpu, 8 mono fixed frequency tone generators -vs.- 80x60 pixel monochrome display, 512k of ram, 33mhz cpu, 2 stereo synths Then at least you could run a software loop to generate graphics - the CPU would be fast enough to handle coloured text or - what if you want to be a synth... the 1st system could be better as you could run a softsynth to give 100's of channels... and stereo wouldn't be as important in a single instrument. ( Actually - even a 33mhz cpu would be capable of some quite impressive soft effects )

I have a problem with your argument.. If we take 1 multicolour sprite, just to simplify things.. Atari is 2 players - so 2 independant colours + 1 mixed colour or black.... that's only 3 colours - with the 3rd colour being very restricted. (The other priority combinations are very interesting - but they also involve playfield, so they almost negate the 'sprite' aspect - I would use them in the number of colours per line argument ) C64 is 1 independant colour + 2 shared sprite colours. - so for a single sprite there are effectively 3 unrestricted colours. For 2 muticoloured sprites things start to go to the Atari side A8 : 4 independant colours + 2 shared/black = 6 C64 : 2 independant colours + 2 shared = 4 so if you stop here ( as you did ) the Atari seems superior... but that's a fallacy.. as you have pretty much exhausted the Atari H/W capabilities here ( missiles could be considers part of the players to avoid any arguments about sprite size ) and the C64 still has 6 more multicolour sprites. If anything the biggest weakness of the C64 sprite system is that there's only 1 unique colour per sprite. You can see it in action in most games and C64 programmers work around the limitation. However even with this limitation the C64 sprites are still more powerfull than the A8... If someone were trying to replicate the Atari pm's directly they would use 3 C64 sprites to emulate 2 linked players. It wouldn't be elegant - but it would work.

The Apple IIe came out in 1983 , the original graphics was effectively 140x192x6 ( b+w + 2 possible colours/7 pixels ) ...here's one picture... http://www.flickr.com/photos/blakespot/2417886747/ and some more here: http://toastytech.com/about/myap.html

Using 16 high zones: 37 characters wide x 12 zones high x 16 bytes each = 7104 bytes leaving 1088 bytes / 16. That would require 444 characters from the map for the screen buffer and still leave you enough space for 68 characters for a full alpha numeric character set w/punctuation . I dont know why you want to use characters though - that just wastes the dma time. Also holey dma is enabled by a15 so you wont need gaps in your hires screen. If someone made a custom memory module - what would be really cool would be a double size X and Y read

Someone has built a remake of the game for the PSP: Look: Colourfull with mainly the same colour count, but no eyecancer here. The colours of the C64 clearly miss "some" brightness steps of the available colours. This is a strange comparision - but for me it actually reinforces how good the original C64 game looked. ( perhaps you need to start a topic at lemon about c64 vs PSP )

If you only want hires graphics you dont really want the overhead of the character set fetch as well..