BLITTER RE-CREATION THOUGHTS

[exxos]

@Icky ohhhh can we have a 32bit blitter now then ? That would solve sooooooooo many TTram related issues ;)

[Badwolf]

We have performed extensive testing and are now confident to announce we have a working Blitter core on real hardware that matches the original Blitter.

Well done all involved!

BW

[stephen_usher]

Indeed! Stirling effort. One fewer original chip to rely upon in future.

[ijor]

We, @ijor and I, have a bit of an update on the Phoenix Sparkalaphobia aka the Hardware FPGA Blitter with Ijor's Blitter core. We have been working in the background on the core and testing. Ijor has been instrumental in helping get the timings and plumbing in place. I have learnt a great deal more about FPGAs through this experience.

Thanks a lot to Icky for his extensive testing and his patience.

What's planned for added features? ;)

32MHz ;)

It is absolutely possible. The core can easily perform at 32 Mhz without problems.

@Icky ohhhh can we have a 32bit blitter now then ? That would solve sooooooooo many TTram related issues ;)

You mean 32-bit address space?

[exxos]

It is absolutely possible. The core can easily perform at 32 Mhz without problems.

Nice. Yeah I'm talking more of a full 32mhz system. The H5 has a 32mhz capable CPU and RAM. We had the original chip set running at 16mhz but its a dead end project really. The goal is a 32mhz capable bus and new shifter modes to make use of all the extra bandwidth ;)

You mean 32-bit address space?

Yes.

[ijor]

You mean 32-bit address space?

Yes.

Shouldn't be too difficult to extend Blitter for supporting 32-bit address space. But you probably would need to implement some kind of backwards compatibility switch. Just in case some software that is not aware of the extended capability writes garbage to the address register upper 8-bits, which original Blitter obviously ignores.

[exxos]

Shouldn't be too difficult to extend Blitter for supporting 32-bit address space. But you probably would need to implement some kind of backwards compatibility switch. Just in case some software that is not aware of the extended capability writes garbage to the address register upper 8-bits, which original Blitter obviously ignores.

It's possible some bad software doesn't handle the higher bits. But as we doing our own OS then if a register could be added to switch modes then we can put it in a desktop menu and just let the user decide which mode to run it. Or a simple app to switch meanwhile.

[mrbombermillzy]

We have performed extensive testing and are now confident to announce we have a working Blitter core on real hardware that matches the original Blitter.

That is an amazing accomplishment. You guys should be very proud! Well done @Icky , @ijor and anyone else involved in this monumentous effort. :yay: (Sorry for the late reply, trying to catch up with stuff I've missed)

While we are on the blitter features wish list, I'm just started working on something interesting, but cannot vouch if it will be useful after I've properly tested, but just in case... would extending the HTRAM matrix size be completely out of the question?

[exxos]

I wonder if the blitter could beat any other CPU functions relating to bit shifting or something. I mean a 50mhz 030 only just seems to beat the blitter and fails it seems on more RAM related functions or something.

Not really sure what TOS does in using the glitter but maybe we could add functions into TOS and the blitter to gain some extra speed somewhere :shrug:

Or could the blitter itself run at higher speeds to do internal shifts which may speed up some existing functions.

[Cyprian]

Not really sure what TOS does in using the glitter but maybe we could add functions into TOS and the blitter to gain some extra speed somewhere :shrug:

line drawing function directly in blitter would be very useful