ron@motmpl.UUCP (Ron Widell) (12/13/90)
This is a response to e-mail from: |---------------------------------------------------------------| | // Wayne D. Diener, Key Tronic Corp. | | // Spokane, WA | | \\ // E-mail reply to: | | \X/ To: isc-br!hawk!wddami!wayned@uunet.uu.net | |---------------------------------------------------------------| and I absolutely cannot get an e-mail path that works. So I am posting the reply. If you are not interested in the 332Kit hit 'n' now! Well, try number three (my mailer is having trouble with your address): Sorry I took so long to get back to you but I've been out of town for a while (one of the hazards of the job). In message <9011210448.AA09780@wddami.spoami.com> you write: >Ron, Since I noticed you talking about the 68332 & you're with Motorola, >maybe you could answer a couple of questions. I bought one of the evaluation >kits and have been playing around with it... > >The very first example in the 68332kit exercise manual doesn't produce the >results indicated: > >332BUG>MD 5000;DI<CR> results in: > >00005000 8080 OR.L D0,D0 >etc. This looks like what you'd get after running the memory self tests under the diags directory. The last test there is a TAS test which will set bit 7 of every byte after the previous test has cleared the byte. > >instead of: > >5000 0000FFFF OR.B #$FF,00 >etc. And this is what you'd get if the firmware monitor did what the exercise manual say's it does, namely: "Power-up fills all user memory space with an alternating pattern of 0's and F's (shown below)." However, on the system I just tried (332Bug Version 1.02) it does not do this. It appears to me that the monitor does not initialize ram at all, and you just see whatever state the bits happened to come up in. More than likely, the docs are ahead of the firmware (in rev level). Although, for the "T 1 <cr>" example, I'm not sure if the manual or the firmware is right. But I think it's the firm- ware as the trace bit applies at the conclusion of the instruction, which occurs after the conclusion of the interrupt service routine which prints the string. Thus, "PIT TIMEOUT\r\n" is printed out on the display prior to the register display. > >The rest of the manual's examples are similarly 'slightly' off. > >That set me to wondering if there was a problem with my board/chip, so >I SD'd to 332DIAG and tried the command (as in the DEBUG MONITOR >USERS MANUAL) CPU A and received an "Invalid command" in response. > >Comparing the results of the 'HELP' command with the diagnostic commands >listed in the manual reveals that the CPU tests (A, B, C & D), Loop-on-error >Mode (LE), and Bus Error Test (BERR) are not implemented..., and in fact >give the 'Invalid Command' response when attempted. Me too. In this case I'm sure that the firmware hasn't caught up to the docs. > >One last question. The PD assembler (AS32) and compiler (CC68K) seem to work >fine, but I think we're going to want to see if we can get a primitive DOS >working. That means that everyone is going to have to help write the software >and that can become really painful without a linker. Do you have any ideas >about where we might find a linker? Even something "close" if it's source code There is a product which is a port of the 'standard' (SGS PCC) Unix 'cc' C com- piler, 'as' assembler and 'ld' linker (with most of the standard header files and library calls). The part no. is M68HXBCC300 and it carries a suggested resale of $795. I have no idea what university pricing is. Other than that, you may want to check with Microtek, Introl, Oasys, etc. Or, if your software types are *REAL* good, port GNU cc as a cross compiler 1/2 :-). Regards, -- Ron Widell, Field Applications Eng. |UUCP: {...}mcdchg!motmpl!ron Motorola Semiconductor Products, Inc., |Voice:(612)941-6800 9600 W. 76th St., Suite G | I'm from Silicon Tundra, Eden Prairie, Mn. 55344 -3718 | what could I know?