ST536 STE EDITION

[exxos]

Been working through tests with GPT5..

Basically doesn't like long word copy it seems.. I would have assumed it should work but something is tripping up...

GPT5 said.

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 don't really understand why CDIS open would work and CDIS closed would fail.. Its beyond my pay grade all this stuff

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.

[exxos]

GPT5 coding the new routines

Just testing a simulated copy fail in this test program

IMG_3978.JPG (47.58 KiB) Viewed 254 times

Copying it over from devpac format to whatever format TOS is in is a PITA though !


STOS has been invaluable once again in all this testing

[stephen_usher]

How about doing a 32 bit read from ROM, write to RAM, read and verify from RAM cycle for each 32 bit value?

Something like:

Code: Select all

	move.l		(a0),d0
	move.l		d0,(a1)
	tst.l		(a1),d0
	bne		error_handler

[exxos]

How about doing a 32 bit read from ROM, write to RAM, read and verify from RAM cycle for each 32 bit value?

I think something similar was done earlier in other tests..

Code: Select all

; Atari ST Assembly Program (Devpac compatible)
; TT-RAM test + TOS ROM copy + verification
; Compatible with STE/TT, Devpac W+ warnings

    OPT W+
    SECTION TEXT

start:
    ; --- Test RAM write/read ---
    lea ram_test_msg(pc),a0
    bsr print_string

    ; Test data
    move.l #$4F10002,a0       ; TT-RAM test address
    move.l #$0000000A,d0
    move.l d0,(a0)            ; Write
    move.l (a0),d1            ; Read
    cmp.l d0,d1
    bne ram_test_fail

    lea ram_test_ok_msg(pc),a0
    bsr print_string

    ; --- Setup copy parameters ---
    move.l #$E00000,source_addr ; TOS ROM start
    move.l #$4F00000,dest_addr  ; TT-RAM start
    move.l #$100000,total_bytes ; 1MB TOS ROM

    ; --- 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                 ; Convert to longwords
copy_loop:
    move.l (a0)+,(a1)+
    subq.l #1,d0
    bne copy_loop

    lea copy_done_msg(pc),a0
    bsr print_string

    ; --- Verify copy ---
    move.l #$E00000,a0
    move.l #$4F00000,a1
    move.l total_bytes,d0
    lsr.l #2,d0
verify_loop:
    move.l (a0)+,d1
    move.l (a1)+,d2
    cmp.l d1,d2
    bne verify_fail
    subq.l #1,d0
    bne verify_loop

verify_ok:
    lea verify_ok_msg(pc),a0
    bsr print_string
    bra wait_key

verify_fail:
    lea verify_fail_msg(pc),a0
    bsr print_string
    ; Report failing address
    move.l #$4F00000,a2
    move.l total_bytes,d3
    lsr.l #2,d3
    sub.l d0,d3
    lsl.l #2,d3
    add.l d3,a2
    lea addr_msg(pc),a0
    bsr print_string
    move.l a2,d0
    bsr print_hex_long
    bra wait_key

ram_test_fail:
    lea ram_fail_msg(pc),a0
    bsr print_string
    bra wait_key

wait_key:
    lea keypress_msg(pc),a0
    bsr print_string
    move.w #1,-(sp)
    trap #1
    addq.l #2,sp

    clr.w -(sp)
    trap #1

; --- Subroutines ---

; Print null-terminated string at A0
print_string:
    move.l a0,-(sp)
    move.w #9,-(sp)
    trap #1
    addq.l #6,sp
    rts

; Print longword in D0 as 8-digit hex
print_hex_long:
    move.l d0,-(sp)
    lea hex_buffer(pc),a0
    move.l d0,d1
    moveq #7,d2
.hex_loop:
    rol.l #4,d1
    move.b d1,d0
    and.b #$0F,d0
    cmp.b #10,d0
    blt.s .digit
    add.b #'A'-10,d0
    bra.s .store
.digit:
    add.b #'0',d0
.store:
    move.b d0,(a0)+
    dbra d2,.hex_loop
    move.b #0,(a0)
    lea hex_buffer(pc),a0
    bsr print_string
    move.l (sp)+,d0
    rts

    SECTION DATA
ram_test_msg:     dc.b "TT-RAM write/read test...",13,10,0
ram_test_ok_msg:  dc.b "RAM test OK",13,10,0
ram_fail_msg:     dc.b "RAM test FAILED",13,10,0
copy_done_msg:    dc.b "Copy complete!",13,10,0
verify_ok_msg:    dc.b "Verification passed!",13,10,0
verify_fail_msg:  dc.b "Verification failed!",13,10,0
addr_msg:         dc.b "Failing address: $",0
keypress_msg:     dc.b "Press any key to exit...",13,10,0
hex_buffer:       ds.b 9              ; 8 hex digits + null

    SECTION BSS
source_addr:      ds.l 1
dest_addr:        ds.l 1
total_bytes:      ds.l 1

END

Long-word copy is used here to maximize speed and match 32-bit TT-RAM.

Word/byte alignment issues are avoided — addresses start at multiples of 4.

Devpac compatibility ensured (END without argument).

RAM test is included to ensure TT-RAM writes work before the copy.

Why the previous attempts failed

Byte vs word vs long-word alignment

The 68000 series CPUs can read/write in byte, word (16-bit), or long-word (32-bit) accesses.

Your SDRAM / TT-RAM controller might have alignment restrictions: misaligned accesses or too-large accesses can trigger data corruption.

In your earlier “long word copy 1 MB” code, $4F10002 was not 32-bit aligned, causing the CPU to write/read in a misaligned way — the TT-RAM returned FFFF or wrong bytes.

Address offsets

You were copying starting at $4F00000, but reads/writes for long words must be aligned on 4-byte boundaries.

Any offset inside the block can produce FFFF or garbage if the controller doesn’t handle misaligned accesses properly.

Control logic / copy_done / TOSCE / bus enable

The TT-RAM controller you’re using isolates ROM during the copy (copy_done), and AS30/BUSEN lines determine when the CPU can access memory.

Using smaller chunks (word copy) avoids timing glitches that occur when reading/writing large long-word blocks.

Word copy works reliably for small blocks

Your 256 KB word copy works because each write is only 16 bits, aligning naturally on the TT-RAM bus and avoiding any long-word glitches.

Long-word copy works if all addresses are aligned

In the corrected program I gave you, the start addresses are aligned on 32-bit boundaries and the loop uses move.l correctly.

The TT-RAM controller handles aligned 32-bit writes correctly, so the copy works and verification passes.

So it could have been some weird alignment issues somewhere as once GPT corrected the alignment stuff it seemed to start working fine afterwards.

[stephen_usher]

If you're always reading from long-word aligned addresses there should be zero issues. You weren't reading long words and accidentally only incrementing the address by two were you?

[exxos]

If you're always reading from long-word aligned addresses there should be zero issues. You weren't reading long words and accidentally only incrementing the address by two were you?

But it was all working fine until CDIS was jumpered..

[stephen_usher]

That's because the CPU was probably burst filling the cache for you and also doing write-back transfers to RAM.

Something in your code was doing something screwy.

[exxos]

That's because the CPU was probably burst filling the cache for you and also doing write-back transfers to RAM.

Something in your code was doing something screwy.

Groks code I got GPT to rewrite the whole thing now Oddly it didn't seem to understand 68k assembly much last time, but seems to more now..

It's pretty bizarre by itself.. Grok seems to have a good go at doing programming but seems to make silly mistakes which it never sees..

GPT sees the mistakes, fixes them, but then it starts adding invalid characters into the code, and if you keep making changes, it seems to "forget" easily and then half your code vanishes that its fixing.

But GPT5 seems better currently. If I run it the code and tell it why doesn't work it generally finds a problem and fixes it.. Slightly annoying as you didn't check its work beforehand though sometimes it will also randomly put spaces in the code which the compiler doesn't like...

So Grok seems more consistent in what it does, But I don't think it can program as good as GPT..

Anyway the PRG is running on badwolfs STE, its running GB6 with "Fast ROM"... Made the changes to the TOS startup, it compiles, but to tired to start messing around programming and erasing ROMs now.. But a lot going on over the next few days of won't have time to do anything else much now anyway..

[stephen_usher]

All AI output are digital fever dreams.

[exxos]

20251021_214308.jpg (92.31 KiB) Viewed 211 times

Been running all day pretty much..


Oddly when CDIS is closed, TTram is like 50% faster