vampire V2 - what should i be using it for...?

[matthey]

Originally Posted by Gorf

I am not sure about the display - writing to a linux frame buffer would eat up quite some bandwidth and performance I guess - so that should be native a soon a possible.

It may be possible to drive a DVI/HDMI display with some expansion I/O pins connected directly to the FPGA as the Vampire SAGA does.

Originally Posted by Gorf

Sure - I am all in for a larger an faster FPGA, but available boards are much more expensive as soon as you go for something bigger.
Not sure how many people are willing to spend 1500€ or more.

The 110k LE Cyclone V is already much bigger than the 40k LE Vampire Cyclone III (those LEs may go further with other resources built into the Cyclone V). I expect it would be big enough for dual core, 68k compatible FPU, virtual MMU, (maybe even integer 128 bit SIMD unit) and of course enhanced Amiga custom chips.

I want to talk to MikeJ before making any moves. I would like to hear what the big project of A-EON/Hyperion/iComp is first and find out if Cloanto is serious about moving toward an open source AmigaOS. AROS certainly has advantages, especially with multi-core support, but AmigaOS is more efficient, more compatible and smaller.

[Gorf]

Originally Posted by matthey

It may be possible to drive a DVI/HDMI display with some expansion I/O pins connected directly to the FPGA as the Vampire SAGA does.

my proposed board has plenty of I/O pins.
but it would be some wasting of the already integrated HDMI port....
Ok - let's go for a dual monitor setup

The 110k LE Cyclone V is already much bigger than the 40k LE Vampire Cyclone III (those LEs may go further with other resources built into the Cyclone V). I expect it would be big enough for dual core, 68k compatible FPU, virtual MMU, (maybe even integer 128 bit SIMD unit) and of course enhanced Amiga custom chips.

that was also my guesstimation.

I want to talk to MikeJ before making any moves. I would like to hear what the big project of A-EON/Hyperion/iComp is first and find out if Cloanto is serious about moving toward an open source AmigaOS. AROS certainly has advantages, especially with multi-core support, but AmigaOS is more efficient, more compatible and smaller.

I would even throw in some money if Cloanto is really into finally open-sourcing it. I probably should not say this, so now they will demand more ... well I said it.

[kolla]

Originally Posted by Gorf

So how difficult would it be to adapt the apollo-core for that?

Why would you want that?

[kolla]

Gorf, are you Sorgelig?

https://github.com/MiSTer-devel/Main_MiSTer/wiki

http://www.atari-forum.com/viewtopic...e65b0bb13b5a9e

EDIT: I guess not, based on your location.

[E-Penguin]

FPGA 68k + ARM makes sense as a spiritual successor to 68k + PPC. Some kind of PowerUP style kernel for the ARM?

[Gorf]

Originally Posted by kolla

Why would you want that?

Why would anyone want a standalone vampire? Same reason.
For me:
My real 68k Amigas are getting old, have no hdmi, are big and noisy.

UAE is nice, but does not "feel" right sometimes. And I love to have a dedicated computer for AOS. UAE4ARM should be slower than Apollo on that FPGA.

[Gorf]

Originally Posted by kolla

Gorf, are you Sorgelig?

https://github.com/MiSTer-devel/Main_MiSTer/wiki

http://www.atari-forum.com/viewtopic...e65b0bb13b5a9e

EDIT: I guess not, based on your location.

Wow - i honestely did not know about that project.
But it shows that my ideas work

[Gorf]

Originally Posted by E-Penguin

FPGA 68k + ARM makes sense as a spiritual successor to 68k + PPC. Some kind of PowerUP style kernel for the ARM?

A linux kernel would run there as a "universal driver", but than you can e.g. run AROS-hosted on the ARM side. Via "Sunaj" (a reverse-JanusUAE) you could start ArosARM Apps from within the 68k-side.

[ptyerman]

At last, some sensible conversation going on instead of the constant bickering, arguing and bitching. I stopped visiting for a while because of it.
If someone built and sold what is been proposed here I would definitely have one, I have no interest in the Vampire at all since it's become clear there's not going to be a 68k compatible MMU and FPU.
I didn't know about the MISTer project either, sounds awesome. Lets hope someone builds and sells them.

[ex68k]

Originally Posted by Gorf

A linux kernel would run there as a "universal driver", but than you can e.g. run AROS-hosted on the ARM side. Via "Sunaj" (a reverse-JanusUAE) you could start ArosARM Apps from within the 68k-side.

Just use the linux you got working already on it, an focus on the amiga emulation. There is enough to work on ;-)

[Gorf]

Originally Posted by ex68k

Just use the linux you got working already on it, an focus on the amiga emulation. There is enough to work on ;-)

That is exactly what I meant. You use the linux-kernel, that has already got drivers for this board and you try to make a much use of it as possible.
(a possible AROS-hosted would simply run onto of this kernel)

That way the 68K side is free of some tasks (eg driving usb-ports) and just lets the linux-slave do the nasty work.

[kolla]

Originally Posted by Gorf

That is exactly what I meant. You use the linux-kernel, that has already got drivers for this board and you try to make a much use of it as possible.
(a possible AROS-hosted would simply run onto of this kernel)

That way the 68K side is free of some tasks (eg driving usb-ports) and just lets the linux-slave do the nasty work.

The idea here is to let the ARM also emulate the 68k chip, since that is a problem already solved, it does not require any licensing etc. - plus it lets the user pick whatever 68k CPU configuration he/she wants/needs - better for compatibility. So, all legacy chipset stuff on the FPGA (with its own SDRAM - aka chipmem), CPU and all "modern" stuff on the ARM (with its own 1GB DDR3 - aka fastram).

[kolla]

Originally Posted by E-Penguin

FPGA 68k + ARM makes sense as a spiritual successor to 68k + PPC. Some kind of PowerUP style kernel for the ARM?

That would require the ARM running in big-endian mode that is compatible with 68k.

[kolla]

Btw - MikeJ is working on using Raspberry Pi compute module as accelerator for the FPGA Archade, which would be very similar to the MiSTer in many respects.

[Gorf]

Originally Posted by kolla

The idea here is to let the ARM also emulate the 68k chip, since that is a problem already solved, it does not require any licensing etc. - plus it lets the user pick whatever 68k CPU configuration he/she wants/needs - better for compatibility. So, all legacy chipset stuff on the FPGA (with its own SDRAM - aka chipmem), CPU and all "modern" stuff on the ARM (with its own 1GB DDR3 - aka fastram).

Since Apollo runs already (supposedly) on high-end FPGA boards it should by able to make use of DDR3 on its own.
So that is were my idea differs from MISTer.
When using emulation od 68K on ARM, you need to go JIT to get good speed, but that is one of the reasons UAE does not "feel" right sometimes, because JIT gives you sometimes very high speed and sometimes not.

On a CycloneV a core like Apollo should outrun a 68k_on_ARM-JIT most of the time. (One could even run both on this board next to each other and see what is faster )

Running in parallel to the ARM would also keep the ARM-side free for things like mp3-decoding (use it as a sound card) or video-decoding. Without slowing down the 68k (except for memory access).

[kolla]

Originally Posted by Gorf

When using emulation od 68K on ARM, you need to go JIT to get good speed, but that is one of the reasons UAE does not "feel" right sometimes, because JIT gives you sometimes very high speed and sometimes not.

The main reason UAE does not "feel right" has little to do with CPU emulation, and a whole lot to do with chipset emulation, and most of all - a whole lot to do with the emulator dealing with both CPU and chipset at once, in a serial sequence, and that there typically is an host operating system that also require CPU cycles. The idea with MiSTer is to offload all chipset emulation to FPGA and let the ARM only deal with 68k emulation and various (modern) I/O.

Speaking of something that gives you very high speed sometimes and other times not - Apollo Core is just like that.

On a CycloneV a core like Apollo should outrun a 68k_on_ARM-JIT most of the time. (One could even run both on this board next to each other and see what is faster )

Sure, or pick whichever fits the software best, I have loads of software that most likely never will run well on Apollo Core.

Running in parallel to the ARM would also keep the ARM-side free for things like mp3-decoding (use it as a sound card) or video-decoding. Without slowing down the 68k (except for memory access).

The ARM has two cores available

[ex68k]

Originally Posted by kolla

The idea here is to let the ARM also emulate the 68k chip, since that is a problem already solved, it does not require any licensing etc. - plus it lets the user pick whatever 68k CPU configuration he/she wants/needs - better for compatibility. So, all legacy chipset stuff on the FPGA (with its own SDRAM - aka chipmem), CPU and all "modern" stuff on the ARM (with its own 1GB DDR3 - aka fastram).

Then just get a RasPi, and leave this poor FPGA alone ;-)

ARm is nice for all the stupid work, like reading/writing sd-cards, usb sticks etc. Gives you nice Ethernet ...

But the FPGA should do the CPU emulation and all the special chips ...

[ex68k]

Originally Posted by Gorf

On a CycloneV a core like Apollo should outrun a 68k_on_ARM-JIT most of the time. (One could even run both on this board next to each other and see what is faster )

Not really spending to much time on it, but an 800MHz ARM should be much slower than a 200MHz Apollo Core, if it really runs 1 OP per clock.

[ex68k]

We should probably make a thread specific to the MisTer ...

[kolla]

Originally Posted by ex68k

Then just get a RasPi, and leave this poor FPGA alone ;-)

No, emulating the chipset is hard stuff, depending on what the software tries to accomplish with the chipset, it can take a lot of resources. Unlike CPU usage that is quite predictable.

ARm is nice for all the stupid work, like reading/writing sd-cards, usb sticks etc. Gives you nice Ethernet ...

But the FPGA should do the CPU emulation and all the special chips ...

The question should be - is it the FPGA or the ARM CPU that has direct access to the DDR3 RAM? There is where the CPU should ideally be.