Interested in this hand-held device?

[saimo]

@Dr_Righteous

Uhm... I must say that I have many doubts: you see, we're not talking about a scandoubler... handling those Graphic Objects is quite complex and I don't think it's just a matter of programming a general-purpose chip... in MOM it's like having 32 framebuffers (or rasters or pixmaps or whatever you want to call them) which require masking, flipping, resizing and collision detection!
Anyway, if it's actually possible, I'm glad of it :-)

@all

The ideas that you are throwing at me here are very much appreciated, but all of them need careful evaluation: since I don't have the complete knowledge to do it, I have to request that you understand fully the MOM architecture, which can only be done after watching the deMOMstration and reading the manuals... but, of course, it's just for those who actually want to spend (or waste ;-)) their energies on my project.

Regards,
saimo

[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.

[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

[Bobsonsirjonny]

@ Saimo,

Sure I think a similar maifesto would do - but emphazise that it is something you have been designing for years - and have written emulators for Desktops, but it was intended as a handheld device - so you would love to see it implemented that way on a handheld - so not a replacement for the GP32, but as an additional platform that it can emiulate :-) For Fun - for curiosity, because it can be done, and for the hell of it :-)

[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

[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?

[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

[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.

[Hooligan_DCS]

"Interested in this hand-held device?"


I thought someone was auctioning his penis

...

[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

[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.  

[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