Firmware v105 for DFB1X? Removing the ROM?

[Badwolf]

Since blitter can't access TT-RAM I didn't see it not accessing flash as an issue (it would access onboard ROM instead. No problem if they're the same. If they're not the same? Don't use blitter.).

It's why anders did BLTFIX to solve the blitter with TTram issues should they arise.

Blitfix does diddly squat on the Falcon, I'm afraid!

BW

[exxos]

Blitfix does diddly squat on the Falcon, I'm afraid!

Don't know why that would be.. Maybe @agranlund can shed some light on that , if that's the case.

[Badwolf]

Blitfix does diddly squat on the Falcon, I'm afraid!

Don't know why that would be.. Maybe @agranlund can shed some light on that , if that's the case.

The way blitfix works with TOS2.06 is to patch the Line A and VDI calls to selectively use blitter depending on the memory range.

There is no alternative VDI or Line A pathway on TOS4, so it can't do this.

It can't even fall back to its default (non-TOS 2.06 & EmuTOS) behaviour of hiding the blitter as the Falcon blitter can't be disabled.

It's why NVDI is listed as a requirement DFB1. Well, prior to EmuTOS being available. Unfortunately NVDI only works around VDI problems. Any old software can still blit away happily and there's no way to stop it on the Falcon.

BW

[don_apple]

I would be willing to help with beta testing new firmware, but if it still requires a special programmer to get new firmware installed I'd have to try to find one of these programmers first (and figure out if it can be used on Linux or macOS, since I don't have any Windows systems).

I use one of these programmers but I did buy it a million years ago, there is probably alternatives by now... I think "USB blaster" might be one ? No idea about Linux or macs though will likely the other forum members can explain all that..

smxilinx.png


Though I would just get to grips with the accelerator before looking to update it anyway ;)

I've managed to "get to grips with the accelerator", it works quite nicely 8-)

Didn't get any info from other forum members so far about using Linux or macOS to flash the firmware on the xilinx chip. But I did some own research and it looks like there are some tools that might work:
https://xc3sprog.sourceforge.net
https://github.com/trabucayre/openFPGALoader

Also found a guide showing how to use a Raspberry Pi instead of the special cable from xilinx: https://anastas.io/hardware/2020/09/29/ ... sprog.html

Maybe I'll give this a try over the weekend to see if I can get this to work.

[mikro]

I have the same Xilinx cable as @exxos and I have successfully used the Impact Arch Linux package for flashing.

[stephen_usher]

This is the one I use, which is a bit cheaper: https://www.amazon.co.uk/Waveshare-Comp ... B00KM70UFG

[Badwolf]

Didn't get any info from other forum members so far about using Linux or macOS to flash the firmware on the xilinx chip. But I did some own research and it looks like there are some tools that might work:
https://xc3sprog.sourceforge.net
https://github.com/trabucayre/openFPGALoader

Also found a guide showing how to use a Raspberry Pi instead of the special cable from xilinx: https://anastas.io/hardware/2020/09/29/ ... sprog.html

Maybe I'll give this a try over the weekend to see if I can get this to work.

Sorry, missed your question.

All my programming is done with Linux or Mac using xc3sprog as you've identified.

Here's my simple programming script. You supply the JED filename as parameter one.

Code: Select all

#!/bin/bash
xc3sprog -c jtaghs2 -p 0 -v "$1"

The cable specified in "-c" may have to be modified for whatever version you have.

I haven't use the Raspberry Pi method myself, but I know it works. Just be careful about the 3V3 line. That is a 3V3 *sense* in the JTAG connector, so best to leave that unconnected when using a Pi.

BW

[stephen_usher]

I haven't use the Raspberry Pi method myself, but I know it works. Just be careful about the 3V3 line. That is a 3V3 *sense* in the JTAG connector, so best to leave that unconnected when using a Pi.

Very definitely don't connect this as you will fry the CPLD.

[Badwolf]

Very definitely don't connect this as you will fry the CPLD.

I don't know about frying the CPLD but backdriving the LDO and possibly putting 3V3 on some of the 5V parts that don't have their own power line up and running is definitely suboptimal.

If the whole shebang were 3V3, I'd say it'd be a good way to program a board in vitro.

BW

[stephen_usher]

If the whole shebang were 3V3, I'd say it'd be a good way to program a board in vitro.

Except, if you look at the CPLD data sheet it almost shouts at you not to try to power the CPLD from this pin. :-) It's not directly connected to Vcc. It's a sense output only. It also says not to power it until the CPLD has been powered up first.