English Amiga Board Amiga Lore


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 01 July 2017, 22:00   #141
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Gorf View Post
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.

Quote:
Originally Posted by Gorf View Post
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.
matthey is offline  
AdSense AdSense  
Old 01 July 2017, 22:12   #142
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 162
Quote:
Originally Posted by matthey View Post
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

Quote:
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.

Quote:
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.
Gorf is offline  
Old 02 July 2017, 02:59   #143
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 727
Quote:
Originally Posted by Gorf View Post
So how difficult would it be to adapt the apollo-core for that?
Why would you want that?
kolla is offline  
Old 02 July 2017, 03:08   #144
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 727
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.
kolla is offline  
Old 02 July 2017, 12:57   #145
E-Penguin
Banana

 
Join Date: Jul 2016
Location: Darmstadt
Posts: 287
FPGA 68k + ARM makes sense as a spiritual successor to 68k + PPC. Some kind of PowerUP style kernel for the ARM?
E-Penguin is offline  
Old 02 July 2017, 14:32   #146
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 162
Quote:
Originally Posted by kolla View Post
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.

Last edited by Gorf; 02 July 2017 at 14:59.
Gorf is offline  
Old 02 July 2017, 14:35   #147
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 162
Quote:
Originally Posted by kolla View Post
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

Last edited by Gorf; 02 July 2017 at 15:35.
Gorf is offline  
Old 02 July 2017, 14:43   #148
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 162
Quote:
Originally Posted by E-Penguin View Post
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.
Gorf is offline  
Old 02 July 2017, 15:12   #149
ptyerman
Registered User

ptyerman's Avatar
 
Join Date: Jun 2012
Location: Worksop/UK
Age: 53
Posts: 940
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.
ptyerman is offline  
Old 02 July 2017, 15:14   #150
ex68k
Registered User

 
Join Date: Jul 2017
Location: co, usa
Posts: 15
Quote:
Originally Posted by Gorf View Post
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 ;-)
ex68k is offline  
Old 02 July 2017, 15:33   #151
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 162
Quote:
Originally Posted by ex68k View Post
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.
Gorf is offline  
Old 02 July 2017, 16:01   #152
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 727
Quote:
Originally Posted by Gorf View Post
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 is offline  
Old 02 July 2017, 16:08   #153
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 727
Quote:
Originally Posted by E-Penguin View Post
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 is offline  
Old 02 July 2017, 16:11   #154
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 727
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.
kolla is offline  
Old 02 July 2017, 16:23   #155
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 162
Quote:
Originally Posted by kolla View Post
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).
Gorf is offline  
Old 02 July 2017, 16:42   #156
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 727
Quote:
Originally Posted by Gorf View Post
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.

Quote:
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.

Quote:
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
kolla is offline  
Old 02 July 2017, 16:44   #157
ex68k
Registered User

 
Join Date: Jul 2017
Location: co, usa
Posts: 15
Quote:
Originally Posted by kolla View Post
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 is offline  
Old 02 July 2017, 16:47   #158
ex68k
Registered User

 
Join Date: Jul 2017
Location: co, usa
Posts: 15
Quote:
Originally Posted by Gorf View Post
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 is offline  
Old 02 July 2017, 16:48   #159
ex68k
Registered User

 
Join Date: Jul 2017
Location: co, usa
Posts: 15
We should probably make a thread specific to the MisTer ...
ex68k is offline  
Old 02 July 2017, 16:52   #160
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 727
Quote:
Originally Posted by ex68k View Post
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.

Quote:
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.
kolla is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Vampire 1200 HanSolo support.Hardware 55 19 June 2017 10:15
Vampire x2 600 drusso66 support.Hardware 11 26 March 2017 10:18
Vampire 2 shipment 8bitbob Amiga scene 16 03 December 2016 11:30
Vampire II - Who is first? JackLeather support.Hardware 2 26 January 2016 13:56
Vampire game name Galder Looking for a game name ? 2 12 May 2014 22:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 18:38.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.37855 seconds with 12 queries