Strange 8255 behavior

classic Classic list List threaded Threaded
138 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Strange 8255 behavior

Michał Pleban
Hello!

I know this is only tangentially related to Commodore (since it involves
an Intel chip) but I hope someone could have some pointers for me.

I've been banging my head for several hours over Ruud's clone of 8088
card, where the 6525 is substituted with Intel 8255. I'm rewriting the
firmware to work with the 8255 chip. Basically it is an interface to the
6526 sitting on the 6509 processor side which allows to transfer bytes
between these two CPUs.

The transmission happens in two directions, which basically looks like
this from the 8088 side (handshaking omitted for clarity):

1. Set the port to output.
2. Write the command byte(s) for the 6509
3. Set the port to input
4. Wait till 6509 finishes its job
5. Read response(s) from the 6509

With the 6525 everything works fine in this model (changing between
input/output is done using writes to the Data Direction Register). But
with the 8255 the step #3 (accomplished by writing a value to the
Control register) confuses the 6509 so thoroughly that it doesn't even
start processing the command.

When I move the step #3 to be below step #4, things work much much
better, but still the 6509 hangs at some point. Only when I remove this
step completely, everything works and MS-DOS boots, but of course the
8088 cannot now read anything from the 6509 so it waits forever for a
keypress.

Why something like this would happen? The only explanation I can think
of is that when the Control register of the 8255 is written, _something_
happens for a very short while with the I/O port pins, before the new
state is set, and this something is enough to trigger some signal in the
6526 which is connected to the 8255's ports. My first suspicion was that
a pin connected to FLAG changes its value, causing the 6526 to create a
spurious interrupt which sends the 6509 into neverland. But I cannot
reproduce this with an oscilloscope - I can see only one interrupt
pulse, not two. But nevertheless, writing to the Control reegister of
the 8255 must have some momentary effect on its pins, because I cannot
explain this phenomenon in any other way.

It's 2AM now and I am completely of ideas. Does anyone know about what
exacly happens in the 8255 when its Control register is written into?

Regards,
Michau.
















Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Dr Jefyll

> handshaking omitted for clarity

Hi, Michal.  Speaking for myself, I'd feel more clarity if the details  
were spelled out.  At least explain, please, which handshake pins  
attach to which (or link to a schematic).


> The only explanation I can think of is that when the Control  
> register of the 8255 is written, _something_ happens [...]

That makes sense to me, but I'd be looking for the "something" on the  
handshake lines (not the data pins of the port).  Or maybe I've  
misunderstood something -- always possible.

cheers
Jeff



Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Michał Pleban
In reply to this post by Michał Pleban
Michał Pleban wrote:

> It's 2AM now and I am completely of ideas. Does anyone know about what
> exacly happens in the 8255 when its Control register is written into?

OK, after extensive googling I found this little gem:

http://www.cpcwiki.eu/index.php/8255

"CAUTION: Writing to PIO Control Register (with Bit7 set), automatically
resets PIO Ports A,B,C to 00h each!"

This information (quite important IMHO) is not found in the datasheet.
Also, it's a very stupid behaviour for an I/O chip to silently reset the
port values when the port direction is modified, but it's Intel, so what
did I expect? :-)

I just have to modify the IPC code logic somehow to work around this...

Regards,
Michau.

Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

peter
> Michał Pleban wrote:
>
>> It's 2AM now and I am completely of ideas. Does anyone know about what
>> exacly happens in the 8255 when its Control register is written into?
>
> OK, after extensive googling I found this little gem:
>
> http://www.cpcwiki.eu/index.php/8255
>
> "CAUTION: Writing to PIO Control Register (with Bit7 set), automatically
> resets PIO Ports A,B,C to 00h each!"
>
> This information (quite important IMHO) is not found in the datasheet.
> Also, it's a very stupid behaviour for an I/O chip to silently reset the
> port values when the port direction is modified, but it's Intel, so what
> did I expect? :-)
>
> I just have to modify the IPC code logic somehow to work around this...
>
> Regards,
> Michau.
>

What if you write to it without bit7 set?

-Pete



smf
Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

smf
On 10/06/2018 02:36, Pete Rittwage wrote:
What if you write to it without bit7 set?
Then it doesn't change the direction.

PPI Control

This register has two different functions depending on bit7 of the data written to this register.

PPI Control with Bit7=1

If Bit 7 is "1" then the other bits will initialize Port A-B as Input or Output:

 Bit 0    IO-Cl    Direction for Port C, lower bits (always 0=Output in CPC)
 Bit 1    IO-B     Direction for Port B             (always 1=Input in CPC)
 Bit 2    MS0      Mode for Port B and Port Cl      (always zero in CPC)
 Bit 3    IO-Ch    Direction for Port C, upper bits (always 0=Output in CPC)
 Bit 4    IO-A     Direction for Port A             (0=Output, 1=Input)
 Bit 5,6  MS0,MS1  Mode for Port A and Port Ch      (always zero in CPC)
 Bit 7    SF       Must be "1" to setup the above bits
  • CAUTION: Writing to PIO Control Register (with Bit7 set), automatically resets PIO Ports A,B,C to 00h each!
  • In the CPC only Bit 4 is of interest, all other bits are always having the same value. In order to write to the PSG sound registers, a value of 82h must be written to this register. In order to read from the keyboard (through PSG register 0Eh), a value of 92h must be written to this register.

PPI Control with Bit7=0

Otherwise, if Bit 7 is "0" then the register is used to set or clear a single bit in Port C:

 Bit 0    B        New value for the specified bit (0=Clear, 1=Set)
 Bit 1-3  N0,N1,N2 Specifies the number of a bit (0-7) in Port C
 Bit 4-6  -        Not Used
 Bit 7    SF       Must be "0" in this case
Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

André Fachat

Am 10. Juni 2018 9:47:50 AM schrieb smf <[hidden email]>:

> On 10/06/2018 02:36, Pete Rittwage wrote:
>> What if you write to it without bit7 set?
>
> Then it doesn't change the direction.
>


This is really a nasty behaviour, clearing the output value on direction change.

I find it amazing what chip designers sometimes do that really annoy the programmers or users. And this sometimes even means additional hardware so it can't be attributed to scarcity of resources  (like I guess clearing interrupt flags by just reading the flags....).

My favourite is the control line of the 6551 that automatically disable receivers and/or transmitters, which makes it almost completely useless except for 3wire serial....

So it is not just intel that does such things...

André

smf
Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

smf
On 10/06/2018 10:57, André Fachat wrote:

> I find it amazing what chip designers sometimes do that really annoy
> the programmers or users. And this sometimes even means additional
> hardware so it can't be attributed to scarcity of resources  (like I
> guess clearing interrupt flags by just reading the flags....).

I assume for cost purposes they don't keep the last output value when in
read mode, so when you switch back to output mode then zeros is probably
the lesser of two evils.

Trying to replace a mos chip with an intel chip is blasphemy :-)



Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

André Fachat


Am 10. Juni 2018 13:21:22 schrieb smf <[hidden email]>:

> On 10/06/2018 10:57, André Fachat wrote:
>
>> I find it amazing what chip designers sometimes do that really annoy
>> the programmers or users. And this sometimes even means additional
>> hardware so it can't be attributed to scarcity of resources  (like I
>> guess clearing interrupt flags by just reading the flags....).
>
> I assume for cost purposes they don't keep the last output value when in
> read mode, so when you switch back to output mode then zeros is probably
> the lesser of two evils.

You mean they have a single latch only, reused for input and output?
Probably more logic around to make that work but could be....

> Trying to replace a mos chip with an intel chip is blasphemy :-)

Guilty :-)

And I would still happily replace the 6551 with a 16550... :-)

André




Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Dr Jefyll
In reply to this post by smf

> On 10/06/2018 10:57, André Fachat wrote:
>
>> [...] (like I guess clearing interrupt flags by just reading the flags....).

I believe clearing interrupts by reading the flags is actually a
feature. It leads to a shorter Interrupt Service Routine because you
don't have to reset that flag explicitly. But yes you have to pay
attention or it'll bite you.  :-(


Quoting smf <[hidden email]>:

> I assume for cost purposes they don't keep the last output value
> when in read mode, so when you switch back to output mode then zeros
> is probably the lesser of two evils.

Hmm, well, maybe, but I'm not convinced (although I agree it'd be the
lesser of two evils).



> Trying to replace a mos chip with an intel chip is blasphemy :-)

Now *that* is something I can fully agree with!!  :-D



Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Michał Pleban
In reply to this post by smf
Hello!

smf wrote:

> I assume for cost purposes they don't keep the last output value when in
> read mode, so when you switch back to output mode then zeros is probably
> the lesser of two evils.

That might be the case when you switch from input to output, but when
you "switch" from output to output (i.e. you leave the direction of the
port unchanged, only modifying some other port) it's just ridiculous.

> Trying to replace a mos chip with an intel chip is blasphemy :-)

Guilty as charged :-) But it's for a good reason: there are only very
little 6525's laying around, and if we want to make the 8088 card
accessible to everyone, we had to change to a chip that's readily available.

Regards,
Michau.


Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Michał Pleban
In reply to this post by André Fachat
Hello!

André Fachat wrote:

> I find it amazing what chip designers sometimes do that really annoy the
> programmers or users. And this sometimes even means additional hardware
> so it can't be attributed to scarcity of resources  (like I guess
> clearing interrupt flags by just reading the flags....).

That's one thing. But the other thing is, creating such nasty behaviour
and *not* documenting it in the datasheet. I consulted 8255 datasheets
from several manufacturers and none mentions this.

Regards,
Michau.


Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Michał Pleban
In reply to this post by Dr Jefyll
Hello!

Jeff Laughton wrote:

> Hi, Michal.  Speaking for myself, I'd feel more clarity if the details
> were spelled out.  At least explain, please, which handshake pins attach
> to which (or link to a schematic).

You're right, but since the interface works flawlessly with the 6525, my
question was more "what is 8255 doing differently?" that "what can go
wrong in this interface?"

> That makes sense to me, but I'd be looking for the "something" on the
> handshake lines (not the data pins of the port).  Or maybe I've
> misunderstood something -- always possible.

It turned out that it was the pin used to generate IRQ on the 6509 after
all - it is the only pin in the output port that has a default value of
1, so resetting it to 0 caused havoc. Fortunately, the pin on the 6509
side (FLAG in the CIA) is edge triggered so it should be possible to
rewrite everything so that the default value is 0 and it still works.

Regards,
Michau.



Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Gerrit Heitsch
In reply to this post by Michał Pleban
On 06/10/2018 01:59 PM, Michał Pleban wrote:

> Hello!
>
> smf wrote:
>
>> I assume for cost purposes they don't keep the last output value when in
>> read mode, so when you switch back to output mode then zeros is probably
>> the lesser of two evils.
>
> That might be the case when you switch from input to output, but when
> you "switch" from output to output (i.e. you leave the direction of the
> port unchanged, only modifying some other port) it's just ridiculous.
>
>> Trying to replace a mos chip with an intel chip is blasphemy :-)
>
> Guilty as charged :-) But it's for a good reason: there are only very
> little 6525's laying around, and if we want to make the 8088 card
> accessible to everyone, we had to change to a chip that's readily available.

How about two 6522 instead? With some clever logic and mapping of the
address bits, you might be able to come up with a register map that
comes close to what the 6525 has, limiting the amount of change in the code.

  Gerrit




Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Clockmeister
  I know nothing of such things, but would it be easier and cheaper to
simulate a 6526 using an Atmel controller(s) of some kind?

On 10/06/2018 8:33 PM, Gerrit Heitsch wrote:

> On 06/10/2018 01:59 PM, Michał Pleban wrote:
>> Hello!
>>
>> smf wrote:
>>
>>> I assume for cost purposes they don't keep the last output value
>>> when in
>>> read mode, so when you switch back to output mode then zeros is
>>> probably
>>> the lesser of two evils.
>>
>> That might be the case when you switch from input to output, but when
>> you "switch" from output to output (i.e. you leave the direction of the
>> port unchanged, only modifying some other port) it's just ridiculous.
>>
>>> Trying to replace a mos chip with an intel chip is blasphemy :-)
>>
>> Guilty as charged :-) But it's for a good reason: there are only very
>> little 6525's laying around, and if we want to make the 8088 card
>> accessible to everyone, we had to change to a chip that's readily
>> available.
>
> How about two 6522 instead? With some clever logic and mapping of the
> address bits, you might be able to come up with a register map that
> comes close to what the 6525 has, limiting the amount of change in the
> code.
>
>  Gerrit
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Francesco Messineo
On Sun, Jun 10, 2018 at 2:49 PM, Clockmeister
<[hidden email]> wrote:
>  I know nothing of such things, but would it be easier and cheaper to
> simulate a 6526 using an Atmel controller(s) of some kind?
>

probably the best thing would be re-creating a clone of the 6525 in a
MAX7000 (5V series) CPLD. I can help (but I haven't a lot of spare
time) if anyone likes doing that.

Frank IZ8DWF

Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Gerrit Heitsch
In reply to this post by Clockmeister
On 06/10/2018 02:49 PM, Clockmeister wrote:
>   I know nothing of such things, but would it be easier and cheaper to
> simulate a 6526 using an Atmel controller(s) of some kind?

Too slow. At 20 MHz you'd have less than 10 cycles to see what the host
CPU wants, deliver that data and get off the bus again.


  Gerrit





>
> On 10/06/2018 8:33 PM, Gerrit Heitsch wrote:
>> On 06/10/2018 01:59 PM, Michał Pleban wrote:
>>> Hello!
>>>
>>> smf wrote:
>>>
>>>> I assume for cost purposes they don't keep the last output value
>>>> when in
>>>> read mode, so when you switch back to output mode then zeros is
>>>> probably
>>>> the lesser of two evils.
>>>
>>> That might be the case when you switch from input to output, but when
>>> you "switch" from output to output (i.e. you leave the direction of the
>>> port unchanged, only modifying some other port) it's just ridiculous.
>>>
>>>> Trying to replace a mos chip with an intel chip is blasphemy :-)
>>>
>>> Guilty as charged :-) But it's for a good reason: there are only very
>>> little 6525's laying around, and if we want to make the 8088 card
>>> accessible to everyone, we had to change to a chip that's readily
>>> available.
>>
>> How about two 6522 instead? With some clever logic and mapping of the
>> address bits, you might be able to come up with a register map that
>> comes close to what the 6525 has, limiting the amount of change in the
>> code.
>>
>>  Gerrit
>>
>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Gerrit Heitsch
In reply to this post by Francesco Messineo
On 06/10/2018 03:03 PM, Francesco Messineo wrote:
> On Sun, Jun 10, 2018 at 2:49 PM, Clockmeister
> <[hidden email]> wrote:
>>   I know nothing of such things, but would it be easier and cheaper to
>> simulate a 6526 using an Atmel controller(s) of some kind?
>>
>
> probably the best thing would be re-creating a clone of the 6525 in a
> MAX7000 (5V series) CPLD. I can help (but I haven't a lot of spare
> time) if anyone likes doing that.

Might not be possible since the 6525 has NMOS output drivers which allow
you to do things that you can't do with CMOS output drivers. Namely
having 2 outputs (one LOW, one HIGH) directly connected.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Francesco Messineo
On Sun, Jun 10, 2018 at 3:22 PM, Gerrit Heitsch
<[hidden email]> wrote:

> On 06/10/2018 03:03 PM, Francesco Messineo wrote:
>>
>> On Sun, Jun 10, 2018 at 2:49 PM, Clockmeister
>> <[hidden email]> wrote:
>>>
>>>   I know nothing of such things, but would it be easier and cheaper to
>>> simulate a 6526 using an Atmel controller(s) of some kind?
>>>
>>
>> probably the best thing would be re-creating a clone of the 6525 in a
>> MAX7000 (5V series) CPLD. I can help (but I haven't a lot of spare
>> time) if anyone likes doing that.
>
>
> Might not be possible since the 6525 has NMOS output drivers which allow you
> to do things  that you can't do with CMOS output drivers. Namely having 2
> outputs (one LOW, one HIGH) directly connected.

if this "feature" has really been exploited, then it could be probably
emulated with open drain outputs or other "tricks" (like series
shottkys) but it really depends if and how it's used.

Frank

Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Groepaz
Am Sonntag, 10. Juni 2018, 15:26:47 CEST schrieb Francesco Messineo:

> On Sun, Jun 10, 2018 at 3:22 PM, Gerrit Heitsch
>
> <[hidden email]> wrote:
> > On 06/10/2018 03:03 PM, Francesco Messineo wrote:
> >> On Sun, Jun 10, 2018 at 2:49 PM, Clockmeister
> >>
> >> <[hidden email]> wrote:
> >>>   I know nothing of such things, but would it be easier and cheaper to
> >>>
> >>> simulate a 6526 using an Atmel controller(s) of some kind?
> >>
> >> probably the best thing would be re-creating a clone of the 6525 in a
> >> MAX7000 (5V series) CPLD. I can help (but I haven't a lot of spare
> >> time) if anyone likes doing that.
> >
> > Might not be possible since the 6525 has NMOS output drivers which allow
> > you to do things  that you can't do with CMOS output drivers. Namely
> > having 2 outputs (one LOW, one HIGH) directly connected.
>
> if this "feature" has really been exploited, then it could be probably
> emulated with open drain outputs or other "tricks" (like series
> shottkys) but it really depends if and how it's used.

if its similar as with what ppl did with 6522 and 6526 (i would assume it is)
- then expect every dirty trick you can imagine being used by real world
software. for example even the subtle differences between the port drivers of
port 1 and port 2 are relevant in 6522/26 emulation.

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

Aesthetic delight lies somewhere between boredom and confusion.
<E.H.Gombrick>





Reply | Threaded
Open this post in threaded view
|

Re: Strange 8255 behavior

Segher Boessenkool
In reply to this post by Dr Jefyll
On Sun, Jun 10, 2018 at 07:50:42AM -0400, Jeff Laughton wrote:

>
> >On 10/06/2018 10:57, André Fachat wrote:
> >
> >>[...] (like I guess clearing interrupt flags by just reading the
> >>flags....).
>
> I believe clearing interrupts by reading the flags is actually a
> feature. It leads to a shorter Interrupt Service Routine because you
> don't have to reset that flag explicitly. But yes you have to pay
> attention or it'll bite you.  :-(

Unless you have a slightly more complex system where you do not handle
all interrupt at once (say, you want to have some priority system for
the interrupt handling), in which case you then need to double-buffer
the status bits.  Which makes the interrupt routines longer and slower :-/


Segher

1234 ... 7