CUDA, EGRET, HC6805 Hacking

[trag]

I am starting a thread over here, so that Powermax and I stop hijacking the "Q700 ADB or board kaput" thread.

This thread is for discussion of topics related to recreating the CUDA and/or EGRET chips from non-Apple hardware.   The chips are based on the Motorola 68HC05 microcontroller according to notes from Apple, so in theory, what is needed is to download the ROM code from an existing chip, program it into the ROM of a new (old stock) 68HC05 chip and proceed.

There may have been variations in the 68HC05 such as package, pinout, amount of RAM or ROM onboard, etc. that make this more complicated.  I haven't checked the relevant datasheets yet.   

There are various versions of the chip used by Apple, so different versions may be needed on different machines.    I can report that I've taken a 341S0060 and installed it into a machine that formerly had a 341S0788 and the machine operated properly afterwards.   Possibly there was some obscure issue that I never ran into, but as far as I can tell, it worked perfectly.

Powermax reports that the CUDA was based on the Motorola 68HC05EG, which may be similar to the 68HC05E1.    Datasheet here HC05E1GRS.pdf

There is a tool for making CUDA dumps, so it should be possible if a compatible 68HC05 can be found, to program the code into a new chip and substitute it into a needy Mac, without scavenging from an old board.  http://www.gryphel.com/c/minivmac/extras/egretrom/index.html

 

[powermax]

which may be similar to the 68HC05EI

68HC05E1

 

[trag]

68HC05E1

Fixed in edit.  Thank you.

 

[techknight]

I know the 6805 assembly language, and even the machine code like the back of my hand. 

Finding replacement pin-compatible chips wont be easy though, it would be easier to disassemble the original ROM and create an equivalent using a PIC or an AVR or something. 

 

[powermax]

it would be easier to disassemble the original ROM

Yep, already done + understanding and commenting it 

and create an equivalent using a PIC or an AVR or something. 

That's a good idea indeed. The biggest problem could be CUDA's clocking. Although it's clocked by an external 32768 Hz crystal, it has a built-in phase-locked loop synthesizer (PLL) that is capable of rising the MCU internal clock up to 4 MHz (32768 * 128).

This frequency switching possibility is exploited in the CUDA firmware as follows:

• when in the power-off state, CUDA operates at the lowest clock speed off the PRAM battery. Anything CUDA does is to tick the clock and to wait for the power switch to be pressed. That low speed allows to save battery power.
  
• when the power switch is pressed, CUDA raises its internal clock to 2 MHz to achieve higher responsiveness
  

I'm not sure if we need to support that way of power saving. The fixed frequency of 2 MHz could be enough...

 

[techknight]

Well if you want a programmable oscillator and PLL during runtime, you have to go with the ATXmega series which I use in my products, But, it would entirely be overkill. 

Honestly it just needs to be clocked at a frequency that it has decent performance, and then be able to have even divisible timings. (ADB, etc) and thats it. 

the AVR is a RISC IC and its capable of a much higher instruction per second count than the 68HC05. 

 

[powermax]

Finding replacement pin-compatible chips wont be easy though, it would be easier to disassemble the original ROM and create an equivalent using a PIC or an AVR or something.

With a PIC/AVR, is it possible to assign a custom functionality to arbitrary pins?

 

[techknight]

Depends on what you mean by that. Each pin has its own set of functions depending on how you declare it. 

Some pins are hooked to timers for PWM, some pins are also interrupts, or UARTs, or ADC compare inputs, SPI, I2C, or just GPIO. Depends on how you write the code to configure it. 

 

[trag]

Digikey still has stock of the MC705P6ACDWE for about $8 each in onesies.    However, the P6 only has 176 bytes of RAM and the E1 that may be similar/equivalent to the CUDA has 368 bytes of RAM.   How much RAM does the CUDA code require?

Reprogramming the functionality onto another platform is certainly a possibility.    A similar option would be to use a 9S08 replacement.   The 9S08 family is backward compatible with the HC05 in terms of core and instructions, to the reprogramming would be minimal.    However, the pinout of the 28 pin SOIC 9S08 that I looked at is very different from the pinout of the 68HC05E1.     Unfortunately, it's not just repurposable I/O pins, but the power and ground are on different pins.  Some kind of interface board would be required, and I'm not sure how one solders that into an SOIC footprint.    Little legs on each side of the board that bend at right angles, so the board sits vertically and the legs go out to the pads?

I haven't checked the datasheet in detail, but I would expect the 9S08 to have the same sort of PLL versatility.

The 9S08 is the successor (renamed?) HC08, which was a slightly more capable variation on the HC05.

Yep, already done + understanding and commenting it

Any chance you could point us at this?

Techknight, how similar is HC05 to 6809 machine code?   I originally learned machine/assembly on the 6809 way back when.   Took a class on interfacing that used the 9S12 more recently.

 

[techknight]

I am not familiar with the 6809. The only reason I know 6805 is because the ST Micro ST19XXX series used it. Also so did the old Siemens SLE series until the switched to 8051. 

 

[Gorgonops]

how similar is HC05 to 6809 machine code

Roughly speaking I think the '05 is more comparable to the 6502 than it is the 6809, but I say that with my only significant exposure to assembly on any of them being the 6502.

 

[trag]

Did a little Google search.   There's a nice discussion back in 1993. 

Groups on Motorola Taxonomy

but Google Groups being the steaming pit of incompetence that it is, I'm not sure the link will stay good, so I'm giong to quote a couple of the postings.
 






 

Jonathan Levine







     
 
 
 
 
7/17/93










>As far as I am aware the 6811 is based on the 6805 family, but with some
>enhancements. The 6805 is itself a rehash of the 6800uP to make it into
>a single chip micro. The 6800, 6805 and 6809 are similar in architectures
>but are not completely code compatible. The 6809 is closer to the 6800
>than the 6805. The 68000 is totally incompatible in terms of machine code.
>I do not know of any 6809 compatible processors.
>--
>P. J. Harding
>CDSS Ltd.
I don't think the above is quite right.  I'm doing this from memory, but
a bunch of years ago I did the side-by-side comparisons from the data
books, and concluded that the HC11 is a 6801 with another register and
a divide instruction.

The 6800 is the base of the tree for all of these families - the 01/HC11,
05, and 09 series'.

Being Motorola parts, the 68Ks retain much of the 8-bit philosophy, such
as big-endianess (?), but it's in no way upward compatible with them.  It's
much more like a PDP-11 than anything else.

This has been previously mentioned, but the Hitachi 6309 parts are code-
compatible with the 6809s.

--
Jonathan Levine

Eero Sarlin







7/19/93






Moto 8bit MPU/MCU's (was Re: ..a 6809 based instruction set?)







In article <21udi3...@srvr1.engin.umich.edu> j...@acc.flint.umich.edu (John Lauro) writes:
>In article <steveh.742544554@tasman> ste...@tasman.cc.utas.edu.au (Steve Howell) writes:
>The 68HC11 might be based on the 6809 (I don't know), but it certainly
>is very different...  They have different addressing modes and different
no it is not, it's based on proprietary MCU, an secret successor to 6801U4

Major Correction:
MC68HC11 is the HCMOS follower of MC6801/3 , having about 91 new instructions
and one new register (Y index register)

 the porting of an Mc6800/01/02/03/08  application to 68HC11 Is quite easy .
MC6809 is the best of motorola's NMOS 8bit processors (HC11 is HCMOS and 68K
is 16bit) and porting from previous exept HC11 is also pretty easy.

porting from MC6809 to HC11 may be easy but only in the unprobable case
if user stack pointer is not used, nor fancy postincrements and predecrements,
and if the programmer that wrote 6809 stuff did not have proper knowledge
of 'Oh nines powerfull instructionset enhancements, but such programmers would
get fired, would'nt they?

MC6805 family was downgraded 6800/02/01 with embedded controlling in mind
(most 6805 variants have internal ROM or EPROM and more or much more I/O)

MC68705xX is eprom variant of NMOS 6805xX
MC68HC705xX is eprom variant of MC68HC05xX (here x is letter and X is number)
MC1468705xX is eprom variant of MC146805
common denominator for previous 3 lines of totas some 200 processors is '6805'
or nowdays HC05 for the middle

MC6804/MC68704 and MC68HC04/MC68HC704 were attempt to get 8bit MCU at 4bit
price, those were downgraded 6805's with special 1bit serial bus at 11MHz

a good basis for studying Motorola's 8bit family genealogy is the 1984/1985
8bit microprocessor & peripherial databook (now obsolete) pages 1-2..1-5
it was printew when there was only 1 HC11 variant and only 1 HC05 variant.

further enligtment might be found from the latter 1988 book DL139 or
Microprocessor,microcontroller and peripherial Data Vol I pages 1-2,1-3

nowdays HC11 family has more variants than total of all M68xx NMOS  MPU's
(that is 6805 nmos excluded)

and the MC68HC08 will continue 68HC05 family upwards as MC68HC16 does to HC11
--
Disclaimer: opinions are and will stay mine, my employer just pays my salary
Eero "HC11F1" A. Sarlin

 

[powermax]

How much RAM does the CUDA code require?

CUDA Firmware actually uses 386 bytes of RAM. It's divided into two main partitions as follows:

• $0090 - $00FF various local variables
  
• $0100 - $01FF 256 bytes of PRAM --> yes, PRAM is simply a part of the CUDA's internal RAM; since it's always powered (either by the mains or the battery) it doesn't lose its contents
  

 

[powermax]

Any chance you could point us at this?

Sure. I attached three different binary dumps. Disassembly including my personal comments aren't included there. I need to take some precautions and don't post those here because they're surely copyrighted...

View attachment CUDA Firmware dumps.zip

 

[trag]

386 bytes, or 368 bytes?    The HC05E1 datasheet says it has 368 bytes, which is not enough if the firmware uses 386 or even 384 bytes.

$0090 - $00FF  =>  $006F which is 112 bytes.    112 + 256 = 368.

 

[powermax]

$0090 - $00FF  =>  $006F which is 112 bytes.    112 + 256 = 368.

368 is the correct amount of required RAM. 386 was a typo. Sorry.

 

[powermax]

Is there any place around here where I can dump all CUDA-related stuff (including pictures, schematics, firmware disassembly etc) I gathered so far? A kind of editable Wiki?

 

[techknight]

Github is the only place I know of. Other than cloud storage like dropbox, google drive, etc. 

 

[powermax]

What's about the 68kmla Wiki?