Motorola Microsystems M68000 Design Module - MEX68KDM issue L 46 week 1979

[inotarobot]

Well after a convoluted journey from USA to Australia my Motorola Microsystems M68000 Design Module - MEX68KDM has arrived.

I will have to take quite a few photos and also some measurement, as its way taller than my other Motorola Microsystem boards, like the 6809 CPU card (Micromodule 17)

1st photo is seller taken pic of my board s/n 3109 - second photo is of same model pcb, taken from a University web document. Interesting the red sticky label exists on 68000 in both photos and at the same angle, but 180deg different in the text. FIY Serial numbers are also different

its the same width to suit card cage (9.75") but is 14" tall compared to the rest of the normal Microsystem boards at 6".

Its even higher than the Motorola Microsystems eprom programming card, that sticks up above the card cage by 3". & its only 9 1/4" tall.

So next step is to just document all board selection jumpers, and take notes of the wire wrap links, that its prior owner had made.

Then I have to locate a copy of the following manual, to see what they all are. So far NO luck finding it online.

Following Detail of MEX68KDM are taken from University document, covering MEX68KDM serial number is 3183, which is only 74 boards after mine.

Also before I power it up, I will take a dump of the 8 eproms (4 even/4 odd) for the on board program

The eproms are labled MUDBUG K dated 26-Jan-84. So far NO google hits on this. Anybody hear of this mudbug ?

The purple ceramic XC68000L4 has a sticky red label 1980 and date code T6E8016. I think that 16th week of 1980, if I recall my date code decodes.

Thats all for now. More info to follow, as I work to power this M68000 Design module up.

 

[inotarobot]

Damn Time flies.

I had forgotten about this board as I had way more pressing issues to deal with.

To answer a recent question I never got around to powering it up.

Yes, it now got added to my long to-do list.

Hopefully by end of 2021

 

[philpem]

I've got a copy of that manual - it recently arrived in a stash of databooks. I'm waiting to hear if the person who sold it to me has the devkit too.

I probably can't easily scan it without cutting the binding (not going to happen!) - but I could snap photos of the pages you need, if that would help.

Funnily enough I found your thread searching for more info on the board. I was curious if anyone was selling one! I've been wanting a 68K SBC for a while.

 

[inotarobot]

Philpem I have only recently got power back after a few weeks post a severe storm here in the state of Victoria, Australia, and this is the first time i have been on Net for weeks.

Its Friday night after a long week so I am about to head to the "Sheep bed Paddock".. Will gett back to answering you here within 5 days.

 

[WGX]

(I realize I'm responding to and old post - I'm mainly a Motorola type and not here often).
Curious if you had any luck getting your MEX68KDM board running.
I was looking thru one of my boxes of firmware and found copies of the original MACSBUG firmware for your DM board. I'd planned to disassemble them someday, but found VUBUG more easily adaptable.
IIRC MUDBUG was a product of the University of Arizona's computer sciences department.
Cheers,

 

[Bruce Tomlin]

Okay, I downloaded it and was able to figure out (with the help of a good photo of the board) that I needed to merge U72+U50 and U73+U51. Historic versions of Macsbug is one of my special interests (along with historic versions of MS-BASIC), so thanks, this is a good one.

The part that confuses me is only the first half of each ROM is 68000 code (at $020000 and $021000). The second half of each ROM is a bunch of 4-word fields with a lot of repetition. Does anyone have any idea what this might be? It's entirely possible that it might not even be readable from the 68000 because of where the code goes.

00 00 00 00 00 00 00 00
10 F3 D1 E3 FE 7F 00 00
99 00 63 7E EC 44 A5 9B
40 EE D1 E3 FE 7F 00 00
D0 27 94 70 FF 7F 00 00
D0 27 94 70 FF 7F 00 00
00 00 00 00 00 00 00 00
D0 27 94 70 FF 7F 00 00
80 E9 D1 E3 FE 7F 00 00
B4 02 A4 13 01 00 00 00
D0 27 94 70 FF 7F 00 00
D0 27 94 70 FF 7F 00 00
00 00 00 00 00 00 00 00
D0 27 94 70 FF 7F 00 00
D0 E9 D1 E3 FE 7F 00 00
FF A7 A3 13 01 00 00 00
00 00 00 00 00 00 00 00
40 EE D1 E3 FE 7F 00 00
99 00 63 7E EC 44 A5 9B
D0 27 94 70 FF 7F 00 00
40 EE D1 E3 FE 7F 00 00
09 00 00 00 00 00 00 00
D8 97 A8 13 01 00 00 00
D0 27 94 70 FF 7F 00 00
30 EE D1 E3 FE 7F 00 00
67 A4 A3 13 01 00 00 00
50 E8 DC 70 FF 7F 00 00
10 F3 D1 E3 FE 7F 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
...

 

[WGX]

Hi Bruce,
I couldn't find your "10 F3 D1 E3 FE 7F" string in my contiguous binary - I suppose I should have included it earlier.
IIRC, rom binary U72 (X14) is EVEN(0), U73 (X15) is EVEN(1), U50 (X16) is ODD(0) and U51 (X17) is ODD(1). I think.
You would have to concatenate the even and odd binaries separately first, (0) followed by (1), and then shuffle the resulting binaries (EVEN then ODD, of course). Or just use the attached contig binary.
I have photocopies of parts of a Motorola manual related to the commands and ram equates, but for an earlier version (1.1) of MACSBUG. I'll scan and post what I have later. I haven't found it online anywhere.
Cheers,

 

[Bruce Tomlin]

The bytes I showed were after merging even with odd. It may be that the program I used to merge them added the extra data, because I started with 4 x 2K and somehow ended up with 2 x 8K. The program was just something I had hacked up two years ago, looks like it's time to see what I did wrong, but I'd really rather write a more general ROM utility.

EDIT: Ah, looks like I used a buffer size of 4096 and didn't properly handle a smaller file. Hmmm... I guess those numbers were just a bunch of 64-bit pointers lying around in memory.

 

[WGX]

Hi Bruce;

I found these pages in my MACSBUG disassembly efforts. They are *very* similar to those in the Corvus document on bitsavers.
Cheers,

Bill

 

[Bruce Tomlin]

Yes, the vector addresses handwritten on page 28 are the same, so not much difference at all. And it's probably essentially the same hardware, so page 26 should be useful too.

But page 24 is really useful for disassembling, as it documents the layout of the RAM area. Slight differences in code versions might show up as missing or extra variables.

I'm still angry at myself for back in the 90s working with this weird 68K system in a VT100 clone terminal with an LSI-11 backplane, for not keeping a copy of the Macsbug that it had, and I don't know why I didn't think to save it. It ran an obscure 68K Unix clone called "Regulus". They were literally starting the system up by doing a G command to run some bits of boot code in the ROM. I made a simple text menu system that let you select the right boot code without a cheat sheet. IIRC, I even added a "park hard drive" command, since the hardware was from just before the 40 meg mark when auto-parking became standard. I think the Macsbug it had was from about the same era as this one. (It also used parity RAM, and I found out real quick that you can't skip writing all of memory during startup to initialize the parity!)

 

[WGX]

I'm still angry at myself for back in the 90s working with this weird 68K system in a VT100 clone terminal with an LSI-11 backplane, for not keeping a copy of the Macsbug that it had, and I don't know why I didn't think to save it.

In hindsight there's a lot I wish I'd squirreled away for later, but you can't keep everything. (You can try, tho).
I took a 68000 night course at a local polytechnic about 40yrs ago. (I'd planned to wirewrap a 68K SBC on an S100 protoboard). One evening the instructor brought in a MEX68KDM just for show. After class I went up to admire it and asked the price (yikes!). Joking, I asked if I could "borrow" the eproms for a week - to my surprise he said yes (!). I made two sets of copies - still have them. Wrote a concat and shuffle program in Basic, disassembled a few pages by hand, then wrote a one-pass disassembler in Basic. Never did finish the disassembly, or the S100 board, tho.
Had no idea anyone would be interested in an old MACSBUG monitor. I hope you find it interesting.

Cheers,

 

[Bruce Tomlin]

I noticed that I had a document mentioning the Corvus Concept having a Macsbug 2.0, and it's here: https://bitsavers.org/pdf/corvus/Corvus_Concept/firmware/Macsbug_2.0/

I also found some Corvus ROMs of the 1.32 version, but those files were short dumps, with two and three bytes missing. But it was clearly the same version that you posted yesterday.

But I did finally finish my own disassembler a few years ago. It's an interactive tracing disassembler (see link in sig), and it goes through this stuff like butter, with a little direction from a human. It's fun watching the raw hex blink into assembly code. These 8K Macsbugs only take a couple of hours to rough out.

My first attempts at writing a disassembler in Basic date back to 1979 when I was in high school, so it took me a while to get there.

EDIT: I also found some Corvus Concept Macsbug manuals here: https://bitsavers.org/pdf/corvus/Corvus_Concept/manuals/

They both refer to the 2.0 version, and they seem to be basically the same info.

 

[WGX]

Thanks for pointing out the link to your 68K disassembler. It looks like I have another project . It should come in handy.
I'm currently building a small bus-based 68K system (from Mega-Micros in the UK). It will be fun to see if I can get MACSBUG running on it.