Bus error ranges

[MasterOfGizmo]

For my MIST board i just wrote a little tool that checks the io area from ff0000 to ffffff for allowed read access methods. Of course i also ran this through hatari and a real mega st 4 and the results differ significantly.

This is the output on the physical machine:

Code: Select all

Allowed read access:
from ff8000 to ff800d: any
from ff800e to ff81ff: none
from ff8200 to ff820d: any
from ff820e to ff823f: none
from ff8240 to ff827f: any
from ff8280 to ff8603: none
from ff8604 to ff8607: word
from ff8608 to ff860d: any
from ff860e to ff87ff: none
from ff8800 to ff88ff: any
from ff8900 to ff89ff: none
from ff8a00 to ff8a3f: any
from ff8a40 to fff9ff: none
from fffa00 to fffa3f: odd byte and word
from fffa40 to fffbff: none
from fffc00 to fffe11: any
from fffe12 to ffffff: none

And this is what the same program outputs on hatari:

Code: Select all

Allowed read access:
from ff8000 to ff8001: odd byte and word
from ff8002 to ff81ff: none
from ff8200 to ff8209: odd byte and word
from ff820a to ff820b: any
from ff820c to ff820f: odd byte and word
from ff8210 to ff823f: none
from ff8240 to ff827f: any
from ff8280 to ff8603: none
from ff8604 to ff8607: word
from ff8608 to ff860f: odd byte and word
from ff8610 to ff87ff: none
from ff8800 to ff88ff: any
from ff8900 to fff9ff: none
from fffa00 to fffa3f: odd byte and word
from fffa40 to fffbff: none
from fffc00 to fffdff: any
from fffe00 to ffffff: none

Of course this needs further investigation to check write access and to see where registers are mirrored and how and what those areas return that don't contain any mirrors.

[MasterOfGizmo]

And this is the program written for gcc:

Code: Select all

#include <stdio.h>
#include <osbind.h>

// read byte test. Returns 1 on bus error
char test_rb(void *adr);

asm (
     "_test_rb: move.l  4(sp),a0\n\t"  // address
     "       movem.l d1-d2,-(sp)\n\t"  // save registers
     "       move.l sp, d1\n\t"        // save stack pointer
     "       st.b  d0\n\t"
     "       move.l 8,d2\n\t"
     "       move.l #berr,8\n\t"
     "       move.b (a0),d3\n\t"
     "       clr.b   d0\n\t"
     "berr:  move.l d2,8\n\t"
     "       move.l d1,sp\n\t"
     "       movem.l (sp)+,d1-d2\n\t"
     "       rts\n\t"
     );

// read word test. Returns 1 on bus error
char test_rw(void *adr);

asm (
     "_test_rw: move.l  4(sp),a0\n\t"  // address
     "       movem.l d1-d2,-(sp)\n\t"  // save registers
     "       move.l sp, d1\n\t"        // save stack pointer
     "       st.b  d0\n\t"
     "       move.l 8,d2\n\t"
     "       move.l #berr2,8\n\t"
     "       move.w (a0),d3\n\t"
     "       clr.b   d0\n\t"
     "berr2: move.l d2,8\n\t"
     "       move.l d1,sp\n\t"
     "       movem.l (sp)+,d1-d2\n\t"
     "       rts\n\t"
     );

char *acc[8] = {                // WOE
  "any",                        // 000
  "odd byte and word",          // 001
  "even byte and word",         // 010
  "word",                       // 011
  "byte",                       // 100
  "odd byte",                   // 101
  "even byte",                  // 110
  "none"                        // 111
};

int main(void) {
  long usp = Super(0l);

  FILE *file;
  file = fopen("berrscan.log", "w+");
  if(!file) {
    printf("unable to open log file\n");
    getchar();
    return 1;
  }

  fprintf(file, "Allowed read access:\n");
  // check bus error ranges
  unsigned long start = 0xFF8000;
  unsigned long i, j = start;
  unsigned char last_state = 0;
  for(i=start;i<0x1000000;i+=2) {
    unsigned char berr_e = test_rb((void*)i);
    unsigned char berr_o = test_rb((void*)(i+1));
    unsigned char berr_w = test_rw((void*)i);
    unsigned char state = 
      (berr_e?0x01:0x00)|(berr_o?0x02:0x00)|(berr_w?0x04:0x00);

    if((state != last_state) && (i!=start)) {
      fprintf(file, "from %lx to %lx: %s\n", j, i-1, acc[last_state]);
      j = i;
    }
    last_state = state;
  }
  
  if(j != i)
    fprintf(file, "from %lx to %lx: %s\n", j, i-1, acc[last_state]);
  
  fclose(file);

  Super(usp);

  return 0;
}

[AtariZoll]

Good idea. Surely need to investigate it in details. And with STE, Mega ST (Clock), Mega STE .
For instance there are few games with bug in code for writing palette to shifter - $FF8240-$FF825F . Bug is that there is overshot, so write 64 bytes instead 32, up to $FF827F. And it causes not bus error on ST (what would force them to fix bug), just does nothing. On STE, however it will write in HScroll register, and ruin screen.

[Cyprian]

Hatari team made similar bus error test:
http://hg.tuxfamily.org/mercurialroot/h ... s/buserror

[npomarede]

Hello

if you have a look at Hatari's sources in the tests/buserror directory, some programs were made by Thomas some years ago to do exactly that.
They try to read/write at all addresses, using either byte or word access and will create a text file with a list of memory ranges.

Results are available for ST, STE, TT and Falcon, but it was never tested against a Mega ST, so Hatari might have some differences with real HW.
So, if you have a Mega ST, maybe you could run these programs in 8 or 16 MHz mode and with cache on or off and send us the results to include them in Hatari.

Nicolas

[MasterOfGizmo]

Oh wow. Those test results in the hatari sources differ significantly from my Mega ST.

My Mega ST actually contains a bunch of additional hardware which i thought is mostly disabled during the tests. I'll repeat the tests with everything removed ...

[Maartau]

Good idea. Surely need to investigate it in details. And with STE, Mega ST (Clock), Mega STE .
For instance there are few games with bug in code for writing palette to shifter - $FF8240-$FF825F . Bug is that there is overshot, so write 64 bytes instead 32, up to $FF827F. And it causes not bus error on ST (what would force them to fix bug), just does nothing. On STE, however it will write in HScroll register, and ruin screen.

+1 for the idea ...

[AtariZoll]

I will run tests on my Mega STE. In Mega ST should be only extra real time clock. In Mega STE we have real time clock, CPU clock/cache control, VME ...

[npomarede]

I will run tests on my Mega STE. In Mega ST should be only extra real time clock. In Mega STE we have real time clock, CPU clock/cache control, VME ...

I don't have a Mega ST, but I thought the clock/cache control register at ff8e21 was also present on Mega ST, not only Mega STE ?

[MasterOfGizmo]

I don't have a Mega ST, but I thought the clock/cache control register at ff8e21 was also present on Mega ST, not only Mega STE ?

Nope, the MegaST doesn't have a 16 Mhz cpu nor caches and thus doesn't have that register. The only differences to an ordinary ST are the blitter and the rtc. The blitters address space is obvious in those bus error range checks and the rtc lives in the same area as the acias without a "bus error gap" in between.

The interesting part to me is that those traces in the hatari source for the plain ST and my own traces from my mega st differ that much and e.g. even byte access are not on both machines allowed for areas like the mmu register. Although the chips involved (the glue chip probably) are even pin compatible and can be exchanged between a ST and a Mega ST it seems they have significant differences.

[npomarede]

If you run Hatari's test program on your Mega ST, do you get different results from your own test program ?

[MasterOfGizmo]

I will run tests on my Mega STE

You can find my tool at
http://code.google.com/p/mist-board/sou ... s/berrscan
It writes a file "berrscan.log" to disk and imho has a much easier to understand output than the output of the hatari programs.

[MasterOfGizmo]

If you run Hatari's test program on your Mega ST, do you get different results from your own test program ?

I'll do that. But i doubt i'd get different results. Actually i ran my tool against hatari and got results that match what i see in the output of the hatari tools.

[npomarede]

If you run Hatari's test program on your Mega ST, do you get different results from your own test program ?

I'll do that. But i doubt i'd get different results. Actually i ran my tool against hatari and got results that match what i see in the output of the hatari tools.

Then maybe the Mega ST really had a different MMU with different "rules" (we see the same diffence between 520 STF and 520 STE, for example some address returned random values on STF and 0x00 on STE IIRC)

[MasterOfGizmo]

Here are the results of the Hatari tools from my Mega ST4:

http://code.google.com/p/mist-board/sou ... SERR_B.TXT
http://code.google.com/p/mist-board/sou ... SERR_W.TXT

[AtariZoll]

Here is result with Mega STE (running berrscan.prg):

Access ranges:
from ff8000 to ff800f: any
from ff8010 to ff81ff: no
from ff8200 to ff820f: any
from ff8210 to ff823f: no
from ff8240 to ff827f: any
from ff8280 to ff8603: no
from ff8604 to ff8607: word
from ff8608 to ff860f: any
from ff8610 to ff87ff: no
from ff8800 to ff893f: any
from ff8940 to ff89ff: no
from ff8a00 to ff8a3f: any
from ff8a40 to ff8c7f: no
from ff8c80 to ff8c87: any
from ff8c88 to ff8dff: no
from ff8e00 to ff8e0f: odd byte and word
from ff8e10 to ff8e1f: no
from ff8e20 to ff8e23: any
from ff8e24 to ff8fff: no
from ff9000 to ff9001: any
from ff9002 to ff91ff: no
from ff9200 to ff9201: odd byte and word
from ff9202 to ff9203: any
from ff9204 to ff920f: no
from ff9210 to ff9217: odd byte and word
from ff9218 to ff921f: no
from ff9220 to ff9223: word
from ff9224 to fff9ff: no
from fffa00 to fffa3f: odd byte and word
from fffa40 to fffbff: no
from fffc00 to fffdff: any
from fffe00 to ffffff: no

[npomarede]

Thanks for the results ; could you also run the 2 attached programs ? That's the ones provided with Hatari and it would easier to compare the results in the same format.

By the way, do you have a TT ? From what I saw in TOS 3.06, the extra ram at address 0x01000000 is scanned during boot by adding 0x20000 bytes until the TOS reaches some bus error. So, without any extra TT ram, we get a bus error at address 0x01000000, but with more RAM it will be later.
The TT's PMMU tables from TOS 3.06 shows 2 regions with different settings : 0x01000000-0x7FFFFFFF (cache enabled) and 0x80000000-0xFEFFFFFF (cache disabled). Do we get bus errors in those 2 regions, or only in one of them ?

Nicolas