Open Source 68K Accelerator Project(s)

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Mon Nov 28, 2016 10:01 pm

this is part of the IACK.
as you wrote above, from the CPU stand point, /IACK is what you wrote. On a ST, the GLUE takes this and generate an actual /IACK signals that goes to the MFP /IACK pin.
So the MFP triggers IRQ, which goes to the GLUE /MFPINT pin (level 6 interrupt). The GLUE then assert the IPLx accordingly. At this point the 68020 finish its current bus access and then goes into interrupt acknowledge (IACK) mode (FCx = 0b111 and A[19:16] = 0b1111). The GLUE assert IACK on the MFP, MFP puts vector on bus, CPU reads it, finishes IACK cycle and jump to vector. In this case AVEC is not asserted and all of this is part of the IACK cycle.
Now when an ACIA triggers an interrupt, the GLUE will also assert /VPA, in this case , the interrupt ack cycle will use AVEC as the ACIA can't generate vector.
From the user manual :
For a device that cannot supply an interrupt vector, the AVEC signal can be asserted, and the MC68020/EC020 uses an internally generated autovector, which is one of vector numbers 31–25, that corresponds to the interrupt level number.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

czietz
Captain Atari
Captain Atari
Posts: 353
Joined: Tue May 24, 2016 6:47 pm

Re: Open Source 68K Accelerator Project(s)

Postby czietz » Mon Nov 28, 2016 10:02 pm

PS: The sections in the 68020 manual are "5.4.1.1 INTERRUPT ACKNOWLEDGE CYCLE—TERMINATED NORMALLY", "5.4.1.2 AUTOVECTOR INTERRUPT ACKNOWLEDGE CYCLE" and "5.4.1.3 SPURIOUS INTERRUPT CYCLE".

terriblefire
Atari freak
Atari freak
Posts: 68
Joined: Sat Nov 12, 2016 10:15 am

Re: Open Source 68K Accelerator Project(s)

Postby terriblefire » Mon Nov 28, 2016 10:05 pm

Thanks. I dont think the amiga ever uses these kind of interrupts and hence why i never see an issue on it.

czietz
Captain Atari
Captain Atari
Posts: 353
Joined: Tue May 24, 2016 6:47 pm

Re: Open Source 68K Accelerator Project(s)

Postby czietz » Mon Nov 28, 2016 10:05 pm

rpineau wrote:Now when an ACIA triggers an interrupt, the GLUE will also assert /VPA, in this case , the interrupt ack cycle will use AVEC as the ACIA can't generate vector.


Aren't the ACIA interrupts handled entirely by the MFP? Both ACIA's IRQ lines are connected to an MFP input only. Hence it generates a vector for that interrupt as well. HBLANK and VBLANK are auto-vector interrupts in the ST, though.

terriblefire
Atari freak
Atari freak
Posts: 68
Joined: Sat Nov 12, 2016 10:15 am

Re: Open Source 68K Accelerator Project(s)

Postby terriblefire » Mon Nov 28, 2016 10:11 pm

rpineau wrote:this is part of the IACK.
as you wrote above, from the CPU stand point, /IACK is what you wrote. On a ST, the GLUE takes this and generate an actual /IACK signals that goes to the MFP /IACK pin.
So the MFP triggers IRQ, which goes to the GLUE /MFPINT pin (level 6 interrupt). The GLUE then assert the IPLx accordingly. At this point the 68020 finish its current bus access and then goes into interrupt acknowledge (IACK) mode (FCx = 0b111 and A[19:16] = 0b1111). The GLUE assert IACK on the MFP, MFP puts vector on bus, CPU reads it, finishes IACK cycle and jump to vector. In this case AVEC is not asserted and all of this is part of the IACK cycle.
Now when an ACIA triggers an interrupt, the GLUE will also assert /VPA, in this case , the interrupt ack cycle will use AVEC as the ACIA can't generate vector.
From the user manual :
For a device that cannot supply an interrupt vector, the AVEC signal can be asserted, and the MC68020/EC020 uses an internally generated autovector, which is one of vector numbers 31–25, that corresponds to the interrupt level number.


Reading that it sounds like i should simply not assert AVEC? I have difficulty here understanding how the glue can know whether the external device is going to place an autovector on the bus or not?

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Mon Nov 28, 2016 10:14 pm

They are indeed (to IO4), but on our 68020 card if we don't do the AVEC using VPA, we don't get any int and no keyboard (from memory, may be I'm wrong).
So not quite sure what's going on there. I'll see if I can log some trace with the logic analyser next time to see what is going on when there is an ACIA interrupt.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Mon Nov 28, 2016 10:20 pm

@terriblefire: The code for AVEC is simple and should be there, even if not used.
The GLUE only generate /IACK from the state of the CPU pins. The MFP will DTACK when putting the vector number on the bus. and in the case of a device that can't put a vector, VPA is probably asserted (the GLUE knows when an ACIA is accessed and will generate VPA).
You code for AVEC looks good to me (it match our VHDL code). I assume the pin is negated after as AVEC is active LO (/AVEC on the CPU).
As for any other interrupt, the device will put a vector on the bus and assert /DTACK (/DSACK1) so the CPU can retrieve the vector number.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

terriblefire
Atari freak
Atari freak
Posts: 68
Joined: Sat Nov 12, 2016 10:15 am

Re: Open Source 68K Accelerator Project(s)

Postby terriblefire » Mon Nov 28, 2016 10:26 pm

@rpineau there is no /IACK pin. This is an internal signal I presume?

The code I am running on the REV1 board right now (in the demo on the video).... does

assign DSACK1 = (CPUSPACE) | (AS20DLY | AS20 | DTACK) & (AS20DLY | AS20 | DSACK1_SYNC);


Which i believe will hold DSACK1 high when the CPU is accessing CPUSPACE. This is likely the issue.

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Tue Nov 29, 2016 12:48 am

Yes, the IACK pin is a pin on the Atari GLUE chip and is generated from the 68000 (68020) interrupt acknowledge signals (FCx and A19-A16) by the GLUE ( 68020 -> bus -> GLUE -> IACK -> MFP and then MFP DTACK -> bus -> CPLD - DASCK1->68020)
So for you, there should not be anything to do regarding IACK. You just need to get DASCK1 asserted when the MFP assert DTACK (placing the interrupt vector on the data bus) and AVEC with the "internal" IACK you're generated and /VPA if needed (so only if IACK and VPA are asserted).

Your DASCK1 code looks good (I assume the DASCK1_SYNC is the delayed DTACK as the CPU is running async to the bus, we have something similar on our board and by the name of the signal .. we all read the same application notes and LUCAS doc :) ).
Regards, Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

ijor
Hardware Guru
Hardware Guru
Posts: 2923
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby ijor » Tue Nov 29, 2016 2:17 am

I don't have much experience with ST accelerators, but I think I do know something about ST internals ...

rpineau wrote:They are indeed (to IO4), but on our 68020 card if we don't do the AVEC using VPA, we don't get any int and no keyboard (from memory, may be I'm wrong).


The only autovec interrupts on the ST are the video interrupts generated interally by GLUE. All other interrupts go through the MFP and are not autovector. Can't be any other way, because as Christian is saying, the only interrupt pin coming to GLUE is the MFP's one.

BUT, the ACIA is a slow device, and GLUE generates the VPA signal for every access to the ACIAs. This makes the CPU to follow the 6800 protocol and run a synchronous bus access. This doesn't happen on an ACIA interrupt, because the interrupt ack cycle is run through the MFP. The ACIA is not involved.

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Tue Nov 29, 2016 4:54 am

@Ijor
Yep, you're right about the ACIA.
As for GLUE interrupt, yes but no on a MegaSTE where there are 2 more interrupt : 3 (VME) and 5 (SCC).
The SCC has a vector register so behave like the MFP in that regard.
For the VME interrupt, the card is supposed to provide an interrupt vector too I believe.
so If I'm not mistaken :
1 -> Unused
2 -> HBL (auto-vectored)
3 -> VME (require a vector on the data bus with DTACK as seen on some card so this is known, can be auto-vectored ?)
4 -> VLB (auto-vectored)
5 -> SCC (vector on the data bus with DTACK))
6 -> MFP (vector on the data bus with DTACK))
7 -> NMI

Which mean you're 100% right and I was wrong.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Tue Nov 29, 2016 5:08 am

So in the light of Ijor's comment and what I put above it's clear that we all looked at the same motorola AN944 and Lucas doc and blindly copied the code for AVEC.
My understanding is that the AN944 did this because Motorola assume that if you use 6800 series devices you'll auto-vector the interrupt (not the case in a ST/STE/MSTE/TT/Falcon).
So I'll have to change my VHDL code to make /AVEC tri-state when not actually asserted from the ST.
Also I guess the implementation of /AVEC on any 68020 system depends on the system itself as it depends on what devices are present and what interrupt they can trigger (with vector on the data bus + DTACK or without using /AVEC).
Regards, Rodolphe

Edit : my new VHDL code for AVEC :
AVEC <= '0' when (FC2 = '1' and FC1 = '1' and FC0 = '1' and A19 ='1' and A18 = '1' and A17 ='1' and A16 = '1' and VPA = '0') else 'Z';
Last edited by rpineau on Tue Nov 29, 2016 5:55 pm, edited 1 time in total.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Tue Nov 29, 2016 7:49 am

On the MegaSTE which uses the TTSCU for interrupt control, the TTSCU /AVEC output is tie to VPA. So that's how the TTSCU makes auto-vectored interrupt.
On STE/STF the GSTMCU/GLUE probably also assert /VPA for auto-vectored interrupt which is why my /AVEC code worked on the STE and MegaSTE.
So /AVEC is really tied to the machine architecture.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Tue Nov 29, 2016 7:56 am

The 68000 user manual is explaining that you need to use VPA (or /AVEC) for auto-vectored interrupt :
Screen Shot 2016-11-28 at 23.55.06 PM.png


Which makes it a lot clearer as to why we use VPA to generate /AVEC now.
You do not have the required permissions to view the files attached to this post.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

terriblefire
Atari freak
Atari freak
Posts: 68
Joined: Sat Nov 12, 2016 10:15 am

Re: Open Source 68K Accelerator Project(s)

Postby terriblefire » Tue Nov 29, 2016 10:07 am

rpineau wrote:The 68000 user manual is explaining that you need to use VPA (or /AVEC) for auto-vectored interrupt :
Screen Shot 2016-11-28 at 23.55.06 PM.png

Which makes it a lot clearer as to why we use VPA to generate /AVEC now.


Hi. I removed CPUSPACE inhibitor from the DSACK1 signal generation. It made no difference.

Here is a VCD of what im capturing from the bus.

https://www.dropbox.com/s/a0ue33jg2mveg ... 1.vcd?dl=0

If you guys want any more signals sniffed let me know. I would have to remove either the IPL or FC signals to get more in there as I'm limited to 32 signals in total.

EDIT: More signals at the expense of IPL/FC

https://www.dropbox.com/s/qk0qkbqk6y4uw ... e.vcd?dl=0

Unsure whats going on here. By the length of the cycle i'm assuming it gets terminated by a VPA. I really need to see what the ST is doing with DTACK and VPA during all this. those signals are harder to get at with the logic probes. If the ST wants me to take the different Interrupt vector here then it should be asserting DTACK which i dont believe it is.

This is the code i have. I keep thinking i found the issue but i never seem to.

http://pastebin.com/Y3QNxi4L
Last edited by terriblefire on Tue Nov 29, 2016 11:16 am, edited 3 times in total.

ijor
Hardware Guru
Hardware Guru
Posts: 2923
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby ijor » Tue Nov 29, 2016 10:32 am

rpineau wrote:On STE/STF the GSTMCU/GLUE probably also assert /VPA for auto-vectored interrupt which is why my /AVEC code worked on the STE and MegaSTE.


Yes, of course. GLUE asserts VPA both for any access to ACIA (but not on an ACIA interrupt, because ACIA is not accessed in this case), and for the internally generated video interrupts as well. The latter must be done because that's the way the CPU knows the interrupt is autovector. From the software side is almost obvious, because both cases produce timing jitter as a consequence of the CPU synchronizing with the E clock on response to the VPA signal.

And the reason that GLUE uses autovector for its own interrupts is simply because it is not fully connected to the data bus. Can't provide a vector of its own.

I'm not really familiar with the MegaSTe.

ijor
Hardware Guru
Hardware Guru
Posts: 2923
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby ijor » Tue Nov 29, 2016 12:06 pm

terriblefire wrote:By the length of the cycle i'm assuming it gets terminated by a VPA.


Not trying to play semantics, but VPA doesn't exactly terminates the bus cycle. VPA triggers a synchronous (to the E clock) bus cycle that the CPU terminates itself in its own timing.

I really need to see what the ST is doing with DTACK and VPA during all this. those signals are harder to get at with the logic probes.


DTACK is available at the MFP. VPA is on the CPU socket. Also both signals have pullups on the main board. The exact location would vary depending on the motherboard revision though.

Probing GLUE (or MMU) signals without soldering is indeed difficult. I once trying to search for suitable probes. The only thing I found was a full PLCC adapter that exposes all signals and costs an arm and a leg.

terriblefire
Atari freak
Atari freak
Posts: 68
Joined: Sat Nov 12, 2016 10:15 am

Re: Open Source 68K Accelerator Project(s)

Postby terriblefire » Tue Nov 29, 2016 12:15 pm

terriblefire wrote:
rpineau wrote:The 68000 user manual is explaining that you need to use VPA (or /AVEC) for auto-vectored interrupt :
Screen Shot 2016-11-28 at 23.55.06 PM.png

Which makes it a lot clearer as to why we use VPA to generate /AVEC now.


Hi. I removed CPUSPACE inhibitor from the DSACK1 signal generation. It made no difference.

Here is a VCD of what im capturing from the bus.

https://www.dropbox.com/s/a0ue33jg2mveg ... 1.vcd?dl=0

If you guys want any more signals sniffed let me know. I would have to remove either the IPL or FC signals to get more in there as I'm limited to 32 signals in total.

EDIT: More signals at the expense of IPL/FC

https://www.dropbox.com/s/qk0qkbqk6y4uw ... e.vcd?dl=0

Unsure whats going on here. By the length of the cycle i'm assuming it gets terminated by a VPA. I really need to see what the ST is doing with DTACK and VPA during all this. those signals are harder to get at with the logic probes. If the ST wants me to take the different Interrupt vector here then it should be asserting DTACK which i dont believe it is.

This is the code i have. I keep thinking i found the issue but i never seem to.

http://pastebin.com/Y3QNxi4L


EDIT2: VPA is not asserted. Nor is DTACK during the interrupt ack cycle. very odd...

terriblefire
Atari freak
Atari freak
Posts: 68
Joined: Sat Nov 12, 2016 10:15 am

Re: Open Source 68K Accelerator Project(s)

Postby terriblefire » Tue Nov 29, 2016 12:42 pm

ijor wrote:
terriblefire wrote:By the length of the cycle i'm assuming it gets terminated by a VPA.


Not trying to play semantics, but VPA doesn't exactly terminates the bus cycle. VPA triggers a synchronous (to the E clock) bus cycle that the CPU terminates itself in its own timing.

I really need to see what the ST is doing with DTACK and VPA during all this. those signals are harder to get at with the logic probes.


DTACK is available at the MFP. VPA is on the CPU socket. Also both signals have pullups on the main board. The exact location would vary depending on the motherboard revision though.

Probing GLUE (or MMU) signals without soldering is indeed difficult. I once trying to search for suitable probes. The only thing I found was a full PLCC adapter that exposes all signals and costs an arm and a leg.


Soldering is not an issue. Question.. are the IPL lines pulled up on the Atari ST? Seems that the ST has no idea that its asserting the IPL lines as it doesnt respond to the interrupt acknowledge.

terriblefire
Atari freak
Atari freak
Posts: 68
Joined: Sat Nov 12, 2016 10:15 am

Re: Open Source 68K Accelerator Project(s)

Postby terriblefire » Tue Nov 29, 2016 12:56 pm

Ok. I managed to capture DTACK and VPA.

https://www.dropbox.com/s/bhiso3vfnvwjj ... e.vcd?dl=0

I have no clue why the ST isnt responing to this interrupt ack.

EDIT: I am seeing IACK right where I am supposed to see it (I tapped off pin 45 on the MFP).

https://www.dropbox.com/s/ueo1nde00jv44wz/iack.vcd?dl=0

Its the MPF that asserts DTACK in this scenario right? Do i need UDS/LDS set for that to happen? I feel like im missing something dumb

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Tue Nov 29, 2016 4:02 pm

yes you need to assert /LDS and/or /UDS as this is how the MFP knows the CPU is reading the vector, so the MFP then put the vector on the bus and assert DTACK.
/LDS and /UDS are only function of /DS, A0, SIZ0 and SIZ1 from the CPU, so if the CPU (68020) assert /DS, /LDS and /UDS should follow.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

terriblefire
Atari freak
Atari freak
Posts: 68
Joined: Sat Nov 12, 2016 10:15 am

Re: Open Source 68K Accelerator Project(s)

Postby terriblefire » Tue Nov 29, 2016 4:54 pm

rpineau wrote:yes you need to assert /LDS and/or /UDS as this is how the MFP knows the CPU is reading the vector, so the MFP then put the vector on the bus and assert DTACK.
/LDS and /UDS are only function of /DS, A0, SIZ0 and SIZ1 from the CPU, so if the CPU (68020) assert /DS, /LDS and /UDS should follow.


Indeed. But for some reason the MFP is not asserting DTACK at the right moment. It is most perplexing,.

czietz
Captain Atari
Captain Atari
Posts: 353
Joined: Tue May 24, 2016 6:47 pm

Re: Open Source 68K Accelerator Project(s)

Postby czietz » Tue Nov 29, 2016 5:01 pm

There are detailed timing diagrams in the MFP's user manual: https://dev-docs.atariforge.org/files/MC68901.pdf
Maybe something's missing.

terriblefire
Atari freak
Atari freak
Posts: 68
Joined: Sat Nov 12, 2016 10:15 am

Re: Open Source 68K Accelerator Project(s)

Postby terriblefire » Tue Nov 29, 2016 5:11 pm

Thanks for that. I'll solder on some wires later and see if i can figure out whats going on.

Many thanks for all the help guys.

rpineau
Captain Atari
Captain Atari
Posts: 491
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: Open Source 68K Accelerator Project(s)

Postby rpineau » Tue Nov 29, 2016 5:41 pm

Our VHDL code for the 68020 using a Xilinx XC95144XL works so there might be something you're missing in your verilog code somewhere.
We will open source our code one we've fixed the remaining problems and have 32bit TOS working but in the mean time if you want to look at the code I can send it to you (it's VHDL).
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests