Motorola 68000.

[Cowthief]

Hello.

Some members have been cracking the 68000 CPU.
This link is to a FREE emulator for this CPU.
http://www.monroeccc.edu/ckelly/easy68k.htm
I have tried it, although it is not as polished as the actual motorola product, it works well.
Thje 6800/68000 series of CPU is what every radio /\/\ makes is based on, from the the STX to the astro spectra and on.

[RADIOMAN2002]

The Motorola processor is the 6800 series, usually the 6807, not 68000, thats used in Apple/MAC computers

[Cowthief]

Hello.

Yes, the 6800 series is the most common CPU in motorola radios.
The 6800 is a 8-bit based CPU.
The 68000 is a 16 bit based CPU, but can run 100% of the code for the 6800 series, as it has all the commands.
You can for example, take a 68000 Single Board Computer (SBC), and put this into a spectra radio, running the original code.
It runs MUCH faster, but as an 8 bit radio.
You can, however, add 16 bit code, within reason, whatever you want.
You can add alpha-tag, external serial port (UART), what have you.

[fireradio]

Hello.

Yes, the 6800 series is the most common CPU in motorola radios.
The 6800 is a 8-bit based CPU.
The 68000 is a 16 bit based CPU, but can run 100% of the code for the 6800 series, as it has all the commands.
You can for example, take a 68000 Single Board Computer (SBC), and put this into a spectra radio, running the original code.
It runs MUCH faster, but as an 8 bit radio.
You can, however, add 16 bit code, within reason, whatever you want.
You can add alpha-tag, external serial port (UART), what have you.

And I suppose that's the magical secret to the face-programmable secret-squirrel spectra

[edit]

[alex]

It's really good to see that since so many people doubt that it's even possible - that they aren't willing to accept a prefectly plausable explanation.

Lets try and be willing to hear him out - just think about the theory of operation.

-Alex

[fireradio]

It's really good to see that since so many people (2?) doubt that it's even possible - that they aren't willing to accept a prefectly plausable explanation.

Lets try and be willing to hear him out - just think about the theory of operation.

-Alex

Fine, I'll bite. First of all, I don't see how this is possible. Swapping out processors in very integrated devices such as radios generally doesn't work too well. Besides that, isn't it pretty difficult to remove and replace surface mount components like that without very specialized equipment? Secondly, what is an SBC? I doubt you can "just plug a 68000 SBC into a spectra" and start playing around. He doesn't offer any technical explanation, just random theories that don't make any sense. Besides, what is the point of doing this? To make that spectra "faster?" Based on cowthief's track record, I am just pretty skeptical about this. But - I'll stand by for an explanation.

[w7com]

Actually if you hack at old computer hardware (old, like the 8 bit machines and 16 bit VME bus stuff) what Cowthief is saying sounds right. He's talking like an old hardware hacker, not a radio person here. A SCB is a Single Board Computer, a term from back in the day when most computers came with seperate I/O, memory and CPU boards. Look up SWTPC 6800 sometime to get a flavor of the era. And yes, I can see how, with a bit of wirewrap, odd sockets, lots of time, and a burning desire one could very well upgrade a spectra to a 68k. Back in the early 80s I made my money replacing the 8042 MPU in a Code-A-Phone with a Commadore C64 (which you could call a SBC.) Stranger things have been done.

I'll grant that a lot of you know way more about RF than I do, but when it comes to the old 8 bit computers and TTL logic, I'll give any of you a run for your money.

This post by Cowthief DOES pass the laugh test.

Added: Looking at the link I see that there is a BASIC available for the 68000 on there too. Now that would be interesting, a Spectra radio with an easy programming interface.

I think a lot of readers here have missed what Cowthief is doing with radios. I don't think that he's just trying to add some features and then box it back up and put it in the car. He seems to be hacking at the core of the radio and signaling subsystems by using other CPU hardware as a tool. I suspect if you would actually read what he writes and then ask intellegent questions instead of running him off at first posting we all would learn some really cool things.

[alex]

The problem here is that there are a lot of people who like to be spoonfed information. I'm one of them. I'll raise my glass to the concept - I admit that.

But people are also here to learn and experiment with different things. THey want to be able to take it apart and peek inside - see how things run. Then, see how far they can make things go. Those people are out there, and are willing to help. The'll guide you though the ways so that you can learn how things are done. Once you start to see the puzzel start to come together - finishing it isn't the hard part.

If you stop and think. What runs the radio? 68K processor. Hmm. Gee - that's not documented anywhere at all.

We can't have every answer, and there are some things people can't share. If you discover them on your own, good for you. Just keep in mind that our existance here is based upon the fact that we have to have some respect for Motorola. Giving out the keys on how to save millions of dollars on upgrades and other assorted fun isn't something that M wants out in the open.

-Alex

[w7com]

I see it a lot like what the Piexx guy did with the Syntor. Pull it's CPU and plug another one in to make a different radio. One of these days Mother Mot won't care so much about Spectras, and when that day comes I think that we'll see many private notebooks come out of the woodwork.

[SlimBob]

Hello.

Yes, the 6800 series is the most common CPU in motorola radios.
The 6800 is a 8-bit based CPU.
The 68000 is a 16 bit based CPU, but can run 100% of the code for the 6800 series, as it has all the commands.
You can for example, take a 68000 Single Board Computer (SBC), and put this into a spectra radio, running the original code.
It runs MUCH faster, but as an 8 bit radio.
You can, however, add 16 bit code, within reason, whatever you want.
You can add alpha-tag, external serial port (UART), what have you.

I call ********.

[w7com]

I call ********.

Why? Just because you don't know how to pull off this trick? Given time and better eyesight I could pull the 6800 series chip from a Spectra and glom a 68k in to run the native code. With a lot more hacking I could get the native code to run in a seperate code space and have CPU cycles left over to add all sorts of trick things, like a UART for serial access. Add some basic video logic (ala C64 or even hacked out of an early Mac) and many fun ideas come to mind.

The easy way to do this on the bench would be to use an ICE (In Circuit Emulator.) That's a PC like machine that has hardware to emulate another CPU. Motorola sells them (or did at one time.)

Logic circuits are just legos. And the legos that are in a Spectra are about the same class used by the Apple II.

I'll call your ******** and raise you your unimanginitive mind.

[Motofanatic]

Ok, I've sat around and taken in all these comments and can't take it anymore since it now boarders on ridiculous.

First off, Cowthief never said he did hook up a 68000 to a Spectra, he just said "for example".

However, he is incorrect you can take 68HC11 code and run it on any 68K family. Can't be done, unless you have the source code to recompile it into a 68K target plus tons of changes to accomodate architectural changes between the 2 families.

Now if someone really wanted, sure you could take probably ANY 8-bit or 16-bit processor with the necessary peripheral support chips and write software to control the same parallel, clock and serial lines on a Spectra command board to emulate a 68HC11 but having your own custom code.

So again, anything is technically possible so long as you have the source code to recompile for a different target with appropriate changes. The BS part is taking native 68HC11 binary and running without any changes on a 68K family. I'll bet anyone this is BS because I've been working on Motorola processors for 20 years in my profession, from 6800, 6811, 68020, 68340, etc. - I design software and hardware for embedded systems (military and commercial) and KNOW it is impossible.

While a good joke and rumor is fun everyone now and then, please don't mis-educate people or mislead people. We're here to learn from each other, not mis-inform people.

[w7com]

You're right, one can't just plug 8 bit 6800 code into a 16/32 bit 68k. I should have checked my old databooks. One could run 68HC11 emulator code on a 68k platform to do the trick but that would really be more of an ICE solution.

I forgot that the Spectra uses the HC11, wasn't that the one with the second page of op-codes one could bank in and out of? Back in a past life I had the HC11 eval kit but that project ended up using a 6500 series solution.

Anyway, I'd really like to see more topics on serious hardware hacking than just the standard "how do I make a funny MODAT noise" and "look how many strobes I have on my POS POV!" I guess that I'll have to start some. I hope I don't get flamed off the board by thinking out-of-box like Cowthief does.

[farscott]

As an embedded hardware engineer, this discussion is interesting. I think that although the proposed swap from the 6800-series to the 68000-series is possible, it is extremely unlikely due to its difficulty. Here is a short list of issues.

1) The 68000-series are 32-bit (data and address register) parts, not 16-bit parts, with a user selectable 16-bit and 8-bit data bus. The packages are very different (say 52, 56, or 64 pins in the 6805 to 132, 144, or 160 pins in the 68331 and 68336), so as to accomodate the wider bus structures.

2) This means that any swap would have to add parts to accomodate the "floating" data and address bus pins of the new design. Floating pins would cause the micro to end up "in the weeds". This is not a simple desolder and replace job. A design would need to be done with an associated PCB layout.

3) While many of the 6800-series parts have on-board flash, the 68000-series usually requires external flash, meaning a need for more external parts and glue logic (either discrete or CPLD would be acceptable at these speeds).

4) The operating speeds of the two parts are different. If the clock is used to derive a baud rate for data transfer or timing, more timing issues would result.

Interesting topic.

[w7com]

As an embedded hardware engineer, this discussion is interesting. I think that although the proposed swap from the 6800-series to the 68000-series is possible, it is extremely unlikely due to its difficulty. Here is a short list of issues.

1) The 68000-series are 32-bit (data and address register) parts, not 16-bit parts, with a user selectable 16-bit and 8-bit data bus. The packages are very different (say 52, 56, or 64 pins in the 6805 to 132, 144, or 160 pins in the 68331 and 68336), so as to accomodate the wider bus structures.

Direct CPU replacement wouldn't work. I was thinking of using a PIO on a SBC. The 68360 eval board would make a nice choice.

2) This means that any swap would have to add parts to accomodate the "floating" data and address bus pins of the new design. Floating pins would cause the micro to end up "in the weeds". This is not a simple desolder and replace job. A design would need to be done with an associated PCB layout.

Yes, if done correctly it should end up looking like Monty's cats got into the wirewrap supplies.

3) While many of the 6800-series parts have on-board flash, the 68000-series usually requires external flash, meaning a need for more external parts and glue logic (either discrete or CPLD would be acceptable at these speeds).

See #1 above

4) The operating speeds of the two parts are different. If the clock is used to derive a baud rate for data transfer or timing, more timing issues would result.

Reminds me of when we were running VIC-20 code on a 6502 board at 4MHz. We had to install a gearshift (divide by 4) and a clutch (ground HALT) to make it work with the Commadore 1541 disk drive. Damn software timing loops!

Interesting topic.

It is! This is the stuff I like to think about. Now if I could just find someone to pay me to play with my favorite 20 year old technology.

[Motofanatic]

Scott, glad to see another real hardware person on here. Your comments are correct and I didn't want to slam-dunk the topic but here are the other major software reasons it won't work:

The HC11 is typically configurable with many built-in, on-chip peripherals. you can have A/Ds, parallel ports, serial ports, timers, etc. The HC11 on the Spectra is HC11A3 but is a close cousin to the HC11E1.

The code running on the MLM OTP PROM is compiled to configure the onchip parallel ports A-D for particular operation as used on the Spectra command board. The 68K does not have these on chip peripherals and even if it did, it would not be memory mapped in the same area.

The HC11 uses a different interrupt table structure than the 68K. The 68K uses a 1kbyte memory mapped interrupt vector table at the bottom of memory. Again, binaries would not be compatible.

The 68K has a concept of user and supervisor modes for protected multi-threaded OS uses. The HC11 does not and its binary code would not be able to configure the 68K as necessary to ensure the proper mode was selected.

Regarding W7COM comment about seeing more of this kind of discussion - I'm not a lawyer, but I seriously doubt you'll see any discussion of how to reverse-engineer the operations of the SB9600 bus or any proprietary message checksuming or data block encryption simply because of intellectual property issues with Motorola.

Yes, I know about the Piexx and also the Anaconda (I've met Matt before). While there is information on batlabs about codeplug hacking, I have never seen any documented information regarding PLL setup or SB9600 configuration. And I have my doubts we ever will (at least publically on here).

[Wowbagger]

As both a hardware and software engineer who has implemented several trunked radio protocols, there is a furthur problem you haven't considered.

OK, suppose you HAD a pin-for-pin compatible 68K running at 16 MHz that could replace the HC11 in the radio. Assume you have the source code, and that the bulk of the code is C rather than assembly. Assume you get the conversions done to map the hardware in the new address space of the new processor. Assume you can fudge the code plugs so the RSS works.

In every trunking protocol I've implemented, you will always have a section that goes something like "The repeater will send a $FOO message. The Radio SHALL respond within 40 ms with a $BAR response."

Now, every time I've done this sort of stuff I've had a VASTLY more powerful processor to work with than your typical radio does (because of the fact that I am doing protocol analysis, parametric analysis, and driving a much more complicated UI than a normal radio has). What I've invariably found is that in such cases, the what the spec SHOULD have said is:

"The repeater will send a $FOO message. The Radio SHALL respond within 40 ms with a $BAR response. However, if the radio responds in less than 20 ms, $BRAND repeaters will barf and not connect. Therefor, the response message SHOULD be generated not less than 30 ms and not more than 40 ms from the recept of the $FOO message."

The speed of the radios acts as a software timing loop (or what I like to call a "Mississippi Loop", since the processor is in effect saying "One Mississippi. Two Mississippi. Three Mississippi."). The designer of the radio did not INTEND to do timing in the code, but unintentionally did. When you use a faster processor, those unintentional code paths break.

So, after you put in your double-ought spy sekrit sooperdooper 68K upgrade, you will find that you STILL don't talk to the repeater!


Sure, in theory you could upgrade the processor in a radio, and add all sorts of neat stuff. In theory, you can live forever. In theory, there is no difference between theory and practice. In practice, there is.

[Motofanatic]

Wowbagger,

You are of course correct. I didn't want to delve into timing issues given all the architectural changes between the two CPU families.

But yes - I am aware of what you speak of having ported code from one processor family to another under completely different RTOS. Sometimes you'll get good source code which clearly documents where critical timing is, sometimes you don't. With a good hardware engineering staff, hopefully a lot of timing and wait state issues between CPU and memory/peripheral components is dealt with, but often communications off the board to the "outside" world is still fixed with hard timing.

Thanks for pointing out these issues and how unlikely it would be to take existing HC11 binaries in a Spectra and have them run without any changes (or even minimal changes) on a 68K family CPU.

[SlimBob]

Sheezy. I have a book on the HC11 and a few boards.. looks like I need to go Spectra shopping....

[Cowthief]

Hello.

The idea is not to take the actual chip and swap.
The idea is to run the emulator, patched, with motorolas code, to find out what is actually going on.
I have a spectra with a SBC patch sitting in Houston Texas.
Again, the idea is to get a greater understanding, not to produce the super spectra from hell.
I use the genuine motorola developer kit, so there is no issue of what will work.
The point of the post is that an emulator for motorola CPUs is out, and it is free.

[SlimBob]

Hello.

The idea is not to take the actual chip and swap.
The idea is to run the emulator, patched, with motorolas code, to find out what is actually going on.
I have a spectra with a SBC patch sitting in Houston Texas.
Again, the idea is to get a greater understanding, not to produce the super spectra from hell.
I use the genuine motorola developer kit, so there is no issue of what will work.
The point of the post is that an emulator for motorola CPUs is out, and it is free.

See, if you'd said this the first time, we probably wouldn't have drug it out. Fascinating idea, but it takes time to learn microprocessors and debug stuff along the way. You also run the risk of things going wrong -- so your modified radio may not be able to have the same reliablity as the original.

Yeah, I'm all for it as well, but I don't have any books on the 68000 series nor any practical knowledge. FWIW, the Syntor X is a Z80-based radio.

[Motofanatic]

Hello.
The idea is not to take the actual chip and swap.
The idea is to run the emulator, patched, with motorolas code, to find out what is actually going on.

This is perfectly plausible.

I have a spectra with a SBC patch sitting in Houston Texas.

In all my years of working on embedded systems, I have never heard of a SBC patch. The physical proportions of a typical SBC would not allow long runs of address and data lines to be interfaced to a Spectra command board without a lot of difficulty and noise problems. As Scott and Wowbagger have pointed out, it is a major undertaking even with the proper hardware designed for the intended use. A SBC by default does not offer that customization.

Again, the idea is to get a greater understanding, not to produce the super spectra from hell.
I use the genuine motorola developer kit, so there is no issue of what will work.
The point of the post is that an emulator for motorola CPUs is out, and it is free.

I have never had a Motorola development kit that didn't work properly. However, we've always had to design a custom ASIC or FPGA to interface the SBC to our hardware (legacy or new). Changing processor families is always a big hardware and software undertaking.

[Cowthief]

Hello.

Yes, the 6500 series has it's quirks.
Yes, the 6800 series is an upgrade, to say the very least.
The 68000 is a big leap.
However, motorola has made the leaps easy.
You see, motorola had released packages, to make the leap.
The spectra, in Houston, is still working.
There is no person who has been there who has said that what I have done so far has not worked.