TF536 + 68000 relocator and ROM board project.

[agranlund]

I can read and write to addresses in the range 0x1000000 to 0x4fffffc. I'm testing with YAARTTT at the moment.

P.S. Still no errors yet. It's almost as if maprom/fastram/EmuTOS etc. are maybe picking up the wrong memory size or location from somewhere and trying to use non-existant memory. I wonder how they determine this.

@agranlund how does this work?

Hey Stephen!

0x01000000+ is indeed the location of the TF53x RAM (same location as the 32bit fastram on Atari TT)
It does sound like there may be some memory corruption going on.

EmuTOS detects the amount of memory by starting at that location and trying to write/read until it fails. This is the range it's going to be used.
It should say 64MB on the boot screen (there was an issue in an earlier firmware that made it detect 68MB and that caused all kinds of memory related issues).
When you run a TOS that doesn't natively support fastram (Atari TOS 2.06) then maprom.prg/fastram.prg will handle the memory detection and hand over that memory to the OS - among a few other things that needs setting up on systems that has 32bit fastram.

To keep it simple, I would test with just EmuTOS and no additional auto programs.
See if you can execute various programs from fastram in that configuration. Frontier could be a good test etc.
ScummST could actually be a good one to test as well since it's using more memory than Frontier does.
And/or under Atari TOS and fastram.prg.
It would be interesting to hear if that works at all or if it bombs out when executing code from fastram.

[stephen_usher]

The problem is that as soon as a program accesses a memory address above the available alt-RAM the processor gets an exception which causes it to halt. This only need to be a read to cause the system to freeze.

This causes EmuTOS to not be able to boot at all, PAK/3 TOS 3.06 to halt on first boot and continue after a reset.

[exxos]

That should not happen.. RAM is declared for use after it has been detected. Programs can't use ram outside of what is declared.

[stephen_usher]

Indeed, it should only get a Bus Error not exception 11.

I wonder if the /BR pin on the 68030 isn't getting good contact...

[stephen_usher]

OK. I can confirm that addresses which give a bus error on the 68000 are causing the system to lock on the TF536. (e.g. read 0x0)

I guess the only way to test to see if /BERR is being asserted is soldering a wire on the pin on the underneath of the board.

P.S. Monitoring the /BERR pin on the socket shows no /BERR generation when the TF is in there *EVER* but does when a 68000 is in there. The Xilinx chip is generating that for the TF isn't it?

[stephen_usher]

OK. Wired up a wire on the 68030 socket pin underneath and I am seeing /BERR but it's also generating Exception 11 rather than /BERR.

I wish that I hadn't given away the 40MHz 68EC030 now so that I could have checked to see if it was the CPU itself which had become faulty.

Then again, when I try to access 0x5000000 there's no /BERR and the CPU just halts (/HALT goes low and all activity stops).

[stephen_usher]

Well, the Xilinx chip checks out, but do you think it's worth trying to reprogram it just in case it's corrupted its memory?

IMG_2110.jpg

[exxos]

I think you need to try the 536 on a H4 board , at least then all you have to worry about is a bad connection on the 68K socket. Your mixing so much stuff up all at once you need to rule some stuff out first. I doubt @PhilC is going to send your board back with a iffy CPU. He would have tested it for hours before sending it back to you. Its possible the 536 may never work on your particular ST (with or without your relocator). Its why I am stopping upgrades on them as I spend more time debugging the motherboard than working on actual new hardware.

I have exactly the same issue with my PAK030.. Tried multiple CPU's ,multiple motherboards, only ever saw it working once. I sent it to @rubber_jonnie and everything works fine on all his machines. I even tried exactly the same MB revision he had used and I still couldn't get it working no matter what I did. I just get a row of bombs after the fuji appears. I just gave up with it all as I just end up spending 95% of my time debugging stuff which just isn't ever going to work right. That is what your up against trying to build on crappy platform.. and why we developed a new motherboard.

[rubber_jonnie]

Got to agree with @exxos, it's a bit of a lottery as to what will work where with the older boards, especially as time goes by. I've even had boards work with one CPU, then not with another.

I think his suggestion to test on something modern like the H4 is a sensible way to go.

[agranlund]

The problem is that as soon as a program accesses a memory address above the available alt-RAM the processor gets an exception which causes it to halt. This only need to be a read to cause the system to freeze.

This causes EmuTOS to not be able to boot at all, PAK/3 TOS 3.06 to halt on first boot and continue after a reset.

Ok, I'll try with latest EmuTOS here when I get a chance.

EmuTOS, maprom, etc.. detects end-of-memory like this:

a) Try read a byte. If it gets a bus error then this is the end.
b) If no bus error: write a known value, invalidate data cache, read back and compare. If it read a different value back then this is the end.

It starts at 0x01000000 and keeps going until it hits either of the two options above.

TF536 responds to (b) the one without bus error on access to 0x05xxxxxx
It shouldn't hang, the write should not go through, and values read should be 0

I have an old local changelist that makes it respond to (a) with a bus error instead, which is a more "proper" way of doing it. This change was shelved for later since that first mem-detect fix appeared to work in the machines where it was tested.

Was quite a while ago since I ran with that change so I'd have to give it some tests here first but provided it checks out fine you could give that one a try. Do you have the ability to flash the firmware?

(I just re-read a little bit back and it seems your card is quite new though and I assume was working in the machine it was tested on before being sent to you so I'm not sure that would fix anything for you)

Out of interest, and to try and reduce as many factors as possible, what other extra hardware do you have in the machine and if so, does it work without these?