Slight change...
The command to list longs will be "LL" not "X".
Someone mentioned endian change before, can there be (eg) LL and LH to list in the two possible endian choices ?
Byte listings are incrementing-address, so an invisible flip to big-endian is just another thing to confuse users.
1. Commands cannot be A-F. Otherwise how do you know it's not a hex character?
L= List, X= heX, G= Goto, -= store/download, R= Run
...
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.
A-F can be used as commands if they come first on the line!
How many bytes are displayed with just <cr>? 64? 128?
Slight change...
The command to list longs will be "LL" not "X".
"LL" is certainly much better than "X". It's good that L for Long could be accommodated, thank you. Will just <cr> remember whether the last list was "L" or "LL"?
Someone mentioned endian change before, can there be (eg) LL and LH to list in the two possible endian choices ?
Byte listings are incrementing-address, so an invisible flip to big-endian is just another thing to confuse users.
With the extra space after every four bytes, I think little-endian longs are easy enough to see with plain "L". Is there room and the need for a "LW" for listing words? (Already available in TAQOZ.)
Other programs, such as enhanced Debug, don't show any ASCII chars for words or longs because they don't match the order of the displayed hex values, e.g. 'Y' is not FD.
Is it possible to have the option of a space to separate start and end addresses?
1. Commands cannot be A-F. Otherwise how do you know it's not a hex character?
L= List, X= heX, G= Goto, -= store/download, R= Run
...
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.
A-F can be used as commands if they come first on the line!
It's not the way I wrote the monitor, so A-F are invalid.
How many bytes are displayed with just <cr>? 64? 128?
Slight change...
The command to list longs will be "LL" not "X".
"LL" is certainly much better than "X". It's good that L for Long could be accommodated, thank you. Will just <cr> remember whether the last list was "L" or "LL"?
Someone mentioned endian change before, can there be (eg) LL and LH to list in the two possible endian choices ?
Byte listings are incrementing-address, so an invisible flip to big-endian is just another thing to confuse users.
With the extra space after every four bytes, I think little-endian longs are easy enough to see with plain "L". Is there room and the need for a "LW" for listing words? (Already available in TAQOZ.)
Just remember, if you are looking at bytes, they are the actual way they look in hub. For the same data in cog, they will look identical even though you cannot actually read cog/lut bytes.
If you are looking at longs, they represent the way you fetch a long (little endian in the P2). In this case, hub and cog/lut have the same access.
No, there will not be word even though you can actually enter words IIRC.
Other programs, such as enhanced Debug, don't show any ASCII chars for words or longs because they don't match the order of the displayed hex values, e.g. 'Y' is not FD.
The ascii helps to see what's there. If you don't want to see it, don't look
Is it possible to have the option of a space to separate start and end addresses?
I think most people would prefer 100 180ll instead of 100.180ll as they will be far more familiar with space than '.' as a separator. Why make space optional so it can't then be used as a separator?
I have coded it.Test tonight. Nothing comes for free and we are over the ROM limits
I don't even know what Peter has added
Nothing yet, I will probably add more but use less. I have my DE2-115 board running and I can see that it would be helpful to add some DAC support to TAQOZ, or at least allow machine code to be integrated easily.
Comments
000- 11 22 33 44 55 66 <cr>
000L<cr>
and
00000- 11 22 33 44 55 66 <cr>
00000L<cr>
Now explain why the difference?
The command to list longs will be "LL" not "X".
Someone mentioned endian change before, can there be (eg) LL and LH to list in the two possible endian choices ?
Byte listings are incrementing-address, so an invisible flip to big-endian is just another thing to confuse users.
A-F can be used as commands if they come first on the line!
How many bytes are displayed with just <cr>? 64? 128?
"LL" is certainly much better than "X". It's good that L for Long could be accommodated, thank you. Will just <cr> remember whether the last list was "L" or "LL"?
With the extra space after every four bytes, I think little-endian longs are easy enough to see with plain "L". Is there room and the need for a "LW" for listing words? (Already available in TAQOZ.)
Other programs, such as enhanced Debug, don't show any ASCII chars for words or longs because they don't match the order of the displayed hex values, e.g. 'Y' is not FD.
Is it possible to have the option of a space to separate start and end addresses?
If you are looking at longs, they represent the way you fetch a long (little endian in the P2). In this case, hub and cog/lut have the same access.
No, there will not be word even though you can actually enter words IIRC. The ascii helps to see what's there. If you don't want to see it, don't look
What does that mean and do?
I think most people would prefer 100 180ll instead of 100.180ll as they will be far more familiar with space than '.' as a separator. Why make space optional so it can't then be used as a separator?
It is what it is.
Postedit
Now I remember...
xxx.yyy was for an address range and
xxx,zzz was for an address plus line count
Was that a full stop you put at the end of your sentence or should we expect another parameter?
Seconded. Hopefully they can find some room
I don't even know what Peter has added
Nothing yet, I will probably add more but use less. I have my DE2-115 board running and I can see that it would be helpful to add some DAC support to TAQOZ, or at least allow machine code to be integrated easily.