TAQOZ and Monitor listing/dump out format
Cluso99
Posts: 18,069
in Propeller 2
Peter and I are making both our output the same format so that the output can be pasted back into the Monitor (and TAQOZ??) as a download/store string.
Chip has modified pnut too.
Peter includes an extra space between long of 4 bytes which aids readability. I think that's a great idea so will also do that.
Here is the question... We are going to share the header string, so that also needs to be the same. But I fear we are running out of memory so I am thinking on just a single header line instead of two. Here is a sample of the output with a one line header and a two line header. Is the single line header ok?
Chip has modified pnut too.
Peter includes an extra space between long of 4 bytes which aids readability. I think that's a great idea so will also do that.
Here is the question... We are going to share the header string, so that also needs to be the same. But I fear we are running out of memory so I am thinking on just a single header line instead of two. Here is a sample of the output with a one line header and a two line header. Is the single line header ok?
addr- 0 1 2 3 4 5 6 7 8 9 A B C D E F
---------------------------------------------------------
000- 00 08 80 FF 3F 00 0C FC 32 B6 06 F6 1F 04 DC FC '....?...2.......'
004- 40 7E 74 FD 01 B8 A6 F0 1F B8 26 F4 00 B8 62 FD '@~t.......&...b.'
008- FA B7 6E FB 3F 00 0C FC 28 B2 64 FD E0 07 00 FF '..n.?...(.d.....'
00C- 3C 01 06 FB 29 58 65 FD E1 07 00 FF A4 20 04 FB '<...)Xe...... ..'
010- 28 7E 64 FD FF FF FF FF 00 FE 6F FC 35 82 4C FB '(~d.......o.5.L.'
014- 34 C2 4C FB 0A B6 06 F6 33 60 4C FB 2B 7C 4C FC '4.L.....3`L.+|L.'
018- 2F 7E 4C FC 28 7E 64 FD 00 60 07 FB E4 76 4C FB '/~L.(~d..`...vL.'
01C- D8 07 90 CD E2 7A 4C FB 10 00 90 CD E0 78 4C FB '.....zL......xL.'
addr- -0--1--2--3 -4--5--6--7 -8--9--A--B -C--D--E--F
000- 00 08 80 FF 3F 00 0C FC 32 B6 06 F6 1F 04 DC FC '....?...2.......'
004- 40 7E 74 FD 01 B8 A6 F0 1F B8 26 F4 00 B8 62 FD '@~t.......&...b.'
008- FA B7 6E FB 3F 00 0C FC 28 B2 64 FD E0 07 00 FF '..n.?...(.d.....'
00C- 3C 01 06 FB 29 58 65 FD E1 07 00 FF A4 20 04 FB '<...)Xe...... ..'
010- 28 7E 64 FD FF FF FF FF 00 FE 6F FC 35 82 4C FB '(~d.......o.5.L.'
014- 34 C2 4C FB 0A B6 06 F6 33 60 4C FB 2B 7C 4C FC '4.L.....3`L.+|L.'
018- 2F 7E 4C FC 28 7E 64 FD 00 60 07 FB E4 76 4C FB '/~L.(~d..`...vL.'
01C- D8 07 90 CD E2 7A 4C FB 10 00 90 CD E0 78 4C FB '.....zL......xL.'
Comments
EDIT:
added leading 0 to addr column
From the pnut listing (Ctl-M) copy a few lines from the listing (the addr data section) with CTL-C
Now with TeraTerm (PST doesn't support paste), and a connection to the monitor, do edit | paste. You won't see it all go in because of the cr lf issue, so just hit enter to get a clean prompt. Now list the addresses you pasted in For example. 00000.00030L<cr>
And you will see the data is now in hub
Yes, that is better, but better still surely, is to remove all the chaff that does not convey information ?
Which gives this, which is easier to visually scan, and now very similar to most Debuggers HEX screens...
I had trailing and leading hyphens to help connect the two parts of the address. However, that is not necessary as addr can be read across and down and the addresses cannot be confused with data as they are different sizes. Overall the above is cleaner and clearer and I think 0-F look much better right-aligned.
There is a space in the first column. Is this left empty deliberately for a possible C, L or H for Cog, LUT or Hub address?
This look best to me, by far. Simple is often best.
EDIT: Wait, you'll need those dashes. I'll add them. Okay, I also added 'hub' and 'cog'.
In VS, I can have the memory display show hex or dec as well as show bytes, words, dwords, and qwords. It can also display 32bit and 64bit float elements.
Makes it really nice for inspecting memory/data.
It has to do with being able to copy and paste hex-dump lines back into the monitor to actually write the memory.
This is a useful idea.
Reminds me years ago, I had Atmel change & expand their PLD reporting list files, so they could paste-back into the source code.
Quite modest changes, but they make the listing more generally useful.
That's six hex digits for the hub address when five is the maximum. Similarly for cog, it's four when it can't be more than three, but only two in the address column would look strange and could be confused with data. Why not have four address digits on the left always?
If hyphens are back in fashion then I prefer my original idea, especially as "addr" has gone:
What about LUT RAM? Does cog RAM flow into LUT and LUT into Hub automatically, or does each wrap around to its own start?
Doing that makes this hex dump unlike all the others I'm used to looking at, where the BYTE address is the left most column, and individual BYTES are shown.
It would be cleanest to have lut also as a heading, (even if the address also infers in-lut)
Makes it easier for new users to know what they are seeing.
What I said was wrong. 0-F refer to bytes, but addresses on the left refer to longs? Confusing.
The dash "-" is required as the store/download character for the monitor routine, just like L, G etc.
Similarly, the single quotes around the ascii is required (first one) is used to terminate the input in store/download. Otherwise you would not be able to cut and paste multiple lines or else that ascii would get stored too.
You can simply determine cog and lut by the 3 digit addresses. I don't have the space to put cog/lut/Hub in the header.
I output cog/lut/hub using the same routine, and to be consistent, I output the lot in bytes. So if your program is in hub and copied to cog, the bytes listed will be the same, not reversed.
My preference is to group each long with dashes in the heading. Shall I put the 0..F on the left or right nibble?
Roger.
I assume you got my emails about jumping back to 'try_serial' after SD boot failure. Just constrain your register usage to cog $1C0..$1EF. And no touching the LUT. If your code needs to use the LUT, the reentry will have to change.
I prefer right nibble, but is that the right question to ask?
I think mixing byte and long addressing is really confusing and users will hate it. Either have one or the other. The heading could be just "addr-" or omit it entirely. The versions of Debug I use don't tell me which of the 16 bytes is which and they are still useful.
If only the first single quote is required, could you move it so there is a space either side?
Given the address is in longs, but the data is in bytes, that's far from simple or clear.
Hence TonyB_'s suggestion of byte addresses & byte values
I'd scrub the leading '-' on the address line chaff, as that is not needed, but the trailing - is apparently a command, so it can be tolerated..
The full address is also required for the same reason. The header provides a reference only. Its not an address.
It's not like these are the only tools. Making these built in bits work well together is most important.
However, here is the format as it is right now:
Does that address field not auto-extend for > 1MB ?
My .02
In the Monitor, list $8000 to show what's there first, then paste with TeraTerm (edit|paste), then list out again to verify. All works
Copy also works from pnut listing and monitor listing too.
Here is the latest version of pnut's listing
A few thoughts:
1. It is unfortunate that L is not the command for Long data dumps. X is not intuitive. I wonder whether B and L could be used for Byte or Long dumps (or DB and DL perhaps)?
2. Three digit addresses for cog/LUT and five (or four) digits for hub addresses is a scheme that users should get accustomed to fairly quickly. No headings reduce the confusion. Presumably 200 is the first LUT address?
3. Does the first single-quote character before the ASCII block in effect signal the start of a comment string? If so, couldn't the second quote at the end be removed? The first quote would be better with a space afterwards in case the first data byte is $27.
4. Will there be copy & paste of long data between the Monitor and TAQOZ? They don't appear to be compatible at the moment as TAQOZ displays twice the data per line (too much IMO).
Is the underscore necessary?
5. Is it worthwhile trying to keep to a 80 character limit per display line, for the dump commands at least?
L= List, X= heX, G= Goto, -= store/download, R= Run
2. Yes, $000-$1FF is COG, $200-$3FF is LUT, $00000-$FFFFF is HUB.
3 or less digits are COG/LUT, 4+ digits are HUB. IIRC also any address >$400 will also be HUB. I actually fool the LIST command for HUB by setting bit 20=1 ie $100000 because that address bit is ignored when I do a rdlong.
3. Yes. In years gone by, the ascii was wrapped in single quotes. There is just as much reasoning to do it one way or the other. This is the way I chose.
4. Yes. Try this in Monitor
0- 11 22 33 44 55667788 <cr>
L<cr>
No (paste from TAQOZ. I am limited to a buffer of 78 characters, plus zero termination $0.
5. If I count correctly, I output 78 characters for the long format. TAQOZ exceeds 80 chacters for long dumps but there is no ascii. The underscores do enhance readability. I had to mod my code to allow underscores.
History: My Monitor was written for the original P2, way before even P2HOT. By design, it would have been a simple job to make it also run on P1, a job I never got time to do. I wrote it using LMM mode (a method used by Bill Henning to run code from HUB before hubexec was thought of. The original Monitor was way more versatile than its cut-down sibling today. Commands had a trailing optional numeric modifier. It also included a complete disassembler listing option. These all needs to be stripped to reduce the footprint in order for TAQOZ to fit.
By design, I also wanted to utilise as little resources as possible. It does not use PA or PB except in one instance, and here it pushes and pops the original value. It does use the internal stack, and likely almost the full depth - I had traced it a long time ago.
Other than Hub memory, it uses a 16 long footprint $1E0-$1EF in COG, and no LUT.
The HUB is all in ROM except for the read buffer of 80 characters. Currently this defaults to Hub $02000[80] but can be user relocated. After discussions with Chip, I intend to shift this into HUB ROM Yes, the ROM is not write protected so we've decided to use it. By removing the list heading, I gained enough space for the buffer. There is also the possibility of overwriting part of Chip's booter.
I'd like to put back the use of just <cr> to carry on the next List command. This used to work on the original monitor.