First Amiga 600 FPGA Accelerator - Vampire 600

[majsta]

@robinsonb5
I see this project to go on exactly that way. Replacing this MC68K with FPGA gives you everything you have on modern computers: various controllers etc...

Regarding to TG68, this will be used just to prove that design is working but there are much faster cores there so...

Now I m building logic analyzer to fix my A600 boards because I don't have single one that is working, and can't fix them without logic analyzer. Anyhow there are few more test I need to finish on this accelerator but he is working but somehow timings are different then original cpu, so until I repair one A600 board I can't give you any proof that this concept of mine worked...Only this litle part...

But where did you find information about production of new A1200 ???

[matthey]

Originally Posted by majsta

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.

It must not be easy whether it's real hw<->fpga or fpga<->fpga. Jens (Deep Sub Micron) doesn't have the N050 softcore working in the Natami prototypes either. I think he knows what he's doing too.

Originally Posted by majsta

But where did you find information about production of new A1200 ???

I don't think it's new production but rather found old stock:

http://www.amiga.org/forums/showthread.php?t=61870

[Amiga1992]

Originally Posted by matthey

I don't think it's new production but rather found old stock:

http://www.amiga.org/forums/showthread.php?t=61870

So if he cons 500 suckers into buying his machines which might have fucked capacitors (in storage for so long??) at 150 euros (!!), he'll save this year's accountancy with 75000 easy euros.

I don't know about you, but I don't trust any ex-Amiga rep.

[kipper2k]

Originally Posted by Akira

So if he cons 500 suckers into buying his machines which might have fucked capacitors (in storage for so long??) at 150 euros (!!), he'll save this year's accountancy with 75000 easy euros.

I don't know about you, but I don't trust any ex-Amiga rep.

Let a few people buy it first and wait for any fallout, it wouldnt take long. Someone will always break the seal as soon as they rip the plastic off lol

Hmmm, i would probasbly be in that group

[billt]

About the 3V/5V level shifting issue, I saw an article today. Sounds like it's expected to work up to 1Mbps signal rate, which I'm not sure if it's fast enough for this kind of thing or not.

http://www.eetimes.com/design/analog...ystem=embedded

[majsta]

According to my calculations I provided 13Mbps and just send email to confirm that this should be enough. I m finishing PCB rev 1.2 and need to send it to production tomorrow so I m double checking everything and see no problems...
Read this page 5
http://focus.ti.com/pdfs/logic/gtlp.pdf

[Stedy]

Hi Majsta,

Consider these TTL bus switch devices, http://www.ti.com/product/sn74cbt3384a.

Incident wave switched devices like the GTLP, designed for a backplane will wreak havoc inside the Amiga. With upto 100mA drive, GTLP devices are designed for impedance controlled and terminated backplanes, like VME (which I know well). The Amiga quite happily uses 4mA TTL logic, would not use more than 12mA drive strength.

If you want a schematic review done, PM me.

Ian

[majsta]

I don't use GTPL, I use ALVT devices BiCMOS 5V tolerant and only problem here is VT on BiCMOS devices 1.5V and on CMOS or TTL could go to 2.5V but people from NXP told me that this should not be a problem. Also ALVT devices provide 12mA and like I said 13Mbps up to more then 40MHz per signal so for basic version this should be enough. Also there is other side on ALVT devices who is connected to PLCC68 socket and from there Amiga can accept LVCMOS signals regarding to VIH or VIL rates so external pull up resistors are not needed here. Again maybe I m wrong here but i checked everything million of times and I conclude that ALVT devices can be used in this process. Yes there are number of better solutions but those ALVT devices are only one I could get for reasonable price. Better solution is for example dual voltage drivers like 8 bit TXB0108 but this complicates design regarding of providing 5V and 3.3V VCC to one device so I decide to use drivers who are 5V tolerant.
@ Stedy you are talking about quickswich devices by TI, IDT or Pericom and they can solve this but only Pericom produce 16 bit ones and those are hard to find for me. Like PI5C34X245. Please read my paper regarding voltage level translation at:
http://majsta.com/modules.php?name=N...article&sid=13

[Stedy]

@majsta

You only need voltage level translation on 26 signals,
D15-D0, BR, BGACK, IPL0, IPL1, IPL2, RESET, HALT, BERR and VPA.
Of these, BR, BGACK, IPL0-2, BERR and VPA are input only and only need fixed direction control.

For the databus, use the R/nW signal to control any direction signals, though if you use the parts I recommend, you do not need to worry. I have used the CBTD3384 devices on PCI bus for the last 3 years with no issues.

You do not need voltage level translation on output only signals, like the address bus, providing the FPGA can drive compatible levels, which I'm sure it can. The MC68000 outputs 2.4V for Voh (min) so you need to check the I/O types of the FPGA and ensure it meets that. Vol, is normally ok across all 3.3V I/O ranges. Over the last 13 years, I have successfully interfaced 5V, 3.3V, 2.5V and 1.8V logic. Not paying attention to the input and output levels is where most junior engineers slip up.

Ian

[Shadowfire]

Stedy -
I'd still put some sort of voltage protection on all the lines, since other 5V devices can become bus master and drive those lines (address bus, etc). I doubt that tristating the outputs will stop a short through the device's internal protection diodes.

[majsta]

Yes you need to secure all the lines because you may decide to leave original CPU running for some time and then to take over the bus once core is started. Also I think that voltage level translation needs to be bidirectional and it needs to have all signal translated back to CMOS. Some signals, for example R/W is used from other devices and those devices may have problem with LVCMOS signals send by FPGA. So next step in my voltage level translation research is dual voltage translators VCC(A) track A side of the translator (LVCMOS) and VCC(B) track B side (CMOS).

[kipper2k]

I have been looking at the Max13103 level shifters for a project that offers internal bidirectional logic level shifting based on user voltages that is TTL compatible they have different channel width, they are not too cheap but they would save a lot of space and extra components that may be needed if using other methods

[majsta]

I have already selected devices, ordered them, and done every modifications to the PCB. There are number of the devices that can solve those problems but like you said they are not cheap and most of them are octal bus drivers but there are few that have 16 channels and those are the one I found and they will be used in the design. I know that number of people was talking that LVCMOS can be accepted by the rest of Amiga board but all of my testings are saying that this could drive to some problems and I just want to remove that from my mind by doing proper voltage level translation. For example I have more then 200 buffers from original design who are 5V I/O tolerant but they just can't do the job...

[majsta]

Work continues, two days ago received new PCB's with lot of modifications. One assembled and first testings done.
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. HALT separated into halt_a and halt_b, halt_a input and halt_b output from FPGA. You can see that FPGA sends low halt_b and receives low halt_a
3. RESET is also separated
4. 2-wire bus arbitration is used so FPGA sends BR low and receive low BG so this is prove that MC68K detect new device and confirm that sending BG. I also left possibility for 3-wire bus arbitration creating BGACK as output signal from FPGA to original CPU
5. For the first time there is also movement on R/W signal and regarding to that you can notice that Voltage level translators are changing direction for bidirectional data signals.

Problems:
Like I said before I don't have working A600 board anymore and need to repair one or order new one but please I would like to see comments regarding to logic data picture.

[Stedy]

Hi,

Looking at the logic analyser trace I can see the following.:
The data is active for S1-S7 of the CPU clock (Good),
AS, UDS and LDS are active for the correct length of time (good),
RnW toggles correctly.

The potential issues are:
An interrupt has occurred, IPL= 6 which means interrupt 0 has been triggered.
Could do with seeing the FC2-FC0 bits, this helps to relate the timing signals as they are set on S0.
nDTACK is stuck low, it should toggle with each address phase (unless this is an Amiga peculiarity). This is most likely screwing things up as the TG68K core will keep inserting wait states until DTACK is de-asserted (logic 1) but your design carries on regardless.

Can you also show the state of the VPA signal?

Ian

[Lord Aga]

Bravo brate
Just keep going, never give up !

[majsta]

@Stedy Thank you for review VPA is not used since on A600 motherboard is tied with BR using Pull up resistor, and since on this board motherboard only CPU was working this is the best I could do. Also on this design FC2-FC0 are not connected in any way to FPGA. I can't provide any more info because I don't have working A600 motherboard and need to wait for PLCC sockets for other chips on board and for logic probes and connect them to this Accelerator to see what's wrong with my motherboards but I ll have to find a way to order one more for comparing. There is always something taking me back...

[majsta]

Like I said I don't have working A600 motherboard and don't have equipment to actually "catch" signals and determine what's wrong. So I created Logic Analyzer using my FPGA Accelerator board. 5 minutes job and now I have serious equipment. Check video

[ Show youtube player ]

1. Accelerator uses VCC from Amiga motherboard
2. Connection to the PC using JTAG->USB
3. One probe from Accelerator
4. VHDL code (one part for translators, second one for probe , third for LED who depends on probe status)

[majsta]

FIRST START:

[ Show youtube player ]

[mfilos]

Some progress going on!
Congratz mate! Keep up the good work and updating us! \o/