First Amiga 600 FPGA Accelerator - Vampire 600

[majsta]

Ok if you don't have time or something I would like to repair them. I allready have one board in repairing status but as I said I can't finish anything untill I buy hot air gun I repaired those part I found dead with soldering station but some of them can't be repaired without hot air.

[majsta]

Found and buy hot air machine and some more tools so there is no way that I could have any problems regarding to soldering. Also ordered package of new FPGA and more parts. For past days worked on website regarding to this project, there is no info but design is finished. Also on that web site you will find a lot of info regarding to this and other projects. I ll provide informations, pictures this week. But for now you can check the desing address is www.majsta.com

[majsta]

Ok new info 5 days ago I have managed to start board and because of lack synchronization amiga started but only with grey screen, but it was huge progress for me. But as I have changed some parts of the code I just don't know how I started damn thing

So regarding to TG68 I think that main problem is regarding to active high and low states and I need from someone to verify this.

On original MC68K as, lds, uds are in active low state but in Tg68 core is active high state so I changed that to:

oTG68_ASn <= not as_s;
oTG68_UDSn <= not uds_s;
oTG68_LDSn <= not lds_s;


dtack is active low on Mc68K and on Tg68 is active high. So my board overheats on alvt devices(voltage level translation) because of this and when I have done some changes regarding to this board stops overheating.

Also I have changed alvt bidirectional control for one alvt device

alvt_oe1 <= '0';
alvt_oe2 <= '1';
alvt_oe <= alvt_oe1 when rw_s = '1' and uds_s = '0' and lds_s = '0' else alvt_oe2 when rw_s = '0' and uds_s = '0' and lds_s = '0';
.
.
.
.
U2_1DIR_C <= alvt_oe;
U2_1OE_C <= '0';
U2_2DIR_C <= alvt_oe;
U2_2OE_C <= '0';

Ok I think that main reason here for this does not work is regarding of difference regarding to high and low states between TG68 and original CPU

[Damiga]

Congratulations on the progress!

I just found this thread and it seems you've been working very hard.

Keep up the good work!

[Stedy]

@Majsta

There is an error in your bus interface logic.

The uds and lds signals can be at different states when accessing byte wide ports. The MC68000 does not have an A0 address bit, instead it relies upon UDs/LDS to select the 2 LSBs. Figure 5-4, Word and Byte Read-Cycle Timing digram of the MC68000 User Manual clearly shows this.

Is your design in Verilog or VHDL?

Ian

[majsta]

As you can see it is VHDL.
After some testing today I have some solutions but I need to confirm this.
Now I have working core but with problems with dtack and r/w and they sometimes work and need to find out why they don't work every time, but like you said it is in the manual.
Tomorrow I ll check FC0,1,2 signals as they are not implemented into TG68 core and they might have some relations to Read cycles but that's easy to solve...
I know about A0 solved that.
So in my opinion I need to done lot of modifications to TG68 but I m getting closer and again today I have got grey screen on Amiga so those are good news for bug tracking. It would not be so hard to finish this if there is any documentation for TG68 as some of the signals are inverted. For example there is no way to start core without inverting DTACK and inverting RESET shifted thru 2 registers. Why have no idea...

[majsta]

Ok new info.
1. Managed to start accelerator every time and found many problems with code and repair that.
2. Managed to disable old CPU and accelerator worked on 7.09Mhz as only CPU in system but there was no boot because there was some short circuit and now investigating that.

So at this point accelerator board is working and to my knowledge everything looks the same like on original CPU but there is no boot. But after solving all of those problems there is no much left to solve to start TG68 on basic frequency but lets wait for few more tests. I need to find out that short circuit and then it should boot. So when I look back at my work it could be done in just few days if only someone told me those simple steps but maybe noone didn't know.

1. Solve voltage level translation and program devices with FPGA
2. Join data_in data_out in TG68
3. There are no inverted signals in TG68
4. Disable old cpu taking BR and BGACK low and then only then start accelerator

Maybe now all of this looks easy for me now but really, one year ago I didn't know anything
I hope that in next few days we will see this working because I just don't think that so much is left to fix.

[robinsonb5]

Originally Posted by majsta

So at this point accelerator board is working and to my knowledge everything looks the same like on original CPU but there is no boot. But after solving all of those problems there is no much left to solve to start TG68 on basic frequency but lets wait for few more tests.

Exciting stuff! Good luck finding the (hopefully) last few problems and getting this working.

So when I look back at my work it could be done in just few days if only someone told me those simple steps but maybe noone didn't know.

That's the price of treading new ground. I know Tobiflex got an A500 running on the TG68, but apart from that it's entirely possible no-one else has ever attempted it.

Anyhow, once again, good luck

[NovaCoder]

Good work Majsta, keep it up

This is without doubt the future of Amiga Accelerators.....watch this space!

[gulliver]

@Majsta

Have you taken a look at Livio Plos accelerator´s design? It is very simple and a dead easy to build 68000 accelerator. It is very good for understanding the basics. So if you have a working 68000 core with proper processor signals you can in a very short time implement an usable accelerator.

Just read this EAB thread for further information:

http://eab.abime.net/showthread.php?...ght=livio+plos

Good luck with your project

[majsta]

@gulliver Zetr0's website does not work anymore and either way those schematics, samples of other accelerators can't be used here because TG68 core does not have all of the signals related to bus takeover so instead of creating those signals I decided to resolve it by adding some electrical components who can overcame those. Also I think that this is not proper solution adding 14Mhz CPU without logic components because there could be bus timings problems. But once accelerator is started at basic frequency it can be overclocked and only few signals needed to solve to get it done.

@robinsonb5 Believe me that I have contacted everyone who ever downloaded TG68 core and as far I know only Tobiflex managed to connect core to real hardware, everyone else didn't create anything and there is no proof.

[billt]

Originally Posted by majsta

@gulliver Zetr0's website does not work anymore and either way those schematics, samples of other accelerators can't be used here because TG68 core does not have all of the signals related to bus takeover so instead of creating those signals I decided to resolve it by adding some electrical components who can overcame those. Also I think that this is not proper solution adding 14Mhz CPU without logic components because there could be bus timings problems. But once accelerator is started at basic frequency it can be overclocked and only few signals needed to solve to get it done.

logic components? you've got an fpga. that should be all the logic components you should need in there. the only other things you should need are voltage adjustments outside the fpga and passive stuff (resistors, caps) and power.

why do you need more logic stuff?

[gulliver]

@majsta

I was pointing to that thread specifically because the circuit narmi suggests lets the L. Plos accelerator take over the Amiga bus in an easy and timing friendly way. Take a closer look.

[majsta]

@billt I was not talking about fpga accelerators. When I said that logic elements should be used I was thinking about various modifications on mounted on top of original CPU using Mc68010 or Mc68000 on 14Mhz without any other components and that could create bus timing difference.

[billt]

Originally Posted by majsta

@billt I was not talking about fpga accelerators. When I said that logic elements should be used I was thinking about various modifications on mounted on top of original CPU using Mc68010 or Mc68000 on 14Mhz without any other components and that could create bus timing difference.

Ah, sorry, my mistake in misunderstanding.

[ImmortalA1000]

If you get this working you should work on an A1200 020 softcore version because 15000 A1200 brand new computers are coming to market after being found in a warehouse. A1200 is crippled without fast ram and 14mhz is too slow for AGA, and Jens 28mhz ACA is too slow for the price.

[desiv]

Originally Posted by ImmortalA1000

...because 15000 A1200 brand new computers are coming to market after being found in a warehouse.

Wasn't it 1,500..

Still a good number

desiv

[Lord Aga]

Originally Posted by ImmortalA1000

If you get this working you should work on an A1200 020 softcore version

Yup, 100 MHz FPGA 020 for A1200 seems like the next big step in the Amiga world. It would be a killer add on.

[FOL]

Originally Posted by desiv

Wasn't it 1,500..

Still a good number

desiv

I find it strange that a warehouse is sitting there and forgotten about for such a long time.
They were sat there thinking, we need more space, oh look we can use warehouse 13, oh my its full of brand new amiga 1200's.
I dont think so, seems very strange.

[robinsonb5]

Originally Posted by Lord Aga

Yup, 100 MHz FPGA 020 for A1200 seems like the next big step in the Amiga world. It would be a killer add on.

The current '020 version of the TG68 (as used in the Chameleon Minimig port) is clocked at around 113Mhz but the controlling logic only allows it to run 1 cycle in 4, so it'd be more accurate to call it 28MHz. (The FPGA isn't up to running it flat out at more than about 35Mhz.)

Where things get very interesting with the FPGA, though, is the other things you can do - think custom processor instructions to speed up MP3 decoding, or using the inbuilt hardware multiplier in the FPGA to make the Multiply instruction run in a couple of cycles...