gnupic: Re: [gnupic] gpdasm 0.13.6 alpha question
Subject:
Re: [gnupic] gpdasm 0.13.6 alpha question
From:
Peter Keller ####@####.####
Date:
17 Mar 2009 07:05:55 -0000
Message-Id: <20090317070453.GA3770@cs.wisc.edu>
On Wed, Mar 11, 2009 at 09:41:10PM +0000, Robert Pearce wrote:
> Given what you've posted, it appears gpdasm may be misinterpreting the
> "type 04" blocks - the lines of the HEX file that begin ":02000004"
So, I inspected the readhex() function and followed what it was doing during
the gpdasm, and eventually found that it led to here:
MemBlock * i_memory_new(MemBlock *m, MemBlock *mbp, unsigned int base_address)
{
unsigned int base;
/* added by psilord */
printf("i_memory_new raw base_address = 0x%x\n", base_address);
base = (base_address >> I_MEM_BITS) & 0xFFFF;
/* added by psilord */
printf("i_memory_new cooked base_address = 0x%x\n", base);
mbp->memory = (unsigned int *)calloc(MAX_I_MEM, sizeof(unsigned int));
mbp->base = base;
do {
if((m->next == NULL) || (m->next->base > base)) {
/* Insert after this block */
mbp->next = m->next;
m->next = mbp;
return mbp;
}
m = m->next;
} while(m);
assert(0);
return NULL;
}
Here is some sample output:
i_memory_new raw base_address = 0x30000000
i_memory_new cooked base_address = 0x6000
i_memory_new raw base_address = 0xf0000000
i_memory_new cooked base_address = 0xe000
So, from what I can gather, when readhex is supplying to i_memory_put the
address to which it wants to write, the base address gets miscomputed in the
above function when it is a "new" address in a different memblock.
Given the portion of code in gpdasm.c:dasm() which shifts left the
base address of the mem block by one bit of the processor is of class
PROC_CLASS_16E, maybe when i_memory_new is called and the state.class
is PROC_CLASS_16E, it should shift right the base address by one more
bit so it doesn't get truncated by the 0xFFFF? I hacked a test of that by
hand hand it seemed to do the right thing. However, the state variable
doesn't seem to be used in gpmemory.c, and I fear if I add that dependancy
in there I'm doing something wrong since it wasn't already in there. ;)
Any ideas?
Thanks.
-pete
