DFB1r4 design discussion thread

[Steve]

Sometimes it is wise to double-bodge the bodge.

[Badwolf]

So findings after last night are:-

• Conclusively proved FC[2:0] are needed to be passed through by having one wire fall off which stopped it working :roll:
• Showed timing is defniitely an issue by gating XAS, UDS, LDS through a flipflop on the XCPUCLK line, which allowed the diag cart to boot, albeit run slowly;
• Specified some timing parameters in the verilog and changed a few settings to get the diag cart booting without the extra flip-flop stage. TOS still only half functional at this point. Unable to read Floppy or IDE drives and with a desktop that only updates at bus master changes. IDE and floppy tests pass happily on diag cart;
• Suspected the above symptoms caused by cache not working properly (usually a UDS/LDS issue). Think I've proved this by building an EmuTOS cartridge version with MMU disabled (side effect is cache disabled). This works fine up until I try to run an AES that presumably switches the cache back on;
• Next test will be to solder CIIN to GND, permanently disabling cache and check if TOS boots;
• If so, scoping/probing of the SIZE[1:0], A[0], RW lines which are the sources for the differences in UDS and LDS lines.

So a little bit of progress, but in a very head-scratchy way.

IMG_4740.JPEG.jpg

Progress..?

IMG_4741.JPEG.jpg

Maybe not.

IMG_4742.JPEG.jpg

Aha!

IMG_4743.JPEG.jpg

And, of course *this* works. Doesn't it always? :D


BW

[Badwolf]

CIIN held low, and we're in business.

IMG_4744.jpeg

So: this normally means not requesting the 'other' byte (upper or lower) in a single byte read operation.

I'm going to focus on debugging UDS/LDS, then!

BW

[exxos]

This reminds me of the cache issues I have on the ST TF536.. but as you probably already read before, it only seems to show his head when TOS206 is running from fast-ram. TOS running from ROM is fine, and TOS running from fast ram without cache is also fine. Even compiling TOS with the PAK patches did not help. IIRC the Firmware disables the cache on anything but fast-ram access as well. But the conflict only happens with DMA transfers when the caches are on, and only when TOS is running from fast-ram.

So I will be watching with interest to see if you find any clues to your problem as it may ultimately give some clues as to why I have some issues.

[Badwolf]

This reminds me of the cache issues I have on the ST TF536.. but as you probably already read before, it only seems to show his head when TOS206 is running from fast-ram. TOS running from ROM is fine, and TOS running from fast ram without cache is also fine. Even compiling TOS with the PAK patches did not help. IIRC the Firmware disables the cache on anything but fast-ram access as well. But the conflict only happens with DMA transfers when the caches are on, and only when TOS is running from fast-ram.

So I will be watching with interest to see if you find any clues to your problem as it may ultimately give some clues as to why I have some issues.

Yours sounds very strange indeed. Mine I understand exactly what's happening but not why.

Basically, for the cache to work, whenever you do a read, you should put data on all the lines.

So for an 8 bit bus, it's trivial. You supply one byte at a time. No complications.

For a 16 bit bus you need to return the word at the even address you're reading from, no matter if you only want a byte.

For a 32 bit bus you need to return the longword around the address you're reading from, no matter if you only want a byte, a word or a three-byte triplet.

So, it's simple: for every read operation trigger UDS *and* LDS (for a 16 bit port such as mine) or chip select both high and low word chips on a 32 bit port.

With yours, I can't see how it could be the same problem -- I believe both the upper and lower word chips share the same chip select (DQM[3:0] masks writes). So I'm pretty confident something's amiss elsewhere with your problem.

Screenshot 2021-09-22 at 20.43.13.png

I've proved mine's misbehaving like I suspect: the low CIIN highlighted where there's a LDS but no UDS on a write is a logic error. Shouldn't happen. Need to review my verilog.

Cheers,

BW

[exxos]

hmm.. Could you just not cheat and just drive LDS,UDS from AS30 ? Like you say I think the cache has to do a read on both high and low byte. So if the data is not valid, the cache will just see all 1's..

I don't know if the Falcon chipset will throw a wobbly about it, but it should not matter to the system if it reads a word rather than a byte. At least that is what I do with my ROM decoding, I just do not care about LDS,UDS and only use AS.

[Badwolf]

hmm.. Could you just not cheat and just drive LDS,UDS from AS30 ? Like you say I think the cache has to do a read on both high and low byte. So if the data is not valid, the cache will just see all 1's..

I don't know if the Falcon chipset will throw a wobbly about it, but it should not matter to the system if it reads a word rather than a byte. At least that is what I do with my ROM decoding, I just do not care about LDS,UDS and only use AS.

When it's a read, that's exactly what should happen. It's only writes you have to start using them properly.

Mine's complicated because there is also an 8 bit port on the motherboard (DSP), so there are three logic paths UDS/LDS have to go down (four if you include the 'disabled' mode). I've just balled it up somehow.

BW

[Badwolf]

Fixed!

Took me a while to work it out. Turns out it was a problem with the layout designer not talking to the firmware designer. :chairsmack:

Pin is called XRW... Logic refers to RW throughout. :oops:

Now it's happy, although some slightly funky stats here as the defaults were with EmuTOS.

BW

IMG_4745.jpeg

[exxos]

Pin is called XRW... Logic refers to RW throughout. :oops:

oops :lol: :chairsmack:

[Badwolf]

So what was working as of last night:

• Booting from mobo ROM with external CPU;
• Clock switching accleration of external CPU;
• IDE;
• DMA (Floppy/Blitter).

To do, not necessarily in this order:

• (Physically) Add Flash ROM, enable programming and boot;
• (Physically) Add SDRAM and get a basic configuration working, possibly at 16Mhz for starters;
• Rewrite of SDRAM driver in light of new board capabilties;
• DSP (tested some half-written code, not working. Disabled for now);
• FPU!

I'm tempted to make a start with the SDRAM tonight as it's of the greatest utility.

BW