English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware

 
 
Thread Tools
Old 13 October 2020, 14:01   #201
hammer
Registered User

 
Join Date: Aug 2020
Location: Australia
Posts: 94
Quote:
Originally Posted by Chucky View Post
@hammer that there are differences doesn't mean you have taken "code" and modified it etc..
Since November 2006, Freescale released ColdFire v1 Cyclone-III open-source with "Free license" (i.e. no per use royalty) for Cyclone-III FPGA. It's expected that somebody will exploit this free license open-source project.

Where are your alternative offerings that rival AC68080's offered for sale, price point, and performance?

I don't see TG68K being offered for sale as an A1200 CPU accelerator card.



Quote:
Originally Posted by Chucky View Post
IT IS NOT IN DEVELOPMENT! yes it is a supplyissue. but IT IS STILL NOT IN DEVELOPMENT!.. the 080 is.
Your argument against Apollo's small human resource size is flawed when the larger human resourced Motorola killed 68K. "Size matters not" when you have garbage management with Motorola. NXP didn't change 68K's situation.

There's no AMD like company for 68K CPU family as a "second source" insurance.

AMD's "second source" X86 insurance policy worked when Intel attempted to dumped X86-32 with Itanium IA-64.

After buying AF2010, AF2016, AmigaOS4.1 FE, AF8, AF3.X ROM A1200, two KS314 A500/A1200 AmigaOS packages, I'm not interested in AROS fork aka ApolloOS or CoffinOS i.e. I have enough AmigaOS 3.x licenses that almost rivals my Windows 10 licenses (recycled from existing Windows 7/8/8.1 product keys). There's a high probability, I have to pay for yet another AmigaOS4.1 license for Amiga A1222 Tabor motherboard (assuming the price is at resonable level).

Last edited by hammer; 13 October 2020 at 15:35.
hammer is offline  
Old 13 October 2020, 14:28   #202
hammer
Registered User

 
Join Date: Aug 2020
Location: Australia
Posts: 94
Quote:
Originally Posted by Chucky View Post
Or the simple thing that it is all about preservation. so "new stuff" is simply not of interest. just look at it. there is hardly software out that used the full 060 potential. full RTG potential. or the PPC that we had since the 90s.

we do not have a decent email client, decent ftp client. browser.. ok a browser would be hard for any 68k to really handle in any modern form. but ftp client.. or mail? still nothing.

it simply isn't about making stuff for the future.. it is all about preservation.
when we die off the amiga will die with it
Well, A500/A1200 price segment wasn't replaced in NG Amigas and SAM440/460 was comically obsolete. The mainstream gaming market tolerated PS4's 8 mediocre 1.6Ghz Jaguar CPU cores which includes two 128bit SIMD units per CPU core.

Last edited by hammer; 13 October 2020 at 14:45.
hammer is offline  
Old 13 October 2020, 14:47   #203
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Posts: 1,503
Can't we just agree that it is what it is? The Vampire seems to sell pretty well, relatively speaking, so ultimately it's a success. There will always be people that expected it to be something else (me included), and that happens with all kinds of projects. I think crying about it for several forum thread pages is not going to change anything...

Also regarding making an accurate 060 FPGA core, that would most likely require some very smart clean room design? If it has to be spot on, it would maybe be hard to avoid infringing any potential patents and copyrights? Just a thought, I might be wrong here.
8bitbubsy is offline  
Old 13 October 2020, 15:01   #204
hammer
Registered User

 
Join Date: Aug 2020
Location: Australia
Posts: 94
Quote:
Originally Posted by 8bitbubsy View Post
Can't we just agree that it is what it is? The Vampire seems to sell pretty well, relatively speaking, so ultimately it's a success. There will always be people that expected it to be something else (me included), and that happens with all kinds of projects. I think crying about it for several forum thread pages is not going to change anything...

Also regarding making an accurate 060 FPGA core, that would most likely require some very smart clean room design? If it has to be spot on, it would maybe be hard to avoid infringing any potential patents and copyrights? Just a thought, I might be wrong here.
Patents for 486 and classic Pentium have expired which is the same for classic Pentium era 68060.
hammer is offline  
Old 13 October 2020, 15:13   #205
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Posts: 1,503
Cool. Then I think it would make more sense to try to gather a small team to make an accurate 060 FPGA core, or at least give it a try. I know this is a very big and difficult project, but a lot is possible if you just have the motivation, time and knowledge, and with the help of other people. I'm obviously not going to try though, but maybe Chucky would be interested in making this happen in the future? Just imagine it, finally one could make a cheaper 060 accelerator without the need to source those expensive and getting-hard-to-find 060 CPUs.
8bitbubsy is offline  
Old 13 October 2020, 15:26   #206
hammer
Registered User

 
Join Date: Aug 2020
Location: Australia
Posts: 94
Quote:
Originally Posted by 8bitbubsy View Post
Cool. Then I think it would make more sense to try to gather a small team to make an accurate 060 FPGA core, or at least give it a try. I know this is a very big and difficult project, but a lot is possible if you just have the motivation, time and knowledge, and with the help of other people. I'm obviously not going to try though, but maybe Chucky would be interested in making this happen in the future? Just imagine it, finally one could make a cheaper 060 accelerator without the need to source those expensive and getting-hard-to-find 060 CPUs.
68K needs an "AMD" like cloner company as insurance against stupid Motorola/Freescale/NXP.

In the social media space, somebody is talking about using FPGA to patch Cold Fire V4's 68K instruction set issues i.e. using FPGA as a hardware-accelerated 68K instruction set decoder to feed into ColdFire V4.

In mainstream game consoles, XBO has DX12 micro-coding engine to decode DX12 calls and feed GCN instructions to GCN GPU.

Atm, AC68080 is a reasonable selection for my A1200.

Last edited by hammer; 13 October 2020 at 15:31.
hammer is offline  
Old 13 October 2020, 15:40   #207
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 922
Quote:
Originally Posted by hammer View Post
Patents for 486 and classic Pentium have expired which is the same for classic Pentium era 68060.
Yes, but copyrights haven't. A closely reengineered 060 would probably be found to infringe the copyrights on the original schematics.
grond is offline  
Old 13 October 2020, 15:48   #208
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 922
Quote:
Originally Posted by hammer View Post
In the social media space, somebody is talking about using FPGA to patch Cold Fire V4's 68K instruction set issues i.e. using FPGA as a hardware-accelerated 68K instruction set decoder to feed into ColdFire V4.
Well, social media... Since e.g. all 68k operations operating on 16bit data would require ColdFire emulation code (ColdFire does not support 16 bit data), a single such 68k operation would require several ColdFire instructions to emulate the 68k instruction. How are you going to fit them into loops without having to recalculate branch target addresses all the time? Are you going to work completely without caches? How are you going to deal with the fact that the CodFire emulation code will almost certainly need to operate on additional registers? Are you going to push/pop those registers all the time? ColdFire is rather weak even when comparing a ColdFire ASIC to the softcore 080, such an FPGA-transcoder would be very difficult to implement and the resultant speed would suck.
grond is offline  
Old 13 October 2020, 15:56   #209
Chucky
Registered User

Chucky's Avatar
 
Join Date: Mar 2015
Location: Karlstad / Sweden
Age: 49
Posts: 918
Quote:
Originally Posted by 8bitbubsy View Post
but maybe Chucky would be interested in making this happen in the future? Just imagine it, finally one could make a cheaper 060 accelerator without the need to source those expensive and getting-hard-to-find 060 CPUs.
I am not a FPGA person. I would love to be involved however
Chucky is offline  
Old 13 October 2020, 16:00   #210
hammer
Registered User

 
Join Date: Aug 2020
Location: Australia
Posts: 94
Quote:
Originally Posted by grond View Post
Well, social media... Since e.g. all 68k operations operating on 16bit data would require ColdFire emulation code (ColdFire does not support 16 bit data), a single such 68k operation would require several ColdFire instructions to emulate the 68k instruction. How are you going to fit them into loops without having to recalculate branch target addresses all the time? Are you going to work completely without caches? How are you going to deal with the fact that the CodFire emulation code will almost certainly need to operate on additional registers? Are you going to push/pop those registers all the time? ColdFire is rather weak even when comparing a ColdFire ASIC to the softcore 080, such an FPGA-transcoder would be very difficult to implement and the resultant speed would suck.
Note that ColdFire V4 is only available in ASIC.

I was talking about ColdFire 4V ASIC with FPGA front end decoder. FPGA front end decoder should include other front end hardware.

Also, CF68KLib runs on Version 3 and later ColdFire cores only.

Last edited by hammer; 13 October 2020 at 16:05.
hammer is offline  
Old 13 October 2020, 16:05   #211
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 922
Quote:
Originally Posted by hammer View Post
I was talking about ColdFire 4V ASIC with FPGA front end decoder.
And so did I. Not feasible and slow.
grond is offline  
Old 13 October 2020, 16:06   #212
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Posts: 1,503
Quote:
Originally Posted by hammer View Post
[...]

Atm, AC68080 is a reasonable selection for my A1200.
What's AC68060? Can't seem to find anything about it on Google...
8bitbubsy is offline  
Old 13 October 2020, 16:10   #213
demolition
Unregistered User
demolition's Avatar
 
Join Date: Sep 2012
Location: Copenhagen / DK
Age: 40
Posts: 4,144
Quote:
Originally Posted by 8bitbubsy View Post
What's AC68060? Can't seem to find anything about it on Google...
Apollo Core 68080?
demolition is offline  
Old 13 October 2020, 16:11   #214
hammer
Registered User

 
Join Date: Aug 2020
Location: Australia
Posts: 94
Quote:
Originally Posted by 8bitbubsy View Post
What's AC68060? Can't seem to find anything about it on Google...
Try "AC68080" instead of AC68060.
hammer is offline  
Old 13 October 2020, 16:16   #215
hammer
Registered User

 
Join Date: Aug 2020
Location: Australia
Posts: 94
Quote:
Originally Posted by grond View Post
And so did I. Not feasible and slow.
I'm already aware that any external chips outside the CPU package will have a large performance penalty.
hammer is offline  
Old 13 October 2020, 16:27   #216
Promilus
Registered User

 
Join Date: Sep 2013
Location: Poland
Posts: 111
Quote:
Originally Posted by hammer View Post
For the classic Amiga, SATA is nearly pointless
Well then why fast PIO isn't pointless but slow SATA is? when you can use inexpensive SATA SSD but on amiga you must use sata2ide converter. If you don't know there's LiteSATA FPGA implementation which is OpenSource. All you have to do is implement it and write a driver for AOS. Yes, speed might still be somewhat limited but... that'd be "native controller" and most likely way faster than PIO IDE anyway. So if that's pointless then AMMX, 64bit etc. etc. is pretty much useless as well.
Quote:
I do have Wicher 508i 68000 at 50Mhz for A500 Rev 6A and it's IDE controller is below the double digits MB/s results. My 16GB CF card is rated at 100MB/s
Well, well, and what exactly does it have to do with anything? Except Amiga IDE speed is roughly the same sh*t it was during 040 era with FastATA MKII? Isn't there a room for improvement? Yes there is, but somehow there's focus on faster CPU core which is pretty much just as useful/useless.

Quote:
Designing a high-performance northbridge is not easy. Go ask Mai chipset vendor. LOL
Yup, yup... and that's why there are so many OS projects using OS libs with decent speed. Because you OBVIOUSLT CAN'T do that... Tell that to all those which made it work.

Quote:
Your 2048bit SIMD SVE argument is the real out of context when it's vaporware BS.
Your argument with SSE2/AVX/AVX2 being related to how big game world can be is real BS. I just pointed out it SIMD has nothing to do with addressing and SIMD can be as wide as you want it. Also - SVE is pretty new to ARM and it is basically smarter AVX - it isn't limited to one implementation. You don't need new instructions and new libraries if someone implements wider than 512bit SVE. But you do if you wrote app for SSE2 then wanted to use AVX2 and in the end tried to implement on AVX512.

Quote:
You claimed 64bits is not mainstream when mainstream game consoles exceeded 32bit pointers and 32bit AGUs. Mainstream PCs have 64bit GPRs/64bit ALUs equiped CPUs, 64bit Windows 10, and beyond 4GB memory address range.
I did not say such a thing. I only said full 64bit architecture wasn't necessary at that time (or even now). And fyi 64bit cpus are in game consoles from a pretty long time. Both Xbox360 and PS3 had 64bit PowerPC, Playstation 2 had 64bit MIPS based CPU. But all of those were lacking in operational memory... but that wasn't a problem at that time. I'm pretty sure I wrote 64bit makes things easier but aren't required to make it possible. Nothing more, nothing less.

Quote:
There's a difference between the logical memory address and the physical memory address. 64bit pointer/64bit ALU capability influences the programming model and it's being ready for future physical memory storage expansion.
Both yes and no, as I already proved with both 8 and 16bit designs which have 8bit ALU and 16bit physical address space or 16bit ALU and 24 bit address space respectively. Using the same mechanism you can have 32bit ALU and address space as big as you like.

Quote:
There's a difference between the logical memory address and the physical memory address. Your 36-bit PAE with 32bit pointers argument has performance penalties and has a crap programming model!
Well it did work with many applications (especially engineering and server) regardless of how crappy you claim it to be.
Quote:
X64 has (blablabla)

68000 has (blablabla)

The full 68020 carried (blablabla)
What it has to do with anything?
Quote:
You're a hypocrite. thrashbin yourself.
Yeah, that's from mouth of someone who claimed SSE2/AVX/AVX2 is a basis for big console worlds above 4GB of RAM ...
let's replay that, ok?
Quote:
PC's SSE2/AVX/AVX2 hardware has support for full-speed/double speed/quad speed SIMD INT64 and FP64 to support very large scale game worlds that exceed 4GB ram
Which is obviously a pretty blatant lie or just lack of understanding what SIMD exactly does in CPU and how it's implemented. FYI 128bit SIMD already worked on 32bit CPUs (Athlon, Pentium III).

Quote:
FYI, Intel’s E6x5C series Atom processor includes an FPGA in the same package as the processor since November 2010. LOL. Baka.
For your information when I say HPS I mean HPS. That's tightly integrated to FPGA CPU core. That atom you mentioned only has FPGA communicating through PCIe with it but still has his own pcie controller, memory controller etc. etc. It's not integrated at all. It's only in the same package. If you mix those 2 you're clueless!

Quote:
The fact remains AC68080's AMMX was lifted from X86 world and it's being offered for sale without the crazy 68060 accelerator prices.
Well 1st thing - it's pretty obsolete for quite some time in x86 world
2nd - it wasn't used very long, was pretty much obsolete every since SSE became dominant standard
3rd - at the time MMX was popular open source movement wasn't (so not so great code base anyway)
4th - despite using same or similar mnemonics you can't just take a code from x86+mmx intrinsinc and run it without modification, and if you have to dig into it and change e.g. register names it makes this pretty awful. If you use specific compiler options to translate loops with vector ops to AMMX - you could've make whatever SIMD implementation you'd like, not only mmx inspired.
Promilus is offline  
Old 13 October 2020, 16:41   #217
kipper2k
Registered User

 
Join Date: Sep 2006
Location: Thunder Bay, Canada
Posts: 4,085
So it is decided, we all buy a Pi4, save lots of money, get awesome speed and compatibility. Please close the thread as it spirals deeper into non relevent anarchy
kipper2k is offline  
Old 13 October 2020, 16:45   #218
dreadnought
Registered User
 
Join Date: Dec 2019
Location: Ur, Atlantis
Posts: 719
As soon as you do that, another will appear. Didn't this one start when the old one was still buzzing? Not sure, they all look the same to me
dreadnought is offline  
Old 13 October 2020, 18:12   #219
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Posts: 1,503
Quote:
Originally Posted by hammer View Post
Try "AC68080" instead of AC68060.
Ouch. I should read more closely next time.
8bitbubsy is offline  
Old 13 October 2020, 22:01   #220
Pyromania
Moderator

Pyromania's Avatar
 
Join Date: Jan 2002
Location: Chicago, IL
Posts: 2,559
I like the 68090 myself.
Pyromania is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Monkey Island 1 & 2 versions comparisons Hewitson Retrogaming General Discussion 64 25 October 2018 11:57
APOLLO CORE 68080 emulation in WinUAE ? biozzz support.WinUAE 10 29 June 2018 14:22
68080 CPU on WinUAE AMIGASYSTEM support.WinUAE 6 04 April 2017 19:51
vasm with Apollo Core 68080 and AMMX support phx News 11 18 February 2017 00:22
aca620 board pic, comparisons needed kipper2k Hardware pics 23 24 April 2013 19:51

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 06:54.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.10705 seconds with 16 queries