Jump to content
phuzaxeman

classic battle atari 8bit vs commodore 64

Recommended Posts

What's interesting is when a CPU has undocumented opcodes that work because real microcode was put in for those instructions. They're sort of vestigial opcodes. The 6502 has no microcode, and thus all undocumented opcodes are acted upon by the same mechanisms as for documented ones.

 

That's true of many undocumented opcodes on the Z80 as well, including those involving IXH, IXL, IYH, and IYL, as well as OUT (BC),0 and IN (BC) instructions and the undocumented CB instructions.

Share this post


Link to post
Share on other sites
The standard programmers reference manual just breaks down the instructions and only the more hardware oriented docs for a specific CPU had timing info

...

I'm guessing you'd need to refer to the more hardware oriented stuff or errata for behavior that differs from the Programmers Ref Manual.

...

However, if you were to need such information... you'd need to look at when the prefetch takes place in the clock cycle diagrams. I think that's in the more hardware oriented docs... it wouldn't be in the programmers reference manual.

 

So please tell me where in which hardware manual, errata, data sheet, or whatever, any of the issues I mentioned is documented at all (directly or indirectly)?

 

I made a mistake with the CLR r/m issue, that one was indeed documented in later revisions of the manuals. But none of the others (plus some other issues I didn't mention) is documented anywhere. Not in the programmer manual, not in the user hardware manual, not in datasheets, errata, never.

 

Most of the issues I mentioned were not even described in third party literature. Furthermore, some of them, such as the timing of DIVU/DIVS were completely unknown until very recently.

 

You mean the self modifying code that Motorola and Amiga said *not* to write because it wouldn't work on all CPUs?

 

Can you tell me where/when Motorola said you should not write self modifying code in the 68000?

 

Sorry, never wrote self modifying code on the 68000 because my code was either in ROM or had to run on CPUs where it would break...All that stuff is interesting but did the software written with those tricks work on later versions of the machines?

 

And what this has to do with what we are discussing? We are not debating about the recommended way to code, or about what could break in later revisions.

 

Surely that self-modified code could break in a later version of the computer. That doesn't affect undocumented issues only. Any code that depends on cycle accurate timing would break in a faster processor. And instruction times (for almost cases do are documented). So even if you would rely in documented issues only, your code could still break in the future.

 

So I agree that you should better avoid any issue that could possible break in the future. That was never the point here at all. The point is that many aspects on the 68000 are undocumented, much more than in the 6502.

 

I stand corrected... however it is still 16/32... not 16.

 

Yes, you are right there and I agree.

Share this post


Link to post
Share on other sites
There seems to have been a different design philosophy with the 8-bit chips than the higher ones...

 

Yes, I agree. But for quite some time the 68000 (and not the 68020) was used in application that needed cycle accurate timing. It was used for that purpose long after it was obsolete, precisely because the timing was predictable. Nowadays, an ARM device can offer the same accuracy and actually ARM does advertize them as "predictable".

 

And if code has bugs that unintentionally rely upon undocumented behaviors, I'm not sure what difference it would make if they were documented.

 

That then (almost) all debuggers would emulate them, and that then software emulators could "easily" implement them.

 

Precise emulators do generally exist since, among other things, they're needed by the chip developers themselves.

 

Btw, I understand that since long ago realtime chip emulators are not available (disregarding how precise). It is probably not technically feasible when you are talking about the latest/fastest CPU or GPU. I understand they use software emulation and modelling (obviously, not at realtime).

 

How much is 'perfect' emulation worth? Given a choice between: (1) an in-circuit debug module which plugs into a ten-pin header and offers most of the features of an ICE, including accurate emulation of all documented features, for $1000, or (2) a hardware emulation module which requires soldering on a massive ugly 144-pin connection where the CPU goes, is prone to crashing if anything is bumped, and costs $20,000, which seems a wiser purchase?

 

ICD/BDM wasn't available then. So you can't use ICD in the 68000.

 

Regarding when ICE is worth, and how much perfect emulation is worth, well it depends. For most of us, it is not worth. For Apple or Sun (or even Atari or Commodore) debugging there own boot and kernel 68000 code, $20,000 was nothing.

 

Nowadays, you could say that Microsoft or Intel wouldn't mind at all to pay 1 million dollar for a modern Pentium ICE (which could easily be the actual cost, if that is technically feasible).

 

Anyway, and for the specific case of the undocumented aspects of the 68000. Implementing them wouldn't make a hardware debugger much more expensive. This is of course assuming you have the necessary information, either because it is openly documented or you have it under NDA.

 

And of course that nowadays that we want software emulators and hardware clones of vintage computers, you want/need to emulate the most minimal detail of the original hardware.
Far more critical with 8-bit CPUs than 16-bit ones, and even there mainly for tricky hardware interfacing (including 'beam chasing' video or copy-protection loaders).

 

I don't know about the Amiga, but "Beam chasing" is used in the ST as well. Tons of ST games depend on extremely accurate emulation. And of course that most games are copy-protected. Even when using cracks, many times portions of the "anti-hacking" stuff is still there.

 

What's interesting is when a CPU has undocumented opcodes that work because real microcode was put in for those instructions.

 

Again, those exist in some Intel CPUs. The most (in)famous one was probably LOADALL. Google it for a detailed description of the whole story.

Share this post


Link to post
Share on other sites
That broke many a program on the C64 during it's days. They must of had like over a dozen revisions of the thing, each worst then the last.

What meaningful changes were there in its CPU?

Admittedly, now that you mention it, I maybe recalling compatablity with C-64 mode of the C-128's 8502. :dunce:

The 6510 in the C64, the 8500 in the C64C and the 8502 in the C128 all behave the same, even when it comes to illegal opcodes.

Share this post


Link to post
Share on other sites
The problem is assuming that just because said instruction executes, it's legal. Which is not the case, in chips like the 6502 & 6510, illegal opcodes are a side effect of low level technical design of the CPU and are undocumented because said instruction doesn't exist outside of accidental cross-circuit logic. Many of said illegal opcodes do not even execute, it just so happens, by shear luck, some do with unintended but useful results.

ACK.

 

Some time ago I had a very interesting discussion with a chip-designer concerning the illegal/undocumented/... opcodes of the NMOS 6502 CPUs.

 

First, as we all know, the NMOS 6502 doesn't completely decode all opcodes and thus several parts of the ALU/CPU are active. If the opcodes would have been decoded completely it would have been quite easy to turn them into a NOP or BRK or something else.

 

The next thing isn't that obvious (at least it wasn't to me): If you connect 2 or more NMOS outputs you get a simple "wired AND". The HIGH signal is "weak" and the LOW signal is "strong" (BTW: this doesn't do any harm to the NMOS outputs). And this is what's happening inside the NMOS 6502 (have a look at the illegal opcodes tables floating around and you'll see that a lot of those opcodes have some sort of AND functionality in them).

 

AFAIK all the information about illegal opcodes so far has been gathered by trial-and-error / blackbox testing / reverse engineering. I.e. run an opcode and then look at the results. I don't know if there's a complete and accurate description of all illegal opcodes with all side effects (at least I haven't found one yet).

 

To build a really comprehensive list one would have to analyze the CPU at a gate level and create a formal description of what's going on. Since the illegal opcodes completely depend on the CPU implementation it could even be that some opcodes work slightly different (i.e. a flag set/cleared) on different revisions (6502 vs. 6510 vs. Atari Sally vs. ...).

 

so long,

 

Hias

Share this post


Link to post
Share on other sites

What about the $x2 and $xC opcodes?

 

They cause a lockup which is reversible only by a RESET.

 

But, is it documented what exactly happens? Does the 6502 just spin, reading the one address endlessly? Or does it actually shut up shop completely?

Share this post


Link to post
Share on other sites
That broke many a program on the C64 during it's days. They must of had like over a dozen revisions of the thing, each worst then the last.

What meaningful changes were there in its CPU?

Admittedly, now that you mention it, I maybe recalling compatablity with C-64 mode of the C-128's 8502. :dunce:

The 6510 in the C64, the 8500 in the C64C and the 8502 in the C128 all behave the same, even when it comes to illegal opcodes.

Yes and no, the illegal opcode maybe there, but they execute differently.

 

As an example:

http://www.cloud9.co.uk/james/BBCMicro/Doc...ation/64doc.txt

The rest two instructions on the same line, called 'ANE' and 'LXA'

($8B and $AB respectively) often give quite unpredictable results.

However, the most usual operation is to store ((A | #$ee) & X & #$nn)

to accumulator. Note that this does not work reliably in a real 64!

In the Commodore 128 the opcode $8B uses values 8C, CC, EE, and

occasionally 0C and 8E for the OR instead of EE,EF,FE and FF used in

the C64. With a C128 running at 2 MHz #$EE is always used. Opcode $AB

does not cause this OR taking place on 8502 while 6510 always performs

it.

 

I've been trying to track it down, but there was atleast one early scene demo that didn't work on subsuquent 6510 variants because of it's creative use of illegal ops. But damned if I can remember the name. I know some of the guys on #c-64 used to know, but it's been like 3 years since I've been there. Tho I'd imagine most of the gang is the same. I stopped visiting because I got sick of noob moderators who don't know me taking away ops given to me by higher ranking people.

Share this post


Link to post
Share on other sites
To build a really comprehensive list one would have to analyze the CPU at a gate level and create a formal description of what's going on. Since the illegal opcodes completely depend on the CPU implementation it could even be that some opcodes work slightly different (i.e. a flag set/cleared) on different revisions (6502 vs. 6510 vs. Atari Sally vs. ...).

 

I was hoping supercat or other NMOS expert would study the microphotographs on that Hungarian site. Last time I checked (not so recently) it seemed to me they are not complete. supercat, just out of curiosity, did you check them?

Share this post


Link to post
Share on other sites

The 6510 in the C64, the 8500 in the C64C and the 8502 in the C128 all behave the same, even when it comes to illegal opcodes.

Yes and no, the illegal opcode maybe there, but they execute differently.

Wrong. All those CPUs share the same 6502 core and have the same illegal opcodes because of that.

Share this post


Link to post
Share on other sites

I'd say "very little". Probably under 2% of software on the Atari. Maybe a bit more common on the C-64.

 

If anything, some C-64 games employed some pretty fancy tricks with their copy protection.

 

One of the keys to successful copy protection is to not make it obvious - something like a CPY #144, BNE COPIED! would be detected by a cracker in minutes.

 

A good trick is to have a flag somewhere and check it later.

 

C-64 used such methods as using the RAM under locations 0,1 which can be altered but not read by the CPU. But, you can get VIC to read it for you. And with tricky combination of screen pointer and sprites, use the collision registers to check what's there.

 

Although, that sort of thing doesn't fall into the "undocumented instructions" category.

Share this post


Link to post
Share on other sites
I'd say "very little". Probably under 2% of software on the Atari. Maybe a bit more common on the C-64. If anything, some C-64 games employed some pretty fancy tricks with their copy protection.

 

It is quite common to use illegal opcodes in protections. I don't know exactly how many Atari programs do use it, but it is probably much higher than 2% of the commercially released copy protected software. Of the top of my head, all later Synapse programs use them extensively for protection purposes. I also remember seeing them in several european releases.

 

I'll be surprised if they would be more common in the C64, at least for the same period. It is probably more common on the C64 because it spawns a later period.

 

C-64 used such methods as using the RAM under locations 0,1 which can be altered but not read by the CPU.

 

Interesting, there is a similar feature in the ST, but AFAIK it was never used for protection (or for any other purpose).

Share this post


Link to post
Share on other sites

Using illegals was pretty safe on C64. They worked everywhere. Some early fastloaders/copy protections failed because of other reasons: For example, some fastloaders used a too fast stepping speed which only worked on some drive mechanics, while others could not move the read/write-head that fast. This resulted in the head positioning ending up on the wrong tracks. Another incompability was a too tight serial protocol implementation. Some people programmed hardware like a demo effect: They maxed out every clock cycle. As a result, their serial protocols didnt work on some setups.

Share this post


Link to post
Share on other sites
The standard programmers reference manual just breaks down the instructions and only the more hardware oriented docs for a specific CPU had timing info

...

I'm guessing you'd need to refer to the more hardware oriented stuff or errata for behavior that differs from the Programmers Ref Manual.

...

However, if you were to need such information... you'd need to look at when the prefetch takes place in the clock cycle diagrams. I think that's in the more hardware oriented docs... it wouldn't be in the programmers reference manual.

 

So please tell me where in which hardware manual, errata, data sheet, or whatever, any of the issues I mentioned is documented at all (directly or indirectly)?

Next time I go digging through my storage unit I'll see if I can find the book.

I know at least some of that info is in it since I had to count cycles using the book. The timing diagrams were clearly aimed at hardware designers instead of programmers so I didn't look it over in detail. The company I worked for was engineering their own system and that's how I got the books.

Share this post


Link to post
Share on other sites

Some illegal instructions in these 8 bit CPUs may have been the result of the hand layout process used at the time. It could have been tricks to keep the die small or just to save time.

Share this post


Link to post
Share on other sites

I'd put it down to saving on the component count.

 

Remember, the 6502 was aimed at the $25 component market when competing CPUs were sometimes 10 times the price.

 

I forgot about the Synapse protections.

 

AFAIK, all their games also tended to have checksums which would crash if they didn't match up. Tape games also tested for presence of a disk drive. Disk games often did a check to ensure a disk drive was present.

 

Since we got very little in the way of officially distributed software here in the day, most of what got around was pirated (ie already cracked).

Share this post


Link to post
Share on other sites
So please tell me where in which hardware manual, errata, data sheet, or whatever, any of the issues I mentioned is documented at all (directly or indirectly)?

Next time I go digging through my storage unit I'll see if I can find the book.

 

I wasn't exactly "asking". It was a rhetoric question because I already know the answer.

 

I know at least some of that info is in it since I had to count cycles using the book.

 

Of course. Nobody said that the cycle execution times are undocumented for all the instructions. I said that they are not fully documented for a couple of cases, and I specifically mentioned in which cases. For these cases only the maximum time is documented. And for the DIVx instructions, even the maximum value (only documented timing) is wrong.

 

The timing diagrams were clearly aimed at hardware designers instead of programmers so I didn't look it over in detail.

 

How in earth the timing diagrams are supposed to help for this specific purpose? The diagrams are for generic bus cycles (read cycle, write cycle, etc). They are obviouslly not detailed for each and every instruction and variant (that would be ridiculous).

 

So they are completely useless for deducing instruction execution times, or cycle by cycle execution of each instruction. And even if complete detailed timing diagrams were available (which, again, it wouldn't make any sense), it still wouldn't be enough. It wouldn't be enough because those diagrams don't detail internal (to the CPU) operations.

Share this post


Link to post
Share on other sites
It had an 8 bit DAC but 2 bits were used for cassette and 6 for sound.

Actually, now that I think about it... it had an 8 bit register arranged like that. I don't know if it was an 8 bit DAC or 6 bit.

Either way, they probably could have multiplexed the lines so it could have had an 8 bit DAC output.

 

Hi James.

 

You are right. Roger at www.coco3.com. Mentioned a couple years ago in his chatroom that you could increase the 6bit dac for sound to 8bit. But Roger said you had to cut a tracer line and connect it to the 6bit sound line something like that. been years since Roger mentioned it. But when you did this, I think he said that you lost the Bitbanger port or was it the cassette line.

 

But it is possible to do what you mentioned James.

 

laters

 

Briza

Share this post


Link to post
Share on other sites
Hi James.

 

You are right. Roger at www.coco3.com. Mentioned a couple years ago in his chatroom that you could increase the 6bit dac for sound to 8bit. But Roger said you had to cut a tracer line and connect it to the 6bit sound line something like that. been years since Roger mentioned it. But when you did this, I think he said that you lost the Bitbanger port or was it the cassette line.

 

But it is possible to do what you mentioned James.

 

laters

 

Briza

It's the cassette line.

Share this post


Link to post
Share on other sites

Actually it seems to me, that the atari is still not pushed to its limits. I used Atari 8 bit and c64 for years and I did a lot of reading/research. Also i have programmed both machines in the past.

I remember the ST/Amiga times when a lot of people say the ST cannot do this cannot do that blablabla, but some clever ST coders (demoscene) did the job. So I think this is the same for the atari 8 bit. Its only a shame that it takes more than 20 years to prove that the atari xl for example is just as good as the c64 in cases where the c64 beated the atari xl.

I do not think that games like Turrican is impossible to do on atari xl, I still believe that it is possible. I also looked at the Turrican clone for the xl on you tube and this demo promise a lot I think.

 

Also there is a lot of talking about the sound side of the xl and the c64. Well that's very interesting, because I can make a link to the synthesizers I owned and I discovered a interesting fact. Both the Roland Juno and Jx3P synthesizers are studioequipment, but there is a huge difference between the sound of both machines.

The Jx3P has more possibilities but the Juno sounds more professional, thicker sound/nicer sound. The JX3p sounds thin.

This is the same case in MY opinion with the c64 and the xl. The c64 seems to have more possibilities but sounds a lot more thin than the atari xl soundchip. Plus I think when you do some deeper programming with the Atari xl I think you will get more out of it, I am not sure if that will bring you the same results as the c64 but you can try.

Share this post


Link to post
Share on other sites

No offence to the TP but I don't see what the point is in doing this, it's never going to be clear cut which system is the best, no one is going to agree on anything and everyone is just going to continusly go over all the strengths and weaknesess of the systems. It's been debated so much now.

I'm not sure it's always so much about "which is better," despite that that's pretty much the name of the thread, but rather, it's about exploring different ideas about why, and exploring the systems' separate parts and certain sums of their parts. That is, if you look at several threads that surround this same idea, they don't all unfold in the same way. It's about adding different users' ideas about the two beloved, similar but very different computers that were both far cheaper and better than the Apple IIe. 😂😂😂

 

Cheers!

  • Like 1

Share this post


Link to post
Share on other sites

So... your first post is a necrobump of a thread that's been dormant for 8 years?

  • Like 2

Share this post


Link to post
Share on other sites

My first idea was,

 

Finally, someone has developed a game that you

can play against each other on both kind of

computers.

But sadly just another "witch system was better" thread.

 

Stefan

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...