The CPU clocks for NTSC/PAL are very close: 1.193182 MHz (NTSC), 1.182298
MHz (PAL)
The difference is so slight, I don't think it will matter. Here's the
theoretical cycle breakdown:
baud NTSC PAL Cycles program is using
115200 10.36 10.26 10/11
57600 20.71 20.53 21
38400 31.07 30.79 31
19200 62.14 61.58 62
9600 124.29 123.16 124
2400 497.16 492.62 ~ 456/532
1200 994.32 985.25 ~ 988
Someone with a PAL 2600 should try the existing binaries out to see if they
work - I expect they will.
>Ironically, 57600 works 100% reliably for me now. I
>tried it a few times and made sure the hex converted
>back to a BIN. It was fine. And since my cable
>sucks, I wonder what could be wrong on your end?
>57600 is a very pleasant speed for dumping 4K worth of
>data. 38400 is okay. I have a 2.4ghz PIV so the
>serial port is as modern as they come.
>
>I tried all the speeds downward and they all work.
>
>We really need some PAL volunteers, though. What
>would be the theoretical delay times for PAL?
>
>--- Fred Quimby <c9r@xxxxxxxxxxx> wrote:
> > I've assembled a bin for each baud rate (without TTL
> > level converter, since
> > I don't have one). I've tried them all.
> > Interestingly, 115200 is no longer
> > working for me. Maybe my cabling is bad too, or my
> > serial port is pissed
> > off from getting signals it doesn't like, as 57600
> > is flaky too. But 38400
> > and slower are proving to be quite reliable.
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>Archives (includes files) at http://www.biglist.com/lists/stella/archives/
>Unsub & more at http://stella.biglist.com
>
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://stella.biglist.com
