1. RE: Poking unallocated memory
Hi Ben,
I just happen to have some machine code that I wrote (for Neil gfx lib
long ago) that will convert a physical address to an poke-able
Causeway-friendly virtual address. In the code below, replace
PhysBasePtr with your physical address, and the result video_mem will be
the address that you can poke to.
The machine code uses Causeway interrupt #31, function #19,
"Linear2Near" - CONVERT LINEAR TO APP-RELATIVE ADDRESS
(http://www.delorie.com/djgpp/doc/rbinter/ix/31/FF.html)
Regards,
Pete
include machine.e
-- code to convert the physical base address to the linear frame buffer
address
constant getlfb = allocate(86)
poke(getlfb, {
#60, -- 0: pusha
#8B,#1D,#52,#2B,#14,#02,-- 1: mov ebx, [@linear]
#85,#DB, -- 7: test ebx, ebx
#74,#0C, -- 9: jz batman
#89,#D9, -- B: mov ecx, ebx
#C1,#EB,#10, -- D: shr ebx, 16
#B8,#01,#08,#00,#00, -- 10: mov eax, #801
#CD,#31, -- 15: int #31
-- 17: batman:
#BB,#00,#00,#00,#00, -- 17: mov ebx, PhysBasePtr (24)
#89,#D9, -- 1C: mov ecx, ebx
#C1,#EB,#10, -- 1E: shr ebx, 16
#BE,#00,#00,#40,#00, -- 21: mov esi, 4194304
#89,#F7, -- 26: mov edi, esi
#C1,#EE,#10, -- 28: shr esi, 16
#B8,#00,#08,#00,#00, -- 2B: mov eax, #800
#CD,#31, -- 30: int #31
-- 32: jc robin
#C1,#E3,#10, -- 32: shl ebx, 16
#66,#89,#CB, -- 35: mov bx, cx
#89,#DE, -- 38: mov esi, ebx
#B8,#19,#FF,#00,#00, -- 3A: mov eax, #FF19
#CD,#31, -- 3F: int #31
#89,#35,#52,#2B,#14,#02,-- 41: mov [@linear], esi
#61, -- 47: popa
#C3, -- 48: ret
-- 49: robin:
#31,#C0, -- 49: xor eax, eax
#A3,#52,#2B,#14,#02, -- 4B: mov [@linear], eax
#61, -- 50: popa
#C3, -- 51: ret
#00,#00,#00,#00}) -- 52: linear: dd 0 (82)
poke4(getlfb + 3, getlfb + 82) -- @linear
poke4(getlfb + 67, getlfb + 82) -- @linear
poke4(getlfb + 76, getlfb + 82) -- @linear
poke4(getlfb + 24, PhysBasePtr) -- convert physical base address
call(getlfb) -- to linear frame buffer
video_mem = peek4u(getlfb + 82)
Ben Hanby wrote:
>
>
> Greetings,
>
> My application requires direct access to the top of memory space, near
> the 4 GB limit (where the BIOS resides). As one might expect, the
> CauseWay DOS extender does not allow this, and aborts with a protection
> fault.
>
> If there was actually memory in this area, maybe I could find a way to
> allocate it first, and then poke it. But this is just memory "space",
> not actual memory.
>
> Any ideas?
>
> Thanks,
> -Ben
>
2. RE: Poking unallocated memory
Ben:
I think that the bios resides in lower memory not at the top of memory.
What are you trying to accomplish with your code. Are you using DOS ?
You need to explain what you are trying to do.
Bernie
3. RE: Poking unallocated memory
Pete,
I haven't fully tested it, but so far this code seems to have done the
trick! Thank you very much for pointing this out to me.
One thing I'm still unclear on is the length of the frame buffer that
has been created. The code specifies a starting point for the physical
address, but not the length. The CauseWay interrupt URL you provided
below doesn't provide much detail.
But that is just a curiosity. The code works great.
Regards,
-Ben
euphoria at eberlein.org wrote:
>
>
> Hi Ben,
>
> I just happen to have some machine code that I wrote (for Neil gfx lib
> long ago) that will convert a physical address to an poke-able
> Causeway-friendly virtual address. In the code below, replace
> PhysBasePtr with your physical address, and the result video_mem will be
>
> the address that you can poke to.
>
> The machine code uses Causeway interrupt #31, function #19,
> "Linear2Near" - CONVERT LINEAR TO APP-RELATIVE ADDRESS
> (http://www.delorie.com/djgpp/doc/rbinter/ix/31/FF.html)
>
> Regards,
> Pete
>
> include machine.e
>
> -- code to convert the physical base address to the linear frame buffer
> address
> constant getlfb = allocate(86)
> poke(getlfb, {
> #60, -- 0: pusha
> #8B,#1D,#52,#2B,#14,#02,-- 1: mov ebx, [@linear]
> #85,#DB, -- 7: test ebx, ebx
> #74,#0C, -- 9: jz batman
> #89,#D9, -- B: mov ecx, ebx
> #C1,#EB,#10, -- D: shr ebx, 16
> #B8,#01,#08,#00,#00, -- 10: mov eax, #801
> #CD,#31, -- 15: int #31
> -- 17: batman:
> #BB,#00,#00,#00,#00, -- 17: mov ebx, PhysBasePtr (24)
> #89,#D9, -- 1C: mov ecx, ebx
> #C1,#EB,#10, -- 1E: shr ebx, 16
> #BE,#00,#00,#40,#00, -- 21: mov esi, 4194304
> #89,#F7, -- 26: mov edi, esi
> #C1,#EE,#10, -- 28: shr esi, 16
> #B8,#00,#08,#00,#00, -- 2B: mov eax, #800
> #CD,#31, -- 30: int #31
> -- 32: jc robin
> #C1,#E3,#10, -- 32: shl ebx, 16
> #66,#89,#CB, -- 35: mov bx, cx
> #89,#DE, -- 38: mov esi, ebx
> #B8,#19,#FF,#00,#00, -- 3A: mov eax, #FF19
> #CD,#31, -- 3F: int #31
> #89,#35,#52,#2B,#14,#02,-- 41: mov [@linear], esi
> #61, -- 47: popa
> #C3, -- 48: ret
> -- 49: robin:
> #31,#C0, -- 49: xor eax, eax
> #A3,#52,#2B,#14,#02, -- 4B: mov [@linear], eax
> #61, -- 50: popa
> #C3, -- 51: ret
> #00,#00,#00,#00}) -- 52: linear: dd 0 (82)
> poke4(getlfb + 3, getlfb + 82) -- @linear
> poke4(getlfb + 67, getlfb + 82) -- @linear
> poke4(getlfb + 76, getlfb + 82) -- @linear
>
>
> poke4(getlfb + 24, PhysBasePtr) -- convert physical base address
> call(getlfb) -- to linear frame buffer
> video_mem = peek4u(getlfb + 82)
>
4. RE: Poking unallocated memory
Bernie,
You are correct that the BIOS is normally accessed in "upper" memory,
just below 1 MB. But this is a shadowed version of the BIOS. To talk to
the real deal, you normally have to look at the very top of memory
space.
Regards,
-Ben
Bernard W. Ryan wrote:
>
> Ben:
>
> I think that the bios resides in lower memory not at the top of memory.
> What are you trying to accomplish with your code. Are you using DOS ?
> You need to explain what you are trying to do.
>
> Bernie
5. RE: Poking unallocated memory
Ben:
If you are going to excess the bios through shadow ram then
how are are you going to be sure that a user has it turn on
in setup on that particular system ?
Bernie
6. RE: Poking unallocated memory
You misunderstand. I'm not touching the BIOS in upper memory, which is
usually shadowed. I'm accessing the BIOS through the window at the top
of memory space, which can never be shadowed.
> Ben:
>
> If you are going to excess the bios through shadow ram then
> how are are you going to be sure that a user has it turn on
> in setup on that particular system ?
>
> Bernie
>
>
