Shouldnt this work?
Shouldnt this work?
...
Last edited by Lprogster on Tue Oct 23, 2007 11:32 am, edited 3 times in total.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
all instructions with [...] parts in it access memory. Depending on what you put between them, you access different types of it.
There's some host memory between 0x00000000 and 0x0009fff (the 640 k, and it may be less) and some after 0x00100000. In the gap inbetween you have video memory and the bioses. You are currently trying to store data into this area, which is a Bad Thing.
You should only use the host memory to store your data. I suggest you make a map of how your memory is / should be arranged, and consequently what you can and can not use.
I.e. the idea is good, but it comes at the wrong place.
There's some host memory between 0x00000000 and 0x0009fff (the 640 k, and it may be less) and some after 0x00100000. In the gap inbetween you have video memory and the bioses. You are currently trying to store data into this area, which is a Bad Thing.
You should only use the host memory to store your data. I suggest you make a map of how your memory is / should be arranged, and consequently what you can and can not use.
I.e. the idea is good, but it comes at the wrong place.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
I have realmode print functions in nasm, but not for protected mode. If you search the boards you might find a few written in C which you could port.
it would be something like:
I suggest you deduce the workings of this snippet so you can write your own without help later.
it would be something like:
Code: Select all
LEA ESI, [somestring]
CALL print
print:
MOV AH, color
MOV EDI, 0xB8000
.loop:
MOV AL, [ESI]
OR AL, AL
JZ .done
MOV [EDI], AX
INC ESI
ADD EDI, 2
JMP .loop
.done:
RET
In this specific case you really shouldn't store the data at all. Just use immediate values or registers for the copying loop. If your print code gets more complex you might use the push and pop instructions to cache your local data on the stack.combuster wrote:You should only use the host memory to store your data.
Code: Select all
mov byte [0xB8000], "I"
mov eax, 0xB8000
mov byte [eax], "I"
Code: Select all
variableA db 0x42 // byte (8bit)
variableB dw 0x42 // word (16bit)
variableC dd 0x42 // dword (32bit)
string db "Hello World", 0 // Zero terminated string
gaf
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
when creating flat binaries with NASM, you have to add an ORG directive to your files.
For 32-bit code thats just the physical address where your code is loaded. Something like:
if you have your code stuff loaded at 0x00010000 (= 1000:0000 in real mode)
For 32-bit code thats just the physical address where your code is loaded. Something like:
Code: Select all
ORG 0x10000
Are you sure about that? The attribute-byte must be set for every single character the screen. When you use a BIOS-service to blank the screen, it could be that the attribute is set back to black-on-black again, so you might want to check that. By other outputs - how are they carried out, in particular?Lprogster wrote: The text color must be white on black, cause when I do other outputs (not using print) the text is displayed.
Not necessarily... when you write to VGA directly, the BIOS's idea of what the current color is doesn't matter. Try addingLprogster wrote:The text color must be white on black, cause when I do other outputs (not using print) the text is displayed.
Code: Select all
inc ebx
mov [ebx], BYTE 0x70
[/code]
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
With A20 disabled, you can get access to 2GB of ram... IF you have 4 gigs installed. Basically you can only get access to the even MBs of memory with A20 disabled, effectively halving the amount of memory you can use.Lprogster wrote: EDIT: I am wondering is my bootsector is incorrect... Regarding this; do I need to setup the A20 gate to get all 2GB of RAM if I am in pmode?
So yes, enabling A20 is kindof required.
Also, Gate A20 matters not only in pmode, in real mode you can detect the differences as well.
As for the bootsector, could you post a copy of it for review. I see you copied the ORG directive, but I can't check if its correct or not, and i think its bogus...