exxos blog - random goings on

[exxos]

So this test OPTION2 is removed so we are running at full speed (40mhz). @Badwolf

Oddly now the keyboard is misbehaving again.. It wasn't with OPTION2 enabled. Now it is correctly reporting bit 11...

IMG_0244.JPG

I don't really follow what is going on but I think there are multiple problems happening all the same time :(

I think possibly there could be some sort of bus trashing going on somewhere with the DBF1 :shrug:

[Badwolf]

I was just wondering which CPU was actually reading this data.

The OPTION2 jumper is set.. and the jumper I think you sent it with... Did not know you could disable it... I do now.. :lol:

Righto. So that's the big chip running at 16MHz. Quick guide:-

Default config of jumpers is:-

: : | :

From right to left, that's:

• DISABLE FAST (aka OPTION2). Doesn't allow the clock to switch up to 50MHz mode.
• 128MB. Default is to assume 64MB. Jumpering this tells the system you've fitted the bigger chips. Don't use this. Bad things will happen. :lol:
• DISABLE FLASH. Does what it says on the tin. I didn't have a flash chip when I made your board, so this is probably best left closed.
• MASTER DISABLE. DFB1 is idle, onboard CPU is doing its thing.

So fitting the main DISABLE jumper would provide all the same electrical load as running DFB1 (well, not the power draw), but without it doing any of the computation.

viewtopic.php?p=93781#p93781

Yeah, the little baby jesus hates you.

BW

[exxos]

@Badwolf

With the booster disabled with the jumper, it is doing the same as in this post..

viewtopic.php?p=93550#p93550


So I think bus loading can be likely ruled out at least now.

But it also begs the question why when the booster is enabled I get all sorts of weird results back from the memory test ?

[exxos]

Had a thought to take the FPU out and try the RAM tests again.. Without it started correctly reporting bit 11.. Great I thought.. Rebooted.. Still the same...

So put the FPU back in.. and it is still reporting bit 11 failure (as expected).

I will do more tests after tea... I was really just wondering if the FPU itself was corrupting the bus for some odd reason..

[Badwolf]

Had a thought to take the FPU out and try the RAM tests again.. Without it started correctly reporting bit 11.. Great I thought.. Rebooted.. Still the same...

So put the FPU back in.. and it is still reporting bit 11 failure (as expected).

I will do more tests after tea... I was really just wondering if the FPU itself was corrupting the bus for some odd reason..

But only with that failing board in place? Sounds unlikely.

Do you know which chip is odd bit 11 now?

I'm thinking about swapping it with another chip on the same board and see if your errors move with it.

BW

[Badwolf]

@Badwolf
If you have chances some point can you tried taking samples of the power rail starting up.. As I see this...

I couldn't get a trigger at 200ns, but triggering at 1us and zooming in I see things like this:-

NewFile0.png

NewFile1.png

NewFile2.png

So yes, very bouncy start up.

BW

[mikro]

viewtopic.php?p=93761#p93761

The Falcon's RAM is 32 bit, accessed by VIDEL as such and is I believe interleaved cleverly to increase access speed (@mikro may be able to enlighten us her).

Sorry, I haven't followed the thread but this is what I know about Videl and ST RAM:

In practice, the interleaving is most visible on the ST RAM card setup: it is organized in two 16-bit memory banks of 2 MB each. Many interpret this as the effect of the 16-bit data bus but I don't think this is correct: it actually doesn't matter how the banks are organised if using a 16-bit data bus, see below.

The advantage of those two memory banks is, yes you've guessed it, the interleaving. So even word access ($0000, $0004, $0008, ...) is from bank 0 and odd word access ($0002, $0006, $000A, ...) is from bank 1. So a sequential read leads to accessing banks 0, 1, 0, 1, ...

The reason, as I understood it, is a so-called precharge time for the DRAM which happens after each time you access a bank.

For example a 60ns DRAM can have 40ns precharge time and together with other stuff one memory access can take as much as 110ns (60 + 40 + "the rest").

ST-RAM in Falcon is a 80ns DRAM and the full cycle takes as much as 150ns.

However if one 16-bit bus access takes four cycles in Falcon, for 16 MHz we have 4 * (1/16 000 000) = 4 * 62.5ns = 250ns. Even on an accelerated (25 MHz) data bus one access takes 160ns. So no problem here, we have plenty of time for one DRAM cycle.

This isn't a problem even for a move.l because one word access takes 150ns and we can do another one only after 250ns. So whatever you (as a programmer) do, it shouldn't matter how do you access ST-RAM, you can't do it "wrong". However, what about the Videl?

The Videl reads data from ST-RAM as 32-bit longs. It does this via a burst of 17 long reads (CAS cycles; the first one needs two additional RAS cycles for an init). And here it finally starts to matter: it the reads weren't interleaved, we'd get stalls all the time.

I don't know how quickly Videl reads those longs but I'd bet that it is faster than 250ns (naively we can deduct this from its clock: 25.175 MHz / 32 MHz, i.e. much faster than the CPU).

EDIT: actually we do know how quickly Videl reads those longs. :-) As mentioned, it uses a burst read of 17 longs which stalls the bus for 19 (16 MHz) clock cycles. Therefore if 17 longs take 19 * 62.5ns = 1187.5ns, 1 long takes 1187.5ns / 17 = ~70ns. So you see, we greatly benefit from the fact that this long is read from two banks at once (and then Videl waits for 80ns for the precharge) instead of reading a 16-bit word ... waiting 80ns ... reading another 16-bit word ... waiting 80ns ... etc. Basically doubling our transfer rate.

[Badwolf]

Sorry, I haven't followed the thread but this is what I know about Videl and ST RAM:

Thanks @mikro, so it makes sense that a failing RAM chip will show bit errors at only odd or even word addresses.

Cheers,

BW.

[exxos]

Just been working on stock items just and noticed this seems to be a shortage of SIMM sockets now :roll: In fact nowhere seems to sell them any more full stop :( So been reaching out and seeing who I can pester into obtaining some. But in all likelihood I assume the manufacturers have simply stopped making them now. So other than some last-minute panic buying if possible, it looks like it could be the end of simm sockets now :(

Have noticed similar buying general things like CPUs and such. Seems to be scraping the bottom of the barrel parts these days. More and more parts seem to be faulty and end up binned. I have been ploughing all available funds into buying as much stock as possible but I don't have unlimited funds to buy multitude of different items unfortunately.

[exxos]

:sigh:

IMG_0295.JPG

IMG_0296.JPG