Problem Solved!
Ceibo manual doesn't say anything about it, but you can choose
External OR Internal clocking inside the device. Thanks to everyone
here I opened the emulator and found a crystal! I changed it and it
works perfect.
I changed 12.0mhz crystal with 11.0592mhz - exactly 10% difference!
Nice one!
I'm actually quite impressed from the skills people showed around, I
guess I have lots to learn.

Really thanks guys, you helped a lot!


"Edwin Bland" <edwinb@socal.rr.com> wrote in message news:<PDclc.8896$nn3.3100@twister.socal.rr.com>...
> Hi,
> 
> My Ceibo emulator came with a default 24.0 Mhz crystal.  It has divider
> jumpers... with the default being at 12.0 Mhz.  I had to get another the
> crystal to get nonmultiple frequencies.
> 
> Edwin
> 
> "Edo Reshef" <edoreshef@hotmail.com> wrote in message
> news:7a494870.0404221405.237cb752@posting.google.com...
> > > dingoatemydonut@aol.com (Dingo) wrote:
> > > Are you sure your emulator isn't using an on-board 10Mhz crystal?
> >
> > That's actually my main suspicion, I think the Ceibo DS-51 could have
> > an Internal clock that runs at 12Mhz, DS-51 documentation says nothing
> > about it. Anyway I will to physically look for crystal in the emulator
> > in few dayz since it's weekend here... I'll keep you updated!

Hi,

My Ceibo emulator came with a default 24.0 Mhz crystal.  It has divider
jumpers... with the default being at 12.0 Mhz.  I had to get another the
crystal to get nonmultiple frequencies.

Edwin

"Edo Reshef" <edoreshef@hotmail.com> wrote in message
news:7a494870.0404221405.237cb752@posting.google.com...
> > dingoatemydonut@aol.com (Dingo) wrote:
> > Are you sure your emulator isn't using an on-board 10Mhz crystal?
>
> That's actually my main suspicion, I think the Ceibo DS-51 could have
> an Internal clock that runs at 12Mhz, DS-51 documentation says nothing
> about it. Anyway I will to physically look for crystal in the emulator
> in few dayz since it's weekend here... I'll keep you updated!

> dingoatemydonut@aol.com (Dingo) wrote:
> Are you sure your emulator isn't using an on-board 10Mhz crystal?

That's actually my main suspicion, I think the Ceibo DS-51 could have
an Internal clock that runs at 12Mhz, DS-51 documentation says nothing
about it. Anyway I will to physically look for crystal in the emulator
in few dayz since it's weekend here... I'll keep you updated!

edoreshef@hotmail.com (Edo Reshef) wrote in message news:<7a494870.0404220047.647b3f63@posting.google.com>...
> Tauno Voipio <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message news:<lFxhc.354$wN1.230@read3.inet.fi>...
> > This has a strong scent of a speed / distorsion error. It seems that
> > after 6 bits, the 8051 is off by one bit time.
> > 
> > Please remember that initially the RS-232 standard limited the transfer
> > speed to 20000 bits/s. There may be edge slow-down capacitors at either
> > or both ends of the RS-232 data lines.
> 
> No wonder computers never work!
> 
> > Which crystal and what divisor are you using on the 8051's?
> 
> I'm using 11.0592Mhz

Are you sure your emulator isn't using an on-board 10Mhz crystal?

"Edo Reshef" <edoreshef@hotmail.com> wrote in message
news:7a494870.0404220047.647b3f63@posting.google.com...
> Tauno Voipio <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message
news:<lFxhc.354$wN1.230@read3.inet.fi>...
> > This has a strong scent of a speed / distorsion error. It seems that
> > after 6 bits, the 8051 is off by one bit time.
> >
> > Please remember that initially the RS-232 standard limited the transfer
> > speed to 20000 bits/s. There may be edge slow-down capacitors at either
> > or both ends of the RS-232 data lines.
>
> No wonder computers never work!
>
> > Which crystal and what divisor are you using on the 8051's?
>
> I'm using 11.0592Mhz
> And that the Init code:
>   MOV     PCON,#80h
>   MOV     SCON,#0C8H      ;SET SERIAL PORT TO MODE 3
>   MOV     TCON,#01H
>   MOV     TMOD,#21H       ;SET TIMER 0 TO MODE 1 - 16 BIT MODE
>                           ;AND TIMER 1 TO MODE 2 - AUTO RELOAD MODE
>   MOV     TH1,#0FFH       ;SET TIMER 1 TO PRODUCE 57600 BAUD (0FFH) ?
>   SETB    TR1             ;START TIMER 1

That seems correct.

Can you verify the transmission rate with an oscilloscope
(17.36 us / bit)?

Also, please check the signal edges on the RS-232 lines.

Tauno Voipio
tauno voipio @ iki fi

Tauno Voipio <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message news:<lFxhc.354$wN1.230@read3.inet.fi>...
> This has a strong scent of a speed / distorsion error. It seems that
> after 6 bits, the 8051 is off by one bit time.
> 
> Please remember that initially the RS-232 standard limited the transfer
> speed to 20000 bits/s. There may be edge slow-down capacitors at either
> or both ends of the RS-232 data lines.

No wonder computers never work!

> Which crystal and what divisor are you using on the 8051's?

I'm using 11.0592Mhz
And that the Init code:
  MOV     PCON,#80h
  MOV     SCON,#0C8H      ;SET SERIAL PORT TO MODE 3
  MOV     TCON,#01H
  MOV     TMOD,#21H       ;SET TIMER 0 TO MODE 1 - 16 BIT MODE
                          ;AND TIMER 1 TO MODE 2 - AUTO RELOAD MODE
  MOV     TH1,#0FFH       ;SET TIMER 1 TO PRODUCE 57600 BAUD (0FFH) ?
  SETB    TR1             ;START TIMER 1

Edo Reshef wrote:
> Good point! I didn't know that, that make sense! But how can you
> explain that if the MSB is "0" the byte is not received at all?

Because then the stop bit is invalid (due to baud-timing-skew)....
Post up your xtal, and timer reload values, and there are plenty
here who will spot a ooops...
-jg

Tilmann Reh <tilmannreh@despammed.com> wrote in message news:<c665p1$qg2$1@online.de>...

> I think the problem is somewhere in this area. PCs are not likely
> to support 9-bit frames, and if it works, it's not really safe
> or reproducible.
> Maybe your positive experience was made with another PC or another
> software configuration.

I have done 9-bit framing with a PC at 57600 baud rate communicating
to a PIC controller, it works perfect, sending the 9-bit is really
easy, receiving it a bit is more tricky but I'm not interested in
receiving so I'm OK.

> I strongly recommend to look at the interface lines with a DSO
> and check if the PC really sends correctly.
> You might also consider testing the communication at lower
> speeds first (where the PC hack might eventually work).
> 
> Did you also try the other direction already?

I'll check it with a DSO and see what comes up, I have a really old
DSO so I will see if i can make it work....

garykato@aol.com (Gary Kato) wrote in message news:<20040421115816.07978.00000055@mb-m27.aol.com>...
> >PC Sends  -> 11011011
> >8051 Gets -> 10111011
> >
> >PC Sends  -> 10110011
> >8051 Gets -> 01110011
> >
> >PC Sends  -> 11000101
> >8051 Gets -> 10000101
> >
> >PC Sends  -> 10101011
> >8051 Gets -> 01001011
> >
> >Even more, when the msb is "0" the reception interrupt does not
> >trigger.
> >It looks like the 8051 ignores the PC start bit or something...
> >
> >The protocol is 9-bit multi-drop, which i already implemented on PC
> >side using Space and Mark parities, it worked fine with some other
> >9-bit PIC devices.
> >
> 
> Remember that serial data is sent lsb first. It seems something odd is
> happening at the end of reception, not at the start.

Good point! I didn't know that, that make sense! But how can you
explain that if the MSB is "0" the byte is not received at all?

Gary Kato wrote:

> PC Sends  -> 11011011
>>8051 Gets -> 10111011
>>
>>PC Sends  -> 10110011
>>8051 Gets -> 01110011
>>
>>PC Sends  -> 11000101
>>8051 Gets -> 10000101
>>
>>PC Sends  -> 10101011
>>8051 Gets -> 01001011
>>Even more, when the msb is "0" the reception interrupt does not
>>trigger.
>>It looks like the 8051 ignores the PC start bit or something...
>>
>>The protocol is 9-bit multi-drop, which i already implemented on PC
>>side using Space and Mark parities, it worked fine with some other
>>9-bit PIC devices.
>>
> 
> Remember that serial data is sent lsb first. It seems something odd is
> happening at the end of reception, not at the start.

and that suggests the MSB is perhaps sliding into the STOP bit,
either drive slew as has been suggested, or simply the wrong BAUD rate.
Your errors are all 'at one end' which does not suggest driver skew, but
does fit baud rate miss-match.
-jg