Re: Jump ends nowhere?!

On 10 mrt, 06:23, Keith Kanios <ke...@xxxxxxxxxx> wrote:
On Mar 9, 4:09 pm, 001 <snthib...@xxxxxxxxx> wrote:





On 9 mrt, 21:45, Keith Kanios <ke...@xxxxxxxxxx> wrote:

On Mar 9, 1:22 pm, 001 <snthib...@xxxxxxxxx> wrote:

On 9 mrt, 18:30, Keith Kanios <ke...@xxxxxxxxxx> wrote:

On Mar 9, 6:53 am, 001 <snthib...@xxxxxxxxx> wrote:

On 9 mrt, 12:41, 001 <snthib...@xxxxxxxxx> wrote:

On 9 mrt, 07:22, Keith Kanios <ke...@xxxxxxxxxx> wrote:

On Mar 8, 6:40 pm, Frank Kotler <fbkot...@xxxxxxxxxxx> wrote:

001 wrote:
On 8 mrt, 23:03, Keith Kanios <ke...@xxxxxxxxxx> wrote:

On Mar 8, 3:32 pm, 001 <snthib...@xxxxxxxxx> wrote:

This is probably a noob question... but I just don't get it...

Is that 2nd sector you are trying to jump to even loaded into memory?
I think not...

Okay... that might be a point... it is loaded from a CD and I thought
it would load al sectors of this code... but it is clear that the code
it jumps to is more than 2048 bytes away. Looking further into my
ISO-9660 code I found this:

dw ((Image_end - Image_start) / 0x800) + 1                 ;The number of sectors to
load

...

;The actual data loaded into memory - from sector 0x14
Image_start:
%include "realKernel.asm"
Image_end:

Obviously, this doesn't work, because in my image there was indeed a
'1' as sector-count. It explains a lot!

Do you have any suggestions for a better way to do this? Doesn't it
work with nested includes or shouldn't this work at all?

"Noob question" my achin' back! I gotta stay on my toes to keep up with
you guys! I would expect this to work, or to have Nasm complain.
"%include" is just a "cut and paste", and I would expect this to be
completed before "(Image_end - Image_start) / 0x800" is evaluated... but
it sure looks like this is evaluating to zero! Can you provide an
outline of what includes what? ... unless you've figured it out before
I've understood the question... :)

Best,
Frank

Perhaps, Frank. The assembly process is probably good, and even the
transfer to the CD.

However, it seems like those respective sectors are not being loaded
into RAM; or perhaps the jump is faulty due to a missing/miscalculated
ORG/base address???

001 does claim that his CD was only loading the first sector (2KB on
CD's as opposed to 512 bytes) and that the code being jumped to was
located beyond that first 2KB.

I guess the next step is to wait for more questions or diagnostic
information from 001.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Yes, I  used the El Torito standard with no emulation... I'm really
sure now that the "dw ((Image_end - Image_start) / 0x800) + 1"
evaluates to '1', because I viewed my ISO-image in a hex-editor.
However the code included is more than 2048 (decimal) bytes in total.
I'll take a look at the nested includes, see if it works if I declare
some bytes directly in the included file, instead of including other
files from there.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

When I declare bytes directly in the included file it does do the
math ;) Seems like NASM can't handle includes with more than one level
of depth...

If that was the case, my Operating System would never boot... among
other projects that utilize the same concepts you are using ;)

You just have to make sure you are using include files in a logical
manner.

Are you sure Image_start and Image_end are declared in the right
place???- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

I think it is:

This is the part from cdromboot.asm, it is declared at the bottom:

;The actual data loaded into memory - from sector 0x14
Image_start:
%include "realKernel.asm"
Image_end:

CD_end:

times (0x800 - ((CD_end - CD_start) % 0x800)) db 0      ;End the CD with a
power of 0x800 in total bytes (finnish unfinished sector ;) )

and then... this is realKernel.asm (whole file):

;This file provides a real-mode kernel.
;It is divided in several parts that make up the base functionality
for at least memory-management and module-management
[BITS 16]
Kernel_start:

%include "realStack.asm"
%include "realSafeStack.mac"
%include "realMemoryManagement.asm"

Kernel_end:

Nothing strange except the nested includes...

If you could, post a link of an uploaded copy of your CD boot image
(not the whole 640+ MB ISO) and/or the related source code (only the
parts that involve this loading/execution issue), as I am willing to
look at them to see where the problem may be.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Thank you...

I took a look at things, and I have a few questions/comments.

1.) From the tests I have run, the "dw ((Image_end - Image_start) /
0x800) + 1" code is working just fine. I've added oddly (non-2048
aligned) padded files in a similarly nested manner, and all of the
calculations came out clean.
2.) Is realStack.asm (the first included file) a code module/file; In
other words, is the CD yielding control to code???
3.) Bochs gives me the following when running your image: "prefetch:
EIP [00010000] > CS.limit [0000ffff]".- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

1) That's weird, I use NASM 2.02...
2) Yes, it yields control to that file... it always does with
everything that's included right (as long as there are no jumps over
it)?
3) Bochs doesn't give that in my case... The only thing this CD should
do is load the whole code to 0x0000:0500 (after the IVT and BIOS area)
and execute from there.


It bothers me that you can't reproduce my problem... maybe I can send
you the whole (failing) code?
.

Relevant Pages

  • Re: Jump ends nowhere?!
    ... it jumps to is more than 2048 bytes away. ... information from 001.- Tekst uit oorspronkelijk bericht niet weergeven - ...
    (alt.lang.asm)
  • Re: Jump ends nowhere?!
    ... it would load al sectors of this code... ... it jumps to is more than 2048 bytes away. ... information from 001.- Tekst uit oorspronkelijk bericht niet weergeven - ...
    (alt.lang.asm)
  • Re: Jump ends nowhere?!
    ... it jumps to is more than 2048 bytes away. ... information from 001.- Tekst uit oorspronkelijk bericht niet weergeven - ...
    (alt.lang.asm)
  • Re: can the loading of a large number of records go as quick as in DOS
    ... From your posting it seems that the old program only loaded data as it was ... Tekst uit oorspronkelijk bericht weergeven - ... I load the data via Form_load ...
    (microsoft.public.vb.general.discussion)
  • Re: can the loading of a large number of records go as quick as in DOS
    ... you load the data, and set it to tru when you are done. ... these records all the time in memory. ... Tekst uit oorspronkelijk bericht weergeven - ...
    (microsoft.public.vb.general.discussion)