Do you know this:


http://www.dragonbasic.com/phpBB2/topic.php?t=381

it is a kind of Basic to program the GameBoyAdvance, but it is based on a language TIN that is based on Forth.

Strange: i liked this tiny Basic and at the same time i was very interested in all the Forth ideas and now i know that they are completely related !

sorry about this silly question, but here it come:
with this code, is it possible to boot an PC with my Usb memory stick?
(note: i dont know what "FDD stick" is. :-p)
if yes, then it´s cool.

Shokaku:
There's a page titled mf/tin , search for that on google,
tells a lot of good ideas.

XtcC:
Your memory stick is either identifying itself as a harddrive or a floppy.
Mine thinks he"s a Floppy Disk Drive (FDD), but it got 32 megs...
yeah it should be possible.

I also have a question:
Is 32bit code in real mode
(unreal mode) faster?

Interrupts will also be easier
to setup, play with and faster
to execute, is there any other
advantages?

Adam

, I've try it on 32-Bit mode. But it only give me value -1 on 1f0-1f1 port.

Hey Adman,
Regarding your question about 32-bit code in unreal-mode. The only difference between unreal-mode and real-mode is that the segment limits are set to 4gb. Aside from that it should be identical to real mode and thus code should execute at the same speed. However, if you use 32-bit code in real-mode you would need address/register size prefixes before your instructions. This adds 1-2 bytes per instruction that makes use of a 32-bit register and/or address which can only have a negative impact on speed.

Additionally, how would I modify your code to boot from a flash device? I have a 64mb USB mp3 player that I could hook up. Do you know if it might even be possible to boot directly from the usb device? As far as I know, no BIOS currently supports that.

Ralph, you are talking about the flat real mode - some people do call it unreal mode also, but I prefer to use the "unreal mode" name for the real mode that executes native 32-bit code (without prefixes). Current DOS version of fasm uses it, so you can look there to see how does it look like.

AdamMarquis, your question was answered here: http://board.flatassembler.net/topic.php?t=135#1442

Hm, I always wondered if it was possible to do that. I didn't think the 32-bit flag would carry over into real-mode. That's a really cool, although useless, trick. :)

Why useless? On 386 processor unREAL version of fasm is actually the fastest one. And on modern processor it has the same speed as 32-bit protected mode version.
The only problem when executing 32-bit code in real mode are the interrupts - in fasm I deal with them by using the additional IDT solely for 32-bit mode, which redirects all interrupts to 16-bit mode handlers (with quick mode switches). It was the most suprising for me, that even IDT base address for real mode can be moved! This allows to run 32-bit code with interrupts enabled, though all the 32-bit code must still fit in the first 64kB of segment, because high word of EIP is lost when interrupt is executed in real mode (even with 32-bit code enabled), to execute code from higher offsets you have to disable the interrupts first.

Useless because in my opinion 16-bit code died years ago. There is really no excuse for programming anything worthwhile in it anymore, especially not with everyone slowly migrading to 64-bit. Noone uses 16-bit applications, and if they do there is bound to be a 32-bit version available. It might be easier to learn, but that's not really applicable in this case. I can see how the 386 version can run the fastest, but realisticly, who still uses (and I mean uses, not has) a 386? And for anyone planning on responding with "me", go to your local school or computer store and check around the back by the dumpsters. There's bound to be some better hardware there. :)

As for the IDT base thing, I would've never suspected that. That's a neat trick I'm sure someone other than myself can put to good use. :)

This is 32-bit code, so the death of 16-bit one doesn't apply.
And generally unREAL mode gives you many of the advantages of protected mode (like 32-bit code and access to 4GB addressing space), while keeping it much simpler when you need to program some low-level OS-like features. Abillity to call both 16-bit and 32-bit BIOS functions in very simple way and very quickly, no need for the selectors, full control over hardware - that makes the unREAL an ideal solution when you want to programm something really low-level.

Well, I guess you got a point there. However, can't you achieve the same end result with protected mode if you just ignore all the additional bloat intel decided would be cool to throw in? Only use a single segment, run everything at ring0, etc.
You wouldn't get BIOS access, but real men don't need that anyway. :)

Yes, you're right, but you would have to write that everything yourself aswell.

Has anyone tried changing the boot device with that code yet? From what I can tell, port 1F6h will only let you choose between primary and secondary IDE device. I want to boot from floppy among other things.