debug output contains stray CRs

[jeffgunter]

when trying debug a disk i/o oddity in my tops10 monitor, i get odd simh debug output.

using
SET DEBUG STDOUT
SET RPA DEBUG
SET RPA NODEBUG=DATA

during sequences of
RPA fetch,
RPA fetch2,
RPAx read done
sequences, get stray CRs:

output from vi
DBG(2799152781)> RPA DETAIL: RPA3 seek 395 395^M
DBG(2799152781)> RPA DETAIL: RPA3 read (395,2,10)^M
DBG(2799152781)> RPA EXP: RPA fetch 001000 200000005120^M
DBG(2799152781)> RPA EXP: ^MRPA fetch2 005120 604002537101^M ?why highlighted ^M ?
DBG(2799152781)> RPA EXP: ^MRPA3 read done^M
DBG(2799154074)> RPA CONI: RPA 542 CONI 002413 PC=145733 0^M
DBG(2799154077)> RPA CONI: RPA 542 CONI 002413 PC=145735 0^M

output from hexdump
00001480 3a 20 52 50 41 20 66 65 74 63 68 20 30 30 31 30 |: RPA fetch 0010|
00001490 30 30 20 32 30 30 30 30 30 30 30 35 31 32 30 0d |00 200000005120.|
000014a0 0a 44 42 47 28 32 37 39 39 31 35 32 37 38 31 29 |.DBG(2799152781)| at 14bb? i think,
000014b0 3e 20 52 50 41 20 45 58 50 3a 20 0d 52 50 41 20 |> RPA EXP: .RPA | <== . represents stray 0d, ie=CR, octal 15
000014c0 66 65 74 63 68 32 20 30 30 35 31 32 30 20 36 30 |fetch2 005120 60|
000014d0 34 30 30 32 35 33 37 31 30 31 0d 0a 44 42 47 28 |4002537101..DBG(|
000014e0 32 37 39 39 31 35 32 37 38 31 29 3e 20 52 50 41 |2799152781)> RPA|
000014f0 20 45 58 50 3a 20 0d 52 50 41 33 20 72 65 61 64 | EXP: .RPA3 read|
00001500 20 64 6f 6e 65 0d 0a 44 42 47 28 32 37 39 39 31 | done..DBG(27991|
00001510 35 34 30 37 34 29 3e 20 52 50 41 20 43 4f 4e 49 |54074)> RPA CONI

this results in odd appearing output during some types of displaying.
vi is visually ok because it displays the cr as ^M.
however, for example if i scp the file from linux to my tops10 system,tops10, then tops10 .TYPE (PIP) or .TECO types out the CR and overwrites the line, and makes some of the output "disappear" (because it is overwriten). obviously the data is still there.

i understand completely if your response is that DEBUG isn't a supported thing.
i can make myself happy by post processing the resultant output file to make it more to my liking (ie: no overprints)

[rcornwell]

I thought I fixed all of these to be same order. You should be able to set file format to DOS to remove the CR char. Also aint had to debug disk data in years.

Massbus under RH20 should be solid. Unless you modified your monitor for KLH10.

[jeffgunter]

I'll try to set dos, hoping to get rid of the strays CRs but leave the eol CRLF sequence. we have modified RPXKON slightly, having found some problems with using online formatter and the write-format logic. and the pdp11 mode.  also some oddities in the FTCIDISK conditionals w/r/t DRBs which resulted in some dead code, and vice versa. however, it's not clear to me why i get frequent position hangs running our tops10 under simh -- but don't under klh10.  i think it's possible that it might be that simh simulation is faster than klh10 and tops10 misses an interrupt for something that is completed faster than expected, perhaps while tops10 is under "DSKOFF" or similar.  starting to look into that. our tops10 has something in rpxkon already which is pretty similar to SET RPA DEBUG, and one plan is to compare the trace from tops10/rpxkon against what simh says for the i/o request which hangs.  i will let you know if i find anything that is not my fault.

…

------ Original Message ------ Received: 08:08 PM EST, 11/08/2023 From: Richard Cornwell ***@***.***> To: rcornwell/sims ***@***.***> Cc: jeffgunter ***@***.***>, Author ***@***.***> Subject: Re: [rcornwell/sims] debug output contains stray CRs (Issue #312) I thought I fixed all of these to be same order. You should be able to set file format to DOS to remove the CR char. Also aint had to debug disk data in years. Massbus under RH20 should be solid. Unless you modified your monitor for KLH10. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#312 (comment)", "url": "#312 (comment)", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[rcornwell]

Ok. I believe I pass most of RP diagnostics, I can give you a copy of them if you want to try running them. Some don't make sense like parity errors and like. As to be faster. simH should be slower since it transfers data one word at a time, and simulate seek time.

Note the CR characters are there since set debug stderr output in raw mode so it does not look right in output. If there are any lf/cr's that I missed let me know.