mmm... much simpler/cleaner code here, adapted from AMD's docs

But the first question is : what kind of tempo/display/mark shall I use to witness I can at least enter 64-bit long mode ? I tried a long display after a "db 066h \ db 0eah \ dd my_patched_start64 \ dw selector64 but it failed.

And the second : how to quit it properly ? AMD says u cannot use a direct far jmp in long mode so I tried a far jmp , hardcoded db ff 2e \ dq my_patched_offset.

Still thinking :sweat:


:stupid: I have my first answer : an endless loop works fine :)

mov ecx,100000000
mov ebx,0b8000h + 160*10 + 10
mov eax,33

jmp jmpmemz
align 8
jmpmem:
dd SKIP64
dd 0
dw bootcode16-gdt
jmpmemz:

jmp_64:
db 066h
db 0eah
dd main64
dw bootcode64-gdt
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;;
;;;Start of 64-bit code
;;
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
main64:;At this point,we're using 64-bit code
use32
@@:
mov b,al
add al,1
add bl,2
dec ecx
jmp @b ;better than jnz @b !!!


Now the 2nd... :sweat:
Posted on 2004-02-08 19:40:28 by valy
bogdan, i also think this centralmembackbuffer-implementation is the best one for simplicity (but tell me, do you blast the whole screen again at each mouse pointer move?)

correct me if i m wrong, but if i remember right all you have to do is to

cli
jmp seg_sel_16:bank_switch
back:
sti


where seg_sel_16 is the selector of a seg in the 1st meg with 16b code containing:


bank_switch:
lidt
mov cr0,(cr0 or111...1110)
jmp real_mode_seg_of_this_code_seg:next_instr (cause int will push the selector if you dont do this)
next_instr:
mov regs, ...
int 0x10 (switch bank)
...rep movsd (blast the screen to 0x0A0000, hope you ve got a data segment register still having 4GB limits
(pointing to your src buff,if fs/gs are destroyed by int you must copy the src in lowmem BEFORE int)
mov cr0,(cr0 and 000..0001)
maybe reload data segs (gdtr shouldnt have changed)
lidt
jmp seg_sel_32:back


hmmm... that must be all if i didnt forget something :)

no?

(hope int0x10 dont enable ints again :) )


of course, with this it would be much more complicated to do a mouse handler that only redraws the cursor and not the whole screen and if you need vesa1.2 banking, blasting the whole screen will be ultra slow... or are you using some sort of hw cursor?
Posted on 2004-02-10 08:35:08 by HeLLoWorld
NO I do NOT redraw the whole screen at each mouse pointer move :grin:

1)Mouse is interupt driven so on IRQ12 (PS/2 mouse) i just get the data from the mouse and after raw interpretation i fill up a queue of mouse simple events (one event per mouse hardware interupt).
-->Nothing is redrawn at this point

2)Mouse usually reports multiple pixels movements depending on it movement speed and communications speed. So mouse will be drawn to the calculated destination rather than incrementaly move pixel by pixel (check with you Windows mouse : fast move and see it jump chunks on screen NOT single pixel movement
-->Nothing is redrawn at this point neither

3)When the SOL OS System_Executor checks the Mouse queue it will consume ALL events available and generate appropiate messages to all Windows in OS until the queue is exhausted.
-->Nothing is redrawn at this point neither

Indeed the Mouse is redrawn the LAST on the system backbuffer on each OS loop
(unless i have support for hardware pointer)

And the system backbuffer is rep movsd to video LFB after this.

Lately, in SOLOS there is an optimization that will redraw ONLY what is DIRTY (aka defined like this by either OS or USER applications). And Mouse always makes himself dirty both in the old possitions and the new ones.

However such kind of optimizations complicate things a little: applications should aditionally call Video_Dirty API functions to let OS know what areas to redraw on each loop. Also there is much more work to be done in this area...

So in the end tehoretically IF you do NOT move the mouse and NO window makes itself dirty (aka had dymanic content) THEN nothing will be redrawn ON SCREEN ...

IF i understand well, what you are proposing is a temporary return to realmode in order to do a BIOS int10 software INT and do a bank switch... well i might give it a try but not very soon, since i will prefer to be ale to do it in 32bits mode without a "dangerouse" return to realmode.

I will have to save first 1M of RAM status and INT tables/BIOS variables in order to be able to do this temporary return

i would not actually copy the screen there since i might do it faster in 32bits? I would be tempted to do just the bank switch there....

But i agree it is a logical solution without information on how to directly bank switch in 32bit mode for some video boards
Posted on 2004-02-10 15:00:57 by BogdanOntanu
okay...
so with no optimizations, if you move the mouse without doing anyting else (dragging windows etc) , you still redraw the whole screen ...

with optimizations (dirty areas), if the windows or the OS lag, you still dont redraw the pointer until everyting is calculated.

maybe one could make an exception for the mouse pointer since its so important for user responsiveness, and redraw it at every move (to real VRAM), even in the interrupt handling (that might make some of you SCREAM! :) ), maybe thats how i d do it. and then , yes, add messages to the os queue and wait for the next loop...

i think in windows when everything lags and you drag a window the window sometimes is a little bit behind the mouse cursor.

ofcourse with a banking scheme, all this complicates, if not forbids such a method.
(woohoo! PM/RM switch in an ISR! you would be the first to do that! :) )
Posted on 2004-02-10 15:52:14 by HeLLoWorld
Not exactly


so with no optimizations, if you move the mouse without doing anyting else (dragging windows etc) , you still redraw the whole screen ...


I redraw the screeen every once in a while in OS loop with no regard to the mouse move or not move. Yes without optimizations I redraw the screen every OS frame. But OS frames are not related to the mouse.

I do this every frame or every once in a while full screen redraw because I want to have an realtime OS and i will hate to miss some action on screen because of an event based error or delay in screen updates, but honestly also to keep things extra simple at startup.

Mouse speed/responsiveness depends on IRQ12 and hardware /software setup (acceleratin,dynamics) but has little to do with screen redraw.

I will not advice somebody to redraw the whole screen on mouse IRQ :grin:
You can get as many as 100 or 1000 mouse IRQs per seccond and this will be too much even for faster CPUs ... you can get by with caching what is under mouse and redrawin only that but still i will not advice this.

Besides theoretically most video boards have a hardware cursor designed to avoid such problems. I guess i will just enable that if available on hardware.

So basically in my design, moving or not moving the mouse has very little impact on OS speed with or without considering redrawing issues


i think in windows when everything lags and you drag a window the window sometimes is a little bit behind the mouse cursor.


Well that is a design problem of Windows, basically it delays redraw to gain speed, but on an environment that is event based, multiple events can trigger at most unappropiate times and can cut hardly on such design

Instead i hav choosen a design that is slower but allows more heavy dynamic contents and scalles down gracefully and slowly without bottlenecks and stalls when it has to do heavy overwork

Basically my OS will slow don but will NEVER STALL/not redraw contents


ofcourse with a banking scheme, all this complicates, if not forbids such a method.
(woohoo! PM/RM switch in an ISR! you would be the first to do that! )


Nope i will NOT do such thing :grin: is not my style
I do not even think it is possible without joining the triple fault club on a free ride...

I can deal with banked video board quite easy in the backbuffet to video copy routine, things are much more simple and centralized there...

Problem is i do NOT have such an banked video boar so i can not test this

Only my old laptop has one NeoMagic 128 with 800K video RAM maximum is 800x600x256colors or 640x480x64656colors

So if anybody knows/have the code todo bank switching for this old video board i will like to try it on my laptop
Posted on 2004-02-10 18:10:56 by BogdanOntanu
maybe one could make an exception for the mouse pointer since its so important for user responsiveness


In Windows it is... You have a hardware mousecursor (it is never actually drawn into videomemory, it is an overlay effect, handled by the hardware) which is always updated, sometimes even if the rest of the system has crashed :)
But then you run into the biggest problem when writing your own OS: drivers.
Which is why I'll just stick with Windows. At least I can actually use my hardware then :)
Posted on 2004-02-10 18:46:57 by Henk-Jan
:) I have it ! I am happy :)

Oh, and by the way I do not intend to do a full 64-bit OS, there will NOT be any drivers at all (never wrote one ; Win9x is good for all that stuff).
Posted on 2004-02-11 05:24:20 by valy
http://alexfru.narod.ru/emiscdocs.html contains lfbemu22.zip : linear frame buffer implementation, if anybody interested.
LFBemu 2.2 is a Linear Frame Buffer (aka LFB) emulator for VESA 1.xx+ cards

Otherwise... my current AMDO64 version maps 1 GB memory, I implement basic interrupts/exceptions.
Posted on 2004-02-18 06:38:10 by valy
Hi

I tested funny things like RIP relative-addressing, XMM, a movd that works on 64-bit, a 1 GB paging...
but I fail with IRQ/exception handling, so I wonder how I'll code the debugger :confused:
Linux kernel consists of 2 million lines... I'm quite afraid to dive into.

For my program, get yasm 0.3 from tortall.net, compile under DOS, execute from true DOS.


Last minute : http://www.os-soft.com/default.php?page=main.php
They seem to have done what I am trying to do. GPL. Not to be compiled from DOS but from a Linux machine. I'll give it a try.
Posted on 2004-04-20 01:34:25 by valy
I hardly believe it : it works :) :cool:

So here is another alpha/beta version.

Now who will code an integrated debugger (profiler/ide/assembler...) ? Who will make it bootable from an USB key ? ;)
Too bad, my Opteron bought last August does not seem to have this BIOS option. But I really intend to buy such a device.

Regards
Posted on 2004-05-19 05:43:01 by valy
Hello

What's new ?
1/ My Opteron CAN and did boot from my new and handful USB key :)
2/ I have a solution for debugging common x86-64 programs, below

Here is an easy way to debug x86-64 instructions :
get your favourite IDE for C (Bill's of course !),
compile and write some x86-64 ASM pseudo-instructions in C
with the few routines I give you below.
If you accept the syntax is NOT pure asm - C is limited,
my imagination too, and if you have smarter ways to do it,
please show me your code also. Any positive criticism is welcome.
For instance :
as2(mov al,1);
as2(mov ax,1);
as3eax(add,eax,dptr);
xor(RAX,RBX);
mmx3i(psllq,MM0,3);
movd64(XMM0,RAX);

This is ALPHA work, not even BETA.
Indeed it was easier to code this small emulator
than directly coding my (future) AMDO64 integrated debugger.

/*
What is AMDO64 ? My personal OS.
Only one mode : PM64 (64-bit long mode)
Only one ring : ring0
Only one leitmotiv : easier, faster.
EASIER : current OSes are monsters. Huge. Complex. Similar but different. Never as I want. Supporting obsolete hardware and software.
Mine may be pure 64-bit, compatible with nothing - except my only needs.
I intend mine to may be simple, highly specific.
FASTER : do you realize...
the time we take to develop nice apps, to learn one language ?
Not as fast as I hope, anyway. C is good but far less powerful
than Asm. Asm is efficient but hard to learn and code, and indeed
it is a nonsense to write efficient code slowly (slower than C)
for non critical parts of your program. So if one day I write my
own assembler, I intend to be able to write pure asm only, OR/AND
a kind of C syntax. Writing an IDE better than Bill's is a must - very
very long term and probably just a dream :-(

What's next ?
Now that I have a kind of x86-64 debugger, I intend to add a keyboard driver to my released "agner2.asm", then a few basic screen routines, then an easy and limited way to access FAT32, to read a file, then...
*/

Have a nice day

http://abyss32.chez.tiscali.fr/agner2.asm
http://abyss32.chez.tiscali.fr/a64ver1.zip
Posted on 2005-02-11 05:11:03 by valy
Does your link work? I keep getting 403 forbidden error.
Posted on 2005-02-11 07:57:20 by roticv
Does your link work? I keep getting 403 forbidden error.

That's probably one of new security protections on this board. Open new window (or panel in Mozzila :)) and copy&paste the link. Then it should work.
Posted on 2005-02-12 02:04:46 by MazeGen
Thanks MazeGen

Yes, a copy&paste is enough. Mozilla opens .asm directly.

I worked on that mysterious keyboard this week, and there's one bug less in my new uploaded AGNER2.ASM

Preparing a keyboard driver right now.

Regards
Posted on 2005-02-14 05:52:42 by valy
Keyboard driver OK, but no new release? :P

I wrote a Win32 version that disassembles most part of x86-64 instructions (no FPU).
This is a step to write my integrated debugger into AMDO64.
Any bug report is welcome.

See my website for download (d64.zip on http://abyss32.chez.tiscali.fr//index.html, you can click on my profile icons that I've just updated).

Have a nice day
Posted on 2005-04-15 07:41:07 by valy

Does your link work? I keep getting 403 forbidden error.

That's probably one of new security protections on this board. Open new window (or panel in Mozzila :)) and copy&paste the link. Then it should work.


Actually it seems more like the opposite. Some sites do not allow linking from other sites.
Posted on 2005-04-15 14:37:39 by SpooK
Hello

I wrote a Win32 version that converts Masm32 src to Yasm.
It fits my - light - needs.
Alpha version, buggy... just OK for me, and C source? :P

See my website for download (m32y64.c on http://abyss32.chez.tiscali.fr//index.html, you can click on my profile icons).

Next step for my OS: FAT16.

Bye
Posted on 2005-06-06 06:59:42 by valy
What is this about paging and 64bit OS's, i thorught you did not need paging, but you are limited to 4GB with out it ?.
Posted on 2005-06-07 14:06:44 by Dex4
?
Hello Dex4u.
I don't understand.
Paging is NECESSARYwith AMD64 64-bit long mode.
My agner2.* implements a version that will be good enough for upto 4 GB... or more, but no interest for the moment.
?

Regards


Posted on 2005-06-08 06:10:28 by valy
Hi valy,
? ? ? ? ? I did some more reading and learnt more about the way the 64bit AMD modes work.

PS: i found your code very interesting and helpfull thanks :) .
Posted on 2005-06-08 07:08:22 by Dex4