FBlit source now open.

[utri007]

Long time ago I changed some mails with original author. I think that his original plan was make a monitor driver for FBlit. That would make a configuration and testing easier.

[Yulquen74]

would it be difficult to generate a 68000 compatible version of fblit?

[Samurai_Crow]

Originally Posted by Yulquen74

would it be difficult to generate a 68000 compatible version of fblit?

Yes. But even if it weren't, it would be slower than the blitter.

[Yulquen74]

Originally Posted by Samurai_Crow

Yes. But even if it weren't, it would be slower than the blitter.

Ok, I suspected that.
I did not have stock speed in mind when asking, but rather 68000 systems
clocked at 28-50MHz.

[roondar]

Originally Posted by Yulquen74

Ok, I suspected that.
I did not have stock speed in mind when asking, but rather 68000 systems
clocked at 28-50MHz.

I think the main limit would be the speed at which you can write back to chipmem on OCS systems.

Even with a fast 68000, surely the fact the 68000 can't write back more than 16 bits to chipmemory per write access will give you a best case performance roughly equal to the blitter for simple copy actions?

[Ratte]

Originally Posted by PeterK

Alright, if you know how to do it, then you should write such a monitor driver.
(Btw, the new icon.library is out now.)

It is easier to scan LOADVIEW and configure FBLIT related to the frontmost screenmode / monitorid.

[PeterK]

Just had a very short first look into the FBlit sources and found a small potential bug in FBltBitMap217.s

 ; BltBitMap()
 
SubMain: cnop 0,4
  btst  #ACTIVE,(l_Flags+3,pc)
  bne.s  NewMain    ;--> active...
  move.l  (l_OldBlit,pc),-(sp)
  rts

The CNOP 0,4 should be called above the label SubMain: !!
It's just good luck if CNOP generates real NOPs or the alignment fits anyway.

[utri007]

Originally Posted by PeterK

Just had a very short first look into the FBlit sources and found a small potential bug in FBltBitMap217.s

 ; BltBitMap()
 
SubMain: cnop 0,4
  btst  #ACTIVE,(l_Flags+3,pc)
  bne.s  NewMain    ;--> active...
  move.l  (l_OldBlit,pc),-(sp)
  rts

The CNOP 0,4 should be called above the label SubMain: !!
It's just good luck if CNOP generates real NOPs or the alignment fits anyway.

Thanks Peter! FBlit is very nice program, it makes many games with hires graphic playable. With 040/060 games like SimCity2000, Napalm etc has much faster Graphics.

It also makes OS to FLy and need for chip ram minimized. Wich enables to start games directly from workbench.

I really hope that somebody takes task.

[Samurai_Crow]

It is an easy fix. I just have to move the CNOP directive up a line or the label down one.

edit: DONE!

[HanSolo]

Where I can download fixed version ? (executable ready to install)

[PeterK]

Nowhere !!

It's most likely only a bug in the source code. I guess, the FBlit executable is not broken. So, no need to download anything.

But the source code had to be fixed, because in case of a change in the alignment of the label SubMain, it could result in a zero padding for the CNOP instruction, and that would cause crashes then.

[Seboss]

Long time user of the Amiga, but I only recently started to take an in-depth look to the hardware and software. So I still have a pretty bad intuition about performance of the CPU vs blitter. How fast must the CPU be to beat the blitter at its own game using fblit?

[Samurai_Crow]

Originally Posted by Seboss

Long time user of the Amiga, but I only recently started to take an in-depth look to the hardware and software. So I still have a pretty bad intuition about performance of the CPU vs blitter. How fast must the CPU be to beat the blitter at its own game using fblit?

An 040 can beat it. 030 ties it. The main 2 advantages are that the transparent blits are suboptimal on the blitter but the CPU can re-use the mask and the blitter is only 3.5 MHz.

[Photon]

Originally Posted by Samurai_Crow

An 040 can beat it. 030 ties it. The main 2 advantages are that the transparent blits are suboptimal on the blitter but the CPU can re-use the mask and the blitter is only 3.5 MHz.

Well... you wouldn't say that the CPU runs at 3.5 MHz. It takes 4 cycles for the CPU to write a word to RAM just as it does the Blitter.

All the chips including the CPU run at 7MHz, so it would be strange to single out the Blitter and call it a 3.5MHz co-processor

Its speed will "feel" like a 7-14MHz CPU - without the instruction overhead.

Performance in real applications will be be tempered in both cases by the bitplane depth and resolution to make the speed feel: like this, slower, much slower, or really, really slow (in the case of 640x256x16 on OCS).

For Workbench use on OCS, the sweet spot is the default one chosen for AmigaOS: 4 colors. Above that and it will feel slower regardless of the Blitter/CPU workload distribution.

[Samurai_Crow]

Originally Posted by Photon

Well... you wouldn't say that the CPU runs at 3.5 MHz. It takes 4 cycles for the CPU to write a word to RAM just as it does the Blitter.

All the chips including the CPU run at 7MHz, so it would be strange to single out the Blitter and call it a 3.5MHz co-processor

Its speed will "feel" like a 7-14MHz CPU - without the instruction overhead.

Performance in real applications will be be tempered in both cases by the bitplane depth and resolution to make the speed feel: like this, slower, much slower, or really, really slow (in the case of 640x256x16 on OCS).

For Workbench use on OCS, the sweet spot is the default one chosen for AmigaOS: 4 colors. Above that and it will feel slower regardless of the Blitter/CPU workload distribution.

An 020+ has code caches so there is not much instruction overhead there either. An 020 is typically 50% faster as a result.

[coder76]

Can Fblit use CPU and blitter at same time for same tasks? on AGA machines with fastram, there is certainly enough bandwidth for CPU and blitter to work in parallell into chip ram. With 32-bit memory accesses for everything the bandwidth is 14 MB/sec to chip ram, but as you know blitter has only 16-bit access, bitplanes can be 64-bit (in 4X mode), and CPU has 32-bit memory accesses for 68020+. This means that CPU+blitter bandwidth can maximally be around 10 MB/sec into chip ram, which is quite an improvement over only blitter (around 3,3 MB/sec), or CPU only (7 MB/sec).

[Samurai_Crow]

No. GameSmith does though.

Remember, FBlit stores graphics in Fast RAM that the real blitter can't touch.

[PeterK]

@coder76
Usually FBlit uses graphical objects in FastMem and the blitter is restricted to ChipMem. You have to make a global decision where you want to store your images. Using FBlit has no advantages if your images are located in ChipMem. And FBlit can not split a call like BltBitMapRastport() into two parts. How should that go? Or should it play "one (call) for me, one for you"?

[Samurai_Crow]

Originally Posted by PeterK

@coder76
Usually FBlit uses graphical objects in FastMem and the blitter is restricted to ChipMem. You have to make a global decision where you want to store your images. Using FBlit has no advantages if your images are located in ChipMem. And FBlit can not split a call like BltBitMapRastport() into two parts. How should that go? Or should it play "one (call) for me, one for you"?

GameSmith processes blit nodes with the CPU while waiting for the video blank interrupt to run. That's just how it's done.

[PeterK]

Ok, a particular task (game) can use the blitter directly and not through system calls like BltBitMapRastport(). That way, it can make a decision on every graphical object, whether to use FBlit or the blitter. FBlit may also be used directly, through fblit.library calls, I don't know.