This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>(ie NO_VBR). Does anyone >actually have RTEMS running on a 68000 based processor? Trying hard. Progress slow. :-) > 1: I cannot explain why the vector number is multiplied by 6 > and then 10 subtracted to get the address to store the ISR > service routine. When dealing with 68000 boards with no vector base register there is a problem with setting vectors because it is common to put ROM at 0x0000 address where vectors reside thus making it impossible to change them. Most monitor programs in ROM and similar use the following technique : They put vectors in ROM, the vectors points to an address in RAM that contains JMP or any other jump instruction. Something like : /* this is at address 0x0000 and should be placed in ROM */ vector_table: dc.l _v_RESET_ssp dc.l _v_RESET_start dc.l _v_vector_2 dc.l _v_vector_3 /* this "vector table" is somewhere in RAM */ alternate_vector_table: _v_vector_2 : JMP _v_user_vector_2 _v_vector_3 : JMP _v_user_vector_3 As you can see you have an alternative table ob jumps somewhere in RAM. That might explain the 6 byte vector - it might contain instruction JMP opcode and address. Your setvec fn should take that into consideration. Hope I haven't misguided you. Lp, Tomaz