6502 to 7501/8501 converter

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

6502 to 7501/8501 converter

Jim Brain

I think someone was wanting this: https://github.com/go4retro/Fake7501

-- 
Jim Brain
[hidden email] 
www.jbrain.com
Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Gerrit Heitsch
On 06/17/2018 09:18 AM, Jim Brain wrote:
> I think someone was wanting this: https://github.com/go4retro/Fake7501


Under 'Theory', you wrote the following:

The 6502 address, data, and r/w lines are fed through the CPLD so they
cna be optionally tri-stated, and the on-board PIO port bits 0-6 are
emulated.



The 7501/8501 has Bit 0-4 and 6 and 7 on the PIO port, Bit 5 is the
missing one. This makes it easy to use BIT commands when reading data.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Jim Brain
On 6/17/2018 3:58 AM, Gerrit Heitsch wrote:
On 06/17/2018 09:18 AM, Jim Brain wrote:
I think someone was wanting this: https://github.com/go4retro/Fake7501


Under 'Theory', you wrote the following:

The 6502 address, data, and r/w lines are fed through the CPLD so they cna be optionally tri-stated, and the on-board PIO port bits 0-6 are emulated.



The 7501/8501 has Bit 0-4 and 6 and 7 on the PIO port, Bit 5 is the missing one. This makes it easy to use BIT commands when reading data.
I meant to say "lines", so I updated.

I also added some as yet untested Verilog HDL to implement the functionality.  Comments appreciated.  he datasheets left at least one item ambiguous (to me, at least)

  • I assume the 7501/85xx is derived from the 6510 core, and the 6510 DS says address/data/and r/w are tristated when aec is used, but the 7501 DS says only address is tristated.

Jim


 Gerrit



-- 
Jim Brain
[hidden email] 
www.jbrain.com
Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Gerrit Heitsch
On 06/17/2018 07:11 PM, Jim Brain wrote:

> On 6/17/2018 3:58 AM, Gerrit Heitsch wrote:
>> On 06/17/2018 09:18 AM, Jim Brain wrote:
>>> I think someone was wanting this: https://github.com/go4retro/Fake7501
>>
>>
>> Under 'Theory', you wrote the following:
>>
>> The 6502 address, data, and r/w lines are fed through the CPLD so they
>> cna be optionally tri-stated, and the on-board PIO port bits 0-6 are
>> emulated.
>>
>>
>>
>> The 7501/8501 has Bit 0-4 and 6 and 7 on the PIO port, Bit 5 is the
>> missing one. This makes it easy to use BIT commands when reading data.
> I meant to say "lines", so I updated.
>
> I also added some as yet untested Verilog HDL to implement the
> functionality.  Comments appreciated.  he datasheets left at least one
> item ambiguous (to me, at least)
>
>   * I assume the 7501/85xx is derived from the 6510 core, and the 6510
>     DS says address/data/and r/w are tristated when aec is used, but the
>     7501 DS says only address is tristated.

Well, data needs to be tristated as well or there would be problems with
TED using the bus.

R/W is a slightly different thing on the 7501 since there is some magic
involved with the R/W line and the MUX signal.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

hegedusis
On 2018.06.17. 19:16, Gerrit Heitsch wrote:
On 06/17/2018 07:11 PM, Jim Brain wrote:
On 6/17/2018 3:58 AM, Gerrit Heitsch wrote:
On 06/17/2018 09:18 AM, Jim Brain wrote:
I think someone was wanting this: https://github.com/go4retro/Fake7501


Under 'Theory', you wrote the following:

The 6502 address, data, and r/w lines are fed through the CPLD so they cna be optionally tri-stated, and the on-board PIO port bits 0-6 are emulated.



The 7501/8501 has Bit 0-4 and 6 and 7 on the PIO port, Bit 5 is the missing one. This makes it easy to use BIT commands when reading data.
I meant to say "lines", so I updated.

I also added some as yet untested Verilog HDL to implement the functionality.  Comments appreciated.  he datasheets left at least one item ambiguous (to me, at least)

  * I assume the 7501/85xx is derived from the 6510 core, and the 6510
    DS says address/data/and r/w are tristated when aec is used, but the
    7501 DS says only address is tristated.

Well, data needs to be tristated as well or there would be problems with TED using the bus.

R/W is a slightly different thing on the 7501 since there is some magic involved with the R/W line and the MUX signal.

 Gerrit

assign r_w_7501 = (aec ? r_w_6502 : 'bz); I am missing here the GATE IN signal. That needs to be added just like I added it in FPGATED.  A transparent latch is needed to keep r_w_6502's previous state when GATE IN (MUX) is low. When MUX is high and AEC is not low r_w_7501 can be r_w_6502.
I would do the following (assuming gate_in is an input and r_w_latched is a register).

reg r_w_latched;

always @(gate_in,r_w_6502)
   begin
    if(gate_in)
        r_w_latched=r_w_6502;
   end

assign r_w_7501 = (aec ? r_w_latched : 'bz);

Istvan

Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Jim Brain
On 6/17/2018 2:42 PM, Hegedus, Istvan wrote:
I am missing here the GATE IN signal. That needs to be added just like I added it in FPGATED.  A transparent latch is needed to keep r_w_6502's previous state when GATE IN (MUX) is low. When MUX is high and AEC is not low r_w_7501 can be r_w_6502.
I would do the following (assuming gate_in is an input and r_w_latched is a register).

reg r_w_latched;

always @(gate_in,r_w_6502)
   begin
    if(gate_in)
        r_w_latched=r_w_6502;
   end

assign r_w_7501 = (aec ? r_w_latched : 'bz);

Istvan

I missed GATE_IN, so added as per your notes above.  compiler complains bitterly about the use of a latch.  Would it be permissible to do:

always @(negedge gate_in)

begin

  if(!gate_in)

    r_w_latched <= r_w_6502;

end

and then:

always @(*)

begin

if(aec & gate_in)

    r_w_7501 = r_w_6502;

else if (aec & !gate_in)

    r_w_7501 = r_w_latched;

else

    r_w_7501 = 'bz;

end

To skip the latch?

-- 
Jim Brain
[hidden email] 
www.jbrain.com
Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

hegedusis
On 2018.06.18. 7:41, Jim Brain wrote:
On 6/17/2018 2:42 PM, Hegedus, Istvan wrote:
I am missing here the GATE IN signal. That needs to be added just like I added it in FPGATED.  A transparent latch is needed to keep r_w_6502's previous state when GATE IN (MUX) is low. When MUX is high and AEC is not low r_w_7501 can be r_w_6502.
I would do the following (assuming gate_in is an input and r_w_latched is a register).

reg r_w_latched;

always @(gate_in,r_w_6502)
   begin
    if(gate_in)
        r_w_latched=r_w_6502;
   end

assign r_w_7501 = (aec ? r_w_latched : 'bz);

Istvan

I missed GATE_IN, so added as per your notes above.  compiler complains bitterly about the use of a latch.  Would it be permissible to do:

always @(negedge gate_in)

begin

  if(!gate_in)

    r_w_latched <= r_w_6502;

end

and then:

always @(*)

begin

if(aec & gate_in)

    r_w_7501 = r_w_6502;

else if (aec & !gate_in)

    r_w_7501 = r_w_latched;

else

    r_w_7501 = 'bz;

end

To skip the latch?

-- 
Jim Brain
[hidden email] 
www.jbrain.com
I would not worry because of the warning as in this case our purpose was to infer a latch. FPGA and CPLD tools warn users for inferring a transparent latch because it is a common mistake that a programmer wants to create a Combinational Logic but infers a latch due to the missing else statement in my case (condition for ~gate_in).
Your workaround is however also ok, I have just one concern.

always @(negedge gate_in)

begin

  if(!gate_in)

    r_w_latched <= r_w_6502;

end


In this part I am not sure whether this will ever meet the if requirement. Will gate_in be low already in your condition check? Maybe yes as it is combinational logic. Need to test that.
Otherwise the code is ok.

Istvan

Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Jim Brain
On 6/18/2018 2:43 AM, Hegedus, Istvan wrote:

>
> Your workaround is however also ok, I have just one concern.
>
> always @(negedge gate_in)
>
> begin
>
>   if(!gate_in)
>
>     r_w_latched <= r_w_6502;
>
> end
>
>
> In this part I am not sure whether this will ever meet the if
> requirement. Will gate_in be low already in your condition check?
It will, and the compiler complained about that as well.  I thus
simplified it:

always @(negedge gate_in)

begin

     r_w_latched <= r_w_6502;

end


--
Jim Brain
[hidden email]
www.jbrain.com


Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Jim Brain
In reply to this post by hegedusis
Is there a document that explains the purpose of MUX/GATE_IN?  Why did
the 264 series need to latch the R/W line and why did they need to do it
in the CPU in such an inefficient way?  It would seem routing through
TED or maybe a few transistors (Bil notes that there was an edict to
keep IC count low) would have been far better, as NMI was given up, a
huge loss.



Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Gerrit Heitsch
On 06/18/2018 10:04 AM, Jim Brain wrote:
> Is there a document that explains the purpose of MUX/GATE_IN?  Why did
> the 264 series need to latch the R/W line and why did they need to do it
> in the CPU in such an inefficient way?

The reason, as I understand it, is to make sure that R/W stays LOW long
enough during a write cycle. Remember, the 264 does switch the CPU to
double clock if TED doesn't need the bus. AEC is HIGH all the time
during that period. This means that all signals from the 7501 are
suddenly active only half as long.

Most RAMs don't seem to care since people have reportedly used 6510 in
an adapter with R/W connected directly without issues.

Maybe Bil can shed some light on it? Assuming he reads this...

I have captured write cycles on the logic analyzer. R/W depends on MUX
and can only change state with the rising edge of MUX. Mail me if you
want the images.

  Gerrit




Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Jim Brain
On 6/18/2018 9:54 AM, Gerrit Heitsch wrote:
On 06/18/2018 10:04 AM, Jim Brain wrote:
Is there a document that explains the purpose of MUX/GATE_IN?  Why did the 264 series need to latch the R/W line and why did they need to do it in the CPU in such an inefficient way?

The reason, as I understand it, is to make sure that R/W stays LOW long enough during a write cycle. Remember, the 264 does switch the CPU to double clock if TED doesn't need the bus. AEC is HIGH all the time during that period. This means that all signals from the 7501 are suddenly active only half as long.

Most RAMs don't seem to care since people have reportedly used 6510 in an adapter with R/W connected directly without issues.

Maybe Bil can shed some light on it? Assuming he reads this...

I have captured write cycles on the logic analyzer. R/W depends on MUX and can only change state with the rising edge of MUX. Mail me if you want the images.

 Gerrit




I do want them, but it would be best, I think, if you could host them somewhere for all of us.  I am sure I cannot be the only person stymied by this signal and it's purpose.

Your statement about R/W can only change as MUX rise seems different from the HDL and guidance previously given.  How do we verify this?

Jim


-- 
Jim Brain
[hidden email] 
www.jbrain.com
Reply | Threaded
Open this post in threaded view
|

8502 Adapter

Jim Brain
In reply to this post by Gerrit Heitsch
Since the design is pretty similar, I created this to have parity:

https://github.com/go4retro/Fake8502

I realize I used the wrong footprint for the 7501/8501, so I added that
footprint into  m y library and am fixing the 7501 project PCB.  I am
almost done, and should have the new version online tonight.

Jim


Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Gerrit Heitsch
In reply to this post by Jim Brain
On 06/18/2018 08:00 PM, Jim Brain wrote:

> On 6/18/2018 9:54 AM, Gerrit Heitsch wrote:
>> On 06/18/2018 10:04 AM, Jim Brain wrote:
>>> Is there a document that explains the purpose of MUX/GATE_IN?  Why
>>> did the 264 series need to latch the R/W line and why did they need
>>> to do it in the CPU in such an inefficient way?
>>
>> The reason, as I understand it, is to make sure that R/W stays LOW
>> long enough during a write cycle. Remember, the 264 does switch the
>> CPU to double clock if TED doesn't need the bus. AEC is HIGH all the
>> time during that period. This means that all signals from the 7501 are
>> suddenly active only half as long.
>>
>> Most RAMs don't seem to care since people have reportedly used 6510 in
>> an adapter with R/W connected directly without issues.
>>
>> Maybe Bil can shed some light on it? Assuming he reads this...
>>
>> I have captured write cycles on the logic analyzer. R/W depends on MUX
>> and can only change state with the rising edge of MUX. Mail me if you
>> want the images.
>>
>>  Gerrit
>>
>>
>>
>>
> I do want them, but it would be best, I think, if you could host them
> somewhere for all of us.  I am sure I cannot be the only person stymied
> by this signal and it's purpose.

I don't really have webspace I could use... But feel free to use the
images as you like.



> Your statement about R/W can only change as MUX rise seems different
> from the HDL and guidance previously given.  How do we verify this?

I also have images from my scope which show the same behaviour. What's
left now is to explain that behaviour.

  Gerrit





Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Mario Kienspergher
OK, next try ... answering to the list ... sorry.

> I also have images from my scope which show the same behaviour. What's
> left now is to explain that behaviour.
>
>  Gerrit

The TED system manual of which scans were presented here some time ago
explains the behaviour quite well including timing diagrams. It
correspondens to the HDL implementation if I understand it correctly.

See chapter 5.5.2:
* R/W from the 6502 core is put through transparently to the R/W pin if
MUX is HIGH and is latched when MUX is LOW.
* If MUX goes back to HIGH the latch is released and the (maybe
meanwhile changed) R/W-signal from the core is put through again. This
is why you think you see a change at the rising edge. IMHO it is not
edge triggered but a transparent latch.
* If MUX goes HIGH when AEC is LOW then R/W is changig to HIGH-Z until
AEC is HIGH when MUX is changing from LOW to HIGH.

See also chapter 5.4:
"If AEC is low when Gate In [a.k.a MUX, remark] makes a low to high
transition, the R/W line will go to a high impedance until the next
transition of the Gate In line and AEC is high prior to the transition."

The not-so-complete version (I think) of that manual can be found here:
https://www.pagetable.com/docs/ted/TED%20System%20Hardware%20Manual.pdf

Anyway chapters 5.4 and 5.5.2 are present there, too.

Regards
kinzi

Reply | Threaded
Open this post in threaded view
|

Re: 6502 to 7501/8501 converter

Gerrit Heitsch
On 06/18/2018 09:18 PM, Mario Kienspergher wrote:

> OK, next try ... answering to the list ... sorry.
>
>> I also have images from my scope which show the same behaviour. What's
>> left now is to explain that behaviour.
>>
>>  Gerrit
>
> The TED system manual of which scans were presented here some time ago
> explains the behaviour quite well including timing diagrams. It
> correspondens to the HDL implementation if I understand it correctly.
>
> See chapter 5.5.2:
> * R/W from the 6502 core is put through transparently to the R/W pin if
> MUX is HIGH and is latched when MUX is LOW.
> * If MUX goes back to HIGH the latch is released and the (maybe
> meanwhile changed) R/W-signal from the core is put through again. This
> is why you think you see a change at the rising edge. IMHO it is not
> edge triggered but a transparent latch.


That might be the case, in any way the signal on the scope shows that
R/W only changes state with rising edge of MUX. I didn't guess what's
behind that behaviour.

Any circuit that wants to emulate the 7501 will have to behave the same,
if that takes a latch, fine by me.

  Gerrit