Jump to content
stevelanc

Atari v Commodore

Recommended Posts

Does anybody have any views on where any titles were launched on both Atari and Commodore - and the Atari version is the better of the two?

Share this post


Link to post
Share on other sites

@Those who think PeteD is bad person:

 

I must admit after reading last 100 posts, I don't see logic errors in Pete's posts :ponder:

He is really trying to make best Fist game A8 has seen so give him credit for that...

And his questions are legit so try to answer them with cool head...

So far Frenchman seems the nicer of the two, and he is right.

 

Because a C64 guy disagreeing with an A8 guy automatically means I'm arrogant. ;) My point originally was that Frenchmans "proof" comment was nonsensical and it is, whoever heard of someone trying to prove themselves wrong to prove a point? A lot of people seem to think that if you've never written a full A8 game you can't comment on if something will work on it or not. I've got no wish to continue arguing that point because as a coder for the past 25 years I know what most machines are capable of, I know 100% that the A8 can't do what the C64 can do due to the C64's hardware. In the course of arguing this point I changed semantics on what was considered a hardware sprite, which as I've pointed out over and ovvver again even A8 guys won't agree if the PMGs are "real" hardware sprites because you have to stuff data into them for Y movement. Frenchman picked up on this as an attack at me, totally left the original argument behind and just starts to berate me about it. Of course I'll argue back then but if you've not followed the full argument like that and lost track of the original point I suddenly come off looking worse. Suits me fine.

 

 

 

Pete

Edited by PeteD

Share this post


Link to post
Share on other sites

So far Frenchman seems the nicer of the two, and he is right.

 

- "you're just talking pure garbage"

- "Do you actually realise how STUPID you make yourself sound?"

- "Obviously you know nothing about the A8, you probably read some stuff on Wikipedia, start posting here and that's that."

- "Best for you to keep quiet."

 

I feel sad... :sad:

Share this post


Link to post
Share on other sites

Does anybody have any views on where any titles were launched on both Atari and Commodore - and the Atari version is the better of the two?

Yes :)

 

p.s. We should really go back to the topic... Problem is there are not so many candidates that satisfy criteria, and they were all already mentioned ;)

Share this post


Link to post
Share on other sites

Does anybody have any views on where any titles were launched on both Atari and Commodore - and the Atari version is the better of the two?

 

Y'know, that's vaguely familiar... i've read it somewhere before?!

Share this post


Link to post
Share on other sites

So far Frenchman seems the nicer of the two, and he is right.

 

- "you're just talking pure garbage"

- "Do you actually realise how STUPID you make yourself sound?"

- "Obviously you know nothing about the A8, you probably read some stuff on Wikipedia, start posting here and that's that."

- "Best for you to keep quiet."

 

I feel sad... :sad:

 

Y'know, if frenchman actually levelled an accusation at someone it'd be quite useful, as it stands he just seems to be tossing insults at passing programmers. i don't remember him actually pointing at something specific before calling Oswald a "loser" either...?

  • Like 1

Share this post


Link to post
Share on other sites

@Those who think PeteD is bad person:

 

I must admit after reading last 100 posts, I don't see logic errors in Pete's posts :ponder:

He is really trying to make best Fist game A8 has seen so give him credit for that...

And his questions are legit so try to answer them with cool head...

So far Frenchman seems the nicer of the two, and he is right.

 

What a surprise. The guy who earlier wrote:

This is ATARIAGE. Doh! Not lets all love the competitions crap age. I worked in the industry during the day, sold,repaired etc, I can tell you that yes, I really dislike Commodore for many reasons. We occasionally do some asset recovery work now and see a few Commodore items. Straight to the shredder. :twisted:

...leaps in to side with Frenchman against someone he has decided is potentially anti-Atari.

 

Pete, there's something you should know about Frenchman and Atarian63, something the regular posters on this board probably won't tell you due to politeness and diplomacy. Basically, those two are possibly the biggest frothy-mouthed fools you'll find on these forums. You're better off not engaging with them. They're not interested in discussion. They've staked their tents somewhere far beyond that.

 

Also, lol at the accusations trying to sniff out Pete's c64 sympathies. Show us the code! Prove you are not a counter-revolutionary! Guards, arrest that man!

Share this post


Link to post
Share on other sites

@Those who think PeteD is bad person:

 

I must admit after reading last 100 posts, I don't see logic errors in Pete's posts :ponder:

He is really trying to make best Fist game A8 has seen so give him credit for that...

And his questions are legit so try to answer them with cool head...

So far Frenchman seems the nicer of the two, and he is right.

 

What a surprise. The guy who earlier wrote:

This is ATARIAGE. Doh! Not lets all love the competitions crap age. I worked in the industry during the day, sold,repaired etc, I can tell you that yes, I really dislike Commodore for many reasons. We occasionally do some asset recovery work now and see a few Commodore items. Straight to the shredder. :twisted:

...leaps in to side with Frenchman against someone he has decided is potentially anti-Atari.

 

Pete, there's something you should know about Frenchman and Atarian63, something the regular posters on this board probably won't tell you due to politeness and diplomacy. Basically, those two are possibly the biggest frothy-mouthed fools you'll find on these forums. You're better off not engaging with them. They're not interested in discussion. They've staked their tents somewhere far beyond that.

 

Also, lol at the accusations trying to sniff out Pete's c64 sympathies. Show us the code! Prove you are not a counter-revolutionary! Guards, arrest that man!

Wow! Barnacle whatever is back. Biased as ever! Thought you ran back to the lemon64 area where all agree with you when you are wrong (as usual). More fun to be had here!

C'mon and entertain me!

Just so you all know Barnicle is a real loon. Foolish and entertaining. Kind of a mean version of a Loony Toon charactor.

Edited by atarian63

Share this post


Link to post
Share on other sites
So the C64 users are Devils and you are playing Devil's Advocate. Is that what you meant or am I scraping the bottom of the barrel with the English language?

 

Somewhat! I'm a die hard Atari 8-bit fan, and have been for over 20 years now. Still, I know enough about the machine to realize where it's limitations are.

 

>>- Faster CPU (good advantage, use with wisdow)

 

>Sometimes this can be an advantage, but if you are trying to do colorful games with lots of moving objects, you have to really push the CPU to the limit, pretty much negating any advantage that the Atari has in CPU speed.

 

It's still an advantage. It would be worse if it was running at 894.895Khz. (notice I still kept it evenly divisible into the TV's color burst frequency).

 

It's only an advantage for a project where you require it. If you are trying to port Turrican, or a dozen other games and you are using the superior speed of the Atari CPU to make up for some other limitation (ie. not enough hardware sprites) then the advantage is no longer an advantage. If you are programming RoF, then sure, the faster CPU of the Atari is an advantage-whereby I stated that "sometimes this can be an advantage".

 

Colors are not subjective. The more the better (ALWAYS). If a game doesn't need the colors, you can always use a subset. DLIs can be used for horizontal splits as well. And River raid is a game designed with Atari hardware in mind so they have multi-colors sprites and smooth scrolling. Joust is another good game that uses Atari hardware collision detection and plays smoother than Atari ST version.

 

I don't like the C64 colors. They look too "cartoony" and bright for me. That's subjective, and that's what I meant. The Atari has a larger palette to choose from, but the design of the computer makes it difficult to use many colors in as free a manner as the C64. That's pretty obvious I think.

 

>Color use is just not as flexible as the C64. Where's the Atari's color text mode?

 

Colors are more flexible and easier to deal with in GTIA's linear graphics modes. Atari does have color text modes (you are familiar with Graphics 1 and 2 in BASIC). I posted some code below that you can boot up with in BASIC that allows you to see how the foreground of text color changes in Gr. 0 with background color while retaining luminance set via POKE 709,##. There's also artifacting and sprite underlays to get colors in text mode (gr.0).

 

GTIA modes? That fugly 4x1 pixel? Even die hard Atari fans like myself have to think, WTF? I realize they were squeezing what they could out of the chips and bandwidth they had, but I don't have to like it. Sure, some people have done great things with that mode, and some very smart people have created new modes utilizing them as well, but still a 4x1 pixel?

 

You aren't seriously pointing to Gr.1 and Gr.2 as something to aspire to are you? Those are pretty ugly as well, and pretty much only BASIC games try to use them. Hoorah for the Atari designers (in 1978 no less) for designing all these graphics modes, but some of them are next to useless.

 

 

>>- 128K with 16K banking (That's the most important thing, the extra 64K, Atari can save a lot of speed with this extra RAM or can create more complex games)

 

>The Atari OS and custom chips takes a significant portion of the 64k memory map. The C64 has a much greater RAM area to use for the default configuration of machine. The bank windows is at $4000-7FFF, right in the middle of the memory map, and it's 16k. Using it requires careful placement and manipulation of your code, screen, and data. I think that they would have been much better off with an 8k bank window. The C64 has memory enhancements as well, IIRC.

 

That's more of a subjective thing-- how to use the hidden RAM or expanded RAM.

 

Maybe you and I have different definitions of subjective. The Atari memory banking window is 16k-fact. You have to be careful when you bank and what you bank-fact. I think it was a poor design choice by Atari, but I'm sure there were design trade-offs and cost-benefit analyses that I'm unaware of. Still, I don't have to think it was good just because Atari did it.

 

I wonder why memory enhancements aren't as popular in the C64 scene? Or maybe they are, and I just don't know, I don't follow it very closely I admit. Maybe it's because they don't NEED them as much as we do.

 

>>- Flexible internal design for programming (Always let us to save memory and create interesting effects on screen)

 

>I'd say this is subjective. The C64 has some pretty flexible internal design as well. You can write directly under some of the i/o chips without banking anything out for instance... oh, and the hardware sprites. :)

 

It's not subjective. It's better to boot up into whatever program you want or configuration you want without user intervention. It's better to do a STA WSYNC than write complex IRQ code to stabilize the raster which becomes unstable again once sprites start moving or color RAM gets accessed. Oops, those are the C64 advantages.

 

It's highly subjective. C64 users may wonder why we need to BOOT a DOS to do anything. Why can't you use your disk drive by just turning on the computer? I know they wonder why we have these strange screen-high, single color sprite that you can can only move in the horizontal dimension without bit-banging data around in memory. Atari users think WSYNC is great (so do I.)

 

Here's an example of boot code that allows you to use BASIC with 128 colors in the background and sprites covering the whole screen w/o multiplexing:

 

Nice! I've seen some amazing static screens done on the Atari, using it's advantages to display lots of colors. There has also been some amazing work done lately in actual games that move colorful stuff around the screen, but ask these guys how hard it is to do... writing software sprite engines, or sprite multiplexers...

 

I can still love my Atari 8-bit, but realize it was not the be-all end-all in computer technology, and that maybe, just maybe, the C64 designers got some stuff right, or if not "right" at least better. :) You'd still have to pay me to take a C64 though. :)

Edited by Shawn Jefferson

Share this post


Link to post
Share on other sites

I don't like the C64 colors. They look too "cartoony" and bright for me. That's subjective, and that's what I meant.

 

That surprises me, usually the complaints about the C64 palette are that there isn't enough saturation... perhaps it's a PAL/NTSC thing?

 

I wonder why memory enhancements aren't as popular in the C64 scene? Or maybe they are, and I just don't know, I don't follow it very closely I admit. Maybe it's because they don't NEED them as much as we do.

 

As far as demos go, they're not popular because the coders consider them "cheating" (since everyone else is working with a stock machine) and the rules for most C64 competitions specify a compo machine and it's usually a stock machine, Action Replay 6 or Retro Replay cartridge and a 1541 or 1541-II drive, so they'd be disqualified from competing with a RAM expanded production anyway.

 

For games, i can't think of a single game that requires a RAM expansion apart from Metal Dust, but that needs a SuperCPU as well as the RAM... Pinball Dreams was originally going to be REU only, but then WVL figured out a way to get the stock machine running it. After that, some titles support extra memory as an option but nothing so far is using the potential there - i've been working on a small game that supports an REU myself...

 

Atari users think WSYNC is great (so do I.)

 

i think WSYNC is rather nice too...

Share this post


Link to post
Share on other sites

Yeah, and what application is there on C64 that uses hundreds of NMIs and hundreds of IRQs every frame?

C64 sample replay routines do that.

 

That sounds pretty suboptimal to use hundreds of NMIs and hundreds of IRQs to do a sample playback. If you want to play a sample at 12Khz, you should need about 200 timer IRQs per frame (NTSC).

Share this post


Link to post
Share on other sites
So the C64 users are Devils and you are playing Devil's Advocate. Is that what you meant or am I scraping the bottom of the barrel with the English language?

 

Somewhat! I'm a die hard Atari 8-bit fan, and have been for over 20 years now. Still, I know enough about the machine to realize where it's limitations are.

 

>>- Faster CPU (good advantage, use with wisdow)

 

>Sometimes this can be an advantage, but if you are trying to do colorful games with lots of moving objects, you have to really push the CPU to the limit, pretty much negating any advantage that the Atari has in CPU speed.

 

It's still an advantage. It would be worse if it was running at 894.895Khz. (notice I still kept it evenly divisible into the TV's color burst frequency).

 

It's only an advantage for a project where you require it. If you are trying to port Turrican, or a dozen other games and you are using the superior speed of the Atari CPU to make up for some other limitation (ie. not enough hardware sprites) then the advantage is no longer an advantage. If you are programming RoF, then sure, the faster CPU of the Atari is an advantage-whereby I stated that "sometimes this can be an advantage".

...

Even if your project doesn't require it, you can always slow things down.

 

>>>Color use is just not as flexible as the C64. Where's the Atari's color text mode?

 

>>Colors are more flexible and easier to deal with in GTIA's linear graphics modes. Atari does have color text modes (you are familiar with Graphics 1 and 2 in BASIC). I posted some code below that you can boot up with in BASIC that allows you to see how the foreground of text color changes in Gr. 0 with background color while retaining luminance set via POKE 709,##. There's also artifacting and sprite underlays to get colors in text mode (gr.0).

 

>GTIA modes? That fugly 4x1 pixel?

 

They work great for many things. Sorry, you missed out on many good things. You have only stated your subjective views. There are flexibile modes for 16+ colors and there are also more restricted modes that require more complexity to get more colors.

 

>You aren't seriously pointing to Gr.1 and Gr.2 as something to aspire to are you? Those are pretty ugly as well, and pretty much only BASIC games try to use them. Hoorah for the Atari designers (in 1978 no less) for designing all these graphics modes, but some of them are next to useless.

 

That once again is your limited and subjective views. They are still useful at least to increase CPU time by letting ANTIC handle the pixel replication and drawing of big chars. And I didn't just mention Gr. 1 and 2 (that's what I stated that you should already be familiar with). You can have colored text in Gr.0 and 320*200.

 

>>That's more of a subjective thing-- how to use the hidden RAM or expanded RAM.

 

>Maybe you and I have different definitions of subjective.

 

When you say stuff like 80*200*16 is ugly. That's subjective. It's another graphics mode that exists OBJECTIVELY in reality so Atari is not limited to restricted modes. If you don't have use for it that doesn't make it useless. By the way it becomes 192*240*16 in interlaced overscanned version.

 

>The Atari memory banking window is 16k-fact. You have to be careful when you bank and what you bank-fact. I think it was a poor design choice by Atari, but I'm sure there were design trade-offs and cost-benefit analyses that I'm unaware of. Still, I don't have to think it was good just because Atari did it.

 

If you are an assembly language programmer, it doesn't matter where you put the window as long as it doesn't overlap the I/O area (which it doesn't). For BASIC, that's the only place to put the 16K window where you can use it in BASIC. As far as size of Window goes, you need more than 8K if you ever do overscanned GTIA modes or graphics 8 or even 192*200*4.

 

>It's highly subjective.

 

Nope. It's better to have a boot option and WSYNC than not have them. That increases flexibility. You can always choose NOT to boot and NOT to use WSYNC. More choices means more flexibility.

 

>C64 users may wonder why we need to BOOT a DOS to do anything.

 

That code I posted allows you to boot into BASIC w/o DOS with the machine language code preloaded and running.

 

>I know they wonder why we have these strange screen-high, single color sprite that you can can only move in the horizontal dimension without bit-banging data around in memory...

 

Amiga also has similar sprites although they did add the y-positioning in hardware. C64 sprites are unique amongst the early 1980s machines for having very wide sprites. Screen-high sprites more helpful with overlays.

 

>>Here's an example of boot code that allows you to use BASIC with 128 colors in the background and sprites covering the whole screen w/o multiplexing:

 

>Nice! I've seen some amazing static screens done on the Atari, using it's advantages to display lots of colors. There has also been some amazing work done lately in actual games that move colorful stuff around the screen, but ask these guys how hard it is to do... writing software sprite engines, or sprite multiplexers...

 

It's not a static screen. You can use BASIC while that's running. It was just to show you how colors of text is affected by colors of sprites and background color.

 

>I can still love my Atari 8-bit, but realize it was not the be-all end-all in computer technology, and that maybe, just maybe, the C64 designers got some stuff right, or if not "right" at least better. :) You'd still have to pay me to take a C64 though. :)

 

Never said it was the "end-all in computer technology". Just pointing out somethings which you claimed didn't exist on A8.

Share this post


Link to post
Share on other sites

So much technical discussion without any objective. Instead talking about old glories... Why don't talk about the technical detail on porting in every machine a game not previously programmed?

For example, the very successful game Tower Bloxx from Digital Chocolate.

 

Video of Tower Bloxx 3D version

 

Article about the original 2D version on mobiles

http://www.gamasutra.com/features/20060707/ranki_01.shtml

 

post-6191-125195377405.gif

Edited by Allas

Share this post


Link to post
Share on other sites

So much technical discussion without any objective. Instead talking about old glories... Why don't talk about the technical detail on porting in every machine a game not previously programmed?

For example, the very successful game Tower Bloxx from Digital Chocolate.

 

Yep, with the high quality of many flash or simply web games these days.. is like sometimes some of them talk to you.. "port me.. port me please".. maybe I'm hearing things..

 

For example GTIA 9 (or G15 + some DLI's), hi speed horizontal scrolling, a wide screen.. and this one:

 

http://adamatomic.com/canabalt/

 

Regards.

(no C64 programmers, we saw it first!.. well, well you can have the doves in better resolution.. go ahead)

Share this post


Link to post
Share on other sites
Just so you all know Barnicle is a real loon. Foolish and entertaining. Kind of a mean version of a Loony Toon charactor.

Heheheh. Well I can't argue with that. Particularly that last bit.

 

post-14912-12519587072_thumb.jpg

 

That would be an interesting one to try converting to the Amstrad CPC. With the fast scrolling, you could use that CRTC trickery that shifts the screen a byte at a time, maybe double buffer it for half-byte widths. Plus as it's fairly lacking in colour, you could probably use the amstrad's mode 1 4-colour 320x200 res. Except you'd have to get around the amstrad's total lack of greys in its palette. Maybe go with a blue+purple scheme.

Edited by Barnacle boy

Share this post


Link to post
Share on other sites

So much technical discussion without any objective. Instead talking about old glories... Why don't talk about the technical detail on porting in every machine a game not previously programmed?

For example, the very successful game Tower Bloxx from Digital Chocolate.

 

Yep, with the high quality of many flash or simply web games these days.. is like sometimes some of them talk to you.. "port me.. port me please".. maybe I'm hearing things..

 

For example GTIA 9 (or G15 + some DLI's), hi speed horizontal scrolling, a wide screen.. and this one:

 

http://adamatomic.com/canabalt/

 

Regards.

(no C64 programmers, we saw it first!.. well, well you can have the doves in better resolution.. go ahead)

 

 

Great choice! It's addictive and fast. It remember me the simply Superfly game on Atari.

Share this post


Link to post
Share on other sites

PMg can be used fullscreen without even losing one CPU cycle. The C64's Sprites have to be reused with Raster coding and this costs CPU time for the code itself and it causes VIC II for additional DMA reads which is slowing down the CPU.

The loss of CPU cycles is insignificantly small. And the A8 also needs a DMA to fetch it's PMG bytes.

 

:roll:

 

ANTIC is running his own program , called Display List, and requests the Interrupt itself.

There is no need to have routines running for initial Interrupt handling.

Ofcourse there is:

 

LDA #$80
STA $D40E
LDA #<IRQ
STA $FFFE
LDA #>IRQ
STA $FFFF

; + a display list which tells ANTIC where to trigger the DLI and additional code to setup the display list

 

Now C64:

 

LDA #$01
STA $D01A
LDA #<IRQ
STA $FFFE
LDA #>IRQ
STA $FFFF

; and to tell VIC2 where to trigger the IRQ:

LDA #rasterline
STA $D012

 

So where exactly does A8 "not need" initial interrupt setup?

 

DLIs are set up for the entire display list by adding 128 to whichever mode line you want them. For C64, you have to keep rewriting to the $D012 register to trigger off the next raster line interrupt so that's more overhead.

Share this post


Link to post
Share on other sites

DLI's are quite nice but not in my experience as flexible as rasters, I'm having to use timer interrupts in Fist, not saying that's a bad thing, I used timers on the C64 I was just a bit discouraged when I realised the mighty DLI didn't do what I wanted.

I hope you are aware that by using timer IRQs on A8 your are losing sound channels? This is because the POKEY timers are also used as sound oscillators.

 

This mistaken view was recently brought up by another person as well. You do NOT lose a sound channel, the frequency for the notes uses the same register as the counter for an IRQ, but each sound channel has a frequency and control register. The DACs are controlled by the control registers which are still available for each of the 4 voices.

Share this post


Link to post
Share on other sites
DLIs are set up for the entire display list by adding 128 to whichever mode line you want them. For C64, you have to keep rewriting to the $D012 register to trigger off the next raster line interrupt so that's more overhead.

That's a little simplistic an overview, plus the display list instruction is typically on the line before the one you want to change, assuming most cases use a WSYNC. Also if you wanted to, say, change an 8-pixel high char-mode line half-way down then you'd need more WSYNCs to achieve this - wasting CPU time. My understanding is that the C64 interrupts on the line the programmer wants.

 

As for the C64 re-writing the $D012 register, counter this with a 'dynamic' dlist (example a moving up and down colour bar created by changing the background colour - the C64 can simply modify the value it pokes into $D012 to achieve this - the A8 would either have to re-work the Dlist or have a DLI at the highest point and 'wait' accordingly. Swings and roundabouts really, I see the two pretty evenly balanced.

 

Finally, for both machines, in most examples I would expect to see a part for setting the 'next' interrupt routine's address (e.g. store lo/hi in $200 on the A8) as this is more effecient than having a single DLI routine determining which change is to be made.

 

Mark

Edited by Wrathchild

Share this post


Link to post
Share on other sites
DLIs are set up for the entire display list by adding 128 to whichever mode line you want them. For C64, you have to keep rewriting to the $D012 register to trigger off the next raster line interrupt so that's more overhead.

That's a little simplistic an overview, plus the display list instruction is typically on the line before the one you want to change, assuming most cases use a WSYNC. Also if you wanted to, say, change an 8-pixel high char-mode line half-way down then you'd need more WSYNCs to achieve this - wasting CPU time. My understanding is that the C64 interrupts on the line the programmer wants.

 

As for the C64 re-writing the $D012 register, counter this with a 'dynamic' dlist (example a moving up and down colour bar created by changing the background colour - the C64 can simply modify the value it pokes into $D012 to achieve this - the A8 would either have to re-work the Dlist or have a DLI at the highest point and 'wait' accordingly. Swings and roundabouts really, I see the two pretty evenly balanced.

 

Finally, in most examples I would expect to see a part for setting the 'next' interrupt routine's address (e.g. store lo/hi in $200 on the A8) as this is more effecient than having a single DLI routine determining which change is to be made.

 

Mark

 

General case is DLI doesn't involve different DLI routines for every interrupt so having to OR 128 to DL instruction is superior to having to reload $D012. You also have the IRQs if you want to do something complex but as far as DLIs go (what they were meant for) they involve less overhead than IRQs. They were meant for causing NMI for particular mode lines-- not middle of the mode line. DLIs don't involve resetting NMI status register, no raster line setting, and no comparisons with other IRQs like keyboard or whatever. They are more efficient than IRQs if they are used for what they were meant for.

Share this post


Link to post
Share on other sites

Why don't talk about the technical detail on porting in every machine a game not previously programmed?

For example, the very successful game Tower Bloxx from Digital Chocolate.

 

Video of Tower Bloxx 3D version

 

Article about the original 2D version on mobiles

http://www.gamasutra.com/features/20060707/ranki_01.shtml

 

post-6191-125195377405.gif

 

Oh come on - that was a low blow... Reminding me I had this on my mobile so I'd end up playing it for a few hours instead of coding. Distraction techniques should be banned :)

 

I've been wondering about coding a little game so might go looking at some of the little mobile games to see if there's any that call out to me. Canabalt is quite cool actually - I think both platforms can do a decent job of it so it's all going to be in the extra polish.

 

The platform I want to play with is undecided - probably C64 because I've been missing it, although I've got an Atari ST framework going now. Odd thing about coding that framework is the little demo effects I've been playing with use a shedload of rastertime on an 8mhz ST and I can do them so much quicker on the 8-bit atari. Try kefrens bars or a chessboard zoomer and you'll see what I mean.

 

Not sure about the atari vs c64, but I'm beginning to think the atari 800 beats the ST :)

 

 

I'm off to *ahem* research Canabalt for a bit longer.....

Edited by sack-c0s

Share this post


Link to post
Share on other sites

For example GTIA 9 (or G15 + some DLI's), hi speed horizontal scrolling, a wide screen.. and this one:

 

http://adamatomic.com/canabalt/

 

The game itself would be worth a port, but the game-play has to be changed: The reached distance depends to much on luck but on skill - that's demotivating.

 

A graphics 0 port + DLI and PM under-/overlays could also produce convincing results.

Share this post


Link to post
Share on other sites

@Those who think PeteD is bad person:

 

I must admit after reading last 100 posts, I don't see logic errors in Pete's posts :ponder:

He is really trying to make best Fist game A8 has seen so give him credit for that...

And his questions are legit so try to answer them with cool head...

So far Frenchman seems the nicer of the two, and he is right.

 

Maybe in your dreams. PeteD has absolutly right and his answers are balanced and calm. So i answer to you "nice" Frenchman way: "Best for you to keep quiet"

;) no offence, i only quote your "nicer of the two" ;)

Edited by irwin

Share this post


Link to post
Share on other sites

My understanding is that the C64 interrupts on the line the programmer wants.

 

Yes, the example code posted earlier stuffs the trip value into the raster register and, when that value is reached, VIC-II kicks the IRQ handler. Most people tend to come in a scanline early (like DLIs do) so the top line of the visible screen is $32 and to get there you'd just write $31 to the raster register and wait around a few cycles; the advantage is that writing $35 to raster gets you halfway down that character line, $83 will be a quarter of the way down the tenth character row, a value like $16 gets an arbitary spot in the upper border and so on.

 

Finally, for both machines, in most examples I would expect to see a part for setting the 'next' interrupt routine's address (e.g. store lo/hi in $200 on the A8) as this is more effecient than having a single DLI routine determining which change is to be made.

 

i use the single DLI entry point with have a handler, for example Reaxion has nine DLIs down the screen (it does a few things on the vblank as well, including playing the music and resetting the counter used to work out which DLI is next to be called) which all stuff playfield colour 3 with a value and in some cases change the character base as well since there are three sets in use. The code for that handler is pretty much identical to the one i use on my C64 interrupts apart from it needing to be a bit faster on the A8 to get the splits done in time. As you said, it's not the most efficient option but with the small bit of extra housekeeping required for the C64 interrupts, Reaxion only uses three splits (and it could probably run from two or maybe even one with a bit of planning) so even with a couple of extra register writes it's still taking less resources away from the processor overall.

Share this post


Link to post
Share on other sites

I'm off to *ahem* research Canabalt for a bit longer.....

 

[cough]Reaxion ZX[/cough] Subtle, ain't i? =-)

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...