Stuart's DFB1 Build

[Badwolf]

Yours is a new born baby! Perhaps collectively we can put a tiny bit of pressure on DML to release the sources?

I'm not sure why it doesn't work with the CT2 version, TBH.

BM looks a bit like it's run its course as a project, but if we can prove it's not something fundamentally my card's fault, there'd be no harm in asking, I suppose.

BW

[Steve]

@Badwolf @sety I wouldn't nessesarily say that Badmood is accelerator specific... the builds he produces are just with certain constraints added/removed, like relaxed DSP timings for overclocked motherboards. I know that various builds will all work on a ct60, even the stock version afaik.

Code: Select all

bm030.ttp		Fastest version for base spec (14MB) Falcon030 @ 16MHz
bm030s.ttp		As bm030, with stereo/directional audio (costs a little bit more to mix with panning)

bm030a.ttp		As bm030s, with more strict DSP sync for less powerful CPU accelerators
bmhat.ttp		As bm030s, made PMMU-safe for Hatari emulator variations

bmct2.ttp		CT2/030-optimized build supporting TT-Ram + high quality stereo audio
bmct2u.ttp		As bmct2, without 12.5Hz tickcap (35Hz tick like PC version)
bmct2du.ttp		As bmct2u, assuming 50MHz+ DSP with fast & loose synchronization

bmct6.ttp		CT6x/060-optimized build supporting TT-Ram + high quality stereo audio
bmct6u.ttp		As bmct6, without 12.5Hz tickcap (35Hz tick like PC version)
bmct6du.ttp		As bmct6u, assuming 50MHz+ DSP with fast & loose synchronization

Perhaps we could try the ct2 'du' version since the CPU isn't exactly in the same 'lock and step' as a 16mhz Falcon. Or failing that perhaps bm030a with even stricter DSP requirements should be used... I haven't tried them yet.

I am always using -vgasafe just to be sure. I know -vgasafe is a requirement if bus acceleration is enabled.

That said .. besides BadMood being an issue, me and Stu also are struggling to get the FPU working properly. I noticed there are a couple of pads underneath the FPU unused, should we try populating them?

[Badwolf]

That said .. besides BadMood being an issue, me and Stu also are struggling to get the FPU working properly. I noticed there are a couple of pads underneath the FPU unused, should we try populating them?

The FPU is a bugger at the best of times and so far it looks like no-one has got it to work bar myself.

Since you two both have the ability to do so, can I perhaps suggest you try the experimental 220407 firmware? https://github.com/dh219/DFB/tree/main/DFB1/JEDEC

Nothing FPU-related has changed in that, but I found it more reliable overall for me, so it might be worth trying.

There should be no unpopulated pads beneath the FPU. There are a couple of normally-closed solder jumpers tying a couple of the lines to VCC to allow for using the FPU pins as an expansion port. They should be identified as JPx and not interfered with.

To really debug the FPU, I'd sugest:

a) not using TT-RAM whilst doing this
b) removing R18 so the FPU isn't driven by the CPLD
c) running a line from the CPU oscillator out to the FPU oscilaltor in (or the R1 pad, if not popualted), so the CPU and FPU are clocked by the same clock
d) slowing the CPU right down. Perhaps try a 33MHz oscilaltor, or remove the oscillator entirely and wire to the top of the XCPUCLK pin from the Falcon (16Mhz).

If you can't get the FPU to work at 16MHz in all these circumstances I would be really thinking contacts.

DML's FPU test is the only sure-fire way to prove things are going as they ought.

Reseat. Reseat. Reseat. Push the pins out from the underside of the chip.

Modern PLCC sockets and old design PLCC chips can be unhappy bedfellows. The old chips' pins can be a bit too wide at the top and make contact with the plastic spacers on the socket.

BW

[Badwolf]

@Badwolf @sety I wouldn't nessesarily say that Badmood is accelerator specific...

I just tried this again quickly and BM030 worked for me without any parameters.

B0A024F7-46B9-4272-8928-BEDE0EFB9C2E.jpeg (100.63 KiB) Viewed 2188 times

But I normally use RGB mode (ok, composite in this case) and I noticed you mentioned vgasafe a couple of times.

So I got out the VGA cable and sure enough I see your problems. The screen only flicks into life every two or three seconds for a fraction of a second at a time. Stuart’s jitter measurement would seem to be the smoking gun.

So BM is doing something funky in VGA mode. It must be manipulating Videl directly and it’s timings are off. Possibly because of the clock switching. Perhaps it’s trying to do a cycle calibration loop and failing? Well that likely will, this is a switching booster.

Since the source isn’t published, I don’t think there is anything to do about it. BadMood looks to be DFB incompatible in VGA mode.

The FPU on the other hand should be genuinely soluble and with Steve in country, I suggest I take a look at his card on known working hardware to rule out anything superficial.

BW

[Steve]

@Badwolf thanks for testing in VGA mode, at least that explains what is going on.

[Badwolf]

@Badwolf thanks for testing in VGA mode, at least that explains what is going on.

It would be interesting (although not really fruitful) to see if, when fed the system 16MHz clock, it goes back to working.

BW

[sety]

But I normally use RGB mode (ok, composite in this case) and I noticed you mentioned vgasafe a couple of times.

I just rewired my video connector to switch to RGB mode and you're correct. It runs perfectly in RGB mode. The demo has been looping for over an hour without a problem.

IMG_3019.JPG (146.56 KiB) Viewed 2165 times

I've never really used RGB on the Falcon as I don't own a SC1224, and RGB is less than flattering on a modern flat panel.

On a side note I'm having a play with the flash rom. Is there a particular rom size I should be using. dfbflash writes and verifies ok but no boot with flash enable.

[Badwolf]

I just rewired my video connector to switch to RGB mode and you're correct. It runs perfectly in RGB mode. The demo has been looping for over an hour without a problem.

OK, cool. Thanks for testing that

I've never really used RGB on the Falcon as I don't own a SC1224, and RGB is less than flattering on a modern flat panel.

Really? I think it's only usable on a modern display. Gets rid of all that flickering!

On a side note I'm having a play with the flash rom. Is there a particular rom size I should be using.

Supports 512kB flash (29F400) but has been designed to accomodate, but never tested with, 1MB too (29F800).

The idea being you could have a register that sets it to full 1MB mode (cf Emutos) or have A19 set to high or low (a built-in ROM switcher).

dfbflash writes and verifies ok

That's good!

but no boot with flash enable.

Less so, but perhaps not surprising as that side of the firmware hasn't really been looked at since revision 3b.

Do you have SYSINFO or something similar that can hex dump memory? If so, take a nosey at F80000 -- it should look similar to E00000. ie. start 60 2e 04 04 00 e0 00 30 ...

If it's reversed, your image might need to be byte swapped, for example.

BW

[sety]

Do you have SYSINFO or something similar that can hex dump memory? If so, take a nosey at F80000 -- it should look similar to E00000. ie. start 60 2e 04 04 00 e0 00 30 ...

I dumped the rom...

IMG_3029.JPG (171.37 KiB) Viewed 2144 times

Not exactly what I was expecting, but very beautiful in its own way. It is a 29f800. It's all I had on hand.

[Badwolf]

Do you have SYSINFO or something similar that can hex dump memory? If so, take a nosey at F80000 -- it should look similar to E00000. ie. start 60 2e 04 04 00 e0 00 30 ...

I dumped the rom...

IMG_3029.JPG

Not exactly what I was expecting, but very beautiful in its own way. It is a 29f800. It's all I had on hand.

How it works is that F80000 corresponds to what will decode as E00000 with the disable flash jumper removed. It then wraps at F9FFFF to F20000.

So F20000 -> E20000
F7FFFF -> E7FFFF
F80000 -> E00000
F9FFFF -> E1FFFF

However, I think I can see the problem. I suspect your ROM looks fine at F20000 (should correspond to E20000):

Tos404:

Code: Select all

00E20000  00 01 4e b9 00 e1 f7 3e  5c 8f 60 00 0b c4 20 6e

But! the firmware hasn't been updated to take into account the 29F800 chip, so the E00000-E20000 range has been written into E80000->EA0000. Not a lot of use to boot!

The quick firmware fix would be to recompile with

Code: Select all

assign ROM_A19 = A[19];

changed to

Code: Select all

assign ROM_A19 = 1'b0;

ie. disabling the high half of the flash for now.

Or you could try to lift the A19 pin/cut the track and tie it to ground, but I imagine that would be tricky with those pitches.

That's what you get for trying the advanced features early.

I may be able to make you a JED later, but can't promise.

BW