TF536 + 68000 relocator and ROM board project.

[stephen_usher]

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.

I would agree to a point.

Having tested my most finiky 68000 in the socket I'm using for the TF (and believe me, any timing issues or noise on the bus and that CPU just won't play) and that works fine. Indeed, the TF works completely stably with ST-RAM only, except that it gets exception 11 rather than Bus Error when accessing addresses which don't exist or should generate bus errors. I've had it running Frontier or YAART for hours over night from ST-RAM and it's happy.

As for Phil sending me something duff knowingly, I wouldn't believe that at all, but "things" happen during transport out of any of our control.

As for the H4, as far as I'm aware it doesn't have the ROM decode circuitry or the ability to switch between CPUs (or use 512K ROMS) so I'd still need my board to do this, which goes back to the 68000 socket connectivity again.

[stephen_usher]

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?

Other than my board the only changes are an Exxos 4MB ST-RAM memory upgrade, Goex drive instead of floppy and an Exxos power supply. I've tried to keep the machine as close to stock as possible. The previous TF536 worked, though this was a previous iteration of the board (with *FAR* worse electrical noise etc.).

Reading from memory address 0x5000000 shouldn't go off the TF536 board as that address is being decoded by the Xilinx chip.

I do now have a "Waveshare" knock-off Xilinx "Platform Cable" and I can communicate with the chip, as you could see in the picture in a previous post. I should be able to reprogram it.

[stephen_usher]

During testing... (cleaning contacts) I did get this interesting video artefact, which I just had to share...
https://youtu.be/rk6pjRnEgbo

[stephen_usher]

@agranlund I'm trying to build maprom from source using a (dodgy copy of) Devpac3 I found on the 'Net but I can't for the life of me get it to include the library source files and so it gives a whole load of symbol not found errors (but no errors about not being able to include the files strangely). Any pointers?

I'm just trying to build a copy which only uses the first 32MB for the time being so I can do tests.

Otherwise, as long as I don't try generating a Bus Error the system is currently stable. (Causing a Bus Error by momentarily grounding /BERR causes the same lock-up.)

[agranlund]

Hmmn, the other source files for maprom are in a subfolder and referenced exactly like that from the main source file.
So it should just be a matter of opening maprom.s in devpac3 and hit assemble.

Or is it complaining about some other files?
Maybe double check environment variables in "Options->Environment...".
I have:

Code: Select all

PATH=C:\APPS\DEVPAC3.030\BIN\
INCDIR=C:\APPS\DEVPAC3.030\INCDIR\
CLINKWITH=
LIB=

(obviously replace as suitable for where you installed it etc...)

If you only want fastram detection and registration then you can set OPT_ONLY_RAM to 1 near the top of maprom.s. This will build what is equivalent to fastram.prg.

Setting it to 0 will do the whole thing with the setting up the MMU tables, mapping ROM to fastram and so on.
If you're building it like that, I would toggle OPT_RELO_RAM to 0 as well. I'm going to do that for the version that is on Github when I get a chance - it's really not safe and may be a source of floppy issues and whatnot.

[stephen_usher]

Hmm... That's what I have in my environment. It does Pass 1 OK and then complains about all the SYS_ etc. calls being undefined.

It's probably the dodgy Devpac3 copy.

[stephen_usher]

I think that I *MAY* have found the problem. Some of the files have UNIX line endings or tabs... I'm seeing lots of little bell characters as it's listing during assembly (I turned listing on).

[agranlund]

I think that I *MAY* have found the problem. Some of the files have UNIX line endings or tabs... I'm seeing lots of little bell characters as it's listing during assembly (I turned listing on).

Haha, I was just about to write this. I grabbed the sources off Github and got the same issue.
Opening and resaving each of the .s files in the libs folder using Devpac does the trick.

Sorry about this, guess i need to figure out how to make Github not mess up the files then..

[stephen_usher]

OK, opening each of the files in the editor and saving again fixed it.

The result... With maprom set to 32MB everything works properly... Well, almost. GEMBENCH sometimes crashes during vdi_small_text.

[stephen_usher]

And turning the CPU cache off in Gembench fixes that totally.

So, let's go through this, system is stable if:

• No Bus Errors are generated.
• The CPU caches are turned off. (Both instruction and data, irrespective of their location, ST or TT RAM)

What does that sound like?