Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: saimo on September 07, 2003, 08:12:27 PM
-
Hello everybody!
It is a tough challenge, but I am trying to be concise.
PREAMBLE (just to give an idea of how concise I am going to be...)
--------------------------------------------------------------------------
It is years now that I am working on a hand-held device, whose foremost
aim has always been... pure FUN.
Now it has grown so much that I think it is about time to share this fun
with the world.
Currently, its only tangible implementation is an emulator for the classic
Amigas - I *love* the Amiga - and that is why I am posting here.
I am searching for enthusiast M68k coders who want to have some real fun
programming a really cool piece of "hardware" (obviously this is just my
humble - and biased - opinion).
Of course I would be glad of knowing of happy users, too - there is little
point in having a platform without users, right?
Lastly, I will not slam the door in the face of any company interested in
pulling out a real piece of hardware :) - but, frankly, I do not even dare
to dream of this as a real-world possibility. A more sensible one would be
the development of emulators for other platforms - welcome as well, of
course ;)
Let's have a look at what I am offering, without diving into technical
details - there are large .guides for that and I want to concentrate on
the fun part here.
WHAT IT IS ALL ABOUT
--------------------------------------------------------------------------
The device is named "MOM" and can be looked at as yet another GameBoy-like
console.
Why does it exist?
Simple: I wanted to have *fun* =)
Both developing it and developing _for_ it.
I wanted a device which was easy and funny to hardware-hit; I wanted a
device which was as much coder-oriented as possible, but still powerful
and flexible. So in 1998 (or maybe even 1 year before) I came up with some
design sketches and since then I never stopped working at this project...
... if only I could have worked on it constantly, the release date would
have come much before! - it is quite late, indeed.
I see I am getting lost, despite my initial promise.
Sorry, I just can not resist.
Among its features you can find:
- an MC68030 CPU
- a video architecture entirely based around the concept of extremely
flexible and powerful sprites (scalable, flippable, etc.)
For a complete overview of the system I strongly advice to read the
"MOM - developer's manual" and watch the "deMOMstration", an application
that actually runs on the device itself and that shows some of its key
features.
RELEASE/DISTRIBUTION INFORMATION
--------------------------------------------------------------------------
I am releasing it only now because:
- finally both the general design and the emulator are in a very
advanced stage
- finally the emulator has been tested on 060 (totally developed on a
humble - yet loyal - 030)
- finally there is a little application (the "deMOMstration" mentioned
above) which *visually* illustrates many features of the device - so
you do not have to wade through large technical manuals (that do exist)
to get the idea: all you have to do is spending 10 minutes of your life
sitting & watching
- finally I have some free time to dedicate to potential requests - I got
my Computer Science degree just a few weeks ago and so I will be free
in the near future (ooops! this is now outdated by far, as I lazily
spent the last 2 months happily doing a lot of other unrelated
activities :p)
The distribution packages (just ~500 kb in all) include:
- MOM developer material: documentation, includes, tools, etc.
- MOMiga: MOM emulator for the Amiga
- MOS: an OS for MOM (comprehensive of development stuff)
- deMOMstration: MOM+MOS application that shows some of the key features
of MOM
- MEMOU: MOM+MOS (little) game
To get everything to work, it is enough to unpack the archives, CD in
the directory chosen and launch the script "go_d" to see deMOMstration
or "go_M" to play MEMOU.
No writes to HD will occur (unless you explicitly specify to save the
memory card to HD).
The whole package is e-mailware: if you use it, you *must* send me an
e-mail.
Any _commercial_ use or product based on any or all of its parts is
strictly *prohibited* if not explicitly authorized by a written agreement
with me.
IMPORTANT NOTES ABOUT THE EMULATOR (MOMiga)
--------------------------------------------------------------------------
- it requires an Amiga with at least a 030, AGA and native graphics
output - i.e. redirection through scandoublers or graphic-cards is
likely to produce bad visuals (this is due to the fact that it uses
SHRES screens)
- only rather old versions have been tested on 040 - I have no clue
whether it still works on that CPU, but it should
- it has not been tested on NTSC machines and some parts do not take into
account NTSC timings - yet, it should work anyway
- it is a very complex piece of code: I did my very best to make it as
clean as possible and actually it works perfectly on my machine and on
some 060-equipped Amigas that 2 friends (hello, Timo & Richard!) used
for beta-testing - but beware of patches! Some (combination?) of them
could cause problems (in which case, it should be enough to reboot
without startup-sequence and run it after just SetPatch)!
- it can *not* work on UAE because it requires an MMU, which AFAIK is not
emulated yet
HOW CAN YOU PUT YOUR HANDS ON IT?
--------------------------------------------------------------------------
Simply surf to http://saimobvq.interfree.it/MOM/index.html and download
all the archives.
There you will find also a lot of other interesting information.
For comments, requests of clarification, flames and anything else, write
to saimobvq@interfree.it .
SUMMARY OF AREAS OF INTEREST
--------------------------------------------------------------------------
- development of applications (which I use to call "cartridges")
- development of emulators for other platforms
- development of some specific parts of MOS (for now just data packing
and .mod replay routines (and maybe IEEE math routines))
- adaptation of include files for more programming languages
- porting of support tools to other platforms
- betatesting
- development of the real device ;)
If you are a developer and want to start a MOM project, choose the 4-byte
ID that will mark all of your productions: this way I can make an official
and public list of developers.
Despite the focus of this section is on development, the most important
role is played by... users! The more, the happier I am.
Of course, I do not expect many users to be attracted right now that there
is only a simple game and a technical presentation.
Anybody willing to help me create a user base? ;)
WANT TO KNOW MORE?
--------------------------------------------------------------------------
Well, then why don't you have a look at the deMOMstration? ;)
Seriously, believe me: it is worth a thousand words.
Thanks for reading this far.
Best regards,
saimo
P.S. I am searching for a job...
As you may imagine, I would love to develop for a hand-held device...
not to mention that working with a good team on a GameBoy or GP32
title would make me sooo happy...
... any offers?
-
@saimo
Funny :-)
just downloaded and tested . . . it works fine on my A4000/040 and OS3.9BB2.
Interesting work!
Ciao
-
Ciao!
Thanks for taking the time :-)
Glad to know that it works under that configuration: only old versions of the emulator have been tested on an A4000/040, so I could not grant it would work.
Yet, I'm a bit concerned about speed: unluckily the A4k bus speed is rather low, so it turns out that my A1200+Bz1230 is much faster :-o
Anyway, I'm happy you had fun, that's the main point of the whole project ;-)
Regards,
saimo
-
saimo wrote:
Yet, I'm a bit concerned about speed: unluckily the A4k bus speed is rather low, so it turns out that my A1200+Bz1230 is much faster :-o
Are you referring to the memory bandwidth?
Is the fast ram memory on the motherboard? 4000 desktop systems have a real bottleneck there, memory access takes ages.
If you can get any kind of second hand accelerator to replace the 3640 card (and take the memory directly) you will see a big improvement, even for those that simply transplant the existing CPU.
-
@saimo
Yes effectively, is a bit slow here also (with memory on mobo)
Ciao
PS- . . .siamo italiani e ci scriviamo in inglese :-)
-
Karlos wrote:
saimo wrote:
Yet, I'm a bit concerned about speed: unluckily the A4k bus speed is rather low, so it turns out that my A1200+Bz1230 is much faster :-o
Are you referring to the memory bandwidth?
Is the fast ram memory on the motherboard? 4000 desktop systems have a real bottleneck there, memory access takes ages.
Yes, I meant exactly that.
I'm well aware of that problem, because when I had an A4000/040@25 temporarily under my hands (to write the MMU handling code), emulation always resulted slower by 5-10 FPS compared to the A1200/030@50, and most of that difference was made just by the slow FAST RAM access/bandwidth.
Now I can work on an A4000/060@50 and the speed gain is very noticeable; though, there the real beast is the bottleneck of CHIP RAM.
If you can get any kind of second hand accelerator to replace the 3640 card (and take the memory directly) you will see a big improvement, even for those that simply transplant the existing CPU.
Yes, sure... only that it's not me the guy with the A4000 ;-)
Regards,
saimo
-
Framiga wrote:
@saimo
Yes effectively, is a bit slow here also (with memory on mobo)
Yep, unluckily that's due to the A4k bus :-( (see the other posts in this thread)
PS- . . .siamo italiani e ci scriviamo in inglese :-)
Lo so, e' una specie di gioco da scemi, ma questo e' un sito internazionale!
-
I know, it's a kind of fools' game, but this is an international site!
Ciao,
saimo
-
This HandHeld sounds a lot like the GP32 in spirit. Hardware is different - the GP32 being more powerful.. Many People are developing emulators for the GP32.
You want this thing as a portable games hardware.. how about writing an EMU of it for the GP32?
www.gp32x.com
www.gp32zine.com
These places have info on it. Its a very capable handheld - and can run almost anything!!!!
Seriously - your idea would work excellently on this handheld :-)
-
Will take a look, sounds interesting!
-
You know, it sounds like the Amigo computer could be modified somewhat to suit the specs of the hardware required for an actual MOM device. Or vice versa.
It can be found HERE (http://cgi.snafu.de/dcr/user-cgi-bin/Website?name=HTML_Welcome)...
-
Bobsonsirjonny wrote:
This HandHeld sounds a lot like the GP32 in spirit.
Really?
I've read the news about the GP32 some months ago, but could not bother to learn about its architecture.
But yes, your point is right, in fact I really got excited about that device... if I only had the money... :-(
Hardware is different - the GP32 being more powerful..
Oh, sure.
The "power" of my system is not in high specs, but rather in flexibility, freedom and ease of programming (I can't really find the right words).
Brutal power is only contempled in DAD ;-)
You want this thing as a portable games hardware.. how about writing an EMU of it for the GP32?
www.gp32x.com
www.gp32zine.com
These places have info on it. Its a very capable handheld - and can run almost anything!!!!
Seriously - your idea would work excellently on this handheld :-)
I'm sure you'll have a hard time in believing me - and maybe you'll even laugh in my face - but I really doubt that the GP32 is capable of running the emulation of MOM at full speed.
As I said, I don't know any detail about the architecture - and so the specs - of that machine, but what I know is that the MOM architecture is extremely demanding (and that's why it is just an "ideal" device), especially as for the video part: that a hand-held device is capable of emulating another hand-held device that could well be unfeasible as a real piece of hardware... well, seems pretty incredible ;-)
OK, you know what?
I'm having a tour at the links you provided, hoping to find some precise architectural info so that I can answer better.
Ah, another thing... it seems a bit pointless to me emulating a non-existing hand-held device on another hand-held (which, instead, does exist), unless the emulated one turns out to be better that the emulating one... which I also strongly doubt: sure that GP32 must be a nice machine and surely it has many (if not all) better aspects... I don't really know... well, really time to surf to those pages ;-)
[EDIT]
I've just been at www.GP32x.com and I could find the link to the developer's manual, which I don't have the time to read now (gotta sleep!), so no info gathered.
Can anybody tell me in two words - oh, well, numbers ;-) - the memory<->CPU bandwidth and the CPU clock speed?
BTW: at first glance, it really seems an excellent platform!
[/EDIT]
Regards,
saimo
-
@Dr_Righteous
Just been there.
That's actually another admirable effort by a smart guy who has passion pumping thru his veins.
Unluckily, twisting MOM into an Amigo or viceversa in not trivial at all, because Amigo seems to be made of standard components whereas MOM requires some custom chips (ouch! :-P) that, I suppose, are quite a challenge to design and build for anybody, even big companies like Nintendo and Sony.
Regards,
saimo
-
Dimension/Weight 147mm X 88mm X 34mm(163g)
Display 3.5" Reflective TFT LCD(65,536 concurrent colors)
Resolution 320 X 240 pixel
CPU 32-bit RISC CPU(ARM9)
RAM 8MB SDRAM
ROM 512K
Sound 44.1Khz 16 bit Stereo Sound / 4 Channel Wav Mixing, 16Poly S/W MIDI Support / Earphone Port / 2 Speakers
External Storage Medium Smart Media Card (SMC)
Wireless Multiplayer Gaming 4-Channel RF Module
PC Connection USB Port Connection
Power Supply 2AA batteries (12 hours use time between charges) / DC 3V Adapter
Option Rechargeable Battery
Controls 8-way directional pad (joystick) + Durable 6 key button
MP3 Capability MPEG ( Ⅰ, Ⅱ) Audio Support
Other Add-on Applications Image Viewer, Text Viewer, Media Player, E-Book Viewer
RF Module 2.4GHz ISM Band
-
GP32 Technical Features
The World’s Most Powerful 32-bit Handheld Console(using ARM9 Handheld Console (using ARM9 Processor)
- High-performance
- High-Definition Graphic, Superior Stereo Sound Quality
The World’s First Handheld Console Implementing Wireless RF Technology
- Uup to 4 modules can use any of the 4 channels available on the RF module to play against each other within 10 meters of a line of sight
Digital Multimedia Entertainment Like No Other
- A variety of add-on applications enable digital multimedia content including Music Videos, MP3, Moving Images, Text and Images
-
GP32 Key Functionalities
Multiplayer Wireless Game (local communication)
GP32 boasts cutting-edge Wireless Radio Frequency Technology that delivers
Reliable Multiplayer gaming (2.4GHz ISM band)
- GP32 uses radio signals to communicate through solid barriers such as a building (unlike infrared signals that require an unobstructed line of sight to make a connection), you can play games even when your lovely puppy is standing in front of you wagging his tail, blocking your view.
- Real-time Multiplayer game can be enjoyed by up to 4 different GP32s per channel and a maximum of 4groups can each play different games together.
Multimedia Player
GP32 delivers a significant consumer experience for viewing digital multimedia content on the GP32 platform. GP32 can support content delivered in various media formats.
- GP 32 offers a powerful integrated Viewer to view text, image and E-book files.
- GP32 MP3 Player boasts its 44.1Khz 16bit Stereo Sound / 4 Channel Wav Mixing 16 Poly S/W MIDI Support / Earphone Port / 2 Speakers
PC connectivity System
GP32 coes with USB port connection cable accessory. It allows you to connect it to your PC and your local ISP so that you can swap multimedia content delivered in various media formats (MP3 files, image files, text files and etc.)
-
Gameparks site (the makers of the GP32) (http://english.gamepark.com/)
Hope this is of help :-)
-
BTW - the CPU in the GP32 as a rule is underclocked for battery life :-)
But some EMU's provide a throttle - and most actually run safely at 150Mhz. Some have been able to go at 170Mhz - but this is rare.
Most are actually able to do 150Mhz.
-
@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.
-
@Bobsonsirjonny
First of all, thank you very much for all the detailed info you retrieved for me!
Second... WOW! That GP32 really rocks!
Third, about the capability of running the emulation of MOM on the GP32: surely that beast can run the emulation much faster than any MC68k+AGA Amiga can do, but still I don't think it can do it at full speed.
The main reason is that MOM has 32 masked Graphic Objects (GOs), which can be moved, scaled and flipped freely at each rasterline.
This means that:
- at every rasterline, the machine has to retrieve all the 32 descriptors of the GOs and calculate the starting addresses of graphic data and mask and the fetch "step" for each of them;
- at every pixel, the machine needs to read up to 32 bytes of mask data, to decide which is the GO that the frontmost pixel belongs to and to perform collision detection (this holds assuming that no transparency feature exists, in which case the data fetch rises to 64 bytes/pixel - I'm saying this because the current emulator (MOMiga) does have a particular transparency feature, although, for now, I've decided not to put it in MOM's feature list); finally, it has also to read the value of the chosen pixel and write it in the video buffer.
All this, of course, should happen in sync with the raster drawing on screen in order to achieve a full-speed emulation.
Another crucial point is CPU emulation: that's something that does take a lot of processing power.
Other non-trivial points are the emulation of the rest of the chipset (audio, at least, should not be a big issue).
Apart from all these technical considerations (which could also be (partially) wrong, as I'm not an electronic engineer and I don't know where today's state-of-the-art technology has arrived), I'm still wondering... would it be worthwhile? :-? You see, that GP32 must be really cool, so what's the point? I (as everbody else, I'd bet) would prefer producing native applications for that machine!
Uhm... your point is still quite interesting indeed, so I guess I'm gonna put this in the FAQ ;-)
Regards,
saimo
-
@downix
If that was possible, that would really be a dream, actually ;-)
Seriously speaking, I don't know that chip and, as I said in my previous post, I'm not an electronic engineer, so I may well be wrong.
Assuming that you are implicitly referring to the video part of MOM (which is the most demanding one), the more I think of it, the more I wonder... is it really possible that such a cheap and standard, non-specialized chip can handle such a large, non-burstable, memory data transfer, with all the calculations associated to it?
Are you really sure?
You seem to have experience in the field, so can I ask you to evaluate deeply this possibility? - in practice, I'm asking you to read the full info on the site, watching the deMOMstration and reading the MOM developer's manual (what? No, thanks... as for the coffee, I can help myself ;-) ) to get a precise idea: I know this is quite an effort, so feel free to ignore my request.
Regards,
saimo
-
@ Saimo,
Actually its quite the contrary - whilst native stuff does get written for the GP32, many people prefer to code for an emulator for it - to bring back old memories.
There are commercial outfits developng games and apps for it - but most of the stuff is open source, and home brew. The best way of thinking about is is a hardware version of Amiga Anywear. They are designing the GP64 as we speak - maybe you should have a word with them.
The GP32 already has an Atari ST emulator which is so much faster than the origional machine.. Best thing for you to do would be to head over GP32x.com and post in the dev section. Its a great community - like what we used to be like in the good old days. Many people are still learning, and its free from the company fighting.
BTW another good thing about the GP32 is you can rip the lid off and get under the hood - many people are building custom expansions etc... maybe your custom chips could be added?
-
@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?
-
@Bobsonsirjonny
@ Saimo,
Actually its quite the contrary - whilst native stuff does get written for the GP32, many people prefer to code for an emulator for it - to bring back old memories.
Yea, I know this, and it does make sense!
But, instead, nobody ever has heard of MOM before, so it's not the same thing: why undergoing the hassle of writing a virtual machine for a real one which is already extremely nice? I would be the only one to care!
There are commercial outfits developng games and apps for it - but most of the stuff is open source, and home brew.
I must say that the GP32 has a strong appeal... but I don't have the time nor the money now.
The best way of thinking about is is a hardware version of Amiga Anywear. They are designing the GP64 as we speak - maybe you should have a word with them.
I guess it's going to be backward compatible, that is, my ideas would not fit into their schemes. :-/
The GP32 already has an Atari ST emulator which is so much faster than the origional machine...
I don't argue that it's impossible emulating machines at full speed and more... that depends on the emulated machine!
Best thing for you to do would be to head over GP32x.com and post in the dev section. Its a great community - like what we used to be like in the good old days. Many people are still learning, and its free from the company fighting.
It sounds like a very nice place... but... what would I have to say, there? Try figuring the scene... at a certain point, an unknown dude pops in and says: "Hey, I've got a totally different machine..." - nobody would care, and I'd surely be suggested that I leave for a more suitable place.
BTW another good thing about the GP32 is you can rip the lid off and get under the hood - many people are building custom expansions etc... maybe your custom chips could be added?
Oh well, how could I tell that? - but, yes, I doubt this, too.
Let me add just one thing: of course any MOM emulator on any platform is more than welcome... I surely don't intend to stop anybody who is willing to take the job! This of course includes the GP32, too, so I strongly want this to be clear!
The opinions I expressed here are just to say that, curiously, I find that a GP32 emulator is the most pointless - so it's not something I'm doing in first person (as explained, at that point I'd prefer writing native apps).
Regards,
saimo
-
@downix
Well, if it's no effort to you, why not?
But, let me ask again, have you considered all the aspects of my architecture? (please don't take this as a hint at incompetence)
Regards,
saimo
-
@saimo
This is based on a brief glanceover. I'd be glad to look it over in more depth later on after work.
-
@downix
OK, take your time.
Thanks,
saimo
-
@ Saimo,
I dont think that it is so pointless. Its a handheld device, emulating your handheld. The point being at the moment emulators are targetted for desktops - and therefor you dont have the benefit of it being a handheld.
The GP32 if anything could serve as a development "board" to help you iron things out. And the attitude in the GP32 community is not one of "why? - thats pointless" but one of "Why not - lets do it just because we can" Some really dumb, useless things have come about - just because it could be done. Likewise some really useful things have been built just because it could be done.
If it can be done, somone will do it :-) All you need is sufficient spin to attract em :-)
-
@saimo
Using PLDs as downix suggested is as simple as defining the logic needed to decode the video output, using a language such as VHDL... Then burning the logic to the chips.
Taken from the perspective of binary data conversion, hardware is infinitely simpler to build than software, IMHO. Each chip meerly converts one set of binary data into another, and so on.
"This is what I have, this is what I need... Hey chip, this is how to change it!"
-
@Bobsonsirjonny
OK, let's try!
And, since you seem to know the GP32's scene quite well, do you think that posting a similar manifesto would be good enough?
Regards,
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
-
@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
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,
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 :-)
-
@ 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
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
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 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.
-
"Interested in this hand-held device?"
I thought someone was auctioning his penis
...
-
@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
-
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.
-
@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