Atari v Commodore

[Kr0tki]

And yet we still get games like Popeye when he remains PINK after eating his spinach despite the Atari having 255 more colours to choose from

Playing Popeye on a botched emulator, weren't you? Obviously, you didn't know that PAL Ataris (and also the most popular emulators) produce different colours than NTSC ones; Popeye's sprite turns red after eating spinach on an NTSC computer; just like in the arcade game.

Edited June 28, 2009 by Kr0tki

[atariksi]

I always thought Atari in-game graphics sucks in comparism to most of the late 80s games for C64 (Last Ninja parts, uncountable Shooters and Jump'n'Runs I forgot the names of, etc.) but then I saw the newer Atari productions Crownland and Flowersmania and I have to admit that they look and sound pretty cool! Unfortunately they have been released nearly 20 years too late to have an impact to gaming industry ... but nevertheless many many kudos to the creators! Phantasic work guys!

 

It's interesting to see how people are still involved with developing/discussing stuff for obscure gaming/computer systems and keep the old (though useless ) A vs C vs Spectrum vs ... issues alive.

 

It's useless for you so don't generalize for everyone. I would rather play some games on Atari than modern PCs-- atari still has better joystick interface than modern PCs and cycle-exact coding (using direct to hardware) control amongst other things.

 

Early Atari games did NOT use GTIA modes nor use more than 16K of ROM to keep compatibility with most machines. Obviously, DLI-based kernels and interlacing requires a lot more RAM/ROM. That's why discussion is which machine is better hardware.

[emkay]

I don't think MacLean was experienced in the context of comparing him to the likes of some of the Synapse, Sirius and Broderbund programmers.

 

I think he excelled because he took the machine above the accepted limits of the time.

 

I don't see where to "protect" those guys from the fact that they earned money by doing their 9-5 job?

The experience is on McLean's side, clearly. Doing really outstanding stuff for the time. Kicking some Arcade's ass in 84 on a machine that was build for kicking Arcade's ass in 1979

 

Another problem Atari had - in the early years it was hampered by "Lame Apple II ports". In the middle years, the good stuff came out. In the later years, it was forgotten against a background of ST, Amiga and emerging console wars by a bunch of new players.

 

First Apple, then C64...

 

Most Machine Language games on the A8 don't even exceed Basic boundaries. Seeing Heaven converting hardly the gameport of Gridrunner, and the even worse original version... be sure, it runs in standard Basic almost at the same speed. And, as we know, Basic on the A8 is rather slow, when not using ML routines.

 

Or, having a look at Rescue on Fractalus. Why is it syncronized to the Screen blanking on the A8, and on the C64 it is not?

The result is that it runs - in relative terms - faster on the C64 than on the A8.

 

If this is a weak spot on the A8, someone may explain it to me.

[emkay]

The image is using 160 pixel. The pic is stored in double width for the correct aspect ratio.

 

 

 

Seems to be an issue with the used GIF filter. But the relevant parts are correct and good enough for a mockup.

[atariksi]

...

It does NOTHING of value, we all KNOW the A8 has a great palette and the C64 a limited one, so what?

...

I think this was also related to color depth not just palette. Having 16 colors and being able to show them all isn't that wonderful as having say 12 colors and being able to select them from 256. For general imagery, the probability that a scanline uses all 16 colors available to C64 is close to ZERO. But the probability that it uses 16 from 256 is high given shades most likely will show up (unless they are hand painted by C64 artists).

 

>This thread, like all the others where people (and I don't need to name names) attempt to belittle the C64 and it's excellent software library and rely ENTIRELY on shouting loudly, quoting random hardware performance values and NEVER SHOW anything (or in the case of SID bashing let me hear anything) that PROVES their random and ill founded opinions...

 

The thread has more to do with comparing hardware capability than belittling C64's software library. It does not rely ENTIRELY on shouting loudly nor random hardware performances. It's not based on ill founded opinions. You generalizing over the entire thread is your ill founded opinion. You're just slinging mud at something you haven't fully read/understood. You can't relate number of software titles available to hardware being superior.

 

And yet we still get games like Popeye when he remains PINK after eating his spinach despite the Atari having 255 more colours to choose from The problem is realistically the Atari can't display more than 5 or so colours in a game with 50fps action and at a resolution of 160x200. The simple fact is for most games the C64 has an excellent selection of 16 colours to choose from. The only time you get an advantage is doing things like depth cueing or graduated skies like in say Elektraglide. On that kind of horizontal raster/Displaylist/Copperlist type effect the Atari does win because you can use the extra colours there, but in your average game say something like Bubble Bobble the Atari is backed into a corner as it just can't do any unique 16 colours everywhere on screen to replicate the look of the C64 version.

...

You also are restricted to 4*8 areas. Atari has a different approach so obviously porting from one to the other leads to some problems. It's easy to get 23 colors/scanline and Atari limit is definitely not 5 colors/scanline at 160*200. Earlier games were planned for 5 colors-- low memory useage or were easier to port using char-mode or linear graphics mode. And 23 colors/scanline can be done even in BASIC-- you don't need any DLIs or kernels which can actually get you more colors per scanline.

 

By the way, Popeye does change color after he eats spinach on my Atari (800XL NTSC).

 

>As I said BOTH machines were a compromise, Jay Miner fixed most of them in 1982/83 once the Amiga chipset prototypes were finished (although the sprite features were weak, a typical bugbear of Jay's work, at least he put in a really nice blitter solution) from the Atari A8.

 

But they are taller on both systems-- makes it easier to multiplex vertically.

[atariksi]

To get an object to move around the entire screen using "OR" mode, one approach is that you can replicate the player (using 4X zoomed version) and just use 160*200*4 mode...... So you get a uniform 160*240*7 mode and have P0 and P2/P3/P4 still available with their own 4 colors.

...

If you use narrow mode, you can replicate P0 and P1 on top of each other and get close to full screen coverage and a lot more color combinations. For static images, you don't need to have uniform color selectability throughout the screen, you just optimize player positions/colors based on the image and thus end up with a lot more colors than 16/scanline (use GPRIOR optimally).

I don't need more than 16 colors...

Anything better than 5 colors means a game could be made better looking than 90% of atari's existing games....

 

160x240x7 looks interesting, and would love to see it...

But better to be in char mode... bitmap would slow things down...

Can you code it ?

 

Or make peace with limitations and make a great game like crownland with few DLIs, 5 colors per horizontal stripe, and more use of charbased software sprites....

 

Or what Rybeg said: "judicious level design such that horizontal reuse isn't required " ...

 

If you use char-mode, you get the 160*240*8 uniform color spread but once every 8th scanline, you won't get enough cycles to reuse players horizontally.

 

If you use 160*240*7, you can use P0/P1 (worst case) to cover entire screen and still use P2/P3/P4 for sprites w/own color.

 

I can code it but here's a start for you. BASIC program for 23 colors/scanline with moving object-- use the joystick to move the object (this is slow but it's in BASIC):

 

10 PRINT "Atari BASIC program to show 23 colors/scanline in Graphics 15"

20 PRINT " By Krishna Software Inc."

30 GRAPHICS 15

40 POKE 704,16:POKE 705,32:POKE 706,64:POKE 707,128:POKE 623,16+32

50 POKE 708,4:POKE 709,8:POKE 710,2:POKE 711,13:POKE 712,0

60 POKE 53248,64:POKE 53249,69:POKE 53250,128:POKE 53251,133

70 FOR T=53261 TO 53264:POKE T,255:NEXT T:POKE 53265,192+32+8+2

75 X=48:DX=1:GOSUB 100:GOSUB 200

80 GOSUB 300

85 IF STICK(0)=11 THEN X=X-1

86 IF STICK(0)=7 THEN X=X+1

90 GOTO 80

100 COLOR 1:PLOT 19,0:DR. 19,159

110 COLOR 2:PLOT 20,0:DR. 20,159

120 COLOR 1:PLOT 22,0:DR. 22,159

130 COLOR 2:PLOT 23,0:DR. 23,159

140 COLOR 1:PLOT 24,0:DR. 24,159

150 COLOR 2:PLOT 25,0:DR. 25,159

160 RETURN

200 COLOR 3:PLOT 83,0:DR. 83,159

210 COLOR 4:POKE 53252,132

220 COLOR 3:PLOT 86,0:DR. 86,159

230 COLOR 4:POKE 53253,135

240 COLOR 3:PLOT 88,0:DR. 88,159

250 COLOR 4:POKE 53254,137

260 RETURN

300 COLOR 0:PLOT X-1,0:DR.X-1,159

310 COLOR 3:PLOT X,0:DR. X,159

320 COLOR 1:PLOT X+1,0:DR. X+1,159

330 COLOR 2:PLOT X+2,0:DR. X+2,159

340 COLOR 4:POKE 53255,X+51

350 COLOR 2:PLOT X+5,0:DR. X+5,159

360 COLOR 1:PLOT X+6,0:DR. X+6,159

370 COLOR 3:PLOT X+7,0:DR. X+7,159

380 COLOR 0:PLOT X+8,0:DR. X+8,159

390 RETURN

RUN

[oky2000]

btw. Why when C64 users shows real pictures, Atari users: only famous listing "23 colors per scanline" or fake pictures. We strongly need gfx conventer to show Atari real power. Conventer with computer placed sprites, computer dli, computer rasters. G2f is nice but everything is manual, sometimes very unfriendly, very hard like rasters.

Sorry, but this still misses the point.

 

It is all well and good using a PC or MAC's power to analyze a picture and produce the most optimal implementation of this on the A8 but that same program doesn't know which areas are (or will be) software/hardware sprites in an actual port/conversion of the game and mostly, when this is taken into consideration, you'll find that the game engine required to support it all will impact greatly on the special display code produced by the gfx converter you describe.

 

Perhaps an engine such as this shows promise... Two Moons and One Sun?

 

I don't agree with you.

First: In some games like adventures, rpg, others static screens games (like Elvira - see at bottom) , this converter would be very useful. And also to show what atari can do in gfx. C64 user in 30 seconds can convert any picture. On Atari this takes days and will never be like from convert-program. Easy to write: "look Atari can 23 colors in scanline..." and show only listing or "But the tree is red, not brown, while on the A8 were more colours possible" and show fake image (with in fact RGB colors - not Atari colors and 1x1 pixels btw. For me always red tree is better then NOTHING ) - but really hard to prove this and show truly great image. Computers invents to relieve us from very complex work. On AtariGfx there is no more complicated things then correct placed sprites, priorites, rasters (look in g2f - this is paint tool or assembly code ?)

 

Second: Imagine this: there is engine which allows you to place sprites on screen - in realtime on 8bit Atari. And this engine is very fast because it is only add-on to zx spectrum emulator and this emulator takes the most cpu time.

Look here: http://tiny.pl/36v2 (original in polish, translated via google)

When you looked on pictures maybe you think - not good - but this engine has a big potential. I ask author, great Atari Coder - Mono - about PC version, he answer: Can be done and without Atari cpu limits, on PC can be check every possible sprites, colors combination, and other resolutions like 2x1 pixel - and in effect more accurate conversion.

 

Third: G2Font is very good gfx program but i know much better like Grafx2 or Cosmigo Pro Motion. Of course in this programs you can't save files in Atari formats - but when we have a converter, then we can paint in any program, final picture convert to *.g2f file and retouch and correct minor conversion errors. Overall, much easier way to produce pictures to games, demos instead fake pictures or famous "23 colors listing". Much easier way to show C64 user why Atari is better in gfx.

 

------

- sorry for my poor english.

- i am Atari user since 1986 and never bought C64

- others C64 30 seconds conversion:

 

 

Interesting point, BUT there is nothing stopping the C64 remake of such classic adventure games as The Pawn and The Guild of Thieves on the C64 using trick screenmodes likes MCI IFLI HIFLI etc etc. In which case the graphics would look pretty much identical to the ST/Amiga graphics given you only need a few extra hues of a few colours for that 16 colour artwork

[oky2000]

...

It does NOTHING of value, we all KNOW the A8 has a great palette and the C64 a limited one, so what?

...

I think this was also related to color depth not just palette. Having 16 colors and being able to show them all isn't that wonderful as having say 12 colors and being able to select them from 256. For general imagery, the probability that a scanline uses all 16 colors available to C64 is close to ZERO. But the probability that it uses 16 from 256 is high given shades most likely will show up (unless they are hand painted by C64 artists).

 

>This thread, like all the others where people (and I don't need to name names) attempt to belittle the C64 and it's excellent software library and rely ENTIRELY on shouting loudly, quoting random hardware performance values and NEVER SHOW anything (or in the case of SID bashing let me hear anything) that PROVES their random and ill founded opinions...

 

The thread has more to do with comparing hardware capability than belittling C64's software library. It does not rely ENTIRELY on shouting loudly nor random hardware performances. It's not based on ill founded opinions. You generalizing over the entire thread is your ill founded opinion. You're just slinging mud at something you haven't fully read/understood. You can't relate number of software titles available to hardware being superior.

 

And yet we still get games like Popeye when he remains PINK after eating his spinach despite the Atari having 255 more colours to choose from The problem is realistically the Atari can't display more than 5 or so colours in a game with 50fps action and at a resolution of 160x200. The simple fact is for most games the C64 has an excellent selection of 16 colours to choose from. The only time you get an advantage is doing things like depth cueing or graduated skies like in say Elektraglide. On that kind of horizontal raster/Displaylist/Copperlist type effect the Atari does win because you can use the extra colours there, but in your average game say something like Bubble Bobble the Atari is backed into a corner as it just can't do any unique 16 colours everywhere on screen to replicate the look of the C64 version.

...

You also are restricted to 4*8 areas. Atari has a different approach so obviously porting from one to the other leads to some problems. It's easy to get 23 colors/scanline and Atari limit is definitely not 5 colors/scanline at 160*200. Earlier games were planned for 5 colors-- low memory useage or were easier to port using char-mode or linear graphics mode. And 23 colors/scanline can be done even in BASIC-- you don't need any DLIs or kernels which can actually get you more colors per scanline.

 

By the way, Popeye does change color after he eats spinach on my Atari (800XL NTSC).

 

>As I said BOTH machines were a compromise, Jay Miner fixed most of them in 1982/83 once the Amiga chipset prototypes were finished (although the sprite features were weak, a typical bugbear of Jay's work, at least he put in a really nice blitter solution) from the Atari A8.

 

But they are taller on both systems-- makes it easier to multiplex vertically.

 

Maybe so but they are very narrow AND a bit colourless as well as limited in number (8...same as the C64!) when older machines like the TI and Sord M5 had 32 sprites on screen anywhere, the Amiga sprite system is very weak, they put all their eggs into the 'blitter basket' as far as I can tell. Think of the sprites as a bonus not a feature of the Amiga...good for a mouse cursor

 

(I am joking, it's a bit better than the Archimedes one single hardware sprite which IS the mouse cursor)

[Rybags]

The TI had the limitation of 4 sprites on a scanline... it was reuse to get 32. So, it wasn't quite the powerhouse that the paper figure might lead you to believe.

Edited June 28, 2009 by Rybags

[emkay]

Interesting point, BUT there is nothing stopping the C64 remake of such classic adventure games as The Pawn and The Guild of Thieves on the C64 using trick screenmodes likes MCI IFLI HIFLI etc etc. In which case the graphics would look pretty much identical to the ST/Amiga graphics given you only need a few extra hues of a few colours for that 16 colour artwork

 

As it's prooved recently, the A8 can produce real interlace. Resulting in 480 visual scanlines.

Interlace also offers the possibility of adding real colours into hires. At least it offers to mix Screenmodes, overlapping a half scanline, mixing real colours into hires, or enabling the colour mixing more precisely. Whatever.

[emkay]

But they are taller on both systems-- makes it easier to multiplex vertically.

 

In many games pillars were used to add another layer to the parallax scrolling effect.

just two pokes for the whole image and the effect is there... on the C64 it cost addition cpu time everywhere the sprites got reused.

 

Some additional GPRIOR settings will add many more visuals for a grat parallax effect.

[andym00]

btw. Why when C64 users shows real pictures, Atari users: only famous listing "23 colors per scanline" or fake pictures. We strongly need gfx conventer to show Atari real power. Conventer with computer placed sprites, computer dli, computer rasters. G2f is nice but everything is manual, sometimes very unfriendly, very hard like rasters.

Sorry, but this still misses the point.

 

It is all well and good using a PC or MAC's power to analyze a picture and produce the most optimal implementation of this on the A8 but that same program doesn't know which areas are (or will be) software/hardware sprites in an actual port/conversion of the game and mostly, when this is taken into consideration, you'll find that the game engine required to support it all will impact greatly on the special display code produced by the gfx converter you describe.

 

Perhaps an engine such as this shows promise... Two Moons and One Sun?

 

I don't agree with you.

First: In some games like adventures, rpg, others static screens games (like Elvira - see at bottom) , this converter would be very useful. And also to show what atari can do in gfx. C64 user in 30 seconds can convert any picture. On Atari this takes days and will never be like from convert-program. Easy to write: "look Atari can 23 colors in scanline..." and show only listing or "But the tree is red, not brown, while on the A8 were more colours possible" and show fake image (with in fact RGB colors - not Atari colors and 1x1 pixels btw. For me always red tree is better then NOTHING ) - but really hard to prove this and show truly great image. Computers invents to relieve us from very complex work. On AtariGfx there is no more complicated things then correct placed sprites, priorites, rasters (look in g2f - this is paint tool or assembly code ?)

 

Second: Imagine this: there is engine which allows you to place sprites on screen - in realtime on 8bit Atari. And this engine is very fast because it is only add-on to zx spectrum emulator and this emulator takes the most cpu time.

Look here: http://tiny.pl/36v2 (original in polish, translated via google)

When you looked on pictures maybe you think - not good - but this engine has a big potential. I ask author, great Atari Coder - Mono - about PC version, he answer: Can be done and without Atari cpu limits, on PC can be check every possible sprites, colors combination, and other resolutions like 2x1 pixel - and in effect more accurate conversion.

 

Third: G2Font is very good gfx program but i know much better like Grafx2 or Cosmigo Pro Motion. Of course in this programs you can't save files in Atari formats - but when we have a converter, then we can paint in any program, final picture convert to *.g2f file and retouch and correct minor conversion errors. Overall, much easier way to produce pictures to games, demos instead fake pictures or famous "23 colors listing". Much easier way to show C64 user why Atari is better in gfx.

 

------

- sorry for my poor english.

- i am Atari user since 1986 and never bought C64

- others C64 30 seconds conversion:

 

 

Interesting point, BUT there is nothing stopping the C64 remake of such classic adventure games as The Pawn and The Guild of Thieves on the C64 using trick screenmodes likes MCI IFLI HIFLI etc etc. In which case the graphics would look pretty much identical to the ST/Amiga graphics given you only need a few extra hues of a few colours for that 16 colour artwork

 

If I'm correct, that's MUCSU-Hires (MUltiColor Sprite Underlay Hires) which is about the simplest method available for nicer modes.. Just 9 sprite-splits per frame and pointer changes and bugger all CPU useage.. But still only shares a common 3 colours under the bitmap.. I'd like to see this with more vertical colour splits if Algorithm ever released the source code, or added such a mode..

 

Here's the tool if anyones interested

http://noname.c64.org/csdb/release/?id=76055

 

I've actually been toying with this mode recently, and investigating doing software sprites on this mode, plotting both HiRes data and the expanded underlays, but it's getting mind bogglingly complicated and am close to canning it and reverting to a basic Hires screen mode, and then letting objects use sprite underlays on demand, rather than assuming we can underlay the entire screen.. But then we've got enough sprite coverage to do so without any fancy trickery, so it remains a very very low cpu overhead approach..

 

And it's interesting to know that the A8 suffers from 'badlines' too.. It had been kept very quiet here that you only get 30 odd cycles on those lines (maybe it had been mentioned, but I missed it in this snowstorm of a thread), and with that simple fact a lot of your argument for horizontal re-use goes out of the window I'd imagine..

 

How come the A8 loses so much to memory refresh in one go ? And where about on the scanline does it occur ? And is there anyway to delay it ?

Edited June 28, 2009 by andym00

[Rybags]

A8 does have "badlines" but you're only losing 33 cycles or so compared to a normal line in most cases.

 

e.g. Badline you have 1 DList, 40 code, 40 bitmap, 1 Refresh cycle steals = 82 taken, 32 left for CPU

Next line you have 40 bitmap, 9 Refresh = 49 taken, 65 left for CPU

 

In the case of 9 Refresh per line (most), they occur from just before normal visible window until about halfway, every 4th cycle.

In the case of only 1 Refresh cycle, it occurs just after the visible screen window.

[andym00]

But they are taller on both systems-- makes it easier to multiplex vertically.

 

In many games pillars were used to add another layer to the parallax scrolling effect.

just two pokes for the whole image and the effect is there... on the C64 it cost addition cpu time everywhere the sprites got reused.

 

Some additional GPRIOR settings will add many more visuals for a grat parallax effect.

 

You're wrong here.. For example.. Lets use 3 players to give you same width as a c64 sprite..

You use 3 players full screen height, you have to reload 200 lines of data..

That's going to be (best case assuming lda#imm sta abs pairs) 6 * 200 * 3 cycles.. So just for loading the sprites images you've burnt 3600 cycles (more realistically 6000 assuming indexed loading and storing)..

There's no doubt the cost of the video chip reading from memory as well, so that'll (i guess) add more cycles to your cost.. I guess 1 or 2 cycles per scanline, per enabled player ?

 

And since the c64 has pointers for each sprites we don't move any data, so the 64 consumes (worst case) 5 * 200 cycles (best case) 2 * 200 (For a single one off sprite.. There's DMA startup costs if the displayed sprites are not contiguous)..

So where's the competition ??? 64 has to reposition sprites and change colours with an interrupt, but then again so do you.. I can't see any advantage at all to what you're saying.. In fact the 64 comes out of this way way way better off..

 

If we go into the cost for using all 8 sprites, split all the way down the screen, we're looking at

200 * (3 + (2 * ) cycles, so we burn 3800 cycles for having the sprites re-used completely over the screen height..

 

So we can have all 8 sprites (covering 192 pixels hires), re-used full screen height for the same cost of you having covered 24 pixels (and that was a very generous cycle count for that!)..

 

No competition emkay, sorry... You still have to have your splits like us, you still have to sort stuff, you're in the same barrel when it comes to this, but having achieved far less in terms of screen sprite coverage for the same cost..

 

Edit: I kind of got a bit confused with Emkays posts about the parallax use and a general purpose sprite approach from something earlier I wanted to reply to, but the point still stands about comparison.. I realise for his parallax idea mentioned, that no re-loading is required..

Edited June 28, 2009 by andym00

[andym00]

A8 does have "badlines" but you're only losing 33 cycles or so compared to a normal line in most cases.

 

e.g. Badline you have 1 DList, 40 code, 40 bitmap, 1 Refresh cycle steals = 82 taken, 32 left for CPU

Next line you have 40 bitmap, 9 Refresh = 49 taken, 65 left for CPU

 

In the case of 9 Refresh per line (most), they occur from just before normal visible window until about halfway, every 4th cycle.

In the case of only 1 Refresh cycle, it occurs just after the visible screen window.

 

Wow, that's interesting to know.. I had no idea the A8 lost cycles quite as much.. But I guess that's down to the flexibility of the display, and I had no idea you were having bitmap accesses per scanline.. I've been spoilt by the VIC I guess

I really must get my arse in gear sometime and do some A8 programming

[Rybags]

By "bitmap", I mean character set data.

 

The "cycle loss" is similar on the C-64... it's just that it's CPU runs at half the bus speed, so most of it is transparent.

[andym00]

By "bitmap", I mean character set data.

 

The "cycle loss" is similar on the C-64... it's just that it's CPU runs at half the bus speed, so most of it is transparent.

 

It dawned on me about this just after posting that But I hadn't clicked that you lose so much of the CPU to the display still, I was always imagining you had far more cycles per scanline to play with.. No I'm even more curious about the ability to sensibly and usefully horizontally split sprites given your remaining cycles, and the overhead of any interrupts you'd be throwing around.. Though I suppose you'd abandon DLIs and go with a fixed display kernel as with a 2600 ??

I've been toying with this on the 64, but with sprites not being guaranteed to be enabled on some lines (and no really practical way to make this happen in a useful way within the context of a multiplexor) it makes the timing far too complex to even contemplate, but I guess the timing is far more stable on the A8 given player fetches and other memory fetches will be constant over the screen..

I'm really fascinated by this 23 colour approach, but even after some of the wacky platforms I've programmed for over the last 30 years, I'm not sure I even want to go near that in a game scenario, let alone try to build sensible tools to work with it..

[Rybags]

I don't see the PMG ORing as too daunting.

 

It's probably one of the most under-utilised features of the machine. And using it in a scrolling game wouldn't add a great deal of complexity.

 

Cycle counting I guess is a bit easier on the A8 - enable PMGs, you have the fixed DMA constant there. And you have WSync to align you when needed. On top of that, DLIs are Non-Maskable, so you don't have the worry of an IRQ being in progress and preventing your interrupt happening.

[Wrathchild]

when C64 users shows real pictures

I don't agree with you.

That's fine, I understand that you were talking about static pictures.

 

The spectrum conversions on the link you gave show no more than is already known? The majority of those pictures point out little more than an automatic conversion only gets you so far and that the patching up (done by a human) still needs to be done, e.g. Skool Daze title. Also for some of those picture the results are still lacking, e.g. banding of 'yellow' on the 'Where Time Stood Still' title page (could be tidied further but will still be blocky in the same way those yellow 'borders' on the game screen are. Also the 'shields' in the classrooms on the Skool Daze screen lack colour, compromises have to be made! I am not oblivious to this myself having considered it when working on the Lords of Midnight port.

 

I was not debating that for static pictures an automatic tool will produce great results either. If it is the case that an 'on the fly' support for this within the spectrum emulation engine is possible then good luck to that.

 

What was meant by 'others C64 30 seconds conversion'? Are these Amiga->C64 that other people have done or quick conversions from C64->A8, I'm not seeing the point here? Granted that for RPG's and Adventures I have no problem that there is typically more processing time available for such an engine. Still I'd have reservations, e.g. in the castle gate picture is there a (mouse) cursor movable over all areas whilst retaining its colours and not affecting the background?

 

My point about missing the point was aimed at the debate regarding horizontal (or vertical for that matter) scrolling shoot-em-ups where there are a more than relevant number of moving object. Emkay, was the SMB scrolling MCS demo the cloest example to what you'd like people to understand. Perhaps we should re-awaken where this got too and what, if any, were the issues in completing this to be used in a game?

 

Regards,

Mark

[andym00]

By "bitmap", I mean character set data.

 

The "cycle loss" is similar on the C-64... it's just that it's CPU runs at half the bus speed, so most of it is transparent.

But even with that taken into account..

A quick calculation (of a 320x200 screen) gives me...

25 badlines = 25 * 23 (23 cpu cycles remaining per BL)..

175 normal lines = 175 * 65

112 blanked lines = 112 * 65

So we get ~19230 cycles per frames..

 

With A8 if I've got this right.. These 'badlines' happen (usually) every 8 lines I guess ?

25 'badlines' = 25 * 32

175 normal lines = 175 * 65

112 blanked lines = 112 * 114

so ~24943 cycles per frame..

 

It had never dawned on me that there was such little difference between the two platforms cpu-wise..

Anyway, I'm waffling now.....

 

Is there a difference in consumed cycles between character modes and bitmap modes on the A8 ?

 

And is there a document for the A8s like the infamous Vic-Article https://sh.scs-trc.net/vic/ that describes the memory accesses of the system ?? Preferably something along the lines of 3.6.3. TIMING OF A RASTER LINE. ?

[andym00]

What was meant by 'others C64 30 seconds conversion'? Are these Amiga->C64 that other people have done or quick conversions from C64->A8, I'm not seeing the point here? Granted that for RPG's and Adventures I have no problem that there is typically more processing time available for such an engine. Still I'd have reservations, e.g. in the castle gate picture is there a (mouse) cursor movable over all areas whilst retaining its colours and not affecting the background?

Those pictures are just a normal 320x200 16 colour screens (one foreground colour, one background colour per 8x8 cell (Spectrum mode)).. Underneath the Hires screen there are 7 x-expanded 3 colour sprites, multiplexed down the screen.. This gives a 80x200 (actually 84x200) 3 colour underlay over the entire screen.. You only need 7 sprites since they'll cover 336 pixels in x-expanded mode.. The only cpu overhead is 9 interrupts down the screen to reload sprite pointers.. There's no colour reloading, no other effects apart from just repositioning the sprites vertically and changing sprite pointers (9 times per frame, every 21 scanlines)..

So yes, there's a sprite left over for a cursor, and pretty much all of the cpu remaining as well..

[Rybags]

Bitmap modes don't have character fetches, so you save a bit there.

 

The Hardware Manual has some info on cycle steals but doesn't get too specific.

 

More exact info is in this file. Antic_Timings.txt

[andym00]

Bitmap modes don't have character fetches, so you save a bit there.

 

The Hardware Manual has some info on cycle steals but doesn't get too specific.

 

More exact info is in this file. Antic_Timings.txt

Thanks for that, very interesting reading that...

[popmilo]

...So yes, there's a sprite left over for a cursor, and pretty much all of the cpu remaining as well..

I'm all for commodore but have to correct you

In every line where you use sprites VIC has to read pointer and sprite data...

So you lose 2 cycles for each sprite and 2 or 3 cycles because only instructions that perform write are possible in those last two or 3 cycles before sprite fetching begins...

So you end up losing 14+(2 or 3) cycles, roughly 15 * 200 lines = 3000 cycles...

It's not without cost

 

And as I know one line is 63 cycles long on PAL system ?

25 badlines = 25 * 21 (23 cpu cycles remaining per BL)..

175 normal lines = 175 * 63

112 blanked lines = 112 * 63

So we get 18606 cycles per frame..

 

But still easier to set up than ataris horizontal multiplexing of players, and with more colors and resolution...

[popmilo]

I can code it but here's a start for you. BASIC program for 23 colors/scanline with moving object-- use the joystick to move the object (this is slow but it's in BASIC):

 

10 PRINT "Atari BASIC program to show 23 colors/scanline in Graphics 15"

.

.

.

390 RETURN

RUN

Thanks for an example!

But do I have to type it in or is there a way to copy paste ?