problem with unREAL mode fasm

Index > DOS > problem with unREAL mode fasm

Goto page Previous 1, 2, 3, 4, 5 Next

Author

Thread

Polygon

Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY

Polygon 11 Feb 2008, 14:10

Yes, Hello! I see you at my place also Very Happy

Well, while I'm here, I think I'm making progress with my un-real mode code. Instead of the code doing nothing, at least now it is rebooting the machine when it is executed. Progress? I think so Smile

I'm missiing something really simple, only because I have so little experience with FASM outside of some relatively simple code I use. This code is performing a simple task to set Tras to 17T. I'm just trying to get working code so I can expand on it as needed. It is used in a BIOS.

I've checked about 6 versions of unreal code and mine is very close, just not working.

This is either missing some correct pop/push's, or the segment registers aren't the correct ones or they are being set wrong. Or the GDT data is wrong. Can anyone see what is wrong with this flatmode code?

Code:

use16
        pushfd  
    push    eax
 push    ebx
 push    edx
 call    flatmode                ; first, set up FS to access all 4G 
        
    and ebx,0FFFFC000h              ; mask off bits 31:14 inclusive
 add ebx,250h                    ; point to the relevant part
        mov ax,[fs:ebx]             ; fetch data at 250h address
        and ax,07FFh                    ; set Tras data bit to zero
 or ax,8800h                     ; copy data for Tras 17T
    mov [fs:ebx],ax             ; send data with 17T change

     pop     edx
 pop     ebx
 pop     eax
 popfd                           ; Pop Stack into  Eflags Register
   retf                            ; Return Far from Procedure

;----------------------------------------------------------------------
flatmode:
 push ds
     push fs
     ; first, calculate the linear address of GDT
        xor     edx,edx                 ; clear edx
 xor     eax,eax                 ; clear edx
 mov     dx,ds                   ; get the data segment
      shl     edx,4                   ; shift it over a bit
       add     [cs:dword GDT+2],edx        ; store as GDT linear base addr
                                     ; now load the GDT into the GDTR
       lgdt    fword ptr cs:GDT         ; load GDT base (286-style 24-bit load)
     mov     bx,8                    ;1 * size DESC386 ; point to first descriptor
       mov     eax,cr0                 ; prepare to enter protected mode

       or      al,1                    ; flip the PE bit
   cli                             ; turn off interrupts
       mov     cr0,eax                 ; we're now in protected mode
      jmp 8:next
next:
 mov     fs,bx                   ; load the FS segment register
      and     al,0FEh                 ; clear the PE bit again
    mov     cr0,eax                 ; back to real mode
 jmp 8:next2
next2:
       sti                             ; resume handling interrupts
        pop fs
      pop ds
      ret                             ;
;----------------------------------------------------------------------
GDT:
    dw  000fh                       ; limit low
 dw  GDT                         ; base lo
   db  0                           ; base mid
  db  0                           ; dpltype
   db  0                           ; lim hi
    db  0                           ; base hi

       ; this is the setup for the 4G segment
      dw  0ffffh                      ; limit low
 dw  0                           ; base lo
   db  0                           ; base mid
  db  092h                        ; dpltype
   db  0cfh                        ; lim hi
    db  0                           ; base hi
GDT_END:

EDIT: Fixed code.

Last edited by Polygon on 11 Feb 2008, 15:19; edited 1 time in total

11 Feb 2008, 14:10

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20302
Location: In your JS exploiting you and your system

revolution 11 Feb 2008, 14:25

You still don't have a jump after you change cr0! bitRAKE showed you that even a near jump will work.

11 Feb 2008, 14:25

Polygon

Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY

Polygon 11 Feb 2008, 15:17

Opp's! Posted the old code. The jump is there.... OK, fixed the post.

Still something out of wack Rolling Eyes

11 Feb 2008, 15:17

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20302
Location: In your JS exploiting you and your system

revolution 11 Feb 2008, 16:10

You have jmp 8:label. Remember that the 8 means load CS with the second descriptor in the GDT. Maybe you could add another descriptor (as a code segment) for CS and then jump 16:label.

11 Feb 2008, 16:10

Polygon

Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY

Polygon 11 Feb 2008, 16:59

I'm really way over my head with this, and don't know how to do that. Sorry Smile

I'll try the near jump and see what happens...

11 Feb 2008, 16:59

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20302
Location: In your JS exploiting you and your system

revolution 11 Feb 2008, 17:16

The instruction: jmp seg:label,

seg ---> CS
label ---> IP

if seg=8 then get descriptor from GDT+8,
if seg=16 then get descriptor from GDT+16, etc.

In your GDT you have at +8 a data segment. So you cannot load that into CS, the CPU won't allow it. Which means, you have two options: 1) try what bitRAKE showed and use a near jmp, or 2) make a new descriptor at GDT+16 that is a code segment descriptor and use jmp 16:label

11 Feb 2008, 17:16

Polygon

Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY

Polygon 11 Feb 2008, 17:30

OK, thanks! I was doing fine until I needed to understand segments and descriptors; I need to go back and hit the books. Thanks again!

11 Feb 2008, 17:30

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 13 Feb 2008, 06:08

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/frms.zip

Quote:

Begin3
Title: Flat Real Mode Initializer
Version: 0.0pre2
Entered-date: 19OCT99
Description: Initializes the undocumented Flat Real Mode on 386+ CPUs
Keywords: FRM, Flat Real Mode, UnReal Mode, Big Real Mode, 386
Author: Louis P. Santillan
Maintained-by: lsantil@calstatela.edu
Primary-site: http://www.geocities.com/SiliconValley/Horizon/2979/frm/
Alternate-site:
Original-site: http://www.geocities.com/SiliconValley/Horizon/2979/frm/
Platforms: DOS, x86, 386
Copying-policy: GPL
End

13 Feb 2008, 06:08

DOS386

Joined: 08 Dec 2006
Posts: 1900

DOS386 18 Feb 2008, 04:39

Rugxulo wrote:

Quote:

latest testing r6 of CWSDPMI is recommended over r5 if you want access to huge amounts of RAM

Charles W. Sandmann wrote:

You will want to use the r6 test release if you plan to use more than
500MB.

It's from 2001, and not really useful Neutral

Tomasz wrote:

Quote:

I also did play with DOS interface a bit, I fixed some bugs and also managed to free some space under the 64k code limit, so that I still don't have to get rid of the unREAL mode from the DOS interface.

Rescued Un-REAL to 1.67.26 ... but still it seems to be a battle that can't be won this way Sad

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug

18 Feb 2008, 04:39

neville

Joined: 13 Jul 2008
Posts: 507
Location: New Zealand

neville 17 Jul 2008, 21:47

I'm not sure what the problem really is here, but I certainly rely on "unreal" or "flat real" mode - it's what I use for FAMOS memory operating system.

But, I understand Intel Long Mode does NOT support unreal mode so I will probably have to resort to Prot mode for future 64-bit versions of FAMOS Sad

About the code space - yes DOS flat binaries (COM) must only occupy 1 64K seg, but DOS EXE's must only run below the 16-bit seg:offset 1Mb limit. In FAMOS flat real mode, I run flat executable binaries up to 512Kb (across the equivalent of 8 DOS 64K segments!), and all executable code can be paged in from the 4-gig 32-bit memory space where it resides under FAMOS.

_________________
FAMOS - the first memory operating system

17 Jul 2008, 21:47

Kedar

Joined: 21 Nov 2008
Posts: 16

Kedar 21 Nov 2008, 01:53

Hi Tomasz. I've been working on a 3D GFX program, developed from Kelvar as wrapper code (no offense, credit given). It works well under DOS at this stage, except:
1 The GFX are slower than I would expect (I figure I should be writing to the video card directly for best results),
2 The program wont run under command prompt in 98 or XP (protected mode).
I presume the unREAL mode is a factor. What do you suggest?
(Thanks for FASM by the way, it's still the best PC ASM I've seen...)

21 Nov 2008, 01:53

DOS386

Joined: 08 Dec 2006
Posts: 1900

DOS386 21 Nov 2008, 02:06

> 1 The GFX are slower than I would expect (I figure I should be writing to the video card directly for best results)

VESA LFB uses direct write. Make sure to set the MTTRR's to "WC" (double-you-see Laughing

) for the VESA LFB (CPUID first !). Speed up depends from CPU + M.B. + G.C. : 1.000yyy times up to (reportedly) cca 50 times !!!

> 2 The program wont run under command prompt in 98 or XP
> (protected mode). I presume the unREAL mode is a factor.
> What do you suggest?

Develop for the "correct" OS matching your taste. Don't run DOS code in Windoze.

21 Nov 2008, 02:06

DOS386

Joined: 08 Dec 2006
Posts: 1900

DOS386 21 Nov 2008, 02:14

FYI, in 1.67.28 (obsolete) I found cca 1.5 KiB reserve without listing hack and cca 256 bytes with it ... no investigation of 1.67.29 yet. The trick was splitting DPMISYS.INC (no 64 KiB limit) from SYSTEM.INC .

21 Nov 2008, 02:14

Kedar

Joined: 21 Nov 2008
Posts: 16

Kedar 23 Nov 2008, 21:43

Re VESA LFB uses direct write. Make sure to set the MTTRR's to "WC" (double-you-see ) for the VESA LFB (CPUID first !).
...um, do you get code with that?

I'm just using a modification of Kelvar's VESA routines that gives me 800*600 and allows me to choose 256, 32K, or TC (1, 2, 4 bpp respectively for speed).

I'm used to thinking Amiga and writing direct to Chip RAM and Custom Regs, and setting the Copper to load this to screen, giving me 50 Hz redraw.
I'd like code that gives me the equivalent on PC, and so far I feel like I got faster and more professional results on my 8 MHz Amiga 2000.

Is anyone interested in a project, ie developing the pseudo-ultimate open source wrapper code for DOS Fasm? Cool

(Fasm OS instead of FreeDOS/MS-DOS wouldn't suck either)

This could resolve numerous GFX, SFX, etc issues for all, while all get to keep their personal project code private.

23 Nov 2008, 21:43

DOS386

Joined: 08 Dec 2006
Posts: 1900

DOS386 24 Nov 2008, 10:53

Kedar wrote:

...um, do you get code with that?

http://homepage.ntlworld.com/gvision/gv/vesamtrr.zip

Open source, MASM Neutral

24 Nov 2008, 10:53

Kedar

Joined: 21 Nov 2008
Posts: 16

Kedar 25 Nov 2008, 03:02

Sorry, I thought it was clear I meant FASM source code, but thanks for the executable...I'll try it...

...Again, sorry, I thought the reason I was at this site was because FASM and masm are different things, with FASM being the preference...

25 Nov 2008, 03:02

DOS386

Joined: 08 Dec 2006
Posts: 1900

DOS386 28 Nov 2008, 09:14

> was at this site was because FASM and masm are different things, with FASM being the preference...

True, but you can test the executable, if it brings the speedup, when ran before your code (effect remains until a reboot). If YES, you can port it to FASM. Hint: NDISASM is your friend. I don't have a FASM version Sad

28 Nov 2008, 09:14

Kedar

Joined: 21 Nov 2008
Posts: 16

Kedar 02 Dec 2008, 02:41

...my hard drive just lost its FAT... Rolling Eyes

...so I might be a while...

02 Dec 2008, 02:41

DOS386

Joined: 08 Dec 2006
Posts: 1900

DOS386 19 Feb 2009, 07:07

Tomasz wrote (2008-Jan-09) :

Quote:

I'm OK with throwing away the unreal, but I won't provide DPMI host with fasm. I just feel it's not the way it should be. I would make it work just like FASMD does now.

Done (UNREAL killed Shocked

) in 1.67.32. Still dreaming of a FASM version:

- Same design for commandline and IDE
- Not requiring a DPMI host
- Not suffering from 64 KiB limit
- Still working if a DOS-based DPMI host is present
- Not working on non-DOS

19 Feb 2009, 07:07

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8351
Location: Kraków, Poland

Tomasz Grysztar 19 Feb 2009, 09:46

I don't plan any more work in that direction. Reverting to own DPMI implementation wouldn't be such a good choice, since there are really much better DPMI implementations available out there.

There was once this guy that made fasm interface to work with VCPI, but it wasn't very good and is forgotten now.

The only option I see where the current solution could be improved is to make it scan (in case when no DPMI host is loaded) the PATH directories for one of the known DPMI host executables (like CWSDPMI.EXE) and load it for its single session. That would be the same thing, as the stubs for some of the extenders do.

19 Feb 2009, 09:46

Goto page Previous 1, 2, 3, 4, 5 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum