foft's dfb1 build

[Badwolf]

Last minute late night check - found a couple of pins that were not well soldered on the CPLD.
Plugged it in and... :D

Woo! Congratulations!

BTW does the flash chip now work on the latest jed? I didn't order that since I thought it wasn't ready yet.

I think there's something a bit marginal going on with it, to be honest. I had it working, then it stopped, then it started again. I think last I heard from @sety it wasn't working for him, but he had a 1MB chip rather than my 512kB one, so I may have muffed something up there.

It was working for me when I demo'd it at Cyberlegends on Monday, though.

BW

[foft]

OK, so I should get a 512KB chip if any then, thanks.

BTW I just tried it in my other Falcon, which has a Centurbo 1 3b. Doesn't seem to like that (with the speeder off). Complete guess: I have a low wait state fast rom in there too, so might try fiddling with the settings for that.

[Badwolf]

OK, so I should get a 512KB chip if any then, thanks.

It was built with a 512k chip in mind and all my tests have been with one as that’s what I had.

I decided only at the last minute to throw on a configurable A19 line, so it’s quite possible that isn’t working,

512k would be the safest option, yes.

BTW I just tried it in my other Falcon, which has a Centurbo 1 3b. Doesn't seem to like that (with the speeder off). Complete guess: I have a low wait state fast rom in there too, so might try fiddling with the settings for that.

I find it have to reseat mine a few times on occasion. Old pin headers and recently soldered pin sockets sometimes need a bit of a jiggle to make good connections.

BW

[foft]

I'll double check the seating to be sure, but I think its just the CT1 machine it doesn't like rather than that.

Anyway I've not done much further on this, but since I had to do a Digikey order anyway I popped 2 more copies of the parts in my basket to get it over the threshold! I've just soldered the CPLDs on these - successfully I think.

Guess I should finish the next step on the first before doing the rest of these, get the ram on etc.

[foft]

Finally onto the next step: Fitting the ram. I soldered the 2 ram chips (64MB total) and the 4 KS245 chips.

Its not quite right (yet). I started testing with the original jed and one jumper on to disable flash. fastram.prg did not detect it, well sometimes it said 1MB and crashes.

I upgraded to the latest jed. Now the system only boots past the atari logo with the option 2 jumper on, which I think disables the ram. Once it boots I can remove jumper 2 and it carries on working.

I actually suspect one of these 6 chips is bad, since I pulled them from a non-functional TF1260 board. I was wondering, is there any good software to test a memory range to tell me about bad bits etc to help diagnose?

[foft]

Shamelessly stolen from another build thread:

The RAM, however, should be available, though (it doesn't need activating or anything). SYSINFO in 32 bit mode should show something at 0x10000000 onwards. If it's not all FFs, then there's probably something there.

YAARRTT in 'secret' memory mode should also yield results. Run YAARTTT, press 'M' when asked if you want ST or TT memory checked. Enter 0x10000000 to, say, 0x20000000 and cross your fingers.

I didn't realise sysinfo had a menu! Also trying YAARTTT...

edit: YAARTTT seems to hang with this (it succeeds with 'testing own ram' then does nothing...). Also fastram.prg seems to hang. However fastram is now showing 64MB after rechecking all solders, which is promising.

edit2: YAARTTT runs if I put in a smaller range: e.g. 0x10000000-0x1000008. Though the values read seem bonkers and do not change if I have option2 fitted or not. 0x52aa and 0x77be...
0b101001010101010 (0x52aa)
0b111011110111110 (0x77be)
Doesn't looks like just one of those drivers is iffy, since each handles a group of address lines on the schematic:0-7,8-15,16-23,24-31.
So I guess dodgy ram, just surprised it still shows with option 2 on or off!

edit3: Tried some higher addresses (still within range) and get a larger variety of patterns. Some almost match. Guessing bad ram, going to change those and check again.

edit4: Changed ram, same patterns. Will change bus drivers next!

edit5: Brand new bus drivers, same behaviour. So pretty sure its not ram or bus drivers, so I guess CPU or CPLD...

edit6: CPU does make a difference, but ram does not work in either case. One of the CPU boots with the option2 and the other doesn't! Otherwise identical. So, checking CPLD... Acceleration is fine, but that doesn't mean there isn't a bad connection to the sdram.

edit7: Checked CPLD again, re-flowed just in case. No change. Hmmm!

[foft]

After sleeping on this, I decided to put this board on hold for a while to think about it. I'm going to build the other two boards I have and check the TT RAM works properly on them.

[Badwolf]

Option 2 (is that the farthest to the left)? Locks the CPU to 16MHz in most firmwares. Similarly in most firmwares, that will render TT-RAM unusable.

Please make sure you have the current (1.0) firmware flashed as it removes a lot of the marginals with the TT-RAM at the expense of a few MB/s. Good trade off in my book.

https://github.com/dh219/DFB/releases/d ... B1_1.0.zip

Configuration jumpers for 64MB and no flash should be:-

Code: Select all

: : I :

(ie. all open bar DIS FLASH)

Remove fastram/maprom from your auto folder and then use the YAARTTT 'M' option to test the RAM when nothing's running from it.

I find it unlikely you have bad RAM. it's much more likely there's a bridge somewhere or the firmware you're running was playing too fast and loose with the timings.

Cheers,

BW

[frank.lukas]

I also had Fastram problems and errors with YAARTTT, it was due to bad solder joints on the CPLD although everything looked good...

[foft]

Option 2 (is that the farthest to the left)? Locks the CPU to 16MHz in most firmwares. Similarly in most firmwares, that will render TT-RAM unusable.

Yes, on the left. I didn't know about the 16MHz, I thought it was just disabling TT-RAM.

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

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.

Please make sure you have the current (1.0) firmware flashed as it removes a lot of the marginals with the TT-RAM at the expense of a few MB/s. Good trade off in my book.

https://github.com/dh219/DFB/releases/d ... B1_1.0.zip

I'm on this one now, thanks.

I find it unlikely you have bad RAM. it's much more likely there's a bridge somewhere or the firmware you're running was playing too fast and loose with the timings.

Yeah I'm still wondering if there is a solder bridge somewhere that I can't see. Partly why I think its best to just build the next one, see if it works in my falcon then come back to this one afresh.

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.