Last few days it was lot of fun and hard work to find bug who stopped us from booting into Workbench and complete Apollo-team worked on this. Those who visited our irc channel could see huge motivation from all members to track it down. As you can see on the pictures shown in this article Kickstart 1.3 had some problems with displaying fonts so after investigation we narrowed our potential bugs to Blitter area. Next logical step was to compare information's from original CPU to the Phoenix results. I must say that it was so hard to capture all needed information's using SignalTapII because somehow I was receiving a lot of junk data and serious filtration was needed to capture only information's we can use. What we wanted is to compare those registers: BLTCON0, BLTCON1, BLTAFWM, BLTALWM.
071A 0002 FFFF FFFF
DFF040 DFF042 DFF044 DFF046
BLTCON0 BLTCON1 BLTAFWM BLTALWM
071A 0002 0000 0000
DFF040 DFF042 DFF044 DFF046
BLTCON0 BLTCON1 BLTAFWM BLTALWM
This result shows us where problem was and it means that sometimes Blitter Registers DFF044 and DFF046 are not correctly set with "FFFF" but with "0000". After isolating problem it was just matter of time when we will find it in code and fix it. And yes today we made it happen. You may ask yourself why is he writing about something that is already fixed. This article belongs in the history, today was crucial day for this project, today real magic happened and from this day on you will start to believe again!
This is the first public Phoenix core test. Despite some haters statements that this demo was written specially for Phoenix just to trick everyone that core is fast I must say that this is not true. Demo was tested in number of Amiga configurations and here are the results.
In fact you can test the demo on your system and report the results. You can find it in Read More, Pictures, Files... section of this article.
phoenix_demo4 - start from workbench
phoenix_demo4.bin - start from WinUAE selecting it as an main ROM file with 64MB of Motherboard fast.
At this point I proposed rest of the apollo-team to create some kind of competition for today. As I didn't had the chance to go to the Germany for those testings I will try something from my side, rest of the team will work together in a small Amiga meeting somewhere in Germany. Yes, Phoenix core is ready for testings inside Vampire 600. Stay tuned...
Under the radar lot of work has been done. Apollo-team didn't stopped development on new faster core who will run Vampire 600 faster than any known classics Amiga. I was away for some time but for some time I was working on new Amiga projects. Since Phoenix core is going to its final stage we need demo who will be able to show real performance of the core.
What we need:
1.Someone who owns Vampire 600
2.Have ASM coding skils
3.Capable of creating demo with very CPU demanding calculations based on real time fractal rendering or very demanding texture mapping demos with lot's of MUL and DIV
4.Coder who is able to create demo too slow for 68040 and challenging for 68060
I didn't have the time to write much since I was stuck with soldering but I had the time to read various Amiga forums and I was amusing myself reading about happiness of some people when they realized that one of the Vampire 600 accelerators send to UK was not in working order. It is replaced with working one. Don't worry so much I didn't developed all of this to put you out of business. Do you feel endangered in some way? Don't be afraid. What is most important to you? To see Amiga progress or to live from selling outdated products. I must say that my complete concept was success. Users learned how to upload cores to accelerator. I forced serious developers to buy Amiga 600 to be able to work with my hardware. Soon we will have fastest Amiga accelerator ever produced. I m sorry that you made some wrong decisions few years ago. You could find some time to talk with me :) Now, 30 more boards left for me to send, next 300 will be done by kipper2k in short period of time. At the end it is nice to see that people are selling your accelerators to order mine.
Today I received first pictures from new Vampire 600 user. This specific card was sent to ShK for SAKU 2013 event held at the Finnish Science Center Heureka in Helsinki on September 21st but unfortunately card was not there on time so visitors could only see poster of Vampire accelerator at the entrance hall. It took 11 days for package to arrive from Bosnia to Finland. Please look at the other pictures in Read More, Pictures, Files... section of this article.
You may noticed that 3 Vampire 600 boards are send somewhere but no one from pre-order list have been contacted. Don't be mad just read the story. On 21 Aug 2013 I became Apollo Team Member. What is Apollo you may wonder? Apollo-core is fastest FPGA core today and it is based on MC68K series of CPU. Again, you may ask why all of this is important for us? Yes we can run it inside Vampire accelerator series and get fastest Amiga accelerator ever produced. Now you know where are those 3 boards left. For past few days we are doing lot of work regarding optimization of the Apollo-core because original core can't fit into small FPGA used on Vampire 600. New core is taking shape, code named Phoenix, targeted at 100Mips and available as update for current core Vampire 600 is using at the end of November. What is my role in coding you may ask. I will be doing integration of Phoenix to Amiga Bus and few other things. So far I have created 500 lines of code and it seems that I will need to create 1000 more to get it done. All the time I was waiting for the opportunity to work with such names and to learn from them. Don't get me wrong but again I m proud that they recognized my hard work and invited me to the team. Final conclusion is that if all goes well there will be no point of building another accelerators instead FPGA accelerators. I must say that soon no one from other developers will be able to keep up with this.
UPDATE: September 11, 2013
After publishing this information's I noticed that too much people suggesting how and what needed to be done and why all of this is not possible. The same thing happened to most of the Amiga projects where developers just couldn't keep up with various demands. Adding some non standard features to the core usable for only few programmers takes time and most of the people will never notice or use that part. All of those comments created argue in Apollo team so we agreed that we will stop talking about complete project to the day we have first results. I didn't notice anyone contacting me about using schematics of Vampire 600 I published. So instead of talking what and how something should be done do it yourself. Enough said.
I have managed to finish 3 boards and today I will send them. Their destination: Germany. I must say that assembly of the boards is so difficult and when is done detailed testings are performed. Boards are in working condition and very fast. Complete process of soldering and testing can take complete day for just one board so you need to have patience because waiting list is long. I will need to create better assembly team because there is no way I can do all of this alone. I m mad at one more thing. I should concentrate of creating new products for Amiga and instead of doing that I m stuck with soldering because complete process is so delicate and I can't trust anyone. My assembly team made so much mistakes in process of soldering that I wasted five days to discover them.
For some reason I had to see how all of this performs online and I m satisfied! Is it usable in any way? Yes it is! Like you can see on attached video simple web sites can be used, forums etc. Let me say that maybe 70% of the things you normally do online can be done. But, I have a feeling that all of this could be much better if I had opportunity to connect Amiga to different monitor. Strange thing is that MiamiDX didn't worked and it seems that he have some problems with DNS. For best performance I used Voyager and Aweb. I m disappointed to IBrowse because he was slowest so I don't use it at all. Yes I know that everyone said that he is the fastest one but not in my case. It seems to me also that Voyager have very dirty code with strong will to crash sometimes. On other side is AWEB solid and stable and with few tunings maybe can get most from new sites. Strange thing is that new browsers like OWB and NetSurf needs FPU and ixemul libraries optimised for FPU. Conclusion to this would be that developers are going in wrong way because soon we will have emulated MC68K inside FPGA capable of much more than MC68060 with FPU. On other side there is very interesting project called Merlin Web browser who works on regular MC68K and it has support for CSS it is not stable but it has potential for shore.
Vampire 600 V1: Power of Vampire - game testings ADoom
For some of you this may not look so strange at all but to me, person who actually never had an Amiga before, it was quite surprise to see Doom running on A600. Yes that's because Vampire 600 is doing acceleration but still I had so much questions in my mind looking at this. Without "real" graphic card, without any serious hardware and comparing that to minimum requirements for PC version gives me permission to say PC is just a trash, who stayed alive all of those years because people those days just don't know about anything else. To play PC version of Doom I had to spend serious amount of money back in the days and still game was not playable. On the paper 486 CPU is much better than older CPU's from MC68K series. Some versions are capable of 50Mips or more but for playing this type of games we needed graphic card, sound card and at least 8MB of memory so comparing Amiga 600 with all of this makes me smile. Small machine sitting on the table and able to perform much more than 486 in huge, heavy case with tons of cables and power consumption 10 times greater than A600.
After today's testing I think that I m proud to myself more than ever. Hey!!! I created my own hardware, in some basement, able to play 3D game, able to play Doom. Imagine!!!
Ok now is the time to investigate how many people are interested in Vampire 600 so I can determine how much boards to produce. If you are interested send me Mail.
What you get: CPU: FPGA emulated MC68000 or MC68010 or partially emulated MC68020(your choice)
Performance: More than 6Mips
Memory: 64MB of FastRam (Zorro III space)
Autoconfig: 32MB( for now)
PCMCIA friendly: Yes
You will be informed that your order is placed by mail and listing your name in the picture attached to this topic. Sending accelerator boards will take place hopefully next month and according to the mentioned list. When your board is ready you will receive Paypal invoice to your mailbox. If you don't want to be listed just say in the mail. About guarantee don't worry I don't intend to leave I m here to made significant influence on Amiga scene, remember :) Other components like OSD, loading Kickstart from MicroSD card and PS2 mouse support will be provided later with core upgrades so I suggest everyone to buy USB blaster programmer because I don't intend to stop at 6Mips :) Board will not have PS2 and MicroSD sockets because they are unusable inside case so we will find a way later to bring them out with another small PCB. I forget to say that all of those who had some contribution in this project will have another price or no price at all...
UPDATE: August 6, 2013
Updated Pre-Order list more than 30 reservations added. Please check that you are on the list and if something is wrong contact me. Maybe problem could be because some people Pre-Ordered board twice, once by contact me by mail and once on some other web site. So please if that happened contact me so I can add someone else to that place. It is quite confusing situation to me. I didn't believe that I would need to produce more than 20 boards. Complete day I m answering to PM and email messages and I just can't keep track what I m doing anymore. Please have patience because I m sending boards for production and I just can't answer all mails at this point. Thank you. UPDATE: August 8, 2013
Now board is 32MB autoconfig. But, haters gotta hate. It is just interesting to me what I read on various forums. There are so much people who would like to see all of this fall down, and never see real success. Why? Just so they can say "I told you that all of this will be failure". I don't know the reason for all of this but those days I realized one thing. That Amiga is not destroyed just because company died. Amiga is destroyed by developers and resellers wanted to earn huge money from Amiga name. Like vultures various people are sending me bunch of mails wanting to increase price of the boards and to resell them. Proposal prices about 200Euros :) Let me say this. If I ever seen that someone sells this card for some incredible high price I will stop him by putting tons of boards for sale at manufacturing cost. No more exploiting Amiga scene from now!!! Here is what I said one of the supporters of this project yesterday. Yes I received lot of mails for some proposals. Resellers, manufacturers all of them wanna make money and increase price and benefit from this. I will fool them all opensourcing everything. I will survive alone and do everything alone and my work will be free and I will send lot of boards for free to people and PCB also. I m waiting just for another money transfer from my government. I m in a mission remember. With true amiga spirit. UPDATE: August 12, 2013
Vampire 600 sent into production so in few days I should have first batch in my hands. I would suggest to everyone to buy cheap USB blaster cable and programmer because for sure you will need it in the future.
Now when we have Vampire 600 100% stable I had one question in my mind. Did I managed to design this accelerator properly first time back in 2011. and all of the problems I had were related to my poor coding techniques. Most of the problems at beginning was related to understanding how Voltage translation works. Basically CMOS to LVCMOS and vice verse. For that purpose I used ALVT devices who are not Voltage Translators they are just 5V tolerant transceivers and that was fine because FPGA was protected from higher voltage signals. All of the signals from Amiga bus to FPGA were translated to LVCMOS and FPGA was able to recognize them. But in situation when FPGA needs to send signals to Amiga bus we will need to translate LVCMOS to CMOS and ALVT devices are unable to do that. Next redesign of the board included ALVC devices capable of complete bidirectional translation, but in the same time those are dual voltage translators and having more and more voltages on one PCB can give lot of headache in design process. Few days ago I found some information's that Amiga chipset can recognize LVCMOS signals and I had to try that and in the same time to convince myself that my original design was fine, at least hardware part. So I found V1.1 of the accelerator and connect it with few wires to last version mainly testing behavior of Address bus under LVCMOS. Due to wires signals are slightly delayed and system is not stable all the time but it works. So maybe just maybe Amiga chipset can recognize LVCMOS signals and work stable? I have also sent mail to Philips NXP engineer who was earlier helping me with their products and we will see what he has to say about this. Someone may ask why I m wasting my time on this instead starting production because demand seems high for this product. One of the reasons for performing this tests was because ALVC devices are expensive and for me hard to find. On the other hand I have about 100 ALVT devices waiting to be used and I could easily get more.
UPDATE: August 6, 2013
Maybe most important information for me from start of this project. Today I just made few test to prove that Amiga chipset can recognize LVCMOS. Accelerator started just fine in 3.3V range :)
Since there was no way to find what is wrong with new design I decide to back one step and assembly one of previously designed boards that actually worked, and maybe then I will understand where I was wrong in new design.
Today I finished assembling old 1.3 revision of PCB. This version was created with 4 bit SDRAM memory but it is 90% compatible with new version. All of testing with V1.3 are done in February this year and published here and everything was fine back then. I was able to start any game and to perform any test and everything worked. So today I used old design, old core but I was surprised that all of the problems I have with new design are now present in old one. V1.3 of the board now does not work! It has the same problems accessing FastRam. Let me say that I used the same components, let me say that there are no problems with bad solder joints and finally let me say that code is not changed in any way. What is different than February, only that I m now in new working area. Don't even start thinking that all of this problems are because in those summer days temperatures are high. But, all of this is actually this is good situation now because I will find problems eventually because I was present in the room when old design worked. I m glad to see that old design is not working now and comparing old pictures to what I see now I will find the problem. I just need to have patience right now.
As much patience I have there is no way I can found the problem. There are no more places too look for.
Only one thing I know I will never, never build PCB in white color or any other color than green. Why? Those boards don't have proper protection from hand soldering and you may end with short circuits all over the board. Hand soldering takes longer time so heat may destroy protection layer so you will solder components VCC to GND polygon plane. Maybe all of those problems I had are related to my PCB manufacturer but I know one thing for shore that is very hard to discover any problem on white surface. After solving all of those problems Accelerator was still unstable. But why? I didn't have any instability with older designs. Boards are running for several hours without any problems, playing games, using various programs who depends on FastRam, writing and reading from FastRam using AmosPro. First I was thinking that new system maybe sink too much power from Amiga motherboard. Old SDRAM needed about 150mA, new about 170mA so problem can't be here. Also, compiling design I found out that my design consumes only 219.63 mW. So problem can't be here because in theory FPGA could work with 5 times lower power supply, with less Amps, than I provided. Then I was thinking that maybe in the process reducing cost of production that I have removed some essential components needed for proper work, but that was not the problem because I have put them back and problem remains. So next logical approach is to check PLL because we are now at higher speeds. So I checked VCCINT who needs 1.2V for operation. Voltages are OK, GND plane needed for PLL is fine, there are also enough Amps, SDRAM chip is close enough to FPGA, there is nothing strange I can see there. After all I just don't understand why Vampire 500 works perfectly with only minor modifications to MC68K side and this one refuses to work.
Now, after 2 months of testings I can conclude that problem is not in SDRAM controller because every single one I tried behaves the same. Problem is not in any other signal from Amiga 600 motherboard, they are all treated properly and synchronized to support work on higher freq. On other side for signals to and from SDRAM Fast Input, Output registers are used to support all timings mentioned in SDRAM datasheet and according to Timing Analyzer everything is below needed 5.4ns.
So where is the problem? All instability of the system are related to accessing SDRAM. In that process few hardware parts are included. Crystal oscillator, PLL for generating higher freq. That PLL generates two output signals at same speed, one for running complete core and one slightly phase shifted for running SDRAM chip. So maybe problem can be in determining that phase shift currently set at -1.0ns, but it is the same like on Vampire500 and there everything works fine. So imagine situation where you created Vampire 500 99% based on Vampire 600 design, they are the same only socket is different, cores are the same but somehow Vampire 600 does not work. It is not stable or usable in any way. I have spend 3 years working on this design but I just can't find problem. Vampire 500 is created in few days but works like charm. Now I have no idea what to do.
Update: Found it!!!
Ok here we go. I have a clue what is wrong. It was pure luck to discover such thing. Like we know 8MB of FastRam(Zorro II) are located between $200000 to $9FFFFF. So after detection of that specific range FastRam is added. There are few procedures for memory testings and I have explained few of them in earlier posts, but all the time I was testing $200000 space and didn't test anything higher than that. So few minutes ago I have decided to run LFSR memory tests on $400000 and all of them passed. Then, I have try to write $12345678 sequence into that space using AmosPro and then to read that space after flushing cache and get exact sequence :) So to conclude, something is wrong with $200000 - $3FFFFF address space and that is why I have lost last two months. Another thing that is important to me that reading that sequence in correct order proved that SDRAM clock is correctly phase shifted. So I have tracked down the problem, lets try to solve it.
So next logical step was to add AutoConfig option to this accelerator. Board is detected but Status reports that there is something wrong with the board. My Manufacturer ID 5016 is detected but board refuses to boot.
Yes it was fastest Amiga 600 but somehow there are lot of problems with cache. Why? After few days of investigation I must say that I have no idea. I have tried everything from changing SDRAM chip to checking every single trace on the board. Problem here is that I just can't load all signals needed in SignalTapII to see what is wrong because this FPGA I m using is too small for that. So I m stuck with this now, error is somewhere between SDRAM controller and cache. So today I have managed to create simple SDRAM controller without cache to see can this design work at all. Controller works somehow but again system breaks at one point. So we will see once this controller works maybe we can find a reason for other problems. Yes there are few designs open sourced but it is hard to track what someone wanted to say in code. I know only one thing if I ever finish this project it will be because amazing help from robinson5 from retroramblings.net. So are we close, we were close 2 years ago but it seems that playing with electronics designs is hard :).
After huge investigation I found out that my design can't run on higher frequencies. Maximum frequency possible is 87.5MHz. System can't work on any higher frequency even on 90MHz is unstable. Best results I come to regarding performance was 6.88Mips at that 87.5MHz and it is achieved when code optimization is done. That's about it! So then I started to wonder that maybe something is wrong with only signal I really need to be stable and coming from Amiga motherboard, 7MHz clock signal. Every other signal is not so important regarding timings and can be adjusted if needed inside FPGA but getting basic clock from Amiga motherboard is essential because we need to have proper detection of rising and falling edges of that clock so we can, using them, define read and write states in MC68K bus cycles. So what I needed is to have Amiga motherboard clock more stable because in process of attaching that clock to FPGA I needed to use ALVC device to solve CMOS to LVCMOS translation. But ALVC device gives delay to Amiga clock and it could make signal unstable. So I needed new approach to introduce 7MHz clock to FPGA and in the same time I needed to solve CMOS to LVCMOS translation without ALVC device to save FPGA from damaging I/O pin. I decided to use BAT54S diode who will protect FPGA I/O from higher voltages and in the same time we will have 7MHz clock inside FPGA without major delay and this time delay will be dependent only from length of copper trace between Amiga motherboard and FPGA. Now, because clock is stable it can be easily adjusted inside of FPGA so rising and falling edges of that clock can be properly detected. Compared 7MHz signals, one coming thru ALVC device and one protected with BAT54S, you can see on picture attached. So maybe this is potential problem ?
After adding proper SDRAM chip it was only matter of time when complete design will show much higher performance. Again want to thank robinson5 for much effort for guiding me thru many problems. I must say that after he open sourced his work my job was done. Only thing I needed to do is to compare signals and track his codes. In this article I will add more information's about what's done here but now I m so tired of work that I just don't have strength to do it.
New and final boards are received, one assembled for about 2 hours but PLCC68 connector seems to be a problem because I wanted to experiment and ordered 40 PLCC sockets thru hole who seems don't fit correctly so tomorrow I will try to find a way to solve this. For now board is able to fetch about 50% of signals from Amiga motherboard and that is major problem for now and only thing that can be a problem is PLCC socket.
UPDATE: May 14, 2013 Found appropriate PLCC sockets at my local store. One board assembled and now running at the same speed as before but now we have 16 bit SDRAM on the board so we will soon see what is the limit of this design. So tomorrow modifications to the SDRAM controller will take place. I hope that someone will jump in and create modifications for controller because I m not satisfied with modifications I have done today. Creating SDRAM controller is delicate thing and I don't trust myself in creating such thing. Simple, I don't have enough knowledge for that, but there are few designs I already have and if no one helps i will include them.
This is the latest redesign of Vampire 600 FPGA accelerator. In next few days production will start. So whats new here? You may think that this is the same only some components are placed different. But is it? Most important thing here that now JTAG have over voltage protection and ESD protection and from now on this is a proper development board. Another thing added is PS/2 mouse connector and with cable extender you can mount it anywhere you want. Reason why I used standard PS/2 connector instead some header is that someone can create some specific cable and sell it and again exploit your retro enthusiasm. The same thing is done regarding one more feature Wireless module and this module is compatible with Arduino board modules found at 1 USD so again you are protected from someone wanted to charge you lot of money just because you are buying something Amiga and retro related. Third feature added is SPI connector and from there you can connect anything you want. So stop thinking that this is just Accelerator board.
It is quite easy to design new piece of hardware regarding dimensions but when you need to design PCB to fit into another piece of hardware you may encounter to number of problems. No matter how much you measure final PCB can give you much headaches when you need to create some simple things like holes, sockets etc... Maybe simplest solution for amateur developer is to measure everything using some measurement tool and according to gathered values design virtual PCB, print it on paper in scale 1:1 and then see if everything fits. Take your time because it is easier to print 10 different versions of PCB on paper than to build PCB to find out that you missed something.
How it is done on Vampire 600 PCB? It was complicated because I had to understand space between PLCC-68 socket and 4 holes on Amiga 600 motherboard. Because if you move, for example, PLCC-68 socket just for 1mm you will end up with major problems regarding dimensions between that socket and 4 holes. So since I didn't find any information's regarding this problem on the internet I decided to publish here how it's done and maybe someone will find it useful. I think that in the process of creating open sourced design is essential to pay attention to every detail. So first I used PLCC-68 socket and fit it on top of the MC68K CPU on Amiga motherboard. Then I used red pencil and marked center point of socket. From that center point I measured distance to every hole on Amiga motherboard used for fitting accelerator board. For that purpose I used caliper to get accurate dimensions. After that, in CAD software (in my case Altium designer) I created PCB with 100mmx100mm dimensions and added components and holes at exact locations to support dimension relationship between
PLCC-68 socket and 4 holes mentioned earlier. Then all I needed to do is to print it on paper and see if everything fits. On printed paper I drilled holes in 5 places, center of PLCC-68 socket and on 4 holes. After that by simply placing paper on PLCC-68 socket and finding red colored center point viable try the hole was something I needed to see are the other 4 holes are in correct places so they can be used to assemble Vampire 600 PCB to Amiga motherboard.
New redesign is taking place, maybe replacing Cyclone II with Cyclone III FPGA and adding faster SDRAM. So maybe we are stuck for now.
Anyway for past few days news about this project was published in many forums and dedicated Amiga websites. Thanks to Comi from VOODOO AMIGA who contacted Trevor and inform him about this project. Trevor was so kind to publish project information's on his blog and because of that there was many donations who will help further development. Just because of those donations project stayed alive, there was one moment when I spend all of my funds to complete my idea. Another article was published on Amiga-News. They published related information comparing performance of Vampire 600 with other accelerators. Looking at the comments on their website and few forums it seems that I again need to explain some things. People still think different than me regarding Amiga and now I just know that I will need lot of time trying to make them think different and beyond limits, books and proven concepts. In process of doing that I will keep reading comments about this project two years ago and amuse myself looking the same people changing their mind in matter of days on each published video. So here we go:
1. Can you attach VGA, USB, Wireless, MicroSD, PS2 or something else on any accelerator produced for Amiga?
On Vampire 600 you can!
2. But what regarding the performance compared to other accelerators?
Just wait until I add cache to this thing. Don't trust me again?
3. What if I m nostalgic and only need accelerator with real CPU?
It is quite trivial to make accelerator with real CPU, connect it to Vampire's FPGA simulate 7.09MHz bus cycle and you have it.
So what about those things we can add to this accelerator board, who will add them? Some of them will be interfaced and some of them you can add it. It is time to start thinking different. If you are Amiga user and want to have that feeling that you actually contributed by creating something new and innovative you will find a way. If not, this is not place for you buy an Pentium 19 and enjoy with rest of the people who will spend all his life not thinking how stuff works.
After those conclusions I have done lot of thinking regarding this projects. Do anyone get me regarding this or is there any demand for production such device? What about the price? Reduce costs, build it yourself I will help you.
UPDATE: March 1, 2013 There are some rumors about this project regarding final price. Something like: "It's a cool project but it could cost about 500USD". Let me say once more STOP MILKING MONEY FROM RETRO FANS. New PCB redesign is taking place and I m doing major makeover to drop price under 100USD for advanced version and under 50USD for low end version. So stop spread words about high price and that someone again want's to get rich from Amiga name. Will I succeed regarding final price we will see. For now I can't promise anything but that is the final goal regarding the price. Another thing I m removing current survey from website because there is no point for it because we already have an accelerator. So final conclusion will be that 84 people voted that we will never see Amiga FPGA accelerator created by me and 78 of them supported project. Guess what ? :)
Like I promised first signs of accelerations are here. In total 1.38 Mips are accomplished. System is much faster than before and again want to say there is so much space for increasing performance. Cache needs to be added and complete system runs now at only 72Mhz. So what can I say to all of those who didn't believe in this. Nothing much except it took me about 4380 working hours to accomplish this. Every single day for past 2 years for about 6 hours per day. So again i want to remember you about my words 3 years ago. You didn't work too hard to save the Amiga. Despite your knowledge you didn't do much! So Amiga community is just Talk Talk community!!! On Sun May 23, 2010 at 12:50 pm I have got my first Amiga and few days later I found out that Amiga uses something called MC68000, few days after that I just know that I have a mission... Stay tuned...
In process of adding FastRam to the board I encountered in few problems. First of all I didn't include correct version of SDRAM because I didn't use 16Bit data SDRAM chip to support MC68K data bus. Instead of that I used SDRAM chip with only 4 I/O's. Why, answer is simple I didn't have another ones. Because of this serious modifications was needed to the SDRAM controller. But after those modifications something went wrong again and once more robinson5 jumped to help with SDRAM controller and with memtests. Because memtests are taking so much time on slow machines he proposed to me to use AmosPro to test memory.
print hex$(leek($200000)) --Read current RAM value and cache it
loke $200000,$12345678 -- Write new contents
print hex$(leek($200000) --Read the value from cache
print hex$(leek($210000)) print hex$(leek($220000)) --Flush the cache by reading another locations
print hex$(leek($200000)) --Read the value from RAM
In images shown in this article we can see that something is wrong and instead of getting $12345678 we have got $12385678 so further investigation is needed here.
Those days I m receiving lots of mails regarding real speed of this accelerator. Also, I have noticed lot of discussions about this on various forums. Somehow all of those testings was very confusing for most of the people especially when I published information's that I m able to run TG68 core at 127MHz and that I have done promising testings on 150 and 200Mhz. To understand why all of this is so slow we need to explain how Amiga accelerators work. And we can do it in just one sentence. Every CPU from MC68K series used to replace model used on motherboard needs to mimic his bus cycles and acceleration can be expected only when we connect some peripheral device to that new CPU. So like you can see at this point it is essential to create exact timings according to 7.09Mhz CPU clock and then add memory to new CPU at higher speed. This is the only way we can overcome "slow" bus timings regarding to original clock so those bus timings will be used only in situation when new CPU needs to talk to Amiga motherboard. Everything else will happen on much higher clock rate between new CPU and the added memory. For now I m just 0.06Mips behind original MC68K so few more tweaks needs to be done. After that, when we add memory we will know for shore is this an Accelerator or my complete theory was wrong.
Now it's time to increase frequency. First test shows two times better performance of core working at 20.10MHz like you can see on the image shown in this article. Performance are far behind of real CPU but there is so much space for increasing speed. This code runs stable and working in workbench is smooth.
Somehow I convinced myself that I maybe didn't create anything and that all of this is false and that somehow MC68K is working but slowdown in background because my VHDL code so I started to wonder how to test that and after 2 hours here it is. MC68010 in FPGA so now I m convinced, are you ?
After so much work I just know that one day i will succeed. Today is that day. MC68K from Amiga motherboard is definitely disabled and replaced with FPGA version and as you can see on the video and pictures attached complete system is much slower on basic 7.09MHz frequency than original MC68K. But most important thing here is what is gonna happen when I increase speed of FPGA core. For example, basic Amiga 600 with MC68K reports 0.55Mips and 528 Dhrystones and Amiga 600 with Vampire600 FPGA Accelerator reports 0.25Mips and 243 Dhrystones. Now, when you look at the things, after all this years of promising we finally have exit from basic Amiga hardware to another platform, to FPGA, modern environment and from now on we can go anywhere and attach anything to it. In the same time we will preserve Amiga concept and make it available to further generations. My mission continues and there is nothing from now on that can stop me.
Last few days I m doing lot of testings regarding core implementation into the current design. For now Amiga starts booting and passes first few stages of hardware testings and starts loading Kickstart. Integrated core is capable of loading internal ROM like you can see on image, but somehow it is unable to finish reading from Kickstart. Best way to investigate what is wrong here is to print signal states and investigate everything on paper. It may take some time but I hope that I will find a problem and solve it. On the image shown you can notice that I have integrated ASCII characters to get some kind of image on Amiga screen. Main difference between old boot testings is that this boot image is loaded with softcore NOT by MC68K. So from this stage we have working FPGA Accelerator :)
After last published article where I was talking about disabling MC68K and writing to Amiga color register only write cycle was tested. Next logical step was to control color register with some external device like, for example, mouse. This way we could test complete Amiga bus cycles, reading and writing.
Since I separated my project into few small ones only success! It took me only half an hour to implement this part. The goal was simple, disable on board MC68K CPU and replace it with some kind of mini CPU who will only write something on color register. Sounds simple? It took me about 532 lines of code to create something like this.
Those are the stages: 1. First Finite State Machine started.
2. Complete system started with ALVC devices disabled.
3. Amiga system restarted using counters.
4. Finite State Machine who is dedicated for 3-wire bus arbitration enabled.
a) FSM check reset signal and count bus cycle.s
b) FSM asserts BR
c) FSM waits to current cycle is complete (AS and DTACK negated, BG asserted) and asserts BGACK
d) FSM release BR.
e) FSM activate reset signal who enables mini CPU who will write to color register.
4. First FSM check that reset is enabled.
5. ALVC devices are programmed to support Address Bus, AS, LDS, UDS and RW signals as output FPGA signals. In the same stage AS, LDS, UDS and RW pulled high.
6. Write dff180 to Address Bus (Amiga color register).
7.Pull AS low to indicate that valid address is placed and RW low indicating write cycle.
8.Set ALVC devices dedicated for Data Bus as output, check counter and regarding on state of counter write on Data Bus 0f00 for red and 000f for blue color enabling and disabling LED.
9. Pull UDS and LDS low to indicate that valid data is on the bus but if DTACK is low release AS, UDS, LDS and leave RW for another cycle.
10. Pull RW high and set ALVC devices dedicated for Data Bus for input FPGA signals. Restart counter and back to stage 6.
Few days ago something came up to my mind regarding all parts of this project. Why they don't work ? So I started little investigation using SignalTapII from Altera Quartus software to trap all of initial signals once Amiga motherboard is powered up. For this purpose I used some Trigger Conditions for RESET and some other signals. Main reason for doing this that we must consider that Amiga already started all of hers subsystems and in that situation FPGA can't take over the bus. So initial reset need to be done so FPGA can trap those initial signals and according to them take over the bus in specific period of time. Conclusion for this part is that FPGA first need to restart Amiga system and then start bus arbitration and then activate TG68 core. On the video below you can see another prove of this concept. Amiga 600 motherboard is restarted using Vampire 600 accelerator and simple VHDL code.
Vampire 600 V1: Support from the Ministry of Science and Technology
Another great news for the project. I applied for contest for new innovations organized by Ministry of Science and Technology in Republic of Srpska Government. After few days I went to Association of Inventors to present my project and today I received great news that my project was one of few who have been approved by second commission. Their help will be significant regarding project money stability. I hope that my work will provide lot of information's for someone who want's to start this or similar projects.
Thank you for understanding.
Today I was find out that there are some article about this project in the Amiga Mania online magazine issue for September of 2012, and want to thank authors for support and realistic text. Complete online edition you can find HERE, and article about Vampire 600 is on the page 4. Again than you for the support!
Amiga 600 motherboard received. Again, thanks cpiac64 for support! So at this stage work continues and I will provide more information's soon. New accelerator is attached to the motherboard and now I m doing lot of testings. First test says that original MC68K cpu is disabled and FPGA takes control of the bus but there are lot of problems regarding differences between bus timings between TG68 core and original CPU so Amiga motherboard can't detect new emulated CPU who is working stable now. Also those days I have done lot of work regarding writing project documentation because it was hard to keep track about what I have done so far. Documentation currently holds 21 pages and it seems that I have just started writing and explaining what I have done so far.
Because my Amiga 600 boards are too much damaged I am unable to repair them in short period of time so I need to find working ones so I m searching for one or more boards. Either way if you have Amiga 600 motherboard and want to donate or sell please contact me so we can make some deal. Thank you.
One board on its way from Italy. Thanks cpiac64!
Vampire 600 V1: Using FPGA Accelerator as Logic Analyzer
Huge problem for me now is that I don't have any single one working Amiga 600 motherboard, so I had to repair one or two to be able to continue my work. For that job I need serious equipment that I didn't have until today. For proper repair it is not enough to just track schematics and change parts I had to "catch" signals to see it and find out what's wrong on the motherboard. For that job I needed Logic Analyzer so I created Logic Analyzer using my FPGA Accelerator board. 5 minutes job and now I have serious equipment.
1. Accelerator uses VCC from Amiga motherboard
2. JTAG -> USB connection to the PC
3. One probe from Accelerator
4. VHDL code (one part for translators, second one for probe , third for LED who depends on probe status)
In process of using this Accelerator as Logic Analyzer I realize that there is huge problem because Accelerator don't have over voltage protection and every time I accidentally "touch" 12V on Amiga motherboard I destroy Voltage Level Translator. So I needed to have some over voltage protection and after some calculations I decided that best way is to add 680 OHM resistor on input probe to limit clamp current. Now everything is working perfect.
PCB's are received and one assembled for testings. Since I had only one partly functional A600 board I have done only testings regarding disabling original CPU and accelerator board was started and if you look at the logic analyzer you can see that TG68 core is started but since motherboard was not completely functional I was unable to do more. Now I m waiting for logic probes and package of different PLCC sockets so I can investigate rest of chips on motherboard to find out which one is broken.
Changes regarding this PCB version.
1. New Voltage Level Translators used, now I have complete, total CMOS to LVCMOS and now vice verse, I replaced 5V I/O tolerant devices with dual voltage drivers.
2. Included MicroSD socket.
3. RESET signal separated into RESET_A(input to FPGA) and RESET_B(output from FPGA) because RESET is bidirectional signal.
4. HALT signal also separated into HALT_A(input to FPGA) and HALT_B(output to FPGA) so FPGA sends low state to MC68K usind HALT_B tristating Data and Address bus of original CPU. In the same time FPGA is able to receive HALT_A to confirm that operation is successful.
5. For disabling old CPU 2-wire arbitration is used. FPGA sends low active state using BR receiving low active state BG from MC68K. BGACK is ignored here but left as output signal from FPGA if needed for 3-wire bus arbitration.
6. R/W signal is working and according to that Voltage Level Translators dedicated to bidirectional Data Bus are changing direction of input and output side.
1. I don't have any single one working A600 motherboard because I destroy 7 of them in process of learning.
2. I need to repair those or buy new one and that's take money and time, time I have but no money but I m shore that I will overcome this.
Again thank you all for money or hardware donations and check other pictures in Read More, Pictures, Files... section on this Info.
PCB is send to production but PCB manufacturer reported me that there are lot of problems in the design. According to my DRC checks there are no errors and everything is in range of manufacturers specifications. They send me picture of my design where you can see that there are errors and now I just don't know what happened here. Only difference between this and other designs I created are related to including Teardrops on some component pins to ensure connections. Today I have sent design without Teardrops and we will see.
Problem solved! In process of generating Gerber files I accidentally included some Mechanical Layers in *.GTL Top Layer and after removing that everything was fine.
I know that I didn't managed to finish this project but once I finish this part I want to have Accelerator board ready for implementing other functions so I decided to include MicroSD socket and maybe additional FLASH. In my design I already have EPCS4 who is dedicated for programing FPGA chip and additional space from this device can be used for adding small BOOT code who will point system to search KICKSTART on MicroSD card or FLASH. Additional benefit of adding MicroSD card is increasing of speed because old Amiga IDE controller is much slower then modern MicroSD cards. Main problem in adding MicroSD socket was lack of PCB footprints in Altium Designer so today I created one and according to all measurements it should be fine.
Today I received package of Altera Cyclone II FPGA devices, but 3 of them was damaged. Here I just want to inform you that very important thing here is packaging done by the supplier and if packaging is not done proper way pins of the devices will be damaged. Those pins are so delicate and it just can't be repaired. Problem here is that when you buy large quantity of FPGA devices you will get it in plastic housing, and those housings are designed to keep every single device in place and to save them from any potential damage. Supplier then wrap nylon foil around housing to keep devices on place and then when devices are not in correct position in plastic housing nylon foil create pressure to the devices pushing them back to plastic housing destroying pins. So you can see what stupid problems may occur when you start some project. You need to check everything number of times and still some stupid thing can delay your project.
For past 10 days I m working on Accelerator redesign. Basic changes are related to voltage level translation because in previous versions voltage level translation was not complete. Using 74ALVT162245 devices, who have 5V tolerant I/O's, was not best solution because those devices can be only used in process of translation CMOS to LVCMOS but those devices was unusable to translate back LVCMOS to CMOS. In this case all of the signals coming from Amiga 600 board was readable by FPGA but signals going from FPGA to Amiga 600 board was unusable because those signals were never translated to CMOS because 74ALVT162245 is not real translator just transceiver who have 5V tolerant I/O's. Lot of people are talking that rest of Amiga hardware can work with LVCMOS signals but with this new design I just wanted to be shore that level translation isn't problem in design of this Accelerator board. So I decided to use dual supply translating transceiver, and yes like I said before I didn't use those devices because they can complicate design and drive to number of problems on 2 layer PCB. My choice was 74ALVC164245 and main difference here is that VCC(A) is tracking A side of the device and VCC(B) is tracking B side so if we use 5V on one and 3.3V on other side we have complete level translation between CMOS and LVCMOS and vice verse. Other changes on design are related to proper solving BR, BGACK, BG, RESET, HALT and some more signals. Those changes was needed because I may decide to have original CPU up and running for some time until FPGA takes over the bus. New series of devices are ordered, and PCB will be produced in next few days. Here is tracking number so you can track order if you want :) RC110182668HK
Hi I was wondering if you were still progressing on the board ? Maybe this could be turned into a full fleged Amiga if the rest of the chipset can be built into the FPGA or a different FPGA as well ?
Majsta: Thank you for the interest in this project. Testings stopped because I destroyed every single A600 board I had and destroy all of the Cyclone II FPGA devices. Those days I m working on logic analyzer capable of solving 5V inputs because there is no way I can repair those A600 boards without that. Board and everything was destroyed because of Analog and Digital GND problems and after some testings I m building new PCB version 1.2 who will remove those problems. It could be possible to have everything attached to accelerator board so board can act like standalone Amiga or Accelerator board for real Amiga but it could take time. First of all I need to connect to some people to accomplish this, but my idea was to have piece of hardware capable of emulating various cores and when time comes maybe platform could emulate even Natami or some other core. Situation for now is that Accelerator works stable at 7.09Mhz and that is important. After that it is only software thing to increase frequency as you like. When this piece of hardware become "open&source" I believe that smarter people than me will create faster cores at higher frequency's. After two years of testing here is the picture of working Accelerator board. Either way I received some money from donations and with those money I ll order new PCB and few Cyclone FPGA's for testings. Without those donations I wouldn't be able to continue so again THANK YOU ALL FOR UNDERSTANDING AND SUPPORTING THIS PROJECT.
I wrote the last question about progress, thank you very much for your quick answer, I am not used to people actually answering my dumb questions so fast and with many details.
If you have time could explain to me the problem of Digital Ground and Analog Ground, I am not aware of any difference in grounds but maybe I missed something.
I am interesting in helping but I do not have any Amiga hardware yet.
Majsta: I ll provide anyone information's who are interested in this and similar projects but please register and use forum for this purpose because it is hard to talk this way. AGND is used for analog devices like voltage converters or something like that, DGND is used by digital devices like FPGA's, processors, voltage level translators or something like that. Basic procedure is to separate those GND's and use them on different layers connecting them at just one point or to create them on different parts of the board. If you work on this way components VCC's and GND's should know where to go to complete cycle. If you don't solve this properly there could be lot of bad influence on digital signals who can become distorted and unusable.
Today I worked on this project for just 3 hours because I didn't have much time. Today goal was to investigate how to disable MC68000 from Amiga 600 board and replace it with TG68 core used by Accelerator board. So in this situation we will have Accelerator acting as a Master device. Key signals used in this operation are BR - Bus Request, BG - Bus Granted and BGACK - Bus Grant Acknowledge. After some research I found out that there are two ways to arbitrate the bus on MC68000 processor, 3-wire and 2-wire bus arbitration. So I needed to find out what type is used by Amiga hardware designers. Looking at Amiga 600 schematics I found out that BGACK is pulled high and that was sign to me that 2-wire bus arbitration can be used.
Simple understanding of 3-wire bus arbitration is:
Accelerator board activates BR, after that MC68K activates BG, Accelerator sends BGACK to MC68K. After everything is done on the Bus BR signals is deactivated, MC68K deactivates BG and Accelerator confirm that deactivating BGACK signal.
In 2- wire bus arbitration BGACK is not used.
I wanted to simplify this by taking BR and BGACK low because those are their active states and decided to ignore BG signal but that was not best solution su further investigation is needed here.
After reparation of accelerator board for past two days I have done number of testings and changes in hardware design. Yesterday i discovered that clk signal from A600 board is not stable because ALVT devices had problems with GND and solved that. Also there was problems with PLCC-68 socket and address bus was not detected by the ALVT devices. Anyhow to realize those problems I had to write MC68K_probe tool in VHDL to test accelerator and signals from original CPU. After solving those problems I have working TG68 core on Accelerator board but there are lot of things to be done to get this working. First of all I need to disable original CPU to see that everything is fine with Accelerator. I know that I must take BR signal low but there are more signals that need to be handled to take over the bus from original CPU.
Again I destroyed another Accelerator board. In the process of using 7.09Mhz clock from Amiga board I was making some simple changes on the board and after that Cyclone was dead. Why? I just don't have explanation to this because I haven't done anything wrong here. Maybe static electricity or maybe that i didn't used Schottky diodes for protection but they are not used in most of the designs I have seen regarding to dev boards based on Cyclone devices. But in some devices they are used for Combining JTAG and AS Configuration Schemes but as I use only JTAG for testing without any Serial Configuration Device this also doesn't make any sense. So in this case there was no problems with overheating, short circuits and anything that i could done to destroy this device but again this stupid message:
!Error: JTAG chain problem detected
!Error: No device detected
Tomorrow I ll try to repair this board or use another Cyclone FPGA. Last one that I have!
Today major progress for me, for someone is nothing but after so much testing TG68 core is started :) Accelerator is programmed and core on accelerator is working somehow. Again like I said stupid reason reset signal but again I want to say why someone didn't want to point me that there could be a problem... Testing continues :)
Here are some pictures from different periods of development, pictures of two prototype boards, some board modifications and 3D designs of the board. There is little article about this Accelerator from Amiga Future magazine, parts from Accelerator schematics and basic tests. More to come...