DFB1X Falcon booster buyers interests

[Badwolf]

I did do a custom TOS206 for the TF536 stuff, sets up TTram automatically. Though I don't have the blitter to content with. I guess really in TOS404 it needs completely disabling.. but again like you say, is getting into another OS in the mix of it all.

It's not disabling that it needs, but replacing. There are no soft-blitting routines in TOS4, so blitfix style solutions don't work, alas.

EmuTOS supports everything bar truecolour VDI and certain pop-out menus at the moment, I think. It's very stable and you could just leave the old version in as people can upgrade as they like. It is, for the most part, the ideal companion OS for DFB1 as everything (bar TC & some menus) just works out of the box.

But I can only lead the horse to water, as it were. If you think you're going to get more support calls about EmuTOS than TOS4/blitter, fair enough. Of course as both are available you could always insist on switching to TOS before requesting help :)

BW

[Badwolf]

Just a quick one to put on record that Stephen and I as sole authors at point of effect have granted Exxos an exclusive commercial licence to derive products from the DFB1 1.0 release for a minimum period of four years without the need to publish source code or design files.

The document is published here: https://github.com/dh219/DFB/blob/main/ ... 202023.pdf and has taken effect as of 23/6/23.

We're mostly a friendly bunch here, but we've seen the occasional bit of controversy in the past and a very adjacent community to ours has more than its fair share, so this is just to make sure everyone's on the same page and DFB1X is completely above board.

BW

[exxos]

I would just like to further clarify that while things are generally " in the spirit of open source" , there had to be a certain aspect of "commercialism" in order to finish of the project in the way that I have done. I certainly did not take the design straight off git-hub and start selling it. Undoubtedly people will know there's been a fair few hardware/firmware/bug fixes/ changes since the original.

For example, I can spend literally thousands on getting parts on PCBs manufactured and assembled even in small batches. So in order to not go bankrupt personally,There had to be a licence in place to allow me to " protect my investment" . I'm not for example, going to invest several thousand on projects ,then give away all the sources at exactly the same time. Nobody in their right mind would do that.

I do of course thank @Badwolf For allowing me this opportunity to bring this board to the masses. I think it is a great project and well worth investing some capital into getting it produced in bulk for people.

:cheers:

[sporniket]

The pledge is a good thing.

[stephen_usher]

You’re only doing what the patent and copyright systems were originally designed to do, allow innovators to get a return on their work before the knowledge and designs became public property.

Unfortunately patents were turned from things to help innovation into innovation breaks and protection rackets. Also people with deep financial pockets bribed governments to extend copyright periods way beyond the original length so they could keep reaping money from things which should have become public property.

Anyway, I digress. This is a good and clear move @exxos & @Badwolf

[exxos]

I hope to be able to start taking orders for the 40mhz boards tomorrow.

I am not currently sure how many 50mhz boards there will be yet, if any. It could be another couple of weeks before they may appear in the store. Finding 50mhz CPUs looks to be getting time consuming. Fitting them and removing them from the sockets is no easy task either. So the price may end up going up a bit for the 50mhz ones if there are going to become "rare". I really did not expect this to be the case.

I understand if people want to hold out for a 50mhz board. I will not be able to change or upgrade your order, so please bear this in mind if you want to switch between one or the other. Also bear in mind I could run out of stock while people are waiting. So I suggest people keep an eye on this thread daily to see what is going on for the next few days.

I also don't want people to feel disappointed if they do not get a 50mhz board. I think in daily usage people are not really going to notice the difference anyway.

Because I don't know the number of boards until I have tested them, I will try and put them in the store in batches of 5 at a time. It I'll be on a first come first surved basis. I will try and mention each time I add a batch to the store so people don't have to repeatedly keep on checking for stock.

Also please note while they will be listed in the store, shipping will not be immediate and could be around 1-2 weeks delay.

I'm sorry if this all sounds confusing, I'm just trying to keep people updated and what is happening behind the scenes with it all.

[Rustynutt]

All boards come with TOS404 flashed in one bank (the flash has 2 banks selectable by jumper).

Might I suggest flashing EmuTOS 512 in the other bank? That way the customer will have the option of an out-of-the-box-no-software TT-RAM-enabled fast machine to show off with in GB6.

TOS4 requires software to declare the TT-RAM (FASTRAM/MAPROM) and NVDI to avoid the blitter.

BW

NB. I have a patched TOS4 I use in my machine to autodeclare the TT-RAM, but without NVDI you crash at desktop as the blitter gets involved and Bad Things happen. You could flash this, but I suspect it would lead to more tech support calls than 'where's my memory, then'? which you'll get with vanilla TOS4.

Have you tried setting the bus configuration bit for the blitter to be "1/2" CPU clock in your patched TOS?
It helps get the machine to the autofolder where NVDI can be ran.

[stephen_usher]

I wonder if TOS 4.04 could be recompiled with fixed blitter code, maybe even software blitting from the older TOS versions. It won't be binary compatible but only naughty software assumes ROM addresses.

[Rustynutt]

I wonder if TOS 4.04 could be recompiled with fixed blitter code, maybe even software blitting from the older TOS versions. It won't be binary compatible but only naughty software assumes ROM addresses.

From what I vaguely remember reading, Didier essential ripped code utilizing the Blitter out for CT TOS, and read that is what EMUTOS (at least that part of code) utilized. The Blitter cannot be deactivated, just not utilized.
Unfortunate Atari went that way, on the Sparrow, the Blitter can indeed be disabled. But it's not really the same machine. I'm sure they didn't Invision DFB's and CT60, much less the issue it causes :)

czietz, Roger Burrows, or possibly Mikro now the sources are released might have a quick answer for that, but think the long answer is, the Blitter is inside the COMBEL, and in TOS 4 cannot actually be "turned off".
What I've found is keeping the Blitter speed set to 1/2 CPU set in a TOS ROM works to get at least past the logo at boot, then NVDI (or EmuTos) have their own routines where it's not accessed.

That's not to say it's 100%. Have still come across crashes, likely where software bypasses something NVDI doesnt cache.

[exxos]

czietz, Roger Burrows, or possibly Mikro now the sources are released might have a quick answer for that, but think the long answer is, the Blitter is inside the COMBEL, and in TOS 4 cannot actually be "turned off".

As I understand it, the Falcon blitter cannot be turned off. Indeed I had these issues when I wrote GB6 that even if you send the command to turn it off, it still reports enabled.

I think NVDI simply replaces the blitter functions with its own routines, is basically bypasses the blitter entirely. Though I'm not really sure how it ultimately ends up being registered as disabled in GB6 when using NVDI. Though probably replaces that routine as well in TOS :shrug: