exxos's Atari, Amiga & retro forum

frank.lukas wrote: 07 Nov 2022 13:36 I also had Fastram problems and errors with YAARTTT, it was due to bad solder joints on the CPLD although everything looked good...

Thanks, good to know, Most likely it is, the pitch on this CPLD is slightly more than I can handle, even with the usb microscope.

foft wrote: 07 Nov 2022 14:38 Yes, on the left. I didn't know about the 16MHz, I thought it was just disabling TT-RAM.

There isn't a 'disable TT-RAM' jumper on any publically-released firmware as it's not normally needed. On the older firmwares trying to access TT-RAM with OPTION2 jumpered would cause a hang because the timings simply didn't work at 16MHz, so that could be what you're remembering.

I can't recall testing it, but I think TT-RAM and OPTION2 should now work, just quite slowly. Likely slower than ST-RAM, TBH, but it may make testing easier.

What surprises me is that it seems to behave the same in the YAARTTT 'M' with option 2 on and off.

That could be indicitive of a physical problem, but it's non-obvious from your data.

For 'M' mode do you know if the MMU needs touching? I'm wondering if I can just do a read/write physical memory in asm with devpac for instance so I have more control over what is being written/read when and can attach the logic analyzer.

MMU not involved unless you've run something to frob it first. Only thing you need to do is disable data cache and you can read and write to TT-RAM at your leisure.

I have a small command line program that read and writes longwords to the specified address that I use for debugging. I've lost the source now, but it's fairly straightforward. Parse argv[1], peek or poke it.

Christian was kind enough to build me a copy of YAARTTT that exits on first error, that means I can probe around the memory and identify issues. This was mostly for firmware development, but would also be handy in this case.

You can emulate the same effect by holding down ALT immediately after running YAARTTTT, it'll either exit on first error or after the first pass then.

Of course, for elementary data line shorts, poking 0x55555555 and then 0xAAAAAA normally yields results. For address line shorts, YAARTT is better as you'll see, for example, 0x1000080 showing at address 0x1000000 after the first pass.

In my FPGA work I never got to implementing boundary scans, though I think that is how its supposed to work on FPGAs and CPLDs.

I tried to read the documentation about boundary scans. It probably makes sense if you've work with FPGAs for years, but it didn't mean much to me. :?

BW

foft wrote: 07 Nov 2022 14:40

frank.lukas wrote: 07 Nov 2022 13:36 I also had Fastram problems and errors with YAARTTT, it was due to bad solder joints on the CPLD although everything looked good...

Thanks, good to know, Most likely it is, the pitch on this CPLD is slightly more than I can handle, even with the usb microscope.

There are a large number of pins dedicated to the SDRAM, so on balance of probabilities it's entirely feasible everything else is running well but a bad joint or bridge is ruining your TT-RAM day.

BW

Here's a really simple 32-bit poker/peeker. It optionally writes to and address given on the command line then reads it.

Turn your datacache off first (it doesn't do it).

BW

Thanks for that tool, I'll give it a try.

I think I've excluded the CPLD. I changed it for another one and have exactly the same behavior. So it doesn't seem to be the ram, the bus drivers, the CPLD or the CPU. :lol:

Really starting to wonder if it's a software issue! Does fastram.prg USE the ram after it detects it? It detects the size then it bombs. This is definitely mapped at 0x10000000? i.e. 1 then 7 zeros as per that post I copied with the instructions?

Trying that mempro32.ttp. I found a FALCONX accessory that can disable the cache. Then I found a shell okasmishl so I can see the output.

The system rom seems to be 0x10000000, at least I recognize that 602e040 from somewhere!

So it seems mapped at 0x1000000, which makes sense for just above the 24 bit range. I can read/write 16-bit only, but not the other 16-bit.

edit: resoldered one of the rams, now I can read/write both 16-bits. Just individually! So I can write 16-bit at 0x1000000 and 16-bit at 0x1000002. I can read 32-bit ok. So I guess I can a 32-bit write signal issue, otherwise its ok... I hope.

edit2: found a poorly soldered pin on the (replaced cpld). Fixed it - and ttram works. :D :D :D :D
One thing to note, mempro32.ttp still doesn't seem to do 32-bit writes properly... I'm wondering if it doesn't work? Or somehow my ttram is registered and working in 16-bit mode?

edit3: another odd thing. sysinfo shows 'total tt-ram 0k', 'free tt-ram: 65207k'.

So now just the flash to try. There are no tools to flash it in system right, so I need to program it first?

foft wrote: 07 Nov 2022 20:59 Trying that mempro32.ttp. I found a FALCONX accessory that can disable the cache. Then I found a shell okasmishl so I can see the output.

The system rom seems to be 0x10000000, at least I recognize that 602e040 from somewhere!

Ah, sorry. Too many 0s! Yes, TTRAM starts at 16M. 0x01000000.

So it seems mapped at 0x1000000, which makes sense for just above the 24 bit range. I can read/write 16-bit only, but not the other 16-bit.

edit: resoldered one of the rams, now I can read/write both 16-bits. Just individually! So I can write 16-bit at 0x1000000 and 16-bit at 0x1000002. I can read 32-bit ok. So I guess I can a 32-bit write signal issue, otherwise its ok... I hope.

edit2: found a poorly soldered pin on the (replaced cpld). Fixed it - and ttram works. :D :D :D :D
One thing to note, mempro32.ttp still doesn't seem to do 32-bit writes properly... I'm wondering if it doesn't work? Or somehow my ttram is registered and working in 16-bit mode?

edit3: another odd thing. sysinfo shows 'total tt-ram 0k', 'free tt-ram: 65207k'.

Hurrah!

And yes, I do seem to recall one of my mempro32 builds had a 16 but write problem. Sorry again. Grabbed a copy off my hard disc and must have been that dodgy one.

That 0 free TTRAM is a sysinfo bug, I think. GEM desktop should show a whole bunch of memory under ‘desktop configuration’ if it’s working and YAARTTT should now work in ‘T’ mode. :)

BW

foft wrote: 07 Nov 2022 21:52 So now just the flash to try. There are no tools to flash it in system right, so I need to program it first?

If you’re on the latest firmware, there is a flash.ttp program in DFB-Tools that should work.

You need to have flash enabled, but DFB1 disabled, then it works by dragging an (up to) 512k image onto its icon.

DFB1 technically can support a 1M flash chip, but at the moment, the top pin is tied out of use and there is no way to write 1M yet. So 512k it is for now.

BW

EDIT: Erm, embarrassingly I don’t appear to have published DFB-Tools yet! Flash.ttp can be found here for now: viewtopic.php?p=84589#p84589

I have 3 built now, since I had the boards, RAM and CPLDs hanging around. This includes putting the CPLD I originally screwed up soldering on a new board. Definitely getting the hang on these, though still plenty of room to improve more.

All of the CPUs and TT RAM seem good.

So far one FPU fully working, though they are all detected. I remember how fussy these are though putting them into the Falcon, perhaps some pins need bending out. So I need to sit down and try that when I get time. The working FPU sometimes fails, sometimes passed on fputest, so it seems marginal. I'm thinking I might install a slower crystal, since I don't really need a super-fast FPU.

As for the ROM, I just tried again with the 10s delay flash tool and AM29F800. It flashes ok and verifies successfully with emutos. Then it doesn't boot, I just get green stripes. Perhaps I used the wrong image: I used ETOS512U.IMG from the archive (md5 sum 9b441de13eb01d5f757eb4198888c566).