Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Topic started by: polyp2000 on September 06, 2013, 06:59:55 PM
-
I dont have a 600 (only a500 & a1200) -- but i cannot wait to see what happens
now these are about to get in the hands of people!
http://www.majsta.com/modules.php?name=News&file=article&sid=68
N...
-
I dont have a 600 (only a500 & a1200) -- but i cannot wait to see what happens now these are about to get in the hands of people!
They will be in the hands of developers. It's not much different to many of the fpgaArcade boards going to developers and testers. The time and cost to solder and test the boards is disappointing. It seems that the Vampire and fpgaArcade are both having problems in this regard.
-
They will be in the hands of developers. It's not much different to many of the fpgaArcade boards going to developers and testers. The time and cost to solder and test the boards is disappointing. It seems that the Vampire and fpgaArcade are both having problems in this regard.
As far as I know anyone can order a board, not just developers. Looking forward to see first user tests.
-
Great news, wonder where on the list I am to receive one :) I cant wait to play with one!
-
Hi :)
If we are lucky nothing will work :)
-
As far as I know anyone can order a board, not just developers. Looking forward to see first user tests.
True. The regular orders shouldn't be too far behind but the people at the end of the list will probably have to wait a bit.
-
They will be in the hands of developers. It's not much different to many of the fpgaArcade boards going to developers and testers. The time and cost to solder and test the boards is disappointing. It seems that the Vampire and fpgaArcade are both having problems in this regard.
Speaking about the FPGAArcade Replay board ...
While this is true - the first 50 of the production batch I had to hand solder all the connectors (and it takes ages), I'm past that now. The next batch of 100 game fully assembled, but had some component issues which needed to be replaced.
Now the test rigs and software are set up they can test at the factory, so the next 200 will arrive ready to ship. Well, that's the theory at least..
/MikeJ
-
Speaking about the FPGAArcade Replay board ...
While this is true - the first 50 of the production batch I had to hand solder all the connectors (and it takes ages), I'm past that now. The next batch of 100 game fully assembled, but had some component issues which needed to be replaced.
Now the test rigs and software are set up they can test at the factory, so the next 200 will arrive ready to ship. Well, that's the theory at least..
/MikeJ
Nice to know Mike.
Personally, emulating the chipset along with the processor makes more sense to me.
After all, with just a processor replacement were stuck retrofitting old hardware and can't improve on chipset performance.
Although the soldering demo on the Vampire site is pretty neat.
I may have to try that technique.
-
Got one for me? :D
-
The time and cost to solder and test the boards is disappointing.
Do you know that today majsta has told that Kipper2k will also mount them? http://eab.abime.net/hardware-mods/59629-first-amiga-600-fpga-accelerator-23.html
-
@Iggy (http://www.amiga.org/forums/member.php?u=6738)like I said before that soldering technique is so controversial and I suspected that people will start talking about that on forums. But, for the devices that are not made for human soldering is is the only fast and safe way. After following everything showed on video please use flux and wick with soldering iron and after that use hot air to remove any resin or bad solder joints. Final result is much like professional soldering done by machine and everyone will notice that when they receive their boards. There are also other solutions for soldering QFP FPGA device but this one gives me best results. It is easier to solder BGA than QFP package. For BGA you only need proper alignment, flux and oven.
For those who didn't see this here is a video.
http://www.youtube.com/watch?v=gmlWlGiPaog
-
http://www.youtube.com/watchv=gmlWlGiPaog
Yes, very cool.
And if you don't have the equipment for BGAs, its useful.
Thanks.
-
...I dont want one anymore after seeing that video...
I work in electronics assembly, and we often do hand soldered prototypes, and there's no way we'd do something as thermally stressful as that!
-
I have to say that I like more Kipper2K's way:
http://kipper2k.com/soldertut/soldertut.html
But I also think that a thing is to develope something so complicated and another your skills or just the way you choose for soldering....
And anyway the boards are fully tested after that.
-
@Iggy (http://www.amiga.org/forums/member.php?u=6738)like I said before that soldering technique is so controversial and I suspected that people will start talking about that on forums. But, for the devices that are not made for human soldering is is the only fast and safe way.
What would worry me is the fact no anti-static precautions are being taken.
Masking tape! At least get an anti-static mat.
The more normal way to do prototype production is to get a stencil made (30-40 USD laser cut). You can actually get standard stencils for tqfps etc.
Squeeze solder paste through, pop the chip on and heat with a reflow gun.
You get perfect results and no bent pins.
/MikeJ
-
Static is a good point too... but looking at the way it was soldered, I doubt he'd be too worried about that... lol
Static, and heat damage are not immediately evident, the item may work, it might work for weeks, even months or years, and then one day, it just stops working for no apparent reason...
I am a bit confused about how he considers this to be "the only fast and safe way" I can't think of a less safe method!
-
What can I say than there is no single problem is soldering like this. FPGA is not overheated and soldering job looks like machine did it. If someone decide to cancel pre-order less work for me and more regret for someone later :) To tell you the truth I m not so happy because so much orders. I have boards soldered like this for testing purpose who are in working order for past 2 years. Basically this type of FPGA is hard to destroy if he can be detected with JTAG connection it works. After soldering detailed testing procedure taking place in 3 stages. One for testing signals from original CPU just like regular Logic Analyzer, one for testing Amiga bus with fake CPU, more complex one have 3 CPU's inside for testing memory with LFSR.
-
There is no problem soldering like this (soldering along the pins and then wicking it up), I've done it plenty of times and if you use a 15w heat source, you aren't going to damage anything.
This is a perfectly good way to do a short run of SMT boards. I've done it myself, never had a problem with it. Continue on.
-
So anyone care to explain what a Vampire board does?
-
So anyone care to explain what a Vampire board does?
It's an FPGA based accelerator for A600's. It can 'impersonate' either an 68000 or 68020.
-
So anyone care to explain what a Vampire board does?
http://www.majsta.com/
-
http://www.majsta.com/
I'm hoping hooking up with Apollo doesn't derail it.
From Apollo-core.com "Fully User-Code Compatible with MC68000"
Sounds good, but hidden behind that lies the answer to "so what is it incompatible with?"
-
all fine and well. its really exciting news. but with fpga softcores in mind what about fpu?
-
Is Apollo core linked to the natami team?
-
there is no natami team as such for what i know. apollo is a softcore by former natami contributors, gunnar in particular. i dont know who else.
-
We can say that Apollo was build from the knowledge learned in Natami project. Also FPU is done long time ago but I m not so shore will it fit in Vampire 600 board but for other Amigas we will have it for shore. My goal is that we have basic version for A600 because lack of AGA. Maybe there will be some coldfire instructions also but in month or two we will know where we stand.
-
@majsta
i think for starters and for a600 in particular a limited softcore without fpu is enough. good news though that the apollo features fpu. im not sure what would be the gain of adding coldfire instructions. are there any vector instructions or what? by all means do not create another incompatible target software would have to be compiled for. the different versions for different 68k cpus are already annoyance enough. we need unity and common goals, not another split.
-
i think for starters and for a600 in particular a limited softcore without fpu is enough. good news though that the apollo features fpu.
The current FPU is sparse like the ColdFire FPU but with fp immediates and maybe pre-decrement and post-increment for FMOVEM. I would like to see a more robust and 68k compatible FPU. Some think an SIMD will replace the FPU as happened with the x86/x64. Some of that happened because of limitations of the x86 FPU and it's sharing of the registers with the SIMD. In our case, the FPU is needed to do the more common double precision operations that compilers need as an SIMD would be single precision float only.
are there any vector instructions or what?
There is an SIMD unit but it's also not complete.
im not sure what would be the gain of adding coldfire instructions. by all means do not create another incompatible target software would have to be compiled for. the different versions for different 68k cpus are already annoyance enough. we need unity and common goals, not another split.
The ColdFire and other CPU enhancements are mostly aimed at improving code density and modernizing functionality. Defining a new ISA also allows some old instructions and addressing modes that slow a modern CPU to be deprecated so slow CPU traps/exceptions are avoided in new code. The 68000 or 68020 would still be a compatible base and the more common compiler target. There isn't much point in the mini-Apollo (Phoenix) CPU having CF instructions as there will be no ISA to support them but they are practically free. Maybe some support code will be able to make use of them.
Majsta's future hardware creations (probably for AGA) will likely have a significantly larger fpga. It's a tight squeeze fitting a fully pipelined CPU with caches into a Cyclone 2. A larger fpga would allow for a much more powerful CPU with FPU and SIMD.
-
Maybe there will be some coldfire instructions also but in month or two we will know where we stand.
I'd rather have full 68060 compatibility (supervisor/user/mmu/fpu) even if that is less efficient. I'm assuming this isn't going to be open source so that someone else could adapt it to fit this requirement?
-
I'm hoping hooking up with Apollo doesn't derail it.
From Apollo-core.com "Fully User-Code Compatible with MC68000"
Sounds good, but hidden behind that lies the answer to "so what is it incompatible with?"
I wouldn't buy a Vampire A600 based upon future cores, especially one promising the world. On the other hand, I wish them the best of luck in their cut-down Phoenix core for the Vampire A600 - a 100 MIPS 68k A600 would be devastating.
But it is working currently with TG68K at a few MIPS, possibly even over 10 eventually. So buy it if that is good enough for you now.
-
I'd rather have full 68060 compatibility (supervisor/user/mmu/fpu) even if that is less efficient. I'm assuming this isn't going to be open source so that someone else could adapt it to fit this requirement?
It sounds like they are creating a low-end variant called Phoenix to cater for the Vampire A600 that will be far more 68K-like than Apollo. I agree that getting ISA compatibility is the most important, either 68020 or 68060, before new instructions that might be great, but will be unused by classic software.
TBH if they get it working, and if they get 20 MIPS out of it in the end (on the Vampire) I will be impressed. I'm glad they have a development target too, that always helps motivate people.
-
It sounds like they are creating a low-end variant called Phoenix to cater for the Vampire A600 that will be far more 68K-like than Apollo. I agree that getting ISA compatibility is the most important, either 68020 or 68060, before new instructions that might be great, but will be unused by classic software.
There are no user level ISA changes to the 68060 from the 68020 that a compiler would use or target except an FPU ISA which the 68020 did not have. In other words, the 68060 ISA=68020 ISA for almost all purposes.
TBH if they get it working, and if they get 20 MIPS out of it in the end (on the Vampire) I will be impressed. I'm glad they have a development target too, that always helps motivate people.
I too am skeptical of the performance increases over the TG68k given the limited resources. The MIPS test will probably give good results if the code fits in the ICache but the Phoenix will have smaller caches than the 68060 or even the 68040. Many of the timings are better than the 68040 but I expect overall performance similar to a 68040. There isn't any way a Cyclone 2 is going to outperform a 68060. Perhaps SysInfo will give 100MIPS result but that is meaningless.
-
there is no natami team as such for what i know. apollo is a softcore by former natami contributors, gunnar in particular. i dont know who else.
Well, you've just managed to discourage me with that statement.
Gunnar definitely wasn't my favorite member of that team.
Too many tirades.
-
I too am skeptical of the performance increases over the TG68k given the limited resources. The MIPS test will probably give good results if the code fits in the ICache but the Phoenix will have smaller caches than the 68060 or even the 68040. Many of the timings are better than the 68040 but I expect overall performance similar to a 68040. There isn't any way a Cyclone 2 is going to outperform a 68060. Perhaps SysInfo will give 100MIPS result but that is meaningless.
Why is Majsta using such an old and slow FPGA?
Is it tremendously cheaper?
The Apollo needs a complete rewrite to be squished down into the Cyclone 2.
That means it has to be re-debugged all over again. This takes time.
Then it will need to be rewritten again when someone makes a version for a newer, bigger and faster FPGA chip. Which means it will need to be redebugged all over again. Jens will have really a lot of work to do :)
-
Why is Majsta using such an old and slow FPGA?
Is it tremendously cheaper?
Cost. The Cyclone 2 was cheap and adequate for prototyping and proof of concept although Majsta might have switched to a Cyclone 3 earlier if he had known the difficulties of such a small fpga. He has been 100% successful in his original goals. There hasn't been enough time to upgrade to a bigger fpga for production of the Vampire 600. I think he is looking at a Cyclone 5 for the AGA machines.
The Apollo needs a complete rewrite to be squished down into the Cyclone 2.
That means it has to be re-debugged all over again. This takes time.
Then it will need to be rewritten again when someone makes a version for a newer, bigger and faster FPGA chip. Which means it will need to be redebugged all over again. Jens will have really a lot of work to do :)
Much of what you say is true. It is a significant amount of work to shrink the Apollo and then it has less advantage over the TG68k which performs adequately with minimal resources. There are significant parts of the Apollo core that can be reused so some of the debugging would improve both cores. It should be a good learning experience and may be interesting for embedded applications.
-
There are no user level ISA changes to the 68060 from the 68020 that a compiler would use or target except an FPU ISA which the 68020 did not have. In other words, the 68060 ISA=68020 ISA for almost all purposes.
68060 has a few less instructions than the 68020, so to be 100% compatible it shouldn't have them either.
FPU & MMU are also required for 100% compatibility. I don't believe gunnar is going to take over the soft core market, which is what he intends to do. What he's created doesn't really fit the requirement of getting us all access to 68060 accelerators either.
-
68060 has a few less instructions than the 68020, so to be 100% compatible it shouldn't have them either.
You must be referring to the integer 68060 ISA only. Do you really want to drop the integer 64 bit MULS/MULU instructions in hardware just to be 100% compatible with the 68060? This is silly. Maybe a 68060 version of the TG68k will be made to be as close as possible to a 68060 (a waste of time and cycle exact is not possible with <$1000 fpga) but I expect it would be a fraction of the speed of an enhanced 68k like the Apollo that should be 99.9% compatible. How many people turn off JIT and select all the most compatible settings in UAE? Without the compatibility settings, UAE provides instructions that didn't exist on the real processors and uses 64 bit instead of 80 bit floating point among other incompatibilities. Some of the UAE less compatible settings give a more tolerant and stable system like turning off alignment restrictions on the 68000 emulation. The 68060 is a great processor but we should not limit ourselves to it's bounds.
FPU & MMU are also required for 100% compatibility. I don't believe gunnar is going to take over the soft core market, which is what he intends to do. What he's created doesn't really fit the requirement of getting us all access to 68060 accelerators either.
I will be pushing for a more 68060 compatible but further enhanced FPU. An updated FPU ISA would benefit the FPU more than a 68k integer ISA update. I believe a 25%-50% speed and code density improvement of FPU code is possible with hardware and ISA changes. I would like to make the FPU 64 bit to improve timings but if it causes too many compatibility problems then 80 bits has the advantage that it could do reasonably fast 64 bit integer math with more efficient conversion instruction enhancements (a hardware and ISA change).
An MMU is not planned in the near future. The 68060 has a Cadillac of an MMU that would be expensive and difficult to duplicate and test. A simpler MPU would be more likely at first.
-
none pushes for clock for clock 060 compatibility. a winuae type lax 68k compatibility is perfectly enough. still introducing new unique instructions may split the platform, when encouraging the newly compiled software not being full compatible with the legacy systems, that do not provide an extended instruction set.
-
You must be referring to the integer 68060 ISA only. Do you really want to drop the integer 64 bit MULS/MULU instructions in hardware just to be 100% compatible with the 68060? This is silly.
+1
An MMU is not planned in the near future. The 68060 has a Cadillac of an MMU that would be expensive and difficult to duplicate and test. A simpler MPU would be more likely at first.
I really think they should / have to include the simple MMU that the EC060 version has. Iirc it works on 16MB blocks of memory and marks them as cacheable or not. I think that is all it does. No VM stuff.
If they include that then it will be really and truly "060 compatible" so AmigaOS can boot up out of the box.
-
I've actually been thinking of expanding an old 600 I have in storage in the garage, is this the best way to expand a 600?
-
I really think they should / have to include the simple MMU that the EC060 version has. Iirc it works on 16MB blocks of memory and marks them as cacheable or not. I think that is all it does. No VM stuff.
If they include that then it will be really and truly "060 compatible" so AmigaOS can boot up out of the box.
If by VM you mean virtualized memory-mapping then I agree. The page tables on an MMU get unwieldy and large really fast when the page size is small. 16 Meg pages would be much more manageable.
-
I just got an email from Igor, I am next on the list to recive the Vampire 600 so I am a happy camper, can't wait to beef up the little Amiga 600 :D
Edit: I will take Pictures and post when I get it.
-
have you got it yet?
-
Hi has any one received one of the vampire boards and got any results yet ,as it would be interesting to see how well it holds up ,if it does as well as it is suggested, this would indeed be a huge uplift for the Amiga community who I have to say deserve some encouragement for the endeavours to keep the Amiga alive ,I have put my name down for one so I hope I don't get missed lol ,best wishes Brian
-
have you got it yet?
Yeah I got it in November but sadly found out my A600 was dead (haven't used it in ages since I use the A1200) So I gotta find time to fix whatever is wrong with my non booting A600 first, now when xmas is over and we are done moving to our new house I will son have time to give the Vampire 600 a go :)
(http://www.som99.se/vampire.jpg)