Atari v Commodore

[atariksi]

Ehhhrrmmm...

 

 

 

This suites more to gr.9 without a single cycle of cpu help:

 

Well, here is the BMPs of the posted images so someone wants to do better (I just can't seem to get a good A8 palette to colorize it):

KALIYA.ZIP

[TMR]

Seriously. I am shocked to learn how much of a difference the PAL blanking period makes. Good call.

 

That's a constant with all 8-bits to be honest, there are a few C64 games that were considered unfixable for NTSC and it took extensive surgery to get Phobia working for example (the sort behind the multiplexing was ripped out and totally replaced, without that it really wasn't possible to get the thing up on an American machine).

 

The exception with the A8 here is that the cycle stealing also gets less.

 

That has precisely naff all to do with what potatohead and i were talking about; yes, the A8 has less DMA use in those parts of the screen, but if a piece of code is using all the available CPU power in that part of the screen and for some reason can't continue into visible screen area, it will fall over on NTSC. But since you just had to go there, no you're wrong anyway because to a degree the same is true of other 8-bits.

[emkay]

That has precisely naff all to do with what potatohead and i were talking about; yes, the A8 has less DMA use in those parts of the screen, but if a piece of code is using all the available CPU power in that part of the screen and for some reason can't continue into visible screen area, it will fall over on NTSC. But since you just had to go there, no you're wrong anyway because to a degree the same is true of other 8-bits.

 

Why care about it? In the other direction you find many software that went simply crap on 50Hz Ataris.

Popeye or Salmon RUN ... even Pole Position plays fully different on the A8 then.

 

Really, this part of the Atari is a black hole. PAL seems not to exist. Neither by the used chipset nor by the software support. This is the biggest clubfoot of the A8 which is not to blame one the original 800, but it was the biggest mistake Atari has done with the release of the XL ...

If only some "PAL" enhancement was available for that games....

Just like some faster RoF, Eidolon....

Edited October 4, 2009 by emkay

[emkay]

 

Natural Wonders 2

http://noname.c64.or...lease/?id=72560

 

 

Desert dream

http://noname.c64.or...lease/?id=48039

 

 

Deus Ex Machina

http://noname.c64.or...lease/?id=11585

 

 

Maybe its just me but these are damn good IMHO.

nice , however I think Numen is better.

 

 

Numen is tecnically far better, but not from the presentation point.

[TMR]

That has precisely naff all to do with what potatohead and i were talking about; yes, the A8 has less DMA use in those parts of the screen, but if a piece of code is using all the available CPU power in that part of the screen and for some reason can't continue into visible screen area, it will fall over on NTSC. But since you just had to go there, no you're wrong anyway because to a degree the same is true of other 8-bits.

 

Why care about it? In the other direction you find many software that went simply crap on 50Hz Ataris.

Popeye or Salmon RUN ... even Pole Position plays fully different on the A8 then.

 

Well, i don't worry about it as such and if NTSC support isn't realistic to a project i'll omit it - but i'd prefer not to write off a large-ish chunk of potential audience for anything i code in that way because on every 8-bit we're not looking at a massive number of potential players. It's the same reason i don't use RAM expansions generally (even my unreleased C128 code tests are aimed at a 16K VDC RAM) or a SID card with the Plus/4, in fact the same reason everything i do runs from a single load.

[TMR]

Numen is tecnically far better, but not from the presentation point.

 

As someone who is essentially a non coder, you're not qualified to judge that first part.

[emkay]

Numen is tecnically far better, but not from the presentation point.

 

As someone who is essentially a non coder, you're not qualified to judge that first part.

 

 

You don't need to be a coder, to know that. You just need to know about the hardware possibilities.

[Crazyace]

 

 

That last picture shows 253 colours - and seems to have detail at 320 pixel resolution, That's pretty amazing for an A8 image? How do you do it?

 

Popmilo did a better job of looking at the picture than you did. I posted several similar pictures early in the thread-- they all get a bunch of shades added due to JPG not being able to deal with edges very well. But original BMP is 16 shades.

 

No problem, I only posted as the pictures aren't realistic - you should try harder to post accurate images to support your point.

[Crazyace]

 

 

Really, this part of the Atari is a black hole. PAL seems not to exist. Neither by the used chipset nor by the software support. This is the biggest clubfoot of the A8 which is not to blame one the original 800, but it was the biggest mistake Atari has done with the release of the XL ...

 

 

It was annoying seeing messes of pixels on titles like Drol , and missing out on the artifacting - especially as I could never understand why mode 15 was used with artifacting rather than mode 14 with a larger pallette.

[potatohead]

re: NTSC / PAL. Yeah, it was just a pure discussion of blanking time common to all machines, no matter what their memory access scheme is. There is just a nice chunk more time in a PAL frame. So then, that lead to some trade off discussion, nothing more.

 

re: Being able to judge technical without programming skill of some kind. Not possible. Knowing hardware possibilities is a matter of presentation, not technical acumen. When judging the technical merits of a given production, one has to know something about the building of them, beyond hardware specifications, to realistically comment on whether or not a given element actually has technical merit.

 

Sorry, but that is just how it is. NOBODY who spends time writing code will accept otherwise. When you do write some code, then it will be possible to understand why this is.

Edited October 4, 2009 by potatohead

[potatohead]

 

 

Really, this part of the Atari is a black hole. PAL seems not to exist. Neither by the used chipset nor by the software support. This is the biggest clubfoot of the A8 which is not to blame one the original 800, but it was the biggest mistake Atari has done with the release of the XL ...

 

 

It was annoying seeing messes of pixels on titles like Drol , and missing out on the artifacting - especially as I could never understand why mode 15 was used with artifacting rather than mode 14 with a larger pallette.

 

I'm thinking it was a result of the game being written for Apple ][. That machine has a sort of color cell, in that really only 7 pixels are displayed, with the high pixel of each byte shifting the color artifacting a bit to generate two other colors. All Apple graphics are artifact based, and when ported to most (if not all) other similar computers, those ports lose some color definition because the artifact based color cell was unique to Apple. Despite this, the game graphics data could be re-used to a high degree, along with the bitmap routines. Very few changes are needed to port things like that over. Probably the biggest is the blitter, where the goofy Apple ][ addressing occurs. Once that's done, the rest of it maps pretty well.

 

The other thing to consider is that very few American software houses even understood PAL color artifacting. Almost no gear sold or produced (when that was the case, and it sure isn't now) in the US would display PAL. This just made kind of an ugly problem worse, IMHO. Stuff from the States rendered poorly because of these things.

 

From what I've seen, PAL color artifacting is kind of cool, and something that's really played out well over the years. Early on, PAL was seen as limited by a lot of people, because it didn't have the NTSC style artifacts. Fast forward to present day, and I think it's seen as superior all around.

Edited October 4, 2009 by potatohead

[popmilo]

Well, here is the BMPs of the posted images so someone wants to do better (I just can't seem to get a good A8 palette to colorize it):

I use PNG format for posting images...

Good compression and losless encoding...

Here is PNG of A8 version from your BMP

 

Looks good. How did you achieve those resolution enhancments ?

Did you use one color players or combination of two ?

Overlay? Underlay? Single width or double width moved half of gtia pixel to the right of GTIA pixels ?

Changes in X position of players ?

 

Good converter could be made with simple GTIA mode with overlayed PMs and bunch of DLIs for vertical color changes and x position of PMs...

Edited October 4, 2009 by popmilo

[atarian63]

Numen is tecnically far better, but not from the presentation point.

 

As someone who is essentially a non coder, you're not qualified to judge that first part.

As a user and dealer for over 30 years and having been in the industry through all it's trials and tribulations I am uniquely qualified.

Coders code for users.

How long have you been in the industry?

Edited October 4, 2009 by atarian63

[Jetboot Jack]

Being able to judge technical without programming skill of some kind. Not possible. Knowing hardware possibilities is a matter of presentation, not technical acumen. When judging the technical merits of a given production, one has to know something about the building of them, beyond hardware specifications, to realistically comment on whether or not a given element actually has technical merit.

 

I'm not wanting to pick arguments here, but that's not really true is it?

 

I do not code on the 360, PS3 or Wii directly, but I sure as hell know when I see a competent and well programmed piece of work, one that exploits and uses the hardware well, I can see that technically it is good - wether or not the actual content has merit as a game or program...

 

I can see when I look at any piece of software on any platform to be honest, I can appreciate the work from technical, artistic or design merits.

 

I have lots of direct experience of building software on most systems (from the 2600 to the PS3 via the PC et al), and do have a good technical understanding of platforms both modern and old, but I do not have to code to have that understanding, although what I do is work very closely with engineers, appreciate their skills and make an effort to understand the platform's features.

 

sTeVE

[atariksi]

 

 

That last picture shows 253 colours - and seems to have detail at 320 pixel resolution, That's pretty amazing for an A8 image? How do you do it?

 

Popmilo did a better job of looking at the picture than you did. I posted several similar pictures early in the thread-- they all get a bunch of shades added due to JPG not being able to deal with edges very well. But original BMP is 16 shades.

 

No problem, I only posted as the pictures aren't realistic - you should try harder to post accurate images to support your point.

 

The theory is JPG isn't suppose to affect the appearance of an image although the data gets slightly modified. I could use PNG but my image processing tools were written long time ago in DOS and Win 3.1 which doesn't have any PNG support.

[PeteD]

 

I do not code on the 360, PS3 or Wii directly, but I sure as hell know when I see a competent and well programmed piece of work, one that exploits and uses the hardware well, I can see that technically it is good - wether or not the actual content has merit as a game or program...

 

I can see when I look at any piece of software on any platform to be honest, I can appreciate the work from technical, artistic or design merits.

 

I have lots of direct experience of building software on most systems (from the 2600 to the PS3 via the PC et al), and do have a good technical understanding of platforms both modern and old, but I do not have to code to have that understanding, although what I do is work very closely with engineers, appreciate their skills and make an effort to understand the platform's features.

 

sTeVE

 

Being able to judge if something is technically good, yes, "far better" (emkays words) than another thing just because it's different? I don't think that's possible without knowing how things might possibly be coded and for a non coder that's just guesswork. emkay can't tell me how many cycles it would take for my software sprite routine to work and even that would be different depending on the situation, but he can compare it "technically" against someone elses that might look better or display more sprites in a different situation because he knows that the A8 CAN do software sprites? nope.

 

I've had 23 years in the industry now and a good few years coding before that and I wouldn't dare to compare peoples demo or game routines unless I had a clue how they worked algorithmically not just because I know the A8 has a faster cpu.

 

*edit*

The above industry time is just a little comment to atarian63 that his time "selling" and "using" can't really equate to "coding" If you're not a coder and have never written a game let alone a demo or app then I really don't see how you can argue that someone else who hasn't, has the technical knowledge to judge someone's code when they also don't have that knowledge. Kind of like the blind leading the blind.

 

 

Pete

Edited October 4, 2009 by PeteD

[TMR]

Numen is tecnically far better, but not from the presentation point.

 

As someone who is essentially a non coder, you're not qualified to judge that first part.

 

You don't need to be a coder, to know that. You just need to know about the hardware possibilities.

 

Even if that wasn't garbage to start with, you've already proven on several occasions don't know them for the C64 to make that call anyway - it was me had to explain to you about something simple like sprite data pointers, for example.

 

As a user and dealer for over 30 years and having been in the industry through all it's trials and tribulations I am uniquely qualified.

Coders code for users.

 

Demo coders don't, their primary motivation is to write something that will impress other demo coders and they've never cared much for what the userbase as a whole thinks of them. And my point stands, because unless you have a good working knowledge of code it's not possible to judge any demo on it's technical merits anywhere near properly.

 

How long have you been in the industry?

 

The industry is irrelevant in this context and being part of the demo scene is far more appropriate.

[atarian63]

 

I do not code on the 360, PS3 or Wii directly, but I sure as hell know when I see a competent and well programmed piece of work, one that exploits and uses the hardware well, I can see that technically it is good - wether or not the actual content has merit as a game or program...

 

I can see when I look at any piece of software on any platform to be honest, I can appreciate the work from technical, artistic or design merits.

 

I have lots of direct experience of building software on most systems (from the 2600 to the PS3 via the PC et al), and do have a good technical understanding of platforms both modern and old, but I do not have to code to have that understanding, although what I do is work very closely with engineers, appreciate their skills and make an effort to understand the platform's features.

 

sTeVE

 

Being able to judge if something is technically good, yes, "far better" (emkays words) than another thing just because it's different? I don't think that's possible without knowing how things might possibly be coded and for a non coder that's just guesswork. emkay can't tell me how many cycles it would take for my software sprite routine to work and even that would be different depending on the situation, but he can compare it "technically" against someone elses that might look better or display more sprites in a different situation because he knows that the A8 CAN do software sprites? nope.

 

I've had 23 years in the industry now and a good few years coding before that and I wouldn't dare to compare peoples demo or game routines unless I had a clue how they worked algorithmically not just because I know the A8 has a faster cpu.

 

*edit*

The above industry time is just a little comment to atarian63 that his time "selling" and "using" can't really equate to "coding" If you're not a coder and have never written a game let alone a demo or app then I really don't see how you can argue that someone else who hasn't, has the technical knowledge to judge someone's code when they also don't have that knowledge. Kind of like the blind leading the blind.

 

 

Pete

Actually Pete, though you might like to diminish just "selling" or "using" that's mainly just crap.

I have attended more developement conferences that I care to go over. Manufacturer demos and have flown around the country for various forums and symposiums in the industry over the years. Met Tramiel in both commodore and Atari iterations. EA,Activison,etc, met with them all back in the hey day.Was a chain store level buyer at CES during the 80's and early 90's and was wined and dined by all these companies. So to try to diminish my view as you have written a couple lines of code here and there is just silly.

Technical specs are very well known over the years and experience shows when "poor programming" takes place.

No one including most users back then were blind(though I think some coders thought so). Kind of like shovelware today,there were many titles I would refuse to recommend or even carry to customers or to the store locations we had.

In other words we reviewed what we bought and sold, in order to assist customers and store managers.

We listened to customers as well including user groups of the day for input on the quality of items.

I'll stand by may statements here in this thread.

Time and experience,were you in the trenches selling and dealing with this stuff?

Games are written for the players and who would know better than the supplier back in the day? Unlike now there were few sources that were up to the minute.

Not to mention we ran 2 service departments and board level hardware work was our specialty.

Edited October 4, 2009 by atarian63

[emkay]

[quote name='PeteD' date='Sun Oct 4, 2009 9:16 PM' emkay can't tell me how many cycles it would take for my software sprite routine to work and even that would be different depending on the situation, but he can compare it "technically" against someone elses that might look better or display more sprites in a different situation because he knows that the A8 CAN do software sprites? nope.

 

Tell me how you theroretically sprite routine works and I tell you how many cpu cycles it uses. Do you prefer indexed commands or some page zero subroutines?

23 years working in the industry and not beeing able to produce some bytes of working machine code is the really odd stuff.

[emkay]

Even if that wasn't garbage to start with, you've already proven on several occasions don't know them for the C64 to make that call anyway - it was me had to explain to you about something simple like sprite data pointers, for example.

 

You just filled some holes between of what I was knowing. Well, before knowing the easyness of simple sprite pointer adjustment, I had more respect people doing stuff on the C64. Now that I know the pointer function, it shows that a chimp can write games on the C64.

Edited October 4, 2009 by emkay

[PeteD]

[quote name='PeteD' date='Sun Oct 4, 2009 9:16 PM' emkay can't tell me how many cycles it would take for my software sprite routine to work and even that would be different depending on the situation, but he can compare it "technically" against someone elses that might look better or display more sprites in a different situation because he knows that the A8 CAN do software sprites? nope.

 

Tell me how you theroretically sprite routine works and I tell you how many cpu cycles it uses. Do you prefer indexed commands or some page zero subroutines?

23 years working in the industry and not beeing able to produce some bytes of working machine code is the really odd stuff.

 

You can tell me how many cycles it uses when it's finalised and Fist is released, and then you can go to 6502.org and count LDA $whatever =4 etc . I love how you come out with some words you learned zero page or indexed, Well done

 

Once again dood, you're dangerously close to taking your bullshit too far, you want to see my working machine code, go google for it, the fact I've "released" nothing on A8 means nothing in this conversation. Where can I find yours?

 

btw, I do expect an apology for all this "theoretical" stuff and calling me a liar the other day when I post any demo/code/game etc. but of course I won't hold my breath, it would be far beyond you to have the decency.

 

Pete

Edited October 4, 2009 by PeteD

[potatohead]

Being able to judge technical without programming skill of some kind. Not possible. Knowing hardware possibilities is a matter of presentation, not technical acumen. When judging the technical merits of a given production, one has to know something about the building of them, beyond hardware specifications, to realistically comment on whether or not a given element actually has technical merit.

 

I'm not wanting to pick arguments here, but that's not really true is it?

 

I do not code on the 360, PS3 or Wii directly, but I sure as hell know when I see a competent and well programmed piece of work, one that exploits and uses the hardware well, I can see that technically it is good - wether or not the actual content has merit as a game or program...

 

I can see when I look at any piece of software on any platform to be honest, I can appreciate the work from technical, artistic or design merits.

 

I have lots of direct experience of building software on most systems (from the 2600 to the PS3 via the PC et al), and do have a good technical understanding of platforms both modern and old, but I do not have to code to have that understanding, although what I do is work very closely with engineers, appreciate their skills and make an effort to understand the platform's features.

 

sTeVE

 

I think we agree more than not, and perhaps I drew the line too firm. It's not necessary to have written ATARI code. Just that a person has gone off and learned about programming. If that has happened, they will understand the elements in that context, and life is good, and the commentary would carry some weight.

 

I think working with the engineers can impart a lot of what is needed. My experiences are similar, and I do write code, though I don't even come close to what I see posted here. (freaking amazing most of the time --you guys kick ass, and you know who you are)

 

I'll gladly amend that to being involved in the process, fair? I sure think so and didn't mean to ruffle feathers. Not that we haven't all just PO'ed one another at least once on this monster, epic, totally addictive thread.

 

**I'm not placing myself in the "has coded" elite club. At most, I am a rank amateur, who enjoys computing for hobby / personal enlightenment purposes. Retro is great for that, as are micros. See my blog. Lots of people enjoy this hobby at that level, and it's all good. I really don't think there is an "elite" club. Just people doing stuff with various skill levels.

 

Where I was going was for somebody to diminish some effort, without being in the loop at least process wise, is just bad form. Also then, said commentary really doesn't carry any weight, meaning those that did the work, really should not give it much consideration. That's all.

 

Where I was also going is it not being a bad idea to just go and try some stuff! That's where the fun is.

 

Edit: Just re-read the flurry that happened while I was typing.

 

There is a clear difference between "sceners" and "programmers". I love the scene. Always have. It's a competition that has brought us many wonderful things, and I can't think of a better activity for a busy mind. I roped a bunch of "Programmers" into watching Breakpoint this year, and they were flat out stunned! A scener tackled the micro I'm hacking on right now and posted up code that will take the "Programmers" years to sort out. Did it just for fun, and the accolades, of course.

 

On this topic I'm a bit sensitive and defensive of those that choose to push the edge, break the rules and make interesting things happen. They do it because they can, and because others will recognize them for it. If those others are users, fine. But the real core audience are the other sceners, who will see the work for what it is; namely, an expression of art, code and technical skill presented in a way that is compelling.

 

This IS kind of an elite club, and rightfully so. To gain entry, you've got to jump on something, and trancend technical competence. You've got to gain mastery, then bend whatever it is to your will, despite the limitations. The EGOs surrounding that are totally appropriate, and healthy. Those that diminish that just kind of suck in my book. It's not that they are ignorant, it's that they just don't grok the whole thing.

 

I've went ahead and put my flame suit on. Let's hash all of that out, then carry on, GAME ON, whatever. Anybody anywhere that picks up an old machine and who manages to make it do fun stuff warrants the respect. At the same time, let's not diminish those people who can and are willing to absolutely sweat over it. We don't have as many of those as I would like, so why piss in that pool for no return?

 

All good from where I stand, but I just had to express that respect I have for everyone here. There is no reason to diminish one another, is there?

Edited October 4, 2009 by potatohead

[PeteD]

Even if that wasn't garbage to start with, you've already proven on several occasions don't know them for the C64 to make that call anyway - it was me had to explain to you about something simple like sprite data pointers, for example.

 

You just filled some holes between of what I was knowing. Well, before knowing the easyness of simple sprite pointer adjustment, I had more respect people doing stuff on the C64. Now that I know the pointer function, it shows that a chimp can write games on the C64.

 

No wonder there are so many more coders on c64, it's got freaks, nerds, chimps, I wonder who'll be next. Watch out for those asswipe paper videos though

 

 

Pete

[TMR]

Even if that wasn't garbage to start with, you've already proven on several occasions don't know them for the C64 to make that call anyway - it was me had to explain to you about something simple like sprite data pointers, for example.

 

You just filled some holes between of what I was knowing.

 

No, what you know even after that is still only the tiniest fragment of the whole and useless for making the calls you're trying to make. If you did have a basic knowledge, you'd have more questions than answers watching most C64 demos.

 

Well, before knowing the easyness of simple sprite pointer adjustment, I had more respect people doing stuff on the C64.

 

You've never shown even the slightest amount of respect for anyone writing C64 code and close to none for most A8 coders either, so that's obviously rubbish too.

 

Now that I know the pointer function, it shows that a chimp can write games on the C64.

 

And that's three for three because it would take someone who hasn't even the vaguest clue to come out with some idiocy like that.

[emkay]

You can tell me how many cycles it uses when it's finalised and Fist is released, and then you can go to 6502.org and count LDA $whatever =4 etc . I love how you come out with some words you learned zero page or indexed, Well done

 

 

Well, I never was a programmer in profession. But, back in the 80s I wrote small helpers in Assembler, including SIO transfer routines for a Atari networking game.

I also wrote my own loaders and logical DLI routines.... and so on. All learning by interest, non commercial....

Perhaps I'm rusty with all this... since my last coding activies are now 17 years ago.

 

 

 

 

 

Once again dood, you're dangerously close to taking your bullshit too far, you want to see my working machine code, go google for it, the fact I've "released" nothing on A8 means nothing in this conversation. Where can I find yours?

 

I'm not intending to do coding again on the A8.

Edited October 4, 2009 by emkay