Amiga 500 68K Accelerator - DIY

[PR77]

Ok, fixed the slow down "bug". As expected I was delaying /DTACK. I have routed the CPU /DTACK directly to GARY so now I am relying on the Amiga to perform this task. So far I have not had any issues at 14MHz. 28MHz didn't but I suspect it was the 68K. It is an old HMOS P12F-9311 so I might order some newer HC variants. In case you are asking my E-CLK generation is based on the Amiga 7.14MHz CLK (so it easily remains sync'ed with the main CLK). This was a good design decision in the TF accelerators.

Simple SRAM timing calculation @ 14MHz is OK ((14MHz / 8) * 5 = 110ns). In fact 55ns would also be "just" OK at 28MHz.

So now I will move on to the IDE portion of the development. I've seen a few threads around which are not using /INT2, hence no GAYLE emulation. Might see how I get on here.

[PR77]

Well, no IDE support with this PCB spin. I have the data lines flipped. Might hack up the cable if I am feeling brave. But to be honest all these jumper wires are doing my head in. The most parts have now been proved out anyway.

[gregthecanuck]

Originally Posted by PR77

Well, no IDE support with this PCB spin. I have the data lines flipped. Might hack up the cable if I am feeling brave. But to be honest all these jumper wires are doing my head in. The most parts have now been proved out anyway.

I like how you put the jumpers and header pins in your initial designs. Makes a nice inexpensive way to debug/patch without having to cut/patch traces. Something to remember.

Cheers!

[PR77]

Some details relating to my accelerator project have been posted here;

http://eab.abime.net/showpost.php?p=...postcount=2528

[PR77]

A quick update. I have been trying to decouple the MC6800 interface signals (/VPA, /VMA and E) from the MC68000 processor to make room for the 68SEC000 versions when they come. As this version does not have the MC6800 peripheral interface it essentially needs to be created. Even though my accelerator is currently still using the MC68000 this shouldn't matter as it will just be a longer bus cycle by delaying /DTACK.

This has not been going well unfortunately. My 2 channel TDS220 wasn't cutting it so I had to dust off my old "Saleae Logic". It helps, but 24MS/s is a fraction too slow for 7MHz so it is a bit hard to ensure the correct processor states.

@Plasmab, I've had a look at your 6800.v in your DEV branch but I am totally confused. It is too optimised I think... I have taken a similar approach with a counter to determine where in the E phase I am, however I can't see in your verilog how to ensure the /VMA doesn't take too long. Mine is in the second low phase (see attached picture). Is there some kind of trickery with the counter?

In my trace, my bus cycle is terminating because during the MC6800 cycle my /DTACK doesn't seem to get asserted. This is a different issue though.

[plasmab]

Originally Posted by PR77

@Plasmab, I've had a look at your 6800.v in your DEV branch but I am totally confused. It is too optimised I think... I have taken a similar approach with a counter to determine where in the E phase I am, however I can't see in your verilog how to ensure the /VMA doesn't take too long. Mine is in the second low phase (see attached picture). Is there some kind of trickery with the counter?

In my trace, my bus cycle is terminating because during the MC6800 cycle my /DTACK doesn't seem to get asserted. This is a different issue though.

Eh? Its absolutely bare bones? It defines the E clock and when DTACK is asserted to simulate the response from VMA? what is optimized?

/* This block takes care of the VMA signal
 * which is used to acknowledge to old 6800
 * style hardware that a bus transfer has 
 * happened. Resets when the CPU AS is disasserted */
always @(posedge CLK7M or posedge VPA) begin

	if (VPA == 1'b1) begin 
	
		 VMA_SYNC <= 1'b1;
	
	end else begin 
	
		if (Q == 'd9) begin
		
			 VMA_SYNC <= 1'b1;
		
		end

		if (Q == 'd2) begin

			VMA_SYNC <= VPA | CPUSPACE;
		
		end 

	end

end

VMA is disasserted async when VPA is disasserted. What is unclear about that. It happens on the posedge of VPA.

[plasmab]

@PR77 you dont seem to understand verilog

My code in the example above translates to a D-Type Flip flip as follows


CLK = CLK7M
CE = 1
PRE = VPA
CLR = 0
D = (Q == 'd9) | ((Q == 'd2) & (VPA | CPUSPACE));
Q = VMA_SYNC

*Note that CLR is not wired up so its 0, and CLK Enable (CE) is hard wired to 1.

Thats it. Its really really simple verilog. The sensitivity list has VPA and CLK7M. I have no idea why you think that is optimized. Its the only correct way to do it.

(only correct way to disassert async, there may be other ways to do the 6800 bus).

*Note any other way of disasserting VMA needs a counter and a known relationship between the 7M clock and the fast clock. Thats why i used to have 25,40,50mhz firmwares. I fixed this with this approach.

[PR77]

@Plasmab, I will try your verilog as is. I have thought over this and my original thinking was the /VMA assertion phase (Q2) needs to come also with an E_CLK edge, but that happens anyway when Q == 2. I missed this obvious point.

Another question, the CPUSPACE (&FC[2:0]) or'ing with VPA- Reading the MC68000 datasheet I understand that you are doing this essentially to hold off on the VMA if the CPU Space bus cycle is active- interrupt acknowledge cycle. Is this correct, or does it have something to do with you '030 implementation?

[plasmab]

Originally Posted by PR77

@Plasmab, I will try your verilog as is. I have thought over this and my original thinking was the /VMA assertion phase (Q2) needs to come also with an E_CLK edge, but that happens anyway when Q == 2. I missed this obvious point.

Another question, the CPUSPACE (&FC[2:0]) or'ing with VPA- Reading the MC68000 datasheet I understand that you are doing this essentially to hold off on the VMA if the CPU Space bus cycle is active- interrupt acknowledge cycle. Is this correct, or does it have something to do with you '030 implementation?

The 030 and 020 has an AVEC pin. I set that differently and keep it away from the sync bus for performance reasons. Amiga doesn’t use AVEC or VPA for interrupt acknowledge anyway.

[PR77]

No positive advancement updates unfortunately. Still can't get the Amiga to work with my emulated 6800 interface. I keep getting a green boot screen (if I am lucky) and no assertion of /DTACK (CPLD to CPU). I am not sure if I need to consider DMA cycles where /BR, /BG and /BGACK are used. I don't have the system (accelerated CPU and Amiga) de-coupled enough (and working) to dig deeper. Any advice would be greatly appreciated.

BTW, to keep the emulation simple, I have the MC68000 running at MB_CLK = 7 MHz. So the acceleration is bypassed.

P.S., on a positive note, I did finish restoring my A1200 with the works! Even a new keyboard membrane!

[pandy71]

Details on timing are provided in Gayle specification.

https://storage.googleapis.com/googl...dram/gayle.pdf

Or

https://computerarchive.org/files/co...Manual-ENG.pdf

[PR77]

Thanks. I will change the generated E_CLK to synchronize on the falling edge of the 7MHz clock. I didn’t really find anything in the MC68000 datasheet that indicates this is necessary, however when checking the Gayle timing this is clear.

I realized my /DTACK wasn’t asserting because /AS went high in the specific E_CLK phase. ... but I would have thought wait states would have been inserted.

[PR77]

Finally! Done! It was completely stupid, I didn't externally pull-up the MC68000 /VPA input. More to come!

[PR77]

Small update. Now with the MC6800 emulation working, I am having difficulties with the clock domains playing nicely (7MHz base and asynchronous CPU input). My previous "implementation" was simply using the processor for the MC6800 cycles and delaying the /DTACK to processor by 1 7MHz clock cycle. This worked fine for double performance... But who wants that!

My goal is asynchronous MC68SEC000 clocking so I can go up to 50MHz (just like my Minimig). Even 16MHz would be a good start!

[PR77]

HAPPY DAYS!!!

Got asynchronous clocking working with an external crystal. Got my MC68000P12 now running at 20MHz, 1.16 MIPS (I have an extra WS in the FastRAM access which I will remove once I have integrated the design into a single CPLD. I am expecting closer to 2 MIPS).

Then when I get my 68SEC000, 50MHz will just be around the corner.

[huepper]

[PR77]

I couldn't wait! I added a signal between my two CPLDs (one is for FastRam and AUTOCONFIG and the other is the accelerator- as they are only 44 pin devices I needed two) to indicate a fast cycle and thus not insert any waitstates on the /DTACK assertion. It paid off, that is for sure.

I had to slow down my MC68000P12 because at 20MHz it wasn't very stable and sometimes wouldn't boot. Running now at 18.4 MHz and 1.96 MIPs! I am SUPER happy!

I also attached a photo of my setup before I fixed the speed issue for those who are interested.

I really can't wait for my 68SEC000's nows! I will make this design COMPLETELY open once it is more refined and not a big mess of wires.

[plasmab]

I strongly recommend not setting the Amiga /AS when you’re accessing fastmem to prevent accidental reads/writes to the Amiga when accessing fastmem.

[PR77]

Originally Posted by plasmab

I strongly recommend not setting the Amiga /AS when you’re accessing fastmem to prevent accidental reads/writes to the Amiga when accessing fastmem.

Thanks for the hint. I decoupled the FastRAM cycles with the Amiga /AS when I added the link between the two CPLDs. I guess it was the right thing to do.

P.S.,When you're dropping me hints I _know_ I'm on the right track!

[plasmab]

My brain is entire consumed with the 3 instrument approaches I have to make in 30 minutes ...