exxos's DFB1 trials

[stephen_usher]

To modify TOS 4 so radically would require the C source code, strip out the Blitter code, or at least modify it so that it tests for the source and destination addresses and then either call the hardware or a software blitter. If fVDI is available as C source then integrating this would be easier.

Also if the source of TOS is available the GEMDOS xmalloc() system call could be added if it's not already there and taken from TOS 3.06.

[Badwolf]

To modify TOS 4 so radically would require the C source code,

I'm led to believe it doesn't. As I understand it these things are done by lookup tables which can be overridden much like many OS calls. But I'm no expert.

Also if the source of TOS is available the GEMDOS xmalloc() system call could be added if it's not already there and taken from TOS 3.06.

What benefit would there be to this? [we already have Mxalloc() if that's what you mean, but why do you think this helps?]

BW

[stephen_usher]

To modify TOS 4 so radically would require the C source code,

I'm led to believe it doesn't. As I understand it these things are done by lookup tables which can be overridden much like many OS calls. But I'm no expert.

It would be nice to have a clean compiled ROM, especially if we are adding large lumps of code from elsewhere and changing the blitter code a great deal. You don't want the old code using valuable ROM space after all. Also, a newer compiler may produce more efficient code.

Also if the source of TOS is available the GEMDOS xmalloc() system call could be added if it's not already there and taken from TOS 3.06.

What benefit would there be to this? [we already have Mxalloc() if that's what you mean, but why do you think this helps?]

BW

I can never remember where the 'x' should go in the system call. If it's already there and it knows about the two RAM types, as on the TT you can specify ST or TT RAM for memory allocation, then there's no need to fix it.

[Rustynutt]

Bus control register detect is my mistake -- I'm only decoding 0x00FF8007 whereas TOS access it as 0xFFFF8007.
...
I hope that clears up a ffe

I'll honestly admit to not knowing how the flash works on the DFB. I follow along with why you say it can't happen on the DFB, somewhat.

As the AB patches a TOS image in fast ram, and successfully boots from there (on a warm reboot) displaying the Atari logo (thus utilizing the blitter), the blitter can be accessed from fast ram using a TOS image in fast ram.
But thats about as much as it does, and NVDI is definitely require to get to the GEM Desktop.
To my knowledge, there is nothing patched in TOS on the AB which allows this.

That's all I'm saying, so I'm understanding it's a hardware utilization difference on the DFB, and not that the blitter can't be accessed from fast ram? Some difference there, and my mistake for not getting that point.

The 1/2 CPU blitter setting is just to get around running the COMBEL blitter speed to a point it fails.
If the DFB firmware isn't reading the bus control register at 0xFFFF8007, my "hack" at bus acceleration won't work.

Also beginning to think the DFB firmware may be tweeked to function with the bus GALs specifically at 16MHz where boosting the bus to 25MHz may not be possible, without timing enhancements.

Not that the performance of the DFB is in question, it's that at 25MHz, TC mode in VGA is possible. Otherwise, I'd of given up a long time ago :lol:

[exxos]

Does anyone know if it's possible to read the CPU mask via software like on the CT60 ?

[exxos]

I'm starting to think all the 030 cpus have been reprinted as the latest mask. According my my google-foo people claim earlier masks can only do up to 40mhz.

Though it's seemingly a thermal issue with the CPU as a fan blowing over it helps. But not enough for stable operation. Mostly it fails on FPU test, but then the CPU is maxed out doing 50mhz constant, whereas it can pass TTRAM tests all day where the CPU does also run at 50mhz , it's switching back down to 16mhz a lot etc

I think the idea is supported as all the CPUs were tested on a TF536 which does 8/50 switching. But I did heat them all up with my gas soldering iron to make sure they didn't start to malfunction due to heat build up over time. They all passed those tests.

But on the DFB1X with it doing 16/50 seems to make the CPUs fail more often. Thing mostly it's only on FPU tests. So I wonder if I can run the CPU at 16mhz while the fpu is crunching it's numbers at 50mhz. Will test that later and see if it helps.

Though I'm not going to be doing any more firmware tweaks for the boards which go into the store as there are several tweaks which need sorting out and if I wait until every little thing is fiddled with, it would end up being next year before they get into my store. There are no serious issues with the release firmware AFAIK. But people also need to understand how to do firmware updates and not expect things to be 100% perfect out of the box. Until more people test the thing , we just don't know what issues will be. Hopefully none, but as this isn't he first batch, can't guarantee the outcome.

[stephen_usher]

Sounds fair to me.

[exxos]

I did a quick test to not speed up the CPU on FPU access and got 281% in GB6.

For reference:

CPU & FPU 40MHz = 248%
CPU & FPU 50MHz = 311%
CPU 16MHz, FPU 50MHz = 281%

So I guess the FPU is effectively running at about 45MHz :shrug:

Though while this could possibly "trick" 40MHz CPU's running at 50MHz, I don't think this is a good idea because things like integer division which also run the CPU at 50MHz could possibly fail because GB6 does not actually check the result (I was wanting to add that into GB7 but I think it probably won't happen anytime soon)

[stephen_usher]

What benefit does the FPU have in normal (games etc.) software have?

Most applications would have been written for the ST which doesn't have one anyway.

[exxos]

What benefit does the FPU have in normal (games etc.) software have?

None really. Think only BadMood may use it ?