> and it now reliably copies the full 512 KB ROM to TT-RAM and verifies correctly in one pass.
Scanning between the lines, something seems off here. The GPT answer/fix only makes sense if there some kind of unresolved problem - or if it fixed the code without telling you what was actually wrong with it.
The 68000 can read or write 16bit words or 32bit longwords at 2 or 4 byte alignment (but not 1-byte alignment - causes address error). The 68020 and above can manage 1-byte alignment - but it is handled differently. The external reads/writes are always aligned with the 'byte fix' being internal masking.
Anyway software will happily use 2-byte alignment for 32bit reads/writes, without caring what the memory address is - whether it is STRam or somewhere higher up. There are no 32bit address alignment restrictions needing to be followed for any of it. Sure it helps with performance to keep things aligned on the later 32bit 680x0 chips but it is not a functional restriction.
So if the ROM-RAM copy is not working on word alignment but is working on long alignment the problem has to be one of these:
1) the copying code was wrong and wasn't copying all the data. e.g. maybe not copying the final word. this is an easy mistake when rounding-down sizes of word or longword sized copy operations. if copying exactly 1MB though, this *is* a long-aligned size so rounding down isn't an issue. if trying to copy 1MB minus 1 word though, that would be a size-rounding fault (you would lose 2 words not the expected 1, when copying longs).
Code: Select all
; --- Copy ROM to TT-RAM (long-word copy) ---
move.l source_addr,a0
move.l dest_addr,a1
move.l total_bytes,d0
lsr.l #2,d0 ; <------ potential rounding-down fault!
copy_loop:
move.l (a0)+,(a1)+
subq.l #1,d0
bne copy_loopThe fix either to to round-up the divide so it copies *at least* the last longword (which may be 1 more word than intended but not missing any)
addq.l #(4-1),d0 ; (s+3)/4
lsr.l #2,d0
...or safer/better is to operate as words only
...or to operate as longs and catch the missing word, which has the same result but more efficient.....
Code: Select all
move.l source_addr,a0
move.l dest_addr,a1
move.l total_bytes,d0
move.w d0,d1 ; <---- catch the missing (odd word or byte) at the end
lsr.l #2,d0 ; <---- now safe to round down the size without missing a word
copy_loop:
move.l (a0)+,(a1)+
subq.l #1,d0
bne copy_loop
check_final_word:
btst #1,d1 ; <---- detect the odd wordsize
beq.s no_odd_word
copy_odd_word:
move.w (a0)+,(a1)+ ; <---- copy the final word
no_odd_word:
2) the ROM image can't run at an unaligned address (this is likely - I'm not sure why the ROM would need to be placed at a 2-byte address? when the ROM code was compiled it might have been statically compiled to a specific ORG which likely would have been aligned so the code may break if unaligned for reasons unrelated to your code). however if the failure is a read-back verify failure not a runtime failure this isn't the main issue.
3) the TTRam controller is not functioning correctly and not allowing a 32bit write (or read) to occur at word aligned addresses. if this is true, lots of software will break when running from or accessing TTRam because none of it will be expecting that restriction. GPT hints at this but does not tell you this would be a serious fault and will stop most software from working! But this should be easy to test.
Just copy a (long-aligned-size!) pattern of known words from an even-word ST source to an odd-word TT destination address using move.l, then verify back the destination using cmp.w as words so the verify is immune. If it doesn't match, you've got problems. Software will not be able to work with it.
Verified that the error handling and printout were fully functional.
