Crazyace

It was a lot more interesting when you were talking about games and graphics - Disk drives seem to have bought out the worst fanboy tendancies As an aside - I've bought an SIO2PC for the Atari 8 bit ( so that I can test things on a real machine ), is there anything similar ( and cheap ) for the C64 - I'm tempted to ebay one but it would only be for remote testing

also there's no need to use indirect mode to get hires graphics? Just set two sprites up per zone...

Why not develop for the Summer Games cart ( 16K ram ) and forget Pokey for the moment?

But this system doesn't work for more than one object. Also there must be quite a large over head in setting up the interupts to handle this - I guess you are using timers, as DLI's may only be occuring on character boundaries? How many cycles are taken up by the overhead of your two interupt routines per frame?

Nice pictures, rich colors. That clearly shows how A8's various colors can be used to make scene more alive. yeah, luckily its the rainbow scene, even a 2600 would cope with it better then a c64 Now that would be an interesting challenge I think quite a lot of the original C64 table could be reproduced on a VCS

Not sure - it can try... but the DS is way more powerfull than the 7800 ( it's more powerfull than the Jaguar ) and it's throwing around the kind of particles that would make Jeff Minter proud

"Announced and demonstrated in January of 1977 at the Consumer Electronics Show in Chicago, months before the Apple II or Radio Shack TRS80, the Commodore PET was the worlds first "real" computer" apple II started to sell earlier than the pet tho, correct. The PET 2001 was one of the first microcomputers I used at School - our Physics teacher bought it , as there was no 'computer studies' class - before that I'd been using an old PDP-8 via a TTY , and also a 300baud modem link to a shared PDP-11. It's amazing how similar it is in concept to the IBM5100 which came out in 75 ( although as an IBM product it was way more expensive ) The Apple was on another level though - games and graphics on both the PET and the TRS80 really looked poor compared to the high res colour capabilities pretty hard. it would be easyer on todays beefed up a8s with the extra memory. the biggest problem was to squeeze it into 64k. the game has to realtime depack slope,collision, and masking tables (needed when the ball is under something). the math is at 24 bit precision. unused parts of the game bitmap holds data (turned invisible with the color attributes) It's always impressive seeing things on old consoles - both the A8 and the C64

That's really nice - I'd be tempted to make the hires boundary between brown / cyan at the top look lores to match the lower section ( and avoid artifacting )

I think even the A8 could attempt this in hires, but it wouldn't be as easy as on the C64 - I dont actually know why it's not in hires anyway - the original was ported to MSX, which is quite similar to the C64 hires mode Plus it's very easy to show 5 colours per line on the atari ( not thinking about the GTIA modes ) - more if difficult , but it's impossible to show 128 colours on the C64 ( without TV hacks such as flickering ) Apple II June 77 Pet October 77 TRS80 (announced) August 77 - so probally later Atari 800 (announced 78 ) - definitely later When the Atari 800 came out it was pretty price competitive - especially as only the Apple II offered colour graphics.. The Vic-20 was pretty nice for the price though maybe you missed the c64 port ? it would be fun compare it to the 4-5 colored a8 counterpart It would be fun if the C64 port was actually done and not just a WIP demo that seems to have been abandonded. atleast is exists. only the scoring logic is missing. That's really cool - I loved playing pinball dreams & fantasies on the Amiga. How difficult was it to reproduce it on the C64?

and the c64 has to juggle around somehow to show 128 colours? I agree the JBJ that this game doesn't need to be in 320 pixel mode - and if it had been written at the time it would be in 160 mode without any major complaints. The version shown is demonstrating how to emulate the particular c64 look. An Atari version could look like this ( Amstrad version )

The original arcade game is 256 pixels wide - have you looked at that?

If you want a high res ball the bottom of the screen will need to be high res, as if you miss your serve the ball shrinks.. It's quite a accurate conversion of the screen though

I think that demo is just standard mode f scrolling - but it's using the players and missiles to show a starfield

Is the ball really going to look bad at 160res - I didn't have any problems with the atari tennis game.

Cool - what 5200 Rom was it? It would be nice to see your method in operation, because I keep thinking of limitations to it - and I must be missing something else that you're doing or else I'm thinking of a different problem to the one you've solved. Why would I try to implement a double buffer PM system in rom - that would be stupid.... now try to implement multiple animations with your method in rom - maybe with 100's of different frames

I still have problems with this... I can understand it working for one object, but for 2 objects I'd expect that you need 16*16 different PM bases to handle all the combinations. I guess you have something like this (simplified to a 8 line high sprite) PMBASE PMData 0: ++----++++----++++----++++----++ 1: +++----++++----++++----++++----+ 2: ++++----++++----++++----++++---- 3: -++++----++++----++++----++++--- 4: --++++----++++----++++----++++-- 5: ---++++----++++----++++----++++- 6: ----++++----++++----++++----++++ 7: +----++++----++++----++++----+++ Then you have an interupt at the start line, and end line of the sprite to set the X position ( or enable /disable DMA ) To me this seems unworkable beyond the single object - but I may have misunderstood your method? Ok - I never played around with priority conflicts - they always seemed to also involved the PF , which made them less useful for games. Does the conflict give you a different 'or' colour to the normal 'or' colour from combining two players? ( It's not a 320 mode only feature is it? ) I think you can only argue about the 'whole' sprite system - if you really were pedantic you could claim that the c64 multicolour implementation was better because it only needs a single sprite

and the audio timers are normally used for audio

I dont think that's true.... All Atari sprites give 4 player colours + 2 'or' colours + black + '5th player' PF colour = 8 colours. All C64 sprites give 8 sprite colours + 2 shared multicolours = 10 colours.

Example: You can scroll this 27 colour picture(including the shapes of the PM graphics) in and out of the screen by only changing the scrl register, and changing a char line of the Displaylist. Actually if this is 27 colour you cant display it at all on a C64 - as the pallette isn't big enough

yea, strangely I saw that just the other day too, I think that must be fake. Colour usage on the CPC was pretty free and there's some nice looking conversions. Ghost and Goblins looked pretty close to the Arcade in terms of the other 8-bit versions (apart from he didn't lose his armour when hit). Beyond the ice palace looked very good on the cpc I thought. well, lots of others that could be mentioned I guess. I hear it was very difficult to achieve a lot of things on the cpc we take for granted on the A8 and C64 with it's lack of hardware however. The CPC was pretty nice in terms of graphics ( if it had h/w scrolling as standard it's games would have been way more impressive ) I ported jetboot jack from A8 to CPC a long long time ago.... ( tape assemblers, and lots of typing hex numbers in from graph paper )

It does move two multicolor sprites independently in the Y-direction given you have to use one of the methods I mentioned to resolve the zone conflict (vblank, grafn, ...). There are no missiles so you have 1K spare out of the 2K PMBase memory. For animation, you can just have another PMBase rather than update all the PMBases. In the example, they wanted it 8*16 multicolor sprites so RAM useage was 16K. Wasn't trying to do Bruce Lee sprites-- but that was where I was suggesting that they could have used an OR color if the sprites were multicolor. How many different PMBASE values do you need? It seems to me that this system would fail badly in any real situation. Why not just double buffer the PM list and display list ( interupts ) so you have the entire frame to fill the players and set up the interups to move/recolour them. It would be interesting to see a demo though ? Have you got an XEX or ATR image

Funny... I was looking a Nebulus/Tower toppler on Sunday... Have you looked at the Amstrad CPC version - they have a nice sprite defined at 160 pixels ( the screen mode is 160x 16colors/pixel ) ( I originally saw a youtube of Amstrad Street Fighter II - which looked like a fake , but then I thought that the only reason it might be a problem on the CPC would be the cpu time - but it could work on the 7800 )

Bandit's was an Apple II game, converted to A8 and C64. It throws around a lot of software sprites - and would need some serious multiplexing to run using h/w sprites. ( look at the later levels when the bandits, centipede, and balls are all on the screen at the same time ) The C64 look is probally closer to the Apple II original - but the Atari runs faster.

never tried any horizontal mode changes , just read some of the comments about it. It's quite a nice border effect

That's interesting.. I guess you have two sets of multicolour players p0 lum 4 , p1 lum 8 , p2 lum 6 ,p3 lum 10 ( and BAK lum 2 ) then the gradient is bak , p0 , p2 , p1 , p3, p0|p1(12) , p2|p3 (14) pf0 - pf3 can be red , rainbow, black,white - total of 12 colours per scanline .... or is it some other method?