Basically doesn't like long word copy it seems.. I would have assumed it should work but something is tripping up...
GPT5 said.
I don't really understand why CDIS open would work and CDIS closed would fail.. Its beyond my pay grade all this stuff :)We need to use word accesses (move.w) because the ROM is 16-bit wide and the CPU is 32-bit. Using longword accesses (move.l) without swapping can cause the byte order to get messed up on the 68030, especially with CDIS enabled. That explains why your earlier longword copy failed.
I will keep doing tests but I need to fix the ROM copy in my build of TOS anyway..
The longer explanation is...
I've been debugging TOS ROM copying to TT-RAM on a TF536/STE setup, and I finally got it working. Here’s an explanation of why my initial program failed and how it relates to CDIS, word vs longword copies, and the 68030 CPU.
1) **Word vs Longword Accesses**
The 27C4096 ROM is 256K x 16-bit. On the 68030 (and STE memory bus), word accesses (`move.w`) are naturally aligned to 16-bit boundaries, and the CPU reads/writes the correct 16-bit values.
Longword accesses (`move.l`) read/write 32 bits at a time. On a 16-bit ROM, this requires the CPU to perform **two 16-bit accesses internally**, and the order of these accesses can depend on **bus configuration, CPU byte-swapping, and CDIS line**. If the ROM or bus doesn’t handle the second half correctly, you can get **garbled data**, which was exactly what caused the screen corruption and verification failures.
2) **CDIS (CPU Data Inhibit Select)**
CDIS affects **how the 68030 handles 16-bit memory on a 32-bit data bus**.
- If **CDIS is not jumpered**, the CPU will internally swap bytes when doing longword accesses on a 16-bit ROM, potentially hiding issues.
- If **CDIS is jumpered (closed)**, longword accesses are **strict**, and the CPU expects the memory to provide all 32 bits in order. On a 16-bit ROM, this causes incorrect data reads/writes, so longword copy fails.
3) **Why the Original Program Worked Sometimes**
When copying in **words**, the CPU accesses 16 bits at a time, fully aligned to the ROM’s width. This avoids the byte-order issue entirely, and works regardless of CDIS. That’s why copying 256 KB in words worked perfectly.
4) **Why Longword Copy Fails**
Copying the full ROM with `move.l` triggers **unaligned or misordered accesses** on the 16-bit ROM. Depending on CDIS, some of the 32-bit reads/writes are swapped or partially invalid, causing the last few bytes to be wrong and sometimes screen corruption.
**Conclusion:**
- On a 16-bit ROM with a 68030, always use **word accesses (`move.w`)** for copying/verification.
- Longword copies are only safe if the memory bus and ROM support **32-bit aligned, ordered accesses**, or if CDIS is configured to allow byte-swapping.
- CDIS changes the CPU’s behavior on longword accesses, which explains why the original program failed with CDIS closed and sometimes worked when CDIS was open.
Using this understanding, I rewrote the copy program to use **word-by-word copying**, and it now reliably copies the full 512 KB ROM to TT-RAM and verifies correctly in one pass.
