Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

RE: [AVR-Chat] Bogus op-codes

RE: [AVR-Chat] Bogus op-codes

2005-07-25 by Larry Barello

Blank FLASH seems to operate a NOP for me.  When I am debugging the JTAG pod
erases the entire flash (including my bootloader), yet reset to the boot
vector still find 0x000 just fine :)
Show quoted textHide quoted text
-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Bruce Parham
Sent: Monday, July 25, 2005 2:39 PM
To: icc-avr; AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Bogus op-codes

I'm working on a boot loader for the 'm128 and got curious about illegal
op-codes.
Does anybody know what the real hardware does when it executes an
unimplemented code?
Studio sim seems to treat the all ones (0xffff) case as a no-op but I don't
have the
real hardware handy at the moment to see what it does. Thanks in advance for
any
insights.

Bogus op-codes

2005-07-25 by Bruce Parham

I'm working on a boot loader for the 'm128 and got curious about illegal op-codes.
Does anybody know what the real hardware does when it executes an unimplemented code?
Studio sim seems to treat the all ones (0xffff) case as a no-op but I don't have the
real hardware handy at the moment to see what it does. Thanks in advance for any
insights.

Bruce

Re: [AVR-Chat] Bogus op-codes

2005-07-25 by Dave VanHorn

At 04:39 PM 7/25/2005, Bruce Parham wrote:
>I'm working on a boot loader for the 'm128 and got curious about 
>illegal op-codes.
>Does anybody know what the real hardware does when it executes an 
>unimplemented code?

Any damn thing it wants to.
Why would you want to do such a thing?

Re: [AVR-Chat] Bogus op-codes

2005-07-25 by Peter Gargano

Dave VanHorn wrote:
>>Does anybody know what the real hardware does when it executes an 
>>unimplemented code?

> Why would you want to do such a thing?

Many years ago people asked the same question about the Z80. It was 
found there were many useful opcodes that were not documented. This 
was in the days when memory was more valuable than today.

Peter






















te.

Re: [AVR-Chat] Bogus op-codes

2005-07-26 by Dave VanHorn

At 06:15 PM 7/25/2005, Peter Gargano wrote:
>Dave VanHorn wrote:
> >>Does anybody know what the real hardware does when it executes an
> >>unimplemented code?
>
> > Why would you want to do such a thing?
>
>Many years ago people asked the same question about the Z80. It was
>found there were many useful opcodes that were not documented. This
>was in the days when memory was more valuable than today.

I was there. Using 6 MHz Z-80 systems and designing 4 MHz Z-80 systems.
But, the undocumented opcodes were then, and still are, a gamble.
You have no idea if the next rev will do anything similar, or even 
anything at all.

Re: Bogus op-codes

2005-07-26 by Joel Kolstad

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
> I was there. Using 6 MHz Z-80 systems and designing 4 MHz Z-80 
systems.
> But, the undocumented opcodes were then, and still are, a gamble.
> You have no idea if the next rev will do anything similar, or even 
> anything at all.

Back 'in the day' when Apple II's, Commodore 64's, etc. were the PCs 
most mere mortals could afford, undocumented CPU op-codes were not 
uncommonly used by copy protection routines in software, the idea 
being that it would take that much more effort by someone trying to 
bypass the protection if they didn't even know what the instructions 
were!  Of course, eventually the undocumented op-codes operation 
became pretty well known, and there were even assemblers and 
disassemblers that would accept them directly.

I suppose that 'undocumented' is something of a misnomer -- it was 
really just op-codes that weren't specifically 'designed' into 
place, so what they ended up doing was considered a 'don't care,' 
although -- as others have pointed out -- sometimes they did 
something vaguely useful.  The vast majority of the time, though, 
they just did something 'weird' that wasn't particularly handy.

Apple II's and Commodore 64's eventually came out with accelerators 
and newer models that used fancier, faster processors such as the 
65C02 and the 65816 (in 6502 compatibility mode) -- this did, 
indeed, break any code that relied on these op-codes.  (In 
particular, the 65C02 took the chance to add a bunch of new op-codes 
that were oft-requested by users.)

It's interesting to me that many of these old processors never die, 
they just tend to now end up as part of some embedded system.  The 
newer low-end HP calcultors (e.g., HP 33s) use a 6502-compatible CPU 
(ostensibly because it's dirt cheap in quantity), the Z-80 lives on 
in those Rabbit Semiconductor CPUs, the 68k is now quite popular in 
PDAs, etc.

---Joel Kolstad

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.