@rogloh said:
Yes, jmg that is an issue. The latest code Eric added has improved this and has put in the wait for the "." char to be sure the file is loaded in SINGLE mode.
By the way I've just improved the autobaud in loadp2 by sending $80 instead of $55 and measuring clock period for 8 serial bit times being logic low (this is including the start bit) and then shifting this value up by 13 bits so fractional baudrates with the smartpin WXPIN parameter should now work. It also now lets me do 3Mbps which was not reliable before. Still testing but when I'm done I'll submit these changes to Github via a PR or do a bug fix post for Eric.
The other delay changes I put in seem to let me now load from 14400bps up to 3Mbps in both -SINGLE and the default -CHIP modes and I'm not seeing timeouts (yet).
Sounds like good progress, I've done the two-stage loader tests, as the lack of checksum test on -SINGLE was giving false screen reports.
I now have this, which is similar to the ping test fail curve above. ie 4.8MBd is the top reliable rate but higher rates can sometimes work ok.
rem loadp2 -b9600000 -l9600000 -pCOM57 -v HexPat128K.hex always fails checksum
rem loadp2 -b8000000 -l8000000 -pCOM57 -v HexPat128K.hex has roughly 50% fail rate
rem loadp2 -b7384615 -l7384615 -pCOM57 -v HexPat128K.hex OK for 6 of 10
rem loadp2 -b6857143 -l6857143 -pCOM57 -v HexPat128K.hex OK for 3 of 10
rem loadp2 -b6000000 -l6000000 -pCOM57 -v HexPat128K.hex OK for 4 of 12
rem loadp2 -b5333333 -l5333333 -pCOM57 -v HexPat128K.hex ok for 8 of 10
rem loadp2 -b4800000 -l4800000 -pCOM57 -v HexPat128K.hex ok for 12 of 12
success reports like this
trying COM57...
P2 version G found on serial port COM57
Setting load mode to CHIP
Setting clock_mode to 12427f8
Loading fast loader for chip...
Sending header
Loading HexPat128K.hex - 368670 bytes
chksum: 75 OK
but I'm unclear on how the 2 stage loader is choosing the first and second baud rates.
I expected a slower first handshake baud, and then a Clock change and a baud change, which means > 100MHz sysclks should be fine above 4.8MBd - but my tests do not do that ?
@rogloh said:
Both baud rates are the same in the two stage loader as well as for the autobaud char.
I'd be interested to see if my changes let you go higher more reliably. I think they might.
Hmm. if the Baud is not changed, then the upper limit will be RCFAST initial autobaud limited ?
If the P2 SysCLK is flipped to a PLL value, then the second baud rate should be able to go up to 15MBd or above. I can test 12MBd and 15Mbd here.
@rogloh said:
The other delay changes I put in seem to let me now load from 14400bps up to 3Mbps in both -SINGLE and the default -CHIP modes and I'm not seeing timeouts (yet). Going even lower down to 9600bps and below seems to need another change in the port detection timeout area. I might look at that too. I know that these baud rates would be very uncommon but perhaps some setups might have very slow serial links or something and it could still be useful to support.
That's sounding good. Things like power-line modems can have low baud rates. As you say, not common, but it is useful to cover them 'while the bonnet is up'
I wonder if a loader needs command line define of both loader baud rates, should you get a baud-change added ?
@jmg said:
Hmm. if the Baud is not changed, then the upper limit will be RCFAST initial autobaud limited ?
Yes, RCFAST is used in loadp2 and it will limit the rate. Not sure what to, maybe something under 12Mbps if the P2 needs two clock cycles to discern each bit transition and RCFAST ~ 24-25MHz.
I wonder if a loader needs command line define of both loader baud rates, should you get a baud-change added ?
Might not be something I want to work on now, though at some point it might be a useful feature for loadp2 to have if you ever need to go higher. Right now with 3Mbps you could probably download a full 512kB image in around 2s or so which is typically fine for interactive development. It also means loadp2 remains generic and suits all P2 boards including those without crystals.
@jmg said:
Hmm. if the Baud is not changed, then the upper limit will be RCFAST initial autobaud limited ?
Yes, RCFAST is used in loadp2 and it will limit the rate. Not sure what to, maybe something under 12Mbps if the P2 needs two clock cycles to discern each bit transition and RCFAST ~ 24-25MHz.
The upper limit in the tests above is appx 4.8MBd - to get to 12MBd will need a PLL SysCLK of something over 50MHz
@evanh said:
Experience tells me that sysclock/4 (RCFAST/4) = 6 Mbaud is the more reasonable upper limit.
...
Roger hasn't submitted his fixes for the -CHIP autobauding.
The ping tests I did one page back, use only the ROM autobaud, which is multi-bit wide sampling. (ie they do not test loadp2 code base at all, just the ROM itself)
Those tests show anything above 4.8MBd with RCFAST, is less than 100% reliable.
It looks like 9600bps seems to be the lower limit for loading data into the P2, I can't seem to get any response to the initial "Prop_Chk" query made to the P2 at baud rates lower than this no matter how long I make the timeout. Perhaps this is some limit down in the loader ROM from its own auto-bauding process.
@rogloh said:
It looks like 9600bps seems to be the lower limit for loading data into the P2, I can't seem to get any response to the initial "Prop_Chk" query made to the P2 at baud rates lower than this no matter how long I make the timeout. Perhaps this is some limit down in the loader ROM from its own auto-bauding process.
Interesting, I can confirm 9600 is the lowest standard value.
I find 8000 is ok (always works) and 7900 fails (never works) . As you say, must be coded into the autobaud.
The 20% margin the represents for 9600 baud, is probably just enough to say 9600 is field-usable.
@jmg said:
The ping tests I did one page back, use only the ROM autobaud, which is multi-bit wide sampling. (ie they do not test loadp2 code base at all, just the ROM itself)
Those tests show anything above 4.8MBd with RCFAST, is less than 100% reliable.
And exactly the same result for -CHIP on this page?
@rogloh said:
It looks like 9600bps seems to be the lower limit for loading data into the P2, I can't seem to get any response to the initial "Prop_Chk" query made to the P2 at baud rates lower than this no matter how long I make the timeout. Perhaps this is some limit down in the loader ROM from its own auto-bauding process.
@jmg said:
The ping tests I did one page back, use only the ROM autobaud, which is multi-bit wide sampling. (ie they do not test loadp2 code base at all, just the ROM itself)
Those tests show anything above 4.8MBd with RCFAST, is less than 100% reliable.
And exactly the same result for -CHIP on this page?
Yes, very close.
rogloh pointed out the two stage loader does not change baud rates. Maybe it was another loader I was thinking of, that changed baud rates with the two-stages ?
If anything, Loadp2 has a slightly better failure curve than a simple singular ping, as loadp2 can retry until it gets an expected echo - ie gets a working 'autobaud snap'.
@evanh said:
But Roger has improved the operational range of -CHIP with his version.
Yes, my reading is the lower baud is improved (to now be ROM autobaud limited) and the change of autobaud window from single bit to 8 bits, will make the granularity the same as the ROM loader, which also samples over multiple bits.
The upper baud limit is still defined by ROM autobaud and RCFAST, until a second PLL baud stage is added.
If anyone wants to try my loadp2 changes before they are submitted for inclusion and can build from source I have included them here. Copy the zipped files over what is found the latest loadp2 Github source files found linked here and rebuild - I've not tested the associated Windows change though, only Mac, but in theory it should work now I've included the FlushFileBuffers API call on that platform: https://github.com/totalspectrum/loadp2
They should work at supported baud rates ranging from 9600 - 3Mbps using both -SINGLE and -CHIP (default) download modes without timeouts. On the MAC with the FTDI drivers I can get 9600...921600, 1000000, 1500000, 2000000 and 3000000bps download rates working now. Other platforms/drivers may not support all these rates.
I found this line in the ROM sources for the Autobaud ISR
limit long $58E4 'count limit ($58E4 = 1.3889, keeps SCAS within $7FFF w/norm1)
EDIT: I think that's estimated milliseconds at 20 MHz. The measurement is compared against the fall-to-fall time of seven bit-periods. So, longer than a millisecond and it gets rejected to prevent an overflow.
1 millisecond for seven bit periods is in the vicinity of around 9600 bps, so that could explain it.
It's a limit of 7690bps to be precise assuming 25MHz RCFAST. I just tried 7200bps but that failed and 8000bps passed, so it falls somewhere in-between which lines up with this number. Keeping the rate at least 9600bps gives some more safety margin.
Making 9600 the lowest supported rate isn't terrible. It'd be a very old modem that couldn't do that. Amazingly, even the erratic on-off compression behaviour (of old dial-up modems) would be okay here too.
@evanh said:
Making 9600 the lowest supported rate isn't terrible. It'd be a very old modem that couldn't do that. Amazingly, even the erratic on-off compression behaviour (of old dial-up modems) would be okay here too.
I have a number of modems (in original wrappers) that may not support 9600. Does this count??? Don't have a PSTN line tho
I've just submitted a GitHub PR to Eric with the suggested loadp2 changes to reduce serial port timeouts. That code is also now available here: https://github.com/rogloh/loadp2
Hopefully this might make it into loadp2 once it's been tested on a Windows platform.
@Cluso99 said:
I have a number of modems (in original wrappers) that may not support 9600. Does this count??? Don't have a PSTN line tho
Hehe, they'd have to be pre-compression models. You'd be talking pre-1987 as a guess. Once compression was added the comports usually supported 4x faster comport bit-rate than the modulation bit-rate. But did require using hardware handshaking as well.
@Cluso99 said:
I have a number of modems (in original wrappers) that may not support 9600. Does this count??? Don't have a PSTN line tho
Hehe, they'd have to be pre-compression models. You'd be talking pre-1987 as a guess. Once compression was added the comports usually supported 4x faster comport bit-rate than the modulation bit-rate. But did require using hardware handshaking as well.
OT: I have a rare Apple Modem 2400 (Apple branded built in Sydney for the USA market) ~1989 in original packaging. IIRC it is from the first batch we produced for them. Yes, it has MNP compression so it will go to at least 9600, and probably (I cannot recall) 19200 or 38400. IIRC there is a nice easter egg in the code (never before released) ... ATWHO?
ooooo, long time since I last typed any AT commands. EDIT: They're still used for certain modern equipment though aren't they. I went off dial-up when I quit the internet in 1995, next time I was online we had cable and web based router config. Haven't had any reason to be typing AT commands since. On fibre now.
@rogloh said:
I've just submitted a GitHub PR to Eric with the suggested loadp2 changes to reduce serial port timeouts. That code is also now available here: https://github.com/rogloh/loadp2
Hopefully this might make it into loadp2 once it's been tested on a Windows platform.
Does anyone know how to build this in Visual Studio ? Then I can check on Win10.
@jmg Looks like the makefile is setup to build the Windows target only as a cross compile from a Linux system and it's not designed for use with Visual Studio as is. I think you'd probaby need mingw or msys2 loaded on a Windows machine to obtain gcc & make and then do some makefile tweaking to setup a build under Windows.
Comments
Sounds like good progress, I've done the two-stage loader tests, as the lack of checksum test on -SINGLE was giving false screen reports.
I now have this, which is similar to the ping test fail curve above. ie 4.8MBd is the top reliable rate but higher rates can sometimes work ok.
but I'm unclear on how the 2 stage loader is choosing the first and second baud rates.
I expected a slower first handshake baud, and then a Clock change and a baud change, which means > 100MHz sysclks should be fine above 4.8MBd - but my tests do not do that ?
Both baud rates are the same in the two stage loader as well as for the autobaud char.
I'd be interested to see if my changes let you go higher more reliably. I think they might.
Hmm. if the Baud is not changed, then the upper limit will be RCFAST initial autobaud limited ?
If the P2 SysCLK is flipped to a PLL value, then the second baud rate should be able to go up to 15MBd or above. I can test 12MBd and 15Mbd here.
That's sounding good. Things like power-line modems can have low baud rates. As you say, not common, but it is useful to cover them 'while the bonnet is up'
I wonder if a loader needs command line define of both loader baud rates, should you get a baud-change added ?
Yes, RCFAST is used in loadp2 and it will limit the rate. Not sure what to, maybe something under 12Mbps if the P2 needs two clock cycles to discern each bit transition and RCFAST ~ 24-25MHz.
Might not be something I want to work on now, though at some point it might be a useful feature for loadp2 to have if you ever need to go higher. Right now with 3Mbps you could probably download a full 512kB image in around 2s or so which is typically fine for interactive development. It also means loadp2 remains generic and suits all P2 boards including those without crystals.
Experience tells me that sysclock/4 (RCFAST/4) = 6 Mbaud is the more reasonable upper limit.
The upper limit in the tests above is appx 4.8MBd - to get to 12MBd will need a PLL SysCLK of something over 50MHz
Roger hasn't submitted his fixes for the -CHIP autobauding.
...
The ping tests I did one page back, use only the ROM autobaud, which is multi-bit wide sampling. (ie they do not test loadp2 code base at all, just the ROM itself)
Those tests show anything above 4.8MBd with RCFAST, is less than 100% reliable.
It looks like 9600bps seems to be the lower limit for loading data into the P2, I can't seem to get any response to the initial "Prop_Chk" query made to the P2 at baud rates lower than this no matter how long I make the timeout. Perhaps this is some limit down in the loader ROM from its own auto-bauding process.
Interesting, I can confirm 9600 is the lowest standard value.
I find 8000 is ok (always works) and 7900 fails (never works) . As you say, must be coded into the autobaud.
The 20% margin the represents for 9600 baud, is probably just enough to say 9600 is field-usable.
FWIW The RP2040 are using a 1200 baud setting as a Reset signal to the USB bootloader. Certainly an interesting concept.
And exactly the same result for -CHIP on this page?
Possibly a MUL overflow ...
Yes, very close.
rogloh pointed out the two stage loader does not change baud rates. Maybe it was another loader I was thinking of, that changed baud rates with the two-stages ?
If anything, Loadp2 has a slightly better failure curve than a simple singular ping, as loadp2 can retry until it gets an expected echo - ie gets a working 'autobaud snap'.
But Roger has improved the operational range of -CHIP with his version.
Yes, my reading is the lower baud is improved (to now be ROM autobaud limited) and the change of autobaud window from single bit to 8 bits, will make the granularity the same as the ROM loader, which also samples over multiple bits.
The upper baud limit is still defined by ROM autobaud and RCFAST, until a second PLL baud stage is added.
I thought 3 Mbaud was screwy too.
If anyone wants to try my loadp2 changes before they are submitted for inclusion and can build from source I have included them here. Copy the zipped files over what is found the latest loadp2 Github source files found linked here and rebuild - I've not tested the associated Windows change though, only Mac, but in theory it should work now I've included the FlushFileBuffers API call on that platform:
https://github.com/totalspectrum/loadp2
They should work at supported baud rates ranging from 9600 - 3Mbps using both -SINGLE and -CHIP (default) download modes without timeouts. On the MAC with the FTDI drivers I can get 9600...921600, 1000000, 1500000, 2000000 and 3000000bps download rates working now. Other platforms/drivers may not support all these rates.
I found this line in the ROM sources for the Autobaud ISR
EDIT: I think that's estimated milliseconds at 20 MHz. The measurement is compared against the fall-to-fall time of seven bit-periods. So, longer than a millisecond and it gets rejected to prevent an overflow.
1 millisecond for seven bit periods is in the vicinity of around 9600 bps, so that could explain it.
It's a limit of 7690bps to be precise assuming 25MHz RCFAST. I just tried 7200bps but that failed and 8000bps passed, so it falls somewhere in-between which lines up with this number. Keeping the rate at least 9600bps gives some more safety margin.
Making 9600 the lowest supported rate isn't terrible. It'd be a very old modem that couldn't do that. Amazingly, even the erratic on-off compression behaviour (of old dial-up modems) would be okay here too.
I have a number of modems (in original wrappers) that may not support 9600. Does this count??? Don't have a PSTN line tho
I've just submitted a GitHub PR to Eric with the suggested loadp2 changes to reduce serial port timeouts. That code is also now available here:
https://github.com/rogloh/loadp2
Hopefully this might make it into loadp2 once it's been tested on a Windows platform.
Hehe, they'd have to be pre-compression models. You'd be talking pre-1987 as a guess. Once compression was added the comports usually supported 4x faster comport bit-rate than the modulation bit-rate. But did require using hardware handshaking as well.
Complete confidence.
Thanks for the effort Roger.
OT: I have a rare Apple Modem 2400 (Apple branded built in Sydney for the USA market) ~1989 in original packaging. IIRC it is from the first batch we produced for them. Yes, it has MNP compression so it will go to at least 9600, and probably (I cannot recall) 19200 or 38400. IIRC there is a nice easter egg in the code (never before released) ... ATWHO?
ooooo, long time since I last typed any AT commands. EDIT: They're still used for certain modern equipment though aren't they. I went off dial-up when I quit the internet in 1995, next time I was online we had cable and web based router config. Haven't had any reason to be typing AT commands since. On fibre now.
Does anyone know how to build this in Visual Studio ? Then I can check on Win10.
@jmg Looks like the makefile is setup to build the Windows target only as a cross compile from a Linux system and it's not designed for use with Visual Studio as is. I think you'd probaby need mingw or msys2 loaded on a Windows machine to obtain gcc & make and then do some makefile tweaking to setup a build under Windows.