Amiga 500 68K Accelerator - DIY

[Methanoid]

Its a pity you have dropped Ram to 2Mb... Ram isnt expensive but Amigas need for WHDload :-(

[PR77]

Here's the schematic to put the Verilog in some perspective and the UCF. I've checked for shorts against neighbouring pins, local and downstream tracks and dry-joints. All "seems" OK. The thing is, sometimes the CPU runs for much longer and I see a various coloured screens (blue, yellow and red). This is pointing me to something silly in the Verilog which silly.

Originally Posted by Methanoid

Its a pity you have dropped Ram to 2Mb... Ram isnt expensive but Amigas need for WHDload :-(

Rev 4 will have more RAM. At this stage this is more of a learning project for me and to have a completely open design and based on the very cheap 68SEC000 (currently about 4€ per piece). I believe the Amiga community to some extent today and even back in the day when Commodore was still in business, suffered from over-priced HW. And, as fans we simply couldn't afford the cool stuff!

[Methanoid]

SPI for adding network ?? ;-). I am amazed at how many Indy projects like this are around. It shows how much we all love Amiga

Sent from my Redmi Note 4 using Tapatalk

[Stedy]

Originally Posted by PR77

Here's the schematic to put the Verilog in some perspective and the UCF. I've checked for shorts against neighbouring pins, local and downstream tracks and dry-joints. All "seems" OK. The thing is, sometimes the CPU runs for much longer and I see a various coloured screens (blue, yellow and red). This is pointing me to something silly in the Verilog which silly.



Rev 4 will have more RAM. At this stage this is more of a learning project for me and to have a completely open design and based on the very cheap 68SEC000 (currently about 4€ per piece). I believe the Amiga community to some extent today and even back in the day when Commodore was still in business, suffered from over-priced HW. And, as fans we simply couldn't afford the cool stuff!

A few comments on the schematic, some may help

1) Try changing R101 and R102 (DTACK/AVEC) from 10K to 2.2K, this helps the bus goto a safe level quickly when no-one drives the bus.
2) C113, on the output of the 3.3V regulator, is the wrong component type. You need a 10uF or greater Electrolytic or Tantalum capacitor. See section 8.2.2.1.3 of the datasheet, http://www.ti.com/lit/ds/symlink/lm1117.pdf. Your regulator will tend toward instability with an ESR of 0.05R against a lower limit of 0.3 ohms. Your CPLD may behave erratically.
3) The IDE buffers you've chosen are CMOS, the Amiga is TTL. Minimum Logic 1 of CMOS is 3.3V, minimum logic 1 of TTL (Amiga) is 2.4V. Change to HCT logic and all will be well.
4) Add some 10/22uF capacitors around the board for bulk power storage, they help smooth out 'gulps' of power.
5) CPU_CLK may be too slow for the FPGA, a 74LVC1G17 schmitt buffer is required to speed up the clock signal. If the rise/fall times of the signal are too slow the FPGA will not respond correctly. I can't remember the value for the XC95 series CPLD.
6) You should add 4.7K pull-up resistors to TDI, TCK and TMS to prevent unintended entry into JTAG test/programming mode.

I haven't looked at the Verilog yet. Make sure you tristate all signals you should.

[PR77]

Originally Posted by Stedy

A few comments on the schematic, some may help

1) Try changing R101 and R102 (DTACK/AVEC) from 10K to 2.2K, this helps the bus goto a safe level quickly when no-one drives the bus.
2) C113, on the output of the 3.3V regulator, is the wrong component type. You need a 10uF or greater Electrolytic or Tantalum capacitor. See section 8.2.2.1.3 of the datasheet, http://www.ti.com/lit/ds/symlink/lm1117.pdf. Your regulator will tend toward instability with an ESR of 0.05R against a lower limit of 0.3 ohms. Your CPLD may behave erratically.
3) The IDE buffers you've chosen are CMOS, the Amiga is TTL. Minimum Logic 1 of CMOS is 3.3V, minimum logic 1 of TTL (Amiga) is 2.4V. Change to HCT logic and all will be well.
4) Add some 10/22uF capacitors around the board for bulk power storage, they help smooth out 'gulps' of power.
5) CPU_CLK may be too slow for the FPGA, a 74LVC1G17 schmitt buffer is required to speed up the clock signal. If the rise/fall times of the signal are too slow the FPGA will not respond correctly. I can't remember the value for the XC95 series CPLD.
6) You should add 4.7K pull-up resistors to TDI, TCK and TMS to prevent unintended entry into JTAG test/programming mode.

I haven't looked at the Verilog yet. Make sure you tristate all signals you should.

Thanks for your hints. What I have tried so far without any luck;

1. CPU_AVEC is not used so it is simply tied high. CPU_DTACK is driven directly from the CPLD, with either 1'b0 or 1'b1. I will try to 1'bZ when not in use.

2+4. Done, but unfortunately has not helped. To be honest, I feel a little silly I missed this.

3. I haven't loaded these components yet. Just trying to debug the basics first. Will use the HCT though. I picked up on this some time back but forgot to update the schematic.

5. In my Rev 1 design, I used up to 20MHz XTAL oscillator modules without any issues. BUT they were driving a 68000P12 and a XC9572XL CPU. I don't think the 68SEC000 and XC95144XL will make a different but I will add a buffer in the next spin.

6. Will add these in the next spin. Good hint! I am keeping the Xilinx JTAG programmer connected to mitigate this.

[esel]

Nice to see progress on this cool card

[PR77]

So, I monitored the DATA bus during the corrupt start up and observed the following 3 word sequence;

SEQ 1: 0x11 0x11 0x4E 0xF9

SEQ 2: 0x00 0xFC 0x00 0xD2

SEQ 3: 0x00 0x0E 0x33 0xFC

SEQ 1 is correctly containing the magic number 0x11 0x11 and the JMP Opcode. The 68000 loads the (SP) with the first word in ROM, but this gets trashed by the EXEC later in the ROM execution. So far so good.

SEQ 2 is correctly fetching the (PC) register for the initial code. This is at 0x00FC00D2. It now gets interesting.

SEQ 3 is NOT what I expect at address 0x00FC00D2, HOWEVER this word sequence is at address 0x00FC0FD2! It would seem I have some ADDRESS lines stuck, however if that was the case the fetch of DATA in SEQ 1 and SEQ 2 would also be incorrect. Looking into the exec assembly this is an Exception() handler, however I believe this is coincidental as it does not seem to execute. There is where the processor goes into the weeds.

Keep in mind the /OVL is still not asserted so GARY maps ROM to base address 0x00000000 even though the physical addresses on the bus are at base 0x00FC0000.

My Saleae is only 8 channels so using /AS as a trigger only gives me 7 bits. So it takes time to decode the DATA and ADDRESS bus. If anyone lives around DE-51xxx with a logic analyser PM me!

I will try the following;

1. Hi-Z all CPLD address lines as a test.
2. Decode ADDRESS bus.

Any other ideas?

[PR77]

My dream is now a reality! Finally got it working! Ticking over at 30MHz!



EDIT: Popped a 40MHz crystal in... 4.27 MIPS and 4096 Dhrystones! Comment - Cowabunga!

[Niklas]

Originally Posted by PR77

My dream is now a reality! Finally got it working! Ticking over at 30MHz!

Congratulations! Well done.

[Methanoid]

Originally Posted by PR77

My dream is now a reality! Finally got it working! Ticking over at 30MHz!



EDIT: Popped a 40MHz crystal in... 4.27 MIPS and 4096 Dhrystones! Comment - Cowabunga!

Well done!! Q: is that IDE usable with case closed? I notice no other accelerators place IDE connector in that position

Sent from my Redmi Note 4 using Tapatalk

[PR77]

Originally Posted by Methanoid

Well done!! Q: is that IDE usable with case closed? I notice no other accelerators place IDE connector in that position

Sent from my Redmi Note 4 using Tapatalk

Will need a relocator board, however I already have to do a few changes to the PCB so I may move it to the top of the board or the right side. In addition I will route Pin 20 to VCC to allow for the DiskOnModule devices to get power without a power cable.

[Methanoid]

Good to know. Thanks

Sent from my Redmi Note 4 using Tapatalk

[dalek]

well done! looking good

[watman]

cool stuff! looking forward to the 4MB (or better yet - 8MB) version

[PR77]

For those interested, I've updated the Git;

https://github.com/PR77/A500_ACCEL_RAM_IDE-Rev-2

EDIT: From my last PCB run, I have several spare. I am happy to post to anyone interested for 2€ (token value) + Postage.

[PR77]

I think I now have the chained requests working, however the Alfa Data BSC Harddisk / FastRAM I have connected to the Amiga 500 Expansion Power "I believe" has 0x200000 fixed as the base address of the FastRAM.

My Patient Zero Amiga 500 has KS 1.2 so when I enable the Harddisk ROM it cyclically resets as KS 1.2 corrupts A6 and therefore can't boot externally.

@Plasmab, I would like to try to implement in my Verilog external devices AutoConfig first and then the accelerator cards AutoConfig devices. I would then be able to determine if my theory is correct about the fixed base address. Do you think this is do-able?

[plasmab]

Originally Posted by PR77

I think I now have the chained requests working, however the Alfa Data BSC Harddisk / FastRAM I have connected to the Amiga 500 Expansion Power "I believe" has 0x200000 fixed as the base address of the FastRAM.

My Patient Zero Amiga 500 has KS 1.2 so when I enable the Harddisk ROM it cyclically resets as KS 1.2 corrupts A6 and therefore can't boot externally.

@Plasmab, I would like to try to implement in my Verilog external devices AutoConfig first and then the accelerator cards AutoConfig devices. I would then be able to determine if my theory is correct about the fixed base address. Do you think this is do-able?

Your theory is correct.. but you cant allocate your devices last because how would you know when all the other devices are done? there is no feedback.

This is why 24 bit CPUs are no use for the Amiga. You need to put the ram in ZIII space or you're screwed. Hence the TF534.

EDIT: Almost all ZII autoconfig cards for the A500 have fixed bases because there isnt usually a way you can have two of them in the machine.

[patrik]

Originally Posted by PR77

I think I now have the chained requests working, however the Alfa Data BSC Harddisk / FastRAM I have connected to the Amiga 500 Expansion Power "I believe" has 0x200000 fixed as the base address of the FastRAM.

So you are saying that this expansion actually is pretending to be autoconfig?

[PR77]

Originally Posted by patrik

So you are saying that this expansion actually is pretending to be autoconfig?

That is my theory only with regards to the FastRAM base memory assignment (writes to offset 0x4A and 0x48). It simply relies on the fast that the Amiga will always assign 0x20000 so this address was fixed in the address decode PAL.

[plasmab]

Originally Posted by patrik

So you are saying that this expansion actually is pretending to be autoconfig?

Almost all cards for the A500 behave like this.

We had a huge discussion about this on my channel and that’s when I realised 24 bit autoconfig wasn’t going to let people use my cards and older add-on hardware at the same time.

It’s why I have completely dismissed 24 bit type chips in my project.