Atari v Commodore

[atariksi]

BA doesn't matter for the timers. They simply stay in sync.

The background code has to use the same cycles else you get jitters of when the IRQ triggers off.

Pretty much the same on Atari and C64 or anything else.

 

However an IRQ which has to be stable and only doesn't jitter when it uses a very predictable amount of time is of no use. Real world routines aren't simple as that and you always have to de-jitter your IRQs.

 

I see you re-edited your post after I replied. No, I don't buy they are useless. That's your opinion. You don't have to de-jitter them if you can account for all the cycles in your code and that's THE optimal approach. Of course, it's difficult the more complex the code is, but that does not make them useless. One other use (besides one given above) is for I/O to devices that expect things at exact intervals or need to be sampled at exact intervals. I already gave a USE for it above (to save time from WSYNC) so you need to make sure you read the posts.

[atariksi]

Sorry, you just missed the last 25 or so posts. We are trying to avoid jitters with least overhead. That's the subject being discussed.

And you posted a routine which "avoids" jitter by using a very very special case which you will never encounter in real programs.

 

I gave the general formula how to avoid jitter. You can modify that code in the idle loop so as long as divides evenly into the cycles remaining. And those cycles remaining can be modified as well if you need a more divisible dividend by tacking on some instructions to the VBI.

[Lazarus]

I gave the general formula how to avoid jitter. You can modify that code in the idle loop so as long as divides evenly into the cycles remaining. And those cycles remaining can be modified as well if you need a more divisible dividend by tacking on some instructions to the VBI.

But things like that are not possible to do in real programs. You cannot just make your main program "dividable by 17" everywhere under all conditions whatever user input it gets and whatever it has to do. It's just something which is such a weird abstract method that it's simply not possible for a human being to do in a program which exceeds your demo routine size. And btw: The same can easily be done on C64 too because it has the exact same conditions: Timer IRQ/NMI at a certain raster position, same CPU.

[peteym5]

Does the C64 have anything like a bank switching ROM cartridge like we see on the Atari 8-bit? That is one thing that is strong on the Atari 8-bit with doing 32k, 64k, and 128k carts with an 8k or 16k window. Some of the more memory intensive games probably be hard to do on the Commodore 64. My Tempest Xtreem and Dark Chambers would be good examples. On way around it is have portions loaded from a disk, but that is much slower.

 

What's the cost per cartridge on the A8 for the 128K cartridges (assuming you do a run of 100)?

 

I would think flash ram based cartridges would be cheaper and hold more.

 

$15 to $20, depending on how much I do in one bulk. We (Atlantis Games Group) are going over to AtariMax carts that are 128k and there is another type that is one megabyte (1024k). We were at first using XEGS supercarts, but those are harder to flash and had to outsource some of the work.

 

Having lots of memory that can be bank switched in and out allows anyone to make a major game. Those would be games that have lots of levels and need to access lots of data. You can use disks, but that is much slower. I am alittle surprised that it was not common on the Commodore 64. Like I said using cartridges is much faster and harder to pirate.

[Lazarus]

I am alittle surprised that it was not common on the Commodore 64. Like I said using cartridges is much faster and harder to pirate.

On C64 the better disk copy protections are extremely hard to crack due to the programmable drive. For cracking a cartridge you basically only needed to burn an EPROM with cartridge autostart disabled and find out how the banking register works.

[emkay]

I see you re-edited your post after I replied. No, I don't buy they are useless. That's your opinion. You don't have to de-jitter them if you can account for all the cycles in your code and that's THE optimal approach. Of course, it's difficult the more complex the code is, but that does not make them useless. One other use (besides one given above) is for I/O to devices that expect things at exact intervals or need to be sampled at exact intervals. I already gave a USE for it above (to save time from WSYNC) so you need to make sure you read the posts.

 

 

The whole writings about IRQ jitter is like putting coal into the fire for C64 guys. Just forget about POKEY timers and stick to the CPU time correctness after using DLIs ... It worked for 99.99% of available programs.

And, well, why talking about POKEY timer's correctness (µs) , when people even do not recognize the ~ 25% (ms) time offset for 50Hz music programming....

 

This gets ridiculous.... and only helps C64 guys to force their displaced argues...

[atarian63]

Waste of time example again. there are some rare occasions in the 83-84 period but mostly by a wide margin Atari wins easily!

 

And you're saying you didn't sell more C64 software in your unbiased computer store?

 

Must be quality, as you say, is the reason Atari software outsold C64 software everywh..er in your store.....

 

desiv

 

I kid.. I'm a kidder.. I love both...

From my perspective tho, the pics lean towards the 64, even tho you have a reason for almost every one.

My point is he is being very selective.You have to search pretty hard for better than A8 stuff in 83-84. As for software sales, depends on the time period. We were doing 3mil a year in Atari and Commodore at one point so there were lots of both being sold. early commodore not so good, very good 86/early 87, here is the part that bugs me. mid 87 onward even though there were tons of titles c64 software never achieved it's peak again. Piracy,ST,Amiga,pick your poison.

Atari died due to lack of support,not so much lack of demand.

[frenchman]

BTW, there's over 300 official released cartridges for the C64:

http://www.mayhem64.co.uk/main.htm

(look under 'cartridges')

Edited September 25, 2009 by frenchman

[atarian63]

...Waste of time example again.

No, its not waste of time... It shows just what was happening after your so much loved period, before 83....

 

In 1990, money moved away from 8bit to 16bit computers...

Bedroom coders made what they could with machine in their spare time...

And you have games like turrican and mayhem on c64, and games like Yogi on A8...

I think A8 programmers (like polish wave of games that was produced at that period) did best they could.

And I don't think they were worse coders than C64 coders...

 

Just that A8 was simply more difficult (in some cases impossible) to develop certain games for...

 

That is why you get games with 16 colors background and >8 sprites in an average bedroom coders C64 game (Authors of "Mayhem" made one of the prettiest games on commodore just so that their mother could play it in spare time...)...

 

And you get 4-5 color background, and few sprites on A8 because thats easy.... that is straightforward process ...

They are not even bad games, I played some of Polish arcade adventures and it was time well spent...

 

...there are some rare occasions in the 83-84 period but mostly by a wide margin Atari wins easily!

So atari wins in 83-84 ... How nice from you to limit comparing to the timeframe that suits your needs

Sorry, again,waste of time and not symbolic of software of the period, also I would imagine there were many more Atari programmers so in that time frame it was actually easier to write for Atari that some new weird machine.

 

As for picks of time periods, seems like Rockford and I guess yourself prefer times after atari was dead to compare.. bet that works really well for you to compare to the player who has left the field

[andym00]

I am alittle surprised that it was not common on the Commodore 64. Like I said using cartridges is much faster and harder to pirate.

 

It is for sure, but if the cartridges had been more prevailing then by '85 I bet we'd have had a cheaply available battery backed RAM cart that can have ROM images loaded into

[PeteD]

On C64 carts were something used FOR piracy not to prevent it I'm sure there must have been more Expert/Final/etc carts sold than games.

 

Thinking of Expert cart has just taken me back to my demo coding days and not having an assembler for most of it. Writing code in a monitor is no fun, especially when you want to add an instruction in the middle of a routine ahhh the good old days. You tell the kids of today that and they won't believe you.

 

Pete

Edited September 25, 2009 by PeteD

[TMR]

Which of course the C64 isn't actually doing... For the character based screens used in all but one of the games i mentioned, the badlines fetch screen data in the same way the A8 does for the five colur character-based modes being used, less in fact if the A8 has to fetch more bytes because it's scrolling horizontally. The odd game out from my list as far as the C64 is concerned was BMX Simulator, which runs a bitmapped screen for both versions and the C64 is still only taking that same 40 cycles of DMA every eighth scanline, what is the A8 doing?

Good, if A8 is in a 5-color text mode that has 40+ wasted cycles, then the comparison is more even although it probably needs to burn a few more to really make it fair.

 

Thing is, at the C64 end i'm perfectly happy to let you have the forty cycles of interrupt time you were wanting every eighth scanline; apart from anything else, you still haven't said how you're planning to do anything useful with it...

 

It was an assumption because i'd never seen it done; when you explained how the theory works i accepted it despite no working examples and after that point was concerned with how a game using it would look from amongst other things a design perspective. And again, still a moot point because we were talking character modes and you brought up the GTIA, taking us off at a tangent.

You yourself was doubting and now you are blaming me for going off tangent. I can talk about GTIA or GPRIOR 0 easily.

 

No, the tangent was moving away from five colour character-based mode in the first place since we were comparing existing games, once that had happened i found the tangent interesting (who knows, i might actually see if i can get around the sprites standing out, i've had a couple of ideas but i'm not sure they'll work yet) but it still bore no relation to what we were previously discussing. GPRIOR 0 is in a similar boat, the games in question weren't using it so it's not directly related, regardless of how interesting that tangent could be.

 

No, it's also constituting ugly in your interpretation as well.

 

What interpretation? i was using dictionary definitions like you said to and there's nothing to connect the phrases i used directly or otherwise to the word "ugly".

 

And here we go again with that Chewbacca defence garbage...

It's not AGAIN. It *IS* Chewbacca defense and everytime I stated it before it *WAS* Chewbacca defense.

 

The Chewbacca defense is offering up totally irrelevant facts in order to confuse before using that confusion to your advantage; since i didn't introduce anything irrelevant (unless talking about things that may or may not be beautiful when discussing beauty is somehow going off topic, which it isn't of course), i haven't gone anywhere near the Chewbacca defense.

 

On the other hand, since you've essentially introduced the Chewbacca defense in an attempt to deliberately confuse things, you're using the Chewbacca defense... oh the irony!

 

More colors and more shades does make things more beautiful even in your example. You can have a beautiful garbage can or carcass with more colors/shades and an ugly one if you just had purple, yellow, and orange. Your example does not refute that having more colors/shades available does make the objects more beautiful.

 

My point has always been that beauty is subjective, so what is a beautiful rubbish bin to you isn't necessarily going to be for me or indeed anyone else, regardless of how colourful it is or whatever justifications you believe you can offer; there are works of art that are essentially monochrome that some people consider beautiful, others see it in black and white photography. Dances can be described as beautiful without the performers wearing overly colourful clothing, the skills exhibited by sportsmen have been described as some observers in a similar way. And i'll mention it again, the saying "beauty is in the eye of the beholder" is well used enough to be offered as proof and it's not possible to get any more subjective than that.

 

And whilst we're still talking about dictionary definitions, you might want to look up the words garish ("crudely or tastelessly colorful") or gaudy ("that which is gaudy challenges the eye, as by brilliant colors"), the existence of which demonstrate that having more colour isn't always a good thing generally.

[PeteD]

40 cycles minus of course, what is it, 6 in and 6 out before even pushing/popping/ack-ing

 

Pete

[TMR]

I am alittle surprised that it was not common on the Commodore 64. Like I said using cartridges is much faster and harder to pirate.

 

There is literally only one game cartridge that wasn't cracked properly back in the day, that was Toki and the problem was that it used the banking to bring in sprite animations on the fly. The game was still cracked, but the in-game music was removed to make space for those extra sprites.

 

If nothing else, cartridges put the data all in the one place and the more complex disk-based (and indeed some tape-based) protections were significantly harder to circumvent.

 

It is for sure, but if the cartridges had been more prevailing then by '85 I bet we'd have had a cheaply available battery backed RAM cart that can have ROM images loaded into

 

i had a battery backed cartridge, Datel made it if memory serves.

[TMR]

40 cycles minus of course, what is it, 6 in and 6 out before even pushing/popping/ack-ing

 

i wouldn't be duly worried if those cycles weren't even counted... =-)

[TMR]

Thinking of Expert cart has just taken me back to my demo coding days and not having an assembler for most of it. Writing code in a monitor is no fun, especially when you want to add an instruction in the middle of a routine ahhh the good old days. You tell the kids of today that and they won't believe you.

 

Coding with a monitor? You had it easy, when i first started learning machine code on an unexpanded VIC 20 i hand assembled everything and POKEd the code in a byte at a time! And our dad sent all seventeen of us to work for 27 hours a day in the mines...

[andym00]

The whole writings about IRQ jitter is like putting coal into the fire for C64 guys. Just forget about POKEY timers and stick to the CPU time correctness after using DLIs ... It worked for 99.99% of available programs.

And, well, why talking about POKEY timer's correctness (µs) , when people even do not recognize the ~ 25% (ms) time offset for 50Hz music programming....

 

This gets ridiculous.... and only helps C64 guys to force their displaced argues...

 

Calm down.. It was an interesting topic whether you realise it or not.. The only coal that's been thrown on the fire is by you with your "~25% (ms) time offset for 50hz" comment.. I've not got the foggiest what you're trying to say there, which is probably just as well really..

 

Anyway, go play with this:

http://noname.c64.org/csdb/release/?id=82788&show=hidden#hidden

SID music with the driver sampling the output of OSC3 into a delay line

Though you will be needing a real C64 to properly get the benefit of it..

 

I eagerly await your scathing hyperbole and technical description of how Pokey can no doubt do exactly the same thing with using cycle counted hamburgers and a partridge in a pear tree..

[PeteD]

Thinking of Expert cart has just taken me back to my demo coding days and not having an assembler for most of it. Writing code in a monitor is no fun, especially when you want to add an instruction in the middle of a routine ahhh the good old days. You tell the kids of today that and they won't believe you.

 

Coding with a monitor? You had it easy, when i first started learning machine code on an unexpanded VIC 20 i hand assembled everything and POKEd the code in a byte at a time! And our dad sent all seventeen of us to work for 27 hours a day in the mines...

 

I was spoiled for a while having a Beeb Write a basic program and just put asm in it. Whose idea was that? C64, it was down to poking for a while. Me and Claka used to know the hex and decimal for all the opcodes lol

 

 

Pete

[andym00]

On C64 carts were something used FOR piracy not to prevent it I'm sure there must have been more Expert/Final/etc carts sold than games.

 

Thinking of Expert cart has just taken me back to my demo coding days and not having an assembler for most of it. Writing code in a monitor is no fun, especially when you want to add an instruction in the middle of a routine ahhh the good old days. You tell the kids of today that and they won't believe you.

 

By god I had a love affair and half with the Expert Cartridge

Though writing anything more than a few 100bytes in it was not on my agenda.. I still don't understand the sheer maschocism of some of the programmers back then writing entire games using only monitors..

[desiv]

Coding with a monitor? You had it easy, when i first started learning machine code on an unexpanded VIC 20 i hand assembled everything and POKEd the code in a byte at a time! And our dad sent all seventeen of us to work for 27 hours a day in the mines...

 

Software Poke?

 

You were lucky!

 

When I was a kid, we had to poke the bits into the computer using sticks with magnets on the end of 'em!

 

 

OK, seriously, my only assembly was a bit I hand typed into my C64 BASIC program. About then, I decided I shouldn't be doing assembly. :-)

 

desiv

Edited September 25, 2009 by desiv

[Heaven/TQA]

my first 6502 code was poking stuff into computer stores 600xls something like lda 53770, sta d01a, jmp 16384

 

I knew the dec opcodes, too... but nowadays I knew more the hex codes...

 

 

my vic20 basic games plus mc code where written on paper and then turned into data statements... no assembler used...

 

major inspiration in that days was Atlantis with his raster codes...

[andym00]

Coding with a monitor? You had it easy, when i first started learning machine code on an unexpanded VIC 20 i hand assembled everything and POKEd the code in a byte at a time! And our dad sent all seventeen of us to work for 27 hours a day in the mines...

 

Microtan 65 with a hex keypad, though it wasn't the most successful introduction in history Then I got a Vic and later HesMon and basically ruined the rest of my life with 6502

[peteym5]

On C64 the better disk copy protections are extremely hard to crack due to the programmable drive. For cracking a cartridge you basically only needed to burn an EPROM with cartridge autostart disabled and find out how the banking register works.

 

Most of the disk based games were cracked on both machines and why we have many of the images today. There are a few cartridge images that could not be cracked because they had problems figuring out the bank switching registers.

 

It is for sure, but if the cartridges had been more prevailing then by '85 I bet we'd have had a cheaply available battery backed RAM cart that can have ROM images loaded into

Well if we think cartridges were not doing so well in the mid 1980s, it was not Atari or Commodore that took over the game market, it was Nintendo. That was why Atari started manufacturing 64k and 128k carts for the XEGS&7800 in attempt to compete with Nintendo 8. But by the time Atari had it ready to market, Sega came onto the market with the Genesis. So they were going nowhere fast.

 

The other main thing are cartridges load, access and transfer data at the internal speed of the computer. Where things happen almost instant with a cartridge based game, it will take many seconds with a disk based game. You know I am talking about games that cannot be crammed into 64k with lots of fonts, backgrounds, sprites, sound tracks, sound effects, etc.

[TMR]

Most of the disk based games were cracked on both machines and why we have many of the images today. There are a few cartridge images that could not be cracked because they had problems figuring out the bank switching registers.

 

Some of the disk-based games have only been done recently on the C64, some of the Nostalgia and Remember jewel cracks are the first fully working unprotected versions of the games due to sneaky security checks buried in the code and so forth and one or two games still haven't been cracked properly, although in a few cases it's more because someone stuffed up the mastering and, given time and a little luck, even those can at least be partially repaired; take a look at the Nostalgia version of Tony Crowther's Phobia because the surgery required for that crack is extremely impressive; the sprite multiplex was replaced entirely to get some CPU time back for NTSC fixing, a large number of fatal bugs removed... even the original wasn't as stable.

 

On the C64 at least, cartridges offered very little in the way of actual protection and could be pirated pretty much at will with enough knowledge. There were tape loading schemes like Cyberload that offered more of a fight and it's developer John Twiddy (he also coded The Last Ninja amongst others) also wrote the Expert cartridge software for a few generations, so for a while he was basically fighting himself as he'd put new features into the loader and sell it to clients, upgrade the Expert to beat those features and sell that to Trilogic, then go back to the loader, rinse and repeat... that was pretty damned shrewd of him. =-)

[TMR]

By god I had a love affair and half with the Expert Cartridge

 

Up until i got my first Action Replay 6, i was an Expert lover; i had a modified version of the software that a local cracker had done (it made the unfreezing much tidier and could detect program the cartridge as it was switched from "off" to "on") and my first real C64 game Co-Axis was written on a tape-based machine with the Expert and Zeus 64...