Interested in this hand-held device?

[saimo]

@downix

@saimo

an FPGA or PLD is not a general-purpose chip.  They're programmable chips.

Oh, right. I guess I heard of those gates arrays 3 or 4 years ago, when some company was designing/building a kick-ass, ultra-flexible computer entirely based on FPGAs (no CPU as generally intended!).
I said general-purpose to indicate general use, I did not know it actually refers to a precise category of chip (as I gather from your answer).

Want 32 framebuffers, program one to do it.  Want an MPEG decoder, you got it.  How about a 3D texture mapping routine, bingo.

Really?
Wow, now this is interesting!

I'll look into how much work it would be,

Great!
And... in case it turns out to be not that hard, could you also evaluate the feasibility of DAD, please? :-P

but I'd note, I've designed sprite engines for FPGA's before (one with 256 sprites, mind you)

This is only good news to me! :-)

and usually the key issue is not the FPGA but the memory bandwidth.

Yeah, of course.
The clock figure I gave for the Video RAM (133 MHz) was calculated considering 64 bytes/pixel data fetch, but, as discussed in a previous post, this could be lowered to 33, thus almost halving the memory frequency.
Though, here I must also stress that my design, being somewhat "ideal", contemplates a zero-waitstate interface to the CPU for the Video RAM, which is achieved by a custom double port RAM (the port for the CPU is read-write, while the one to the Video Unit - the circuitry responsible for video data handling - is read-only, in order to avoid mutual exclusion problems): this, obviously, makes everything more difficult...

Anyway, do your evaluation and let me know...

Regards,
saimo

[saimo]

@ Bobsonsirjonny

Uhm, it will require some rework (y' know, too much emphasis on the Amiga - different audience), but... OK.

Thanks for the suggestions!

Regards,
saimo

[saimo]

@downix

@saimo

I just spent 3 hours figuring it out.

Thanks a lot, this is very much appreciated :-)

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

Ouch!
And why so?

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!

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!

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

[saimo]

@downix

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.

Ooops!
I just checked and actually the archive was corrupt  :getmad:, so you (and whoever downloaded it) must have missed other files, too!
I'm sorry for the inconvenient, but now a good archive is in place (and the block diagram picture is MOM/dvp/dox/MOM - developer's manual/blk_diagram.ilbm).

Regards,
saimo

[saimo]

@downix

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

Thanks!
Uhm... makes me ponder... should I include it directly as a jpg? I think it would be better, right?

But the basic diagram has a few problems.  Namely, no differentialization between the address bus and the data bus.

You see, that serves just to show how the device is logically organized: the differentiation you suggest - that does exist in reality - is a detail that goes beyond (just, f.ex., would be the indication of the buses width and several other aspects).

Also, you have an MMU where, properly, a bus arbiter should be.  (an MMU should be a seperate unit, sure, but located slightly different)

Oh, but _my_ MMU is _also_ a bus arbiter... a complete "manager" of memory accesses!
Y'know, that's my machine and I make it the way I want ;-) - seriously speaking, as I explained in a number of different places, not all aspects of the architecture take into account costs, complexity, etc.

Not a bad first attempt, however.

Thanks.

Regards,
saimo