intel manuals say that GDT may contain interrupt and trap gate.
how does they work?

when i call this gate, will it work similat to int, but on GDT?
when i jum to this gate, what will happen?


i CANT test because bochs doesnt support it.
im getting
gate type XX unsupported

chapter 3.5, SYSTEM DESCRIPTOR TYPES.
its when you set S bit to 0 in GDT/LDT. IDT also has this bit and i didnt found any info about those 'reserved?' gates.

call gates are explained, task gates work fine. int/trap = not supported

Use Virtual Box instead of Bochs. Then there is always Virtual PC...

then, there is always real PC, with USB boot, floppy boot, or IDE boot.

use bochs to debut the bootloader, and the kernel loader.
after, use a real pc to try your working version. and expand it.

all asm coder should have at least two PCs. one to code, and one to test in real conditions.

and about intel manuals, before to doubt of their content, read them with attention.

using real pc? ur joking? you have ANY idea how long it boots?
bochs is like 2 seconds, with full debug and most important - command line.
in virtualbox i have to use fucking mouse wich is annoying at least, and boot time is also too long.


THERE IS NOTHING ABOUT TRAP INTERRUPT GATES IN GDT!



and trap/interrupt gates doesnt work under virtualbox either

no way, but everybody is free to do what he wants no?

personnaly, my PCs boot faster that bochs.

in boot, i include, start, insert a floppy, load the floppy, execute code on the floppy.
and as long as i know, real PC works exactlly like a real PC, bochs and other don't.

Where does it say that? The only reference to them I can find talks about the IDT, not GDT.

Vol 3A, 2.1.4 "Gate descriptors in the IDT can be interrupt, trap, or task gate descriptors."

chapter 3.5

When the S (descriptor type) flag in a segment descriptor is clear, the descriptor type
is a system descriptor. The processor recognizes the following types of system
descriptors:
• Local descriptor-table (LDT) segment descriptor.
• Task-state segment (TSS) descriptor.
• Call-gate descriptor.
• Interrupt-gate descriptor.
• Trap-gate descriptor.
• Task-gate descriptor.
These descriptor types fall into two categories: system-segment descriptors and gate
descriptors. System-segment descriptors point to system segments (LDT and TSS
segments). Gate descriptors are in themselves “gates,” which hold pointers to procedure
entry points in code segments (call, interrupt, and trap gates) or which hold
segment selectors for TSS’s (task gates).


you might be right. it isnt precisly stated. its just said, its encoding.


how did you made boot time of normal pc < bochs?
i have 2 pcs, and they both perform extensive bios checks.
i can disable few of them, but it still is 30 seconds of boot before my bootloader is executed.

under bochs its < 1 second.

i don't want to troll.
but i confirm, my PC's boot in less time than bochs, and more, they are faster than bochs.
and better, they are more realistic than bochs
and secure, they don't crash my main PC, where bochs can crash the system or freeze.

but i don't want to troll no more, then, it was the last argument i wrote about it.

how fast your pc and bochs boot then?

[troll]
i have 3 machines:
omnibook PIII @ 800MHz (main pc) under win98, and various floppies
netbook atom @ 1.6GHz HT under XP and various USB sticks
desktop PMMX @233MHz under various

and two very old machines:

386DX compaq @ 33MHz under various
386 compaq @ 16MHz under various

and...

megadrive Sega 68000 @ 16MHz under sonic the hedgehog


my main PC boots win98 in 17 seconds (firefox included), and my floppies in 30 seconds (real floppies are naturally slow).
my two others PCs does the same with XP (or win98, or menuet, or dexos, or any) and the same with floppies
my netbook boots from USB stick in 3 to 5 seconds maxi.

bochs boots a simple floppy in 30 seconds mini, excluding the manipulations to start the boot process.
and load a .com file in 1 minute.
[/troll]


i use bochs for only one thing:

debug dangerous boot or kernel code, the ones who can completelly destroy my resisdent system if done in real boot.

i have nothing more to say. if you want to speak with a fool, speak with my lib

something is wrong with your bochs.
my boots almost immidiatly, with floppy image.

bochs is strange. it works really slow if i run dos or windows on it. (without OS it works fine) i tried to play with various settings (cpu, memory, kbd and vgs delays, etc.) but its performance is not acceptable on my core 2 duo with 2 gb of ram. something similar to running xp on pentium, i suppose. so i started using vmware. on my pc i can run 3 virtual machines without significant loss of performance under vmware.

floppy image is not floppy.

of course, with floppy image, it is faster to load, but it is still very slow to execute, and indeed, before to start, you should say to bochs what file to use [2] or [3]
and then, execute [6]
this step is not instantaneous.

and emulator is not real machine.!
i code for a real machine, not for an emulator.

then, if you start to code, you will have no longer time to chat, and you'll find solutions by yourself.

bochs isnt for os.
its just not compatible enough and too slow.
running bochs is simple.
bochs -q -f file

under console just arrow up and enter, you can connect it with fasm compilation.
up arrow, enter, and you compile and run your code instantly.

Perfect for testing, especially bios wich you cant replace under real machine.


and emulator is real machyne, by principal
just not created by transistors, but code instead. it has to be compatible.

You two are hilarious, it is like a soap opera! Your banter back and forth is awesome...keep it coming!

However, in the end, a real machine is what your code is to run for. I've had many problems with bochs and other emulators, but unfortunately i don't have the spare computers to work with. I do my coding on my laptop, and i have a desktop for a server which i prefer not to boot for testing, since it's busy doing other things.

Personally, i have no choice but to do my coding with bochs, then test it on a real machine. However, lately i've been unable to do much coding due to the lack of support bochs has compared to real machines. I agree that one must be able to practically run the code, not just test it in an emulator. It'd be nice if emulators were more accurate, but they still do not follow all the standards and support all the features at the same time. In theory, yes it's possible. In practice, no, it's not being done.

You test in Bochs, test in VirtualPC, test in VMWare, then go to the hassle of booting from a floppy...
Mind you, Bochs' debugger is worth its weight in bits (nice to see a triple fault actually happen a step at a time).

virtualpc/virtualbox SUCK at testing.
they are actually real machine, with limitations.

vmware is afair illegal, unless you pay and became property of corporation.


bochs is good, i agree it doesnt have all features of cpu, but i cant name even 1. all works for me under is, and bugs are only my fault or misinterpreted manual, like this topic.



btw: bootloader is only 512 bytes long. where can i have extra memory?
how do i obtain address of free-to-use memory in real mode? are there some standards about hardware mappings, or i have to query MSR or something else for memory?