DFB1X Falcon booster buyers interests

[stephen_usher]

So can't you just replace the calls in the ROM to software routines taken from TOS 3.06? Guess that would only work in "TT compatible" resolutions for the pixel depths thinking about it.

Is it a problem with GEM mallocing RAM from the wrong place because TOS 4.04 has no concept of "TT-RAM" and hence treats all RAM as ST-RAM when programs run malloc? Maybe that just needs fixing and mallocx() being implemented for programs which are TT-RAM aware?

[exxos]

So can't you just replace the calls in the ROM to software routines taken from TOS 3.06? Guess that would only work in "TT compatible" resolutions for the pixel depths thinking about it.

No glue, in theory I guess yes, but It would just be easier to use EMUTOS in that case.

Is it a problem with GEM mallocing RAM from the wrong place because TOS 4.04 has no concept of "TT-RAM" and hence treats all RAM as ST-RAM when programs run malloc? Maybe that just needs fixing and mallocx() being implemented for programs which are TT-RAM aware?

The problem is the blitter simply cannot access 32bit address, EG TT-RAM. On GB6 the first tests icons end up corrupted if you run GB6 from TTram with blitter. The "fix" is to use NVDI.

If there was technically a 32bit-blitter it could be added onto the DFB1. @ijor Would be the one to ask about that stuff.

Though as to how you would go about disabling the Falcon one and using the 32bit blitter, no idea.

[stephen_usher]

[

Is it a problem with GEM mallocing RAM from the wrong place because TOS 4.04 has no concept of "TT-RAM" and hence treats all RAM as ST-RAM when programs run malloc? Maybe that just needs fixing and mallocx() being implemented for programs which are TT-RAM aware?

The problem is the blitter simply cannot access 32bit address, EG TT-RAM. On GB6 the first tests icons end up corrupted if you run GB6 from TTram with blitter. The "fix" is to use NVDI.

Indeed, which means that VDI is mallocing RAM from TT-RAM. If whichever GEMDOS call it's making were forced to malloc only from ST-RAM then there would not be a problem as all GEM blit transfers would be in ST-RAM. The TT has a separate malloc call to request allocation of memory in TT-RAM.

[exxos]

Indeed, which means that VDI is mallocing RAM from TT-RAM. If whichever GEMDOS call it's making were forced to malloc only from ST-RAM then there would not be a problem as all GEM blit transfers would be in ST-RAM. The TT has a separate malloc call to request allocation of memory in TT-RAM.

Isn't that what PRGFLAGS is for though ? I mean sure, if you load GB6 into ST-RAM, it will work fine as will any other apps. But if you "force" GB6 to load in TTram, then it will run basically fine , but some blitter functions will fail.

[stephen_usher]

I thought someone said that if TOS was modified to understand TT-RAM at boot then the desktop crashes.

[exxos]

I thought someone said that if TOS was modified to understand TT-RAM at boot then the desktop crashes.

I assume its the same as with the ST, where video RAM tries to allocate into TTram. So you end up with "no video" because the shifter cannot access TTram.

Though I modified TOS206 to enable TTram at boot and it works fine. Can't say for problems with the Falcon though. @Badwolf Mentioned a modified TOS404 today I think but cannot remember what he specifically said now.

EDIT:
viewtopic.php?p=102366#p102366

[MegaSTEarian]

For people in the EU, is there a way to avoid being charged with high custom fees?

[sporniket]

At time of writing, I can only think of that : https://en.wikipedia.org/wiki/Diplomatic_bag

[Badwolf]

At time of writing, I can only think of that : https://en.wikipedia.org/wiki/Diplomatic_bag

There's also encourage your UK friends to vote for a pro-EU party*?

BW



* That's not the blue or red ones, BTW.

[chronicthehedgehog]

Cross-channel drone?