flat assembler
Message board for the users of flat assembler.

Index > DOS > problem with unREAL mode fasm

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon
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
Post 11 Feb 2008, 14:10
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17248
Location: In your JS exploiting you and your system
revolution
You still don't have a jump after you change cr0! bitRAKE showed you that even a near jump will work.
Post 11 Feb 2008, 14:25
View user's profile Send private message Visit poster's website Reply with quote
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon
Opp's! Posted the old code. The jump is there.... OK, fixed the post.

Still something out of wack Rolling Eyes
Post 11 Feb 2008, 15:17
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17248
Location: In your JS exploiting you and your system
revolution
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.
Post 11 Feb 2008, 16:10
View user's profile Send private message Visit poster's website Reply with quote
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon
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...
Post 11 Feb 2008, 16:59
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17248
Location: In your JS exploiting you and your system
revolution
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
Post 11 Feb 2008, 17:16
View user's profile Send private message Visit poster's website Reply with quote
Polygon



Joined: 08 Feb 2008
Posts: 13
Location: Fire Island, NY
Polygon
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!
Post 11 Feb 2008, 17:30
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
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
Post 13 Feb 2008, 06:08
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
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
Post 18 Feb 2008, 04:39
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
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
Post 17 Jul 2008, 21:47
View user's profile Send private message Visit poster's website Reply with quote
Kedar



Joined: 21 Nov 2008
Posts: 16
Kedar
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...)
Post 21 Nov 2008, 01:53
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> 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.
Post 21 Nov 2008, 02:06
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
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 .
Post 21 Nov 2008, 02:14
View user's profile Send private message Reply with quote
Kedar



Joined: 21 Nov 2008
Posts: 16
Kedar
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.
Post 23 Nov 2008, 21:43
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Kedar wrote:
...um, do you get code with that?


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

Open source, MASM Neutral
Post 24 Nov 2008, 10:53
View user's profile Send private message Reply with quote
Kedar



Joined: 21 Nov 2008
Posts: 16
Kedar
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...
Post 25 Nov 2008, 03:02
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> 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
Post 28 Nov 2008, 09:14
View user's profile Send private message Reply with quote
Kedar



Joined: 21 Nov 2008
Posts: 16
Kedar
...my hard drive just lost its FAT... Rolling Eyes
...so I might be a while...
Post 02 Dec 2008, 02:41
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
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
Post 19 Feb 2009, 07:07
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7713
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 19 Feb 2009, 09:46
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
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


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.