TMR Posted November 25, 2008 Share Posted November 25, 2008 I thought you were also a good Atari programmer. You can change the font at any DLI. It's not the same as having a single 256 character font you can arbitarily place around the screen and if you're rendering software sprites on character screens with detailed backgrounds, that's around the time you start running out of space in a 128 character font. That's the problem i had with Reaxion on the Atari 8-bit, eventually it needed three fonts for the in-game display to retain even that much detail and the Plus/4 version just uses the one and requires far less CPU overhead to maintain it. Yeah, great they have Raster interrupt, but Atari has the DLI, IRQs, and simply writing cycle exact code that stays in sync. It's swings and roundabouts, we come back to the subjective opinions as to if it's better to have the DLI helping out or the ability to do stuff whenever you want with raster interrupts; C64 coders like being able to use character modes and kick interrupts in halfway down a character for example, the Atari can't do that with the DLI as far as i'm aware and has to trip an interrupt early and wait for the remaining scanlines. Staying in sync on the C64 isn't as big an issue as you're trying to make it sound either, demos do it all the time and games like Mayhem In Monsterland or Fred's Back have to be cycle accurate for their scrolling routines - in the majority of cases it's not really a need to be more accurate than triggering on the right scanline anyway, though. As supercat suggested, all those color registers would be lot more useful if they had a good palette. If they kept adding sprites, they would end up with more color registers than colors! Actually, there are almost that many anyway; two shared and eight individual for sprites with border, screen and three multicolour registers for characters. But you say that as though having individual registers for each element is a bad thing or something... As i said previously, the "hybrid" machine that Heaven was asking for nearly exists in the C64DTV - essentially it acts like a C64 but with a 256 colour palette (which is laid out similarly to the Atari) and extra functions to allow window scrolling. It also adds a large block of extra RAM and a memory window system like the Ataris use and a DMA (and two source blitter on the later PAL models) to shunt data to and from expansion RAM like C64 RAM expansions do. Link to comment Share on other sites More sharing options...
Crazyace Posted November 25, 2008 Share Posted November 25, 2008 In bandwidth terms the Vic is better as it has a 12 bit bus - that's 50% more. Even if a 16 colour mode took most of the b/w it would still be usefull for graphics. 80 column text would be extremely difficult ... If you spread the character fetch you could run 80+10 fetches per line though - widescreen would be 96+12 which would probally be every possible cycle 80+16 fetches woud fill the char buffer in five lines - leaving 3 lines with a little more cpu activity Link to comment Share on other sites More sharing options...
Oswald Posted November 25, 2008 Share Posted November 25, 2008 Yeah, great they have Raster interrupt, but Atari has the DLI, IRQs, and simply writing cycle exact code that stays in sync. As supercat suggested, all those color registers would be lot more useful if they had a good palette. If they kept adding sprites, they would end up with more color registers than colors! on the c64 wsync takes extra code, but it "stay in sync" after that naturally. all those color registers would be not so useful with a big palette. 8 bit colors means instead of 3 different colors/chars the machine ends up with 1.5.. not a lot more useful I'd say. There was a reason why the designers decided beside 4 bit colors. Link to comment Share on other sites More sharing options...
+wood_jl Posted November 25, 2008 Share Posted November 25, 2008 I dont remember ever claiming that. qoute ? anyhow forget the amiga, its a8 vs c64. I was wondering when Oswald would chime in! Welcome! I love this stuff....most enjoyable reading on the web! BRING IT! Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 25, 2008 Share Posted November 25, 2008 ']aehm... and please upgrade my Atari with - 8 24x21 mono or 12x21 sprites multi - colour ram per cell - 256/512 chars font - "shadow ram" - hscrol per highres pixel that would be enough for me... btw. you don't need to have Wsync as there are ways around, DLI = Raster Interrupt btw. more text modes... the c64 has already more text modes than we Atarians know... check out www.codebase64.org I thought you were also a good Atari programmer. You can change the font at any DLI. 512 chars-- how are you selecting the char using 8-bit value? --- please look in the c64 hardware manual what I ment with 512 char... remember pressing shift + commodore key? and of course you can select fonts on via IRQ. Only restriction is the VIC-Bank but there are aways to avoid that too. And please ask Tezz and co what the main issue was with Bomb Jack... it was the font restricitons 128 char per "zone". and this leads to c64 conversion to 800... you are not able to take the gfx directly as 256 redefinable chars per font vs 128 chars. Yeah, great they have Raster interrupt, but Atari has the DLI, IRQs, and simply writing cycle exact code that stays in sync. As supercat suggested, all those color registers would be lot more useful if they had a good palette. If they kept adding sprites, they would end up with more color registers than colors! --- please again.... yes... I thought Wsync is great, too... but there are "standard" methods for c64, too to get the same... or how do you think would all these demo tricks possible without syncing the IRQs with the raster beam? so...now I tell you some other few important details... I can set on c64 at any raster position not only where display list bit is set... handy, too... but have you ever tried to do vertical scrolling plus DLIs? see my Boinxx... it is tricky, too as the DLI will move when doing vscroll.... so you have to correct that...on c64...scrolling is not binded to raster IRQs. Yes, I am programmer and touched the evil one and my love. But please have you ever coded a game on both? then you realise the 256 char font vs 128 char font... sure you can come cross like in my game with 7 fonts (3 per charline = 1 zone) but for what? just to gain 1 extra colour and to have char modes instead of bitmap mode or using hardware sprites. sure you can try to rebuild everything by software plus antic/gtia techniques but in terms of games I have to state that the c64 has more to offer "out of the box" esp. when using assembler. but I forgot what I am missing on c64 side... a linear bitmap mode... Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 25, 2008 Share Posted November 25, 2008 I thought you were also a good Atari programmer. You can change the font at any DLI. It's not the same as having a single 256 character font you can arbitarily place around the screen and if you're rendering software sprites on character screens with detailed backgrounds, that's around the time you start running out of space in a 128 character font. That's the problem i had with Reaxion on the Atari 8-bit, eventually it needed three fonts for the in-game display to retain even that much detail and the Plus/4 version just uses the one and requires far less CPU overhead to maintain it. Yeah, great they have Raster interrupt, but Atari has the DLI, IRQs, and simply writing cycle exact code that stays in sync. It's swings and roundabouts, we come back to the subjective opinions as to if it's better to have the DLI helping out or the ability to do stuff whenever you want with raster interrupts; C64 coders like being able to use character modes and kick interrupts in halfway down a character for example, the Atari can't do that with the DLI as far as i'm aware and has to trip an interrupt early and wait for the remaining scanlines. Staying in sync on the C64 isn't as big an issue as you're trying to make it sound either, demos do it all the time and games like Mayhem In Monsterland or Fred's Back have to be cycle accurate for their scrolling routines - in the majority of cases it's not really a need to be more accurate than triggering on the right scanline anyway, though. As supercat suggested, all those color registers would be lot more useful if they had a good palette. If they kept adding sprites, they would end up with more color registers than colors! Actually, there are almost that many anyway; two shared and eight individual for sprites with border, screen and three multicolour registers for characters. But you say that as though having individual registers for each element is a bad thing or something... As i said previously, the "hybrid" machine that Heaven was asking for nearly exists in the C64DTV - essentially it acts like a C64 but with a 256 colour palette (which is laid out similarly to the Atari) and extra functions to allow window scrolling. It also adds a large block of extra RAM and a memory window system like the Ataris use and a DMA (and two source blitter on the later PAL models) to shunt data to and from expansion RAM like C64 RAM expansions do. I have one here at work... maybe I should upgrade that with keyboard & power supply... And TMR is right regarding the 128/256 font.... I was just posting my message before I read his post. Link to comment Share on other sites More sharing options...
TMR Posted November 25, 2008 Share Posted November 25, 2008 I have been playing around with 160*200*8, 160*200*10, and 160*200*11 modes (w/o interlace) on Atari and I don't have any problem setting up my palette using the OR player mode. For example, set register 704 to 2, 705 to 4 and the OR will be 6 and you have 3 shades of gray using 2 indices. And what about if you want three colours and the third isn't the value produced by the OR? C64 would have been better off doing the OR or some logical operation rather than having two fixed color registers. So on Atari if I have two multicolored sprites, I can get 6 unique colors. On C64, if I use two multicolored sprites I can get 4 unique colors. Well yes... although that does mean you're running the Atari sprite hardware at full tilt and the C64 is leaving three quarters of it's sprites idle so as comparisons go it's a rather weak way of "winning". Even if we turn off half the C64 sprites and only use the same number that the Atari is using for those two three colour objects, if the C64 overlays two multicolour sprites and each object uses both unique sprite registers and just one of the shared multicolours (so they get one each) then it can match exactly what you're doing with the Atari except that the third of those colours isn't governed by a calculation based on the other two and can be selected by the programmer. If we use the C64 hardware at "full tilt" rather than hobbling it for the example, with half the hardware sprites overlaid to create one of two objects per scanline (which is what the Atari is doing) that's four unique and two shared colours per object or five totally unique colours if we distribute the shared colours between the two as before. Link to comment Share on other sites More sharing options...
emkay Posted November 25, 2008 Share Posted November 25, 2008 In bandwidth terms the Vic is better as it has a 12 bit bus - that's 50% more. The Atari has 2 graphics chips. One that has a 16 Bit Adress bus and one that has 8 Bit registers for colour counting... The colours are only limited by the GTIA. Even if a 16 colour mode took most of the b/w it would still be usefull for graphics. 80 column text would be extremely difficult ... If you spread the character fetch you could run 80+10 fetches per line though - widescreen would be 96+12 which would probally be every possible cycle 80+16 fetches woud fill the char buffer in five lines - leaving 3 lines with a little more cpu activity The Char fetch would not be necessary if they were stored in the external memory. Antic only was needed for down-compatibility to the older machines and for extensive screenusage. Only some command was needed then. a command that tells "E-GTIA" -> now compatibility mode -> now extended mode... The extended mode could be controlled by ANTIC's DMA. The Screendata is pre loaded and the DMA controls what's happening on the screen. There were two ways to store the screen data into the external RAM 1. Simply Data polling via writing into registers (good for Business use and 80 coloumns) 2. An "E-GTIA" Mode that can be loaded through a special command via ANTIC's DMA Link to comment Share on other sites More sharing options...
analmux Posted November 25, 2008 Share Posted November 25, 2008 (edited) And what about if you want three colours and the third isn't the value produced by the OR? Good point, but let's look at VIC2 sprites. 2 out of 3 colours are shared by all sprites. This doesn't happen on atari That's the reason why us atarians may use softwaresprites instead. Then, all we need to do is add one PM underlay to give us the 'same' freedom as on C64 (at least when the first 2 palette-colours of the sprites are the same as the gfx palettes) ....but, what's left to discuss? we don't need to say 1000 times that c64 sprites are way more powerful. I wouldn't even call PMG sprites. So, in fact, when we compare c64 to atari, we could say it's an improvement in a lot of aspects (far not all though). To make a 'fair' comparison, I'd only like to add memory (which could be put into a cartridge). Let's say 64kb --> 320kb. Then, some of the sprites can be simulated by unrolled loops of code. Maybe there's some space left to include one digi-channel of sound to add some SID-like features. With a lot of memory, even analogue filters could be 'emulated'. Standard atari 8bit including a (external) memory expansion is very close to C64 in my opinion. That's all we can add without making it a totally different machine. I think a memory expansion is a fair upgrade, from the 1978 point of view, to lift a8 to the 1982 level. Edited November 25, 2008 by Analogue Multiplexer Link to comment Share on other sites More sharing options...
frogstar_robot Posted November 25, 2008 Share Posted November 25, 2008 its even more amusing how atari fans are trying to byte of pieces of amiga's fame for their 8 bit machine. I'm more of a Jay Miner fan than an Atari fan and would have preferred Amigas over STs even if they had something like an Osborne label slapped on them. No brand loyalty here. Sorry. Link to comment Share on other sites More sharing options...
Fröhn Posted November 25, 2008 Share Posted November 25, 2008 And what about if you want three colours and the third isn't the value produced by the OR? Good point, but let's look at VIC2 sprites. 2 out of 3 colours are shared by all sprites. This doesn't happen on atari As I mentioned above: You need 4 players to have two 3-color players on Atari with the OR-restriction on the 3rd color. Take 4 C64 sprites and join them similar to A8 player joining -> you have 3 independent colors for both resulting sprites and even 4 spare sprites left with another 4 free colors + 2 combined colors. On A8 the missile colors are 100% shared with the player colors, so by using the C64 sprites that way you have much more freedom on color choice and still much bigger sprites. ....but, what's left to discuss? we don't need to say 1000 times that c64 sprites are way more powerful. I wouldn't even call PMG sprites. "Sprites" is just a more general term than "Players" and "Missiles". Standard atari 8bit including a (external) memory expansion is very close to C64 in my opinion. That's all we can add without making it a totally different machine. I think a memory expansion is a fair upgrade, from the 1978 point of view, to lift a8 to the 1982 level. 320k in 1982? Link to comment Share on other sites More sharing options...
Crazyace Posted November 25, 2008 Share Posted November 25, 2008 In bandwidth terms the Vic is better as it has a 12 bit bus - that's 50% more. The Atari has 2 graphics chips. One that has a 16 Bit Adress bus and one that has 8 Bit registers for colour counting... The colours are only limited by the GTIA. That's got almost nothing to do with bandwidth though... Even if a 16 colour mode took most of the b/w it would still be usefull for graphics. 80 column text would be extremely difficult ... If you spread the character fetch you could run 80+10 fetches per line though - widescreen would be 96+12 which would probally be every possible cycle 80+16 fetches woud fill the char buffer in five lines - leaving 3 lines with a little more cpu activity The Char fetch would not be necessary if they were stored in the external memory. Antic only was needed for down-compatibility to the older machines and for extensive screenusage. Only some command was needed then. a command that tells "E-GTIA" -> now compatibility mode -> now extended mode... The extended mode could be controlled by ANTIC's DMA. The Screendata is pre loaded and the DMA controls what's happening on the screen. There were two ways to store the screen data into the external RAM 1. Simply Data polling via writing into registers (good for Business use and 80 coloumns) 2. An "E-GTIA" Mode that can be loaded through a special command via ANTIC's DMA That's a really complex scheme though - why have external memory when the internal memory is fast enough If you were redesigning the XL(or XE ) you could just use faster memory - colclk/1.5 rather than 2 would give you a lot more clock cycles for antic dma during a line. The changes I'm thinking of are probally more limited, because I thinking what could have been put in for use in the 800XL ( or 130XE ) by Atari at that time - for the price they wanted to sell the machine Link to comment Share on other sites More sharing options...
atarian63 Posted November 25, 2008 Share Posted November 25, 2008 Overscan not useful? Then why do more than half the C-64 demos out there get the C= owners dribbling with joy over something as trivial (to an Atarian) as sprites in the border? IMO, one of the biggest shortcomings by far of the C-64 was the 320x200 fixed architecture. Using sprites in the border is useful only in the context of things like status displays for games. its just a technical stunt, appart from that its not useful. and why is 320x200 is a shortcoming? how many % of the a8 games use overscan ? the biggest shortcoming by far of the c64 is the slow cpu believe me. but if you look at it with a perspective its the price it pays for having VICII being able to do all the sprites, and colors etc. C64's biggest shortcoming is that is was a poorly made POS. Link to comment Share on other sites More sharing options...
TMR Posted November 25, 2008 Share Posted November 25, 2008 C64's biggest shortcoming is that is was a poorly made POS. When i got my 800XL for Christmas it didn't work properly, it would throw up a red screen four or five times a day on average so i returned it a few days after new years day, described the fault to the clerk in the shop and he didn't even bother firing it up to test the problem because the chain of stores had already received several hundred returns with the same issue by that point. Compared to my first C64, a 1984 issue machine that had been thrashed by it's previous owners (a local software development firm) and subsequently took a major pounding from me as well but still works to this day, i know which one i'd call poorly made and it doesn't tally with what you've said... Link to comment Share on other sites More sharing options...
Oswald Posted November 25, 2008 Share Posted November 25, 2008 overscan.. Link to comment Share on other sites More sharing options...
Rybags Posted November 25, 2008 Share Posted November 25, 2008 Errr... sprites. And 2/3rds (or even more on NTSC) of your CPU cycles gone as a result. Link to comment Share on other sites More sharing options...
TMR Posted November 25, 2008 Share Posted November 25, 2008 And what about if you want three colours and the third isn't the value produced by the OR? Good point, but let's look at VIC2 sprites. 2 out of 3 colours are shared by all sprites. This doesn't happen on atari No, but running out of sprites when there are two on a scanline doesn't happen on the C64 either and i know which of the two i consider to be less of a disadvantage... That's the reason why us atarians may use softwaresprites instead. Then, all we need to do is add one PM underlay to give us the 'same' freedom as on C64 (at least when the first 2 palette-colours of the sprites are the same as the gfx palettes) That's a bloody huge "at least when" you have there mister... =-) i'd disagree about the "same" freedom too, since the CPU load per software sprite is vast compared to what the C64 needs to juggle it's hardware; it may be only two thirds the CPU power (give or take) but we're talking a significant amount of data being chunked around per frame and all the pre-stored stuff to account for. Lets "keep it simple" (since some people seem to like doing that =-) and assume a static screen and two objects with three colours that are 8x16 pixels and yes i'm weighting this in the Atari's favour by not asking for C64-sized objects; to move both every frame the Atari has to clear and then write 32 bytes per object, so 132 bytes per frame including the four horizontal position registers compared to the C64's twelve register writes (since we're using four hardware sprites in pairs for this theoretical example, same as the Atari to get the same colour control). Unless someone plans on making some wild claim about the Atari being eleven times faster than the C64 that's a huge chunk of bytes more to transfer... Link to comment Share on other sites More sharing options...
GameEngine Posted November 25, 2008 Share Posted November 25, 2008 overscan.. Nice picture but unfortunate example. The nice thing about overscan is when you have it in a game so you can see much more and borders do not bother you (or at least when you scroll text so it does not pop up in the middle of the screen). Link to comment Share on other sites More sharing options...
TMR Posted November 25, 2008 Share Posted November 25, 2008 Errr... sprites. And all those G2F examples reproducing C64 pictures use sprites as well, nobody said that using sprites on one to simulate the abilities of the other wasn't allowed... And 2/3rds (or even more on NTSC) of your CPU cycles gone as a result. That and the utter bitchiness of the cycle exact timing is exactly why C64 bunnies get excited about the C64 doing overscan; if it was just a matter of setting a register or similar, nobody would shout about it. Link to comment Share on other sites More sharing options...
Oswald Posted November 25, 2008 Share Posted November 25, 2008 Errr... sprites. And 2/3rds (or even more on NTSC) of your CPU cycles gone as a result. my bet would be 90% even for pal Link to comment Share on other sites More sharing options...
Oswald Posted November 25, 2008 Share Posted November 25, 2008 Nice picture but unfortunate example.The nice thing about overscan is when you have it in a game so you can see much more and borders do not bother you (or at least when you scroll text so it does not pop up in the middle of the screen). any a8 game examples of overscan ? Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 25, 2008 Share Posted November 25, 2008 (edited) Venus Express... http://atari.fandal.cz/detail.php?files_id=5488 Schreckenstein: http://atari.fandal.cz/detail.php?files_id=4420 Rally Speedway: http://atari.fandal.cz/detail.php?files_id=2802 Ballblazer: http://atari.fandal.cz/detail.php?files_id=1387 Blue Max: http://atari.fandal.cz/detail.php?files_id=1438 just to name few... Edited November 25, 2008 by Heaven/TQA Link to comment Share on other sites More sharing options...
Oswald Posted November 25, 2008 Share Posted November 25, 2008 Heaven, and what would it take to make a scrolling platformer (using that nifty wrapparound scrolltech) ? how much rtime and chars does it take to add a 16x16 softsprite into such a scenario? Link to comment Share on other sites More sharing options...
Heaven/TQA Posted November 25, 2008 Share Posted November 25, 2008 (edited) Oswald, do not know... I mean overscan can be usefull for such things but I never played around with these new techniques. I am enabling in general overscan if possible... and for softsprites in general does not make a real difference as instead of 40 bytes scanlines f.e. you have 48 instead....? I personally found games strange when they used standard screen size but used PMs which crossed the (small) borders.... that was lame imho. Edited November 25, 2008 by Heaven/TQA Link to comment Share on other sites More sharing options...
Crazyace Posted November 25, 2008 Share Posted November 25, 2008 For the Pacman demo running 4 ghosts + Pacman is taking most of a frame at the moment ( at 60Hz ) This is not fully optimised code, and implements a mask/data sprite, rather than simple Xor. 5 sprites - 16x16 pixels each, renderer as 20x16y for horizontal, and 16x24y for vertical. Real H/W sprites are way,way better Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts