changing the .org address doesn't change whether or not they are executed, and the hello world program that player did showed two extra characters before the "Hello World" when compiled with .org $9D93 and did not when compiled with .org $9D95. I thought that Nostub programs were to be compiled with .org $9D95, but shells like ion, MOS, and DCS used 9D93
Will_W wrote:
changing the .org address doesn't change whether or not they are executed, and the hello world program that player did showed two extra characters before the "Hello World" when compiled with .org $9D93 and did not when compiled with .org $9D95. I thought that Nostub programs were to be compiled with .org $9D95, but shells like ion, MOS, and DCS used 9D93
Seriously? I never really thought about the difference, but I suppose that's probably true. And you're correct, changing the .org would only change calculated non-relative jumps and calls, not the bytes that are included in the program.
Both are with 9D93. 100% sure.
(We're talking about label off-by-2 errors)
Then can you explain why the address was wrong by two bytes in the hello world program when compiled with $9D93? Can you explain why when I check in an emulator, the $BB,$6D is located at $9D95? Despite all the documentation claiming the contrary, I do not understand why 9D95 works and 9D93 does not.
Will_W wrote:
Then can you explain why the address was wrong by two bytes in the hello world program when compiled with $9D93? Can you explain why when I check in an emulator, the $BB,$6D is located at $9D95? Despite all the documentation claiming the contrary, I do not understand why 9D95 works and 9D93 does not.
.org tells the assembler where the code will be loaded into memory, it doesn't tell the OS where to load it. So if .org is wrong, all of your labels will be incorrect, but the data will still be located in the correct spot.
That said, programs launched with Asm( use .org $9D93, I don't know about shells.
I saw the debugger, the asmprgrm token was in 9D95, I don't understand it.
Edit: I test using rom version 1.12. Has the start point changed since then?
Probably not, but you should probably test on a newer OS anyway. IIRC, a number of things were added in 1.13, such as several hooks.
I lack the resources to test this. Would someone else do so?
The AsmPrgm token shouldn't even be copied to the execution area afaik. I'm definitely sure that the first byte of
executed code is loaded to $9d95.
One more thing: if you put the BB6D before the .org directive, you write $9d95. If you put it behind, you write $9D93.
Code:
.nolist
#include "ti83plus.inc"
.list
.org $9d93
.db $BB,$6D ;9d93
ld hl,text ;9d95
bcall(_PutS) ;9d98
bcall(_NewLine) ;9d9b
ret ;9d9c
text: ;9d9d
.db "Hello World",0
That's all.[/i]
EDIT: For the sake of avoiding misunderstandings: I'm testing with TilEm on OS 2.43, 83+ SE. (shouldn't change anything, though, unless you're on a 83)
Mapar007 wrote:
The AsmPrgm token shouldn't even be copied to the execution area afaik. I'm definitely sure that the first byte of executed code is loaded to $9d95.
Z80 has no true concept of "execution area" or "data area". So yes, AsmPrgrm token (and indeed all data in the program) will end up in what you are calling the "execution area".
Kllrnohj wrote:
Mapar007 wrote:
The AsmPrgm token shouldn't even be copied to the execution area afaik. I'm definitely sure that the first byte of executed code is loaded to $9d95.
Z80 has no true concept of "execution area" or "data area". So yes, AsmPrgrm token (and indeed all data in the program) will end up in what you are calling the "execution area".
By execution area I mean $9d95.
When I test it, the BB,6D is loaded into 9D95. Can anyone replicate it? I used wabbitemu with rom version 1.12.
I should have tested it on a real calculator when I had the chance.
KermMartian wrote:
Actually, that's only marginally true. The z80 implementation used in the 83/84-series calcs is physically prevented from executing in RAM Page 1, so technically $c000 through $ffff can be considered the "data area", and $8000 through $bfff memory that can be used as either executable or stored data. Nevertheless, you are correct, though without being pedantic, Mapar007 is also correct that the $BB,$6D doesn't get copied to $9d95 under either the native Asm execution routine or any third-party implementation.
Yes, I know about the $c000 cutoff. But is that enforced by the Z80 processor or by a different chip? I don't think Z80 itself has any concept of no-execute or protected areas.
Regardless, it isn't marginally true, its entirely true. The $c000 isn't a code/data separation, its simply a hard limit. If you look at an ELF executable, for example, there are clear separations of code and data. Same with x86, you can define code memory and data memory. Nothing like that exists on the Z80.
@Will_W: Post both your code AND a screenshot of the debugger showing the token at $9d95. I wouldn't be too surprised if you are simply misreading the debugger.
or accidentally have doubled your AsmPrgm tokens....
It's a hardware component blocking the $C000 area. You cannot execute code on even-numbered RAM-pages. By default, page 81h is mapped into the $8000-$BFFF bank, and page $80 is mapped into the $C000-$FFFF bank.
Kllrnohj wrote:
[...]Same with x86, you can define code memory and data memory.[...]
More specifically, for those who are curious, you can independently set the read, write, and execute bits on pages of memory. If you keep all your code on one page, with +rx-w, and your data on another page, with +rw-x, then you avoid the possible unpleasantness of executing data or reading code as data. Of course, you can't then have code and data on the same page, nor can you use such a scheme with SMC.
KermMartian wrote:
More specifically, for those who are curious, you can independently set the read, write, and execute bits on pages of memory. If you keep all your code on one page, with +rx-w, and your data on another page, with +rw-x, then you avoid the possible unpleasantness of executing data or reading code as data. Of course, you can't then have code and data on the same page, nor can you use such a scheme with SMC.
Actually, you can set it on a per byte basis or per page basis (specified on a per entry basis, so you can mix and match). You can also set the privilege level (ring 0-3, also known as kernel (ring 0) and user (ring 3) space) as well as whether it is valid in 16-bit real mode or 32-bit protected mode.
There are both global and local descriptor tables (up to 2^16 of them), so the kernel can have protected areas as well as every process.
And just to nitpick, you can't set rwx independently. You specify whether it is code or data. If code, whether or not you can read from it (writing isn't allowed), and if its data, whether or not you can write to it (reading always allowed)
What does the GUI say about his fill level? IT'S OVER 9000!!! 
