Interested in this hand-held device?

[downix]

@saimo

From what I read, your custom chip work could be fit into a $5 Xilinx Spartan II.  I have several here from my own custom chip work and I've fit much more complex beasts into one.

[downix]

@saimo

I've implimented similar video systems in the Spartan II before.  There are similar chips from Altera as well.  Would you like me to set up a gate estimate for you, so you'll get an idea how large a chip to look into?

[downix]

@saimo

This is based on a brief glanceover.  I'd be glad to look it over in more depth later on after work.

[downix]

@saimo

an FPGA or PLD is not a general-purpose chip.  They're programmable chips.  Want 32 framebuffers, program one to do it.  Want an MPEG decoder, you got it.  How about a 3D texture mapping routine, bingo.

I'll look into how much work it would be, but I'd note, I've designed sprite engines for FPGA's before (one with 256 sprites, mind you) and usually the key issue is not the FPGA but the memory bandwidth.

[downix]

@saimo

I just spent 3 hours figuring it out.  (Difficult to do, as I lack an Amiga, running a Pegasos, so the guide files were a bear to handle)

I'd estimate no more than 45k gates for the custom work.  While that would fit into a Spartan IIE, I'd recommend looking into the Virtex II due to the latter parts higher speed.  Heck, it is not inconcevable to convert your C code into the core verilog routines, even tho it would take customization work after that to get it to be completely hardware-based.  Or do you have schematics?

[downix]

saimo wrote:
@downix

(Difficult to do, as I lack an Amiga, running a Pegasos, so the guide files were a bear to handle)

Ouch!
And why so?

MorphOS doesn't have an amigaguide file reader atm.

I'd estimate no more than 45k gates for the custom work.  While that would fit into a Spartan IIE, I'd recommend looking into the Virtex II due to the latter parts higher speed.

Uhm... for just the video part or the whole machine?
As for the chip... well, you are the expert in that field!

For the custom-chip sections, namely audio and video.

Heck, it is not inconcevable to convert your C code into the core verilog routines, even tho it would take customization work after that to get it to be completely hardware-based.  Or do you have schematics?

Erm... and who told you that my code is written in C? ;-)
Everything is 100% asm!

Ok, a bit different then

And, apart from that, I'm really sure that solution would not work: you see, a software emulation, for speed reasons, performs its activities by using a totally different approach; f.ex., there are 8 different routines to handle sprites (a sprite can be: the one with less priority  - i.e. the first one to be drawn -, flipped, scaled) and they will become 16 when (if) I will add collision detection - the only major part missing) and some make use of longword accesses to memory, whereas a hardware solution would not care about those differences as it should always be able to cope with the heaviest load using a single precalc/fetch/process/write method.

As for the schematics, the only thing available is the general block diagram in the docs dir (MOM/dvp/dox/MOM - developer's manual/).

Regards,
saimo

A block diagram, also commonly called a Register Transfer Model is actually a good starting point for any custom chip work.  I could not find one, even tho I clicked on the button for it.  It kept popping up an error.

[downix]

I converted the ilbm to jpg for easier viewing if anyone would be interested.

But the basic diagram has a few problems.  Namely, no differentialization between the address bus and the data bus.   Also, you have an MMU where, properly, a bus arbiter should be.  (an MMU should be a seperate unit, sure, but located slightly different)  Not a bad first attempt, however.