TF CD32 Riser Revision 2 Design Complete

68030 + SDRAM + IDE

Moderators: terriblefire, Terriblefire Moderator

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 701
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Mon Oct 19, 2020 1:17 am

terriblefire wrote:
Sun Oct 18, 2020 10:06 pm
Dont decode A[0] or you will never see the odd byte request.

e.g.

Code: Select all

wire JOY0DATA = A[23:1] == {20'hDFF00, 3'b101}; 
wire JOY1DATA = A[23:1] == {20'hDFF00, 3'b110}; 
I am struggling with access to JOY0/1DAT_L section of address. Still don't know why :(
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 701
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Mon Oct 19, 2020 9:05 am

What I think I need to do is to Arm ack (intsig7) transform to single pulse on rising edge of intsig7.

I don't know how long it takes for intsig7 signal to set and then reset, it can cover both cycles of data read.

So it may trigger arm interrupt, but I double check if interrupt is still pending, in this case I wouldn't see second read.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

terriblefire
Moderator Team
Moderator Team
Posts: 3454
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Mon Oct 19, 2020 11:45 am

arkadiusz.makarenko wrote:
Mon Oct 19, 2020 9:05 am
What I think I need to do is to Arm ack (intsig7) transform to single pulse on rising edge of intsig7.

I don't know how long it takes for intsig7 signal to set and then reset, it can cover both cycles of data read.

So it may trigger arm interrupt, but I double check if interrupt is still pending, in this case I wouldn't see second read.
You also MUST use an always block for the DTACK.

Code: Select all


always @(posedge CLKCPU_A or posedge AS) begin 
	
	if (AS == 1'b1) begin 
	
		DSACK_INT <= 2'b11;
	
	end else begin 
		
		DSACK_INT <= ... your logic ...
		
	end
	
end 

assign DSACK ? PUNT_INT ? 2'bzz : DSACK_INT;

if you dont understand the code above STOP and figure it out first. If you dont do this DTACK will not reset when the bus cycle ends. This will synchronously assert DSACK but disassert it as soon as AS is disasserted
———
I get cranky when asked to repeat myself.

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 701
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Mon Oct 19, 2020 5:41 pm

I have adapted this, and now DSACK0 should be asserted only on AS low, INTSIG7 up and when address is decoded and punt is ok.

Code: Select all

wire rtc_decode = A[23:16] == 8'b1101_1100; //RTC registers at $DC0000 - $DCFFFF read,
wire JOY0DATA = A[23:1] == {20'hDFF00, 3'b101}; 
wire JOY1DATA = A[23:1] == {20'hDFF00, 3'b110}; 

wire punt_int = rtc_decode|JOY0DATA|JOY1DATA;

reg rtc_int;
reg joy_int;
reg intsig_int;
reg dsact_int;
reg punt_ok;

always @(posedge CLKCPU_A) begin 
	rtc_int <= PUNT_IN & rtc_decode ;
	punt_ok <= PUNT_IN & punt_int;
	joy_int <= PUNT_IN & (JOY0DATA|JOY1DATA);		
end


always @(posedge CLKCPU_A or posedge AS20) begin 
	
	if (AS20 == 1'b1) begin 
		intsig_int <= 1'b1;
	end else begin 
		if (INTSIG7 == 1) begin
			intsig_int <= 1'b0;
		end else begin
			intsig_int <= 1'b1; 
		end	
	end
end 


// punt works by respecting the accelerator punt over our punt.
assign PUNT_OUT = PUNT_IN ? ( punt_int ? 1'b0 : 1'bz) : 1'b0;

assign INTSIG2 = rtc_int;
assign INTSIG8 = joy_int;   

assign DSACK = punt_ok?{1'b1, intsig_int}:2'bzz ;


assign INTSIG3 = A[3];
assign INTSIG5 = A[5];
edit:
But still can't see interrupts for A0 = 1 for some weird reason. I even replaced cpld hoping it it has shot A0 pin.

EDIT2.
Switched back to diagrom. I can see now both section read correctly. And data from H is as well in L.

Edit3.
No it is not read correctly. H and L are mirrored. I am going back to searching how to generate right lenght pulse from intsig7. Maybe this will solve my issue :)
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

terriblefire
Moderator Team
Moderator Team
Posts: 3454
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Mon Oct 19, 2020 8:02 pm

You should get H first then L i believe.
———
I get cranky when asked to repeat myself.

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 701
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Mon Oct 19, 2020 10:05 pm

terriblefire wrote:
Mon Oct 19, 2020 8:02 pm
You should get H first then L i believe.

That what I see in mirrored data. What I set up to be entered in H section is both in H and L. If it was reading L then H I would most likely see this other way round.

I have been trying to come out with some logic that would hold arm ack signal high only until AS is asserted and then wait for new rising edge on ack detection, but whatever I think off is bad syntax, I am trying to drive one signal from multiple sources or break on design template.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 701
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Mon Oct 19, 2020 11:58 pm

I started looking at this from ARM side and I do see unusual sequence of reads.

1 Read - (Address A) H section of data - data on bus is being mirrored to both H and L.
2 Read - (Address A) H section of data again - data on databus is ignored.
3 Read - (Address B) L section od data - data on databus is ignored.

CPU is always haltet on interrupt. So I can trace it read by read.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

terriblefire
Moderator Team
Moderator Team
Posts: 3454
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Tue Oct 20, 2020 9:15 am

When you word read address 0xDF0000 (lets say there is a word at this address 0x1234).

0x12341234 is put on the full data bus.

If you DSACK0 (8 bits) it will read 0x12 (D[31:24]) for this address.

It will then ask for a byte at 0xDF0001

0x34343434 is put on the data bus.

If you DSACK0 it will use the data bus bits D[31:24], if you DSACK1 it will use the data bus bits D[23:16].

Its dyamically sizing the bus. All you need to do is understand its BIG endian (the arm is LITTLE endian).

EDIT: i.e. before you send data to the CPLD do htons() on it.
———
I get cranky when asked to repeat myself.

User avatar
arkadiusz.makarenko
Trusted Guru
Trusted Guru
Posts: 701
Joined: Wed Jun 19, 2019 7:36 am
Location: Edinburgh

Re: TF CD32 Riser Revision 2 Design Complete

Post by arkadiusz.makarenko » Tue Oct 20, 2020 9:54 am

terriblefire wrote:
Tue Oct 20, 2020 9:15 am
When you word read address 0xDF0000 (lets say there is a word at this address 0x1234).

0x12341234 is put on the full data bus.

If you DSACK0 (8 bits) it will read 0x12 (D[31:24]) for this address.

It will then ask for a byte at 0xDF0001

0x34343434 is put on the data bus.

If you DSACK0 it will use the data bus bits D[31:24], if you DSACK1 it will use the data bus bits D[23:16].

Its dyamically sizing the bus. All you need to do is understand its BIG endian (the arm is LITTLE endian).

EDIT: i.e. before you send data to the CPLD do htons() on it.

I am setting up data bits on Data bus bit by bit in ARM, so at this point I am just placing counter data (8 bit counter +1 on each read), and I am looking at what is being received on Amiga side in Diagrom.

As I have access only to 8 bit of data bus, on each read I assert DSACK0 to ack that only byte is available, so to my understanding on next read cycle CPU should ask for address+1 (A0 - high), but it asks again for the same address reads it and ignore input, and then moved to address +1 and ignore it again (or places it somewhere where I can't see).
Do not trust people. They are capable of greatness.
~ Stanislaw Lem

terriblefire
Moderator Team
Moderator Team
Posts: 3454
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: TF CD32 Riser Revision 2 Design Complete

Post by terriblefire » Tue Oct 20, 2020 9:58 am

A simpler test would be to use diagrom to probe an area of RAM like B00000 ...

make the arm respond with the lower 5 bits address bits being sent.

that way you should see

00 01 02 03 04 05 06 07 08 .... up to 1F

then it repeats.

Decode like B000xx
———
I get cranky when asked to repeat myself.

Post Reply

Return to “TF330”