exxos's Atari, Amiga & retro forum

derkom wrote: 15 Oct 2020 18:50 Really? Both times I've programmed mine, it's been out of the computer, powered by the Raspberry Pi via the JTAG connector. Should I not be doing that? If that's the wrong way to be doing this, why does the JTAG connector even have a power pin?

So the Xilinx (et al) JTAG adaptors can sense the voltage level of the board in the case when the JTAG adaptor is multi voltage.

You are setting the voltage on the output side of the voltage regulator but not the input... dont do that.

terriblefire wrote: 15 Oct 2020 19:39 You are setting the voltage on the output side of the voltage regulator but not the input... dont do that.

Gotcha. Never realised that could be a problem. I will power it off the bus for future programmings.

OK, looking at the signals with an oscilloscope, the ground rail on the TF536 itself is even more noisy than the input. I'm amazed that it's working at all given the number of times I've seen it spike to 3V on GND! I've got the noise on the input ground rail down to <1V so this is being generated on the TF itself.

I can see attempts to communicate on the JTAG but I'm guessing that it's just too noisy.

The 3V spike only appears with the TF536 actually running and not even if it's switched on but inactive. (i.e. on my board I've switched to the 68000 in the other socket.) It's happening at a frequency which is almost precisely 1KHz (1.035KHz) which seems to be the same frequency of switching as /IPL2 but precisely 2us later than when /IPL2 goes low. There's a 2V drop in +5V at the same time.

It seems that the firmware for the TF536 is allowing of caching of addresses not within the Alt-RAM address space:

• TOS 2.06(UK)
• Boot with "Cache" turned on and no Alt-RAM enabled. (HDDriver 10.10)
• Not all drives show up on desktop. Opening sub-folders often gives an empty folder
• Turn off cache, change resolution (to refresh the desktop) All drives reappear.
• Folders show contents as normal.
• Turn cache back on and sub-folder often show empty again.

I thought that the firmware should only be caching Alt-RAM and nothing else, but this is obviously not the case.

You cannot use the cache with stock 206 there is a bug in the OS.. it was talked about a few times already.. @agranlund I think did some patches to it to fix it but don't think it has been tested / released yet.. For now you have to disable the cache in the desktop menu.. or it might be easier just to run EMUTOS for now.

exxos wrote: 23 Nov 2020 15:54 You cannot use the cache with stock 206 there is a bug in the OS.. it was talked about a few times already.. @agranlund I think did some patches to it to fix it but don't think it has been tested / released yet.. For now you have to disable the cache in the desktop menu.. or it might be easier just to run EMUTOS for now.

From what's been posted previously I was under the impression that the firmware asserted the CDIS line for all addresses outside of the Alt-RAM address range, turning caching off for those addresses. This is important for ST-RAM, of course, as the DMA can change the data in RAM without the CPU's knowledge.

stephen_usher wrote: 23 Nov 2020 16:08 From what's been posted previously I was under the impression that the firmware asserted the CDIS line for all addresses outside of the Alt-RAM address range, turning caching off for those addresses. This is important for ST-RAM, of course, as the DMA can change the data in RAM without the CPU's knowledge.

I can only find it mentioned in passing here https://www.exxosforum.co.uk/forum/viewt ... 276#p50284 I don't think it was ever done @agranlund ? IIRC @agranlund went to patch TOS206 to fix it properly, but I don't remember where this was discussed as we talk about stuff a lot in the private area so people dont get confused whats going on. Even so, all the Atari firmware and patches are likely all still WIP at this point. We are working on some TF536 stuff in the background, but I can't disclose what all this is currently.

I really do suggest you just start out with EMUTOS before getting more complicated with getting TOS206 working.. Trying to bring up hardware and software at the same time just isn't a good idea.

As long as you turn the cache off 2.06 is fine.

I can't currently boot into EmuTOS until I fix the Alt-RAM issue.

stephen_usher wrote: 23 Nov 2020 16:08 From what's been posted previously I was under the impression that the firmware asserted the CDIS line for all addresses outside of the Alt-RAM address range, turning caching off for those addresses. This is important for ST-RAM, of course, as the DMA can change the data in RAM without the CPU's knowledge.

TOS3.06 (and of course EmuTOS) flushes the 68030 data cache after disk operations, so they are fine, this does not happen on TOS2.06.

I wont pretend to be an expert on the area so please excuse me if something here is wrong, but asserting CIIN isn't going to completely disable the cache. It's to prevent data from being put into the cache on read operations.
If you need to prevent writes from creating cache-entries then that is a software issue using the WA flag and/or MMU.

And then you have this one:

Enabling write-allocation has an undesired side effect, though: as the NOT CIIN signal is ignored during write-accesses, a longword-aligned write of a longword will create a valid cache entry that may cause a cache hit during subsequent read accesses, regardless of the caching mode for that memory location as indicated by the external hardware. This behaviour can be corrected only by using the MMU to specify caching modes on a page-by-page basis

There are plenty to read on this subject on Amiga forums :)

If something, somehow, ends up getting a cache entry then subsequent reads will grab it from the cache no matter what, and that may be goodbye if your software is oblivious to it like 206 is. For example:
You allocate a buffer, then you clear it - tada! now you may have created cache entries, DMA writes to the buffer, CPU doesn't know about the DMA write and you've put it in the cache due to that clear so that's what you get back.

Perhaps maprom/fastram may be able to help TOS206 by setting Write-Allocate to off and hope no-one enables it.. if that's ok on TOS, apparently WA must be enabled on AmigaOS for some reason and I can't be bothered trying to understand why :) I have no idea what it defaults to either but it would make sense that default is enabled?
At the same time I should make sure the MMU is being set up properly to tag relevant pages while at it.
I should revisit these programs at some point, I didn't bother too much since it was easy enough to disable caching in the TOS options plus I don't use a floppy or ACSI device in my machine.

For now, I'd recommend disabling the cache in the TOS2.06 options menu, especially if you're using some kind of DMA device or the blitter.

Edit: also 68030 datasheet for some "fun" nighttime reading about its cache: https://www.nxp.com/docs/en/reference-m ... 0UM-P1.pdf

Sidenote: The Atari / TOS also requires "write allocate" to be active on the 68030 or it will crash sooner or later. I could go into a (long) explanation why this happens, but for now I'm just going to quote the UM: "WRITE ALLOCATE [...] The supervisor should set this bit when it shares data with the user task". I.e., it's required when user and supervisor mode access the same memory locations, which obviously happens during TOS calls.

Either use a cache-aware OS or completely disable the cache.