MiniMig with AGA

[bloodline]

Palm wrote:
Has anyone a good technical answer to this:

As the MinMig works great as a A500, is it possible to do the same to the A1200 ? Or is the A1200 so much more complex than the A500, that making it in a FPGA is virtually impossible ?

Just wondering :-)


Espen

The MiniMig has a 68000, AGA needs 68020 minimum... Can you even buy 020s cheap anymore?

The minimig has 12bit video out put... AGA needs 24bit... Should be as simple as adding a few more resistors to the DACs, I think there is enough IO left on the FPGA.

AGA is poorly documented... Bug fixing would be a pain... But I expect there is probably still enough room left on the FPGA (AGA was a very limited upgrade from ECS)... I don't know how much is used right now?

[bloodline]

Denis stated very clearly on these very forums that MiniMig was never intended to be anything more than an Amiga500 clone. That is the Amiga he had and wanted to emulate using an FPGA. A quick look at the hardware shows that the design had always intended 12bit gfx and a 68000, both unable to support AGA.

[bloodline]

More curriosity than anything, I wonder if productivity apps benefit.
One could build a 68k computer with chunky graphics instead.

Productivity apps? Just run UAE/WinUAE

[bloodline]

Why not expose the new chunky "AGA++"/AAA modes via a P96 driver?

The biggest difficulty with adding chunky modes (or a chunky P96 compatible video card alongside the AGA functionality) is that it isn't just the video output circuitry that needs to support chunky, the blitter and other features also need to support it - possibly including chunky-planar conversions.

The biggest advantage on a modern design is RAM quantity and speed. Hopefully this will be quite nice on this card, so 256-colour AGA will work nicely without slowing down the rest of the system... :p

If youvare going to use a P96 driver, why not use a nice modern chip from ATI or Nvidia? It will be cheaper and more powerful than any FPGA solution.

[bloodline]

I'm not sure I have any SVideo or Composite compatible display devices any more... Hmmm, I might have an SVideo/Composite to Scart adaptor

Just stick with VGA/DVI IMHO

[bloodline]

I was thinking how the main board can communicate with the outside world. There's a debug serial port over which we could run PPP or SLIP, or we could use the ARM with its USB port to emulate a high-speed serial-over-usb link.

Secondly, i've been studying the schematics and I don't see any issues with plugging amiga mice into the joystick ports - the h/v pulse lines all go straight into the FPGA, and all three mouse buttons are accounted for.

However I think the ports will be only wired up to 3.3v according to the schematic.

Will this be a problem for autofire joysticks? Do they expect 5v for their electronics ?

From the joysticks I've dismantled in my time autofire simply closed the joy button circuit... No special electronics at all.

[bloodline]

Boards are on the delivery truck according to tracking

Just in time for the new 68k build of AROS!

[bloodline]

I'm seriously considering getting one of these to hack AROS 68k on.

http://acp.atari.org

I've looked at these before. The Coldfire is a really bad fit for Amiga... Ok we can now build AROS for the coldfire, so we can get AmigaOS functionality, but that doesn't magically make Amiga programs coldfire capable... There is a really good link on the Coldire wiki page that lists the differences between the coldfire and the 68k... It's pretty horrific... Coldfire software should run on a 68k, the reverse isn't true

[bloodline]

68K compatibility on coldfire has improved in more recent cores, but you are still left with trap-and-emulate for various operations. Not sure what happened to those instructions where they were implemented but with different behaviour to the 68K; they were the real killer.

Sadly the mul instruction is still not 68k compatible... How can you trap that?

[bloodline]

PS/2 connectors... awww crap... I think I threw away all my old PS/2 keyboards and mice... I thought USB would see me through at least there is a DVI connector (I only have DVI monitors here now...)

[bloodline]

Only schematics available.

Page 2, are the ARM's ADC inputs just tied to the ground? Why not use them for audio sampling?

[bloodline]

Just a small update. The CPU core is still clocked at 28 MHz but this time with two separate 256-byte instruction and data caches.

Your work has piqued my interest with hardware description languages... Though I don't think I will be able to get my head around it, I'll stick with microcntrollers and software

[bloodline]

Clock for clock, that makes your implementation about twice as fast as a real 68020/68030

Nice work!

A guy in his bedroom makes a CPU better than Motorola's entire CPU dev team could make in the 80's... makes you think...

[bloodline]

I was thinking I should learn VHDL or Verilog or something too. When you think of all those "I wish I had XYZ for my old machine" moments...

I just don't think I could grasp it... I'll have to look at some example code and see how it map to hardware... but I can't do stuff like this without a strong visualization of what is really happening.

-edit- What does this project use? VHDL or Verilog?

Already I'm lost:

[bloodline]

Looks a bit like ADA

Apparently that's what it was based on :-/ I've been looking over various VHDL tutorials for the last 15min and nothing is grabbing me... I think I'm just so ¨C¨ ingrained now... I can basically make sense of the listings, but I can't visualize it