hi,
in bochs I have:

     Bochs is exiting with the following message:
     [CPU0 ] prefetch: RIP > CS.limit

I know it is all about code segment, but I don't know how to fix it.
I have a lot of source code, and it is hard to give it all, but it
looks, like:
- define macro which create point, directly in memory
- define macro which create rectangular, use poing macro
- create with rectangular macro, about 6 letters, it is not even a half
of the 320x200 resolution
- give it all in the main nasm module
- call screen drawing macro, which moves all bytes and makes it visible

Problem is, when I try to change this few letters to another


start_video:		; start label

finit			; enable coprocessor
stack			; make stack space, between bootloader and main code
video_init 19		; enable video mode, with given number


drawing:
	splash          ; this is the macro, which makes that letters
        draw_screen

	xor	ah, ah
	int	16h	         ; waiting for key press

;jmp drawing

	jmp	clear
	clear:
	clear_video_memory 0 ; moves 320x200 bytes to memory, make screen
black
	jmp	clear


macro clear_video_memory, makes screen black, but here it gives, this
info which is at the top of this post.
also when I try to do this:

rect 0, 0, 320, 200, 0, 15
     x1, y1, x2, y2, -, color

it makes all screen white, with 15 color, when I do this instead of
clear_video_memory, effect is the same.

how to prevent and fix it?

www.windows.za.pl/mas3.jpg
http://myfilestash.com/userfiles/cage/api_linux_18.tar
source code and screenshot :)

I don't know it is about video memory limit, or simply code limit,
which is maybe in real mode which I`m using currently? I DON'T KNOW :(

johny_cage wrote:

> rect 0, 0, 320, 200, 0, 15

I haven't looked at your code yet (there's a lot of it!). The last pixel 
on your screen is at 319, 199, not 320, 200 - dunno if that's got 
anything to do with it...

Later,
Frank

johny_cage wrote:
> hi,
> in bochs I have:
> 
>      Bochs is exiting with the following message:
>      [CPU0 ] prefetch: RIP > CS.limit

I don't know how RIP can exceed CS.limit. Real mode uses ip, not eip and 
hopefully not rip! I suspect Bochs is confused.

The image with your code boots fine for me. Is that the one you're 
having trouble with?

> I know it is all about code segment, but I don't know how to fix it.
> I have a lot of source code,

Yes. Looks like a lot of it isn't used in the current implementation. 
Your "bootsector.asm" still shows sectors loaded to A000:0000, but 
that's not what's in the image.

> and it is hard to give it all, but it
> looks, like:
> - define macro which create point, directly in memory
> - define macro which create rectangular, use poing macro
> - create with rectangular macro, about 6 letters, it is not even a half
> of the 320x200 resolution

I'm seeing more than 6 letters. "GOLOTA vs Predator" - the filled-in 
'O's look like crap, but otherwise it's a good looking screen. Doesn't 
do anything when I press a key...

> - give it all in the main nasm module
> - call screen drawing macro, which moves all bytes and makes it visible

You set ds to 9000h in your copy-buffer-to-screen routine, and don't set 
it back to 8000h where your data is. That's going to cause trouble, but 
I don't see how it could cause the message you're getting from Bochs...

You might want to keep better track of your segment registers - you 
repeatedly set es to A000h when it's already A000h, for example. That 
won't do any harm, unless you expect it to be something else. Setting ds 
to 9000h and then going back and doing "mov [my_var], ax" is going to 
give unexpected results!

You don't seem to use subroutines much. Got something against 'em? Very 
"repetitive" code...

Maybe if you explain exactly what you're assembling to get the results 
you're seeing... That "bootsector.asm" isn't producing the code I'm 
looking at! (and won't work)

Best,
Frank

Maybe I'm too stupid, to write in nasm :(
I will be trying to change from real mode to protected 32 bits mode :)

http://myfilestash.com/userfiles/cage/api_linux_19.tar

make su, and then:
(my directories, must change)
#!/bin/sh
set +e

cd api
nasm -o bootsector.bin -f bin bootsector.asm
nasm -o api.bin -f bin api.asm
wine merge.exe bootsector.bin api.bin mas.img
cp mas.img /usr/share/bochs/mas/
cd ../../..
cd /usr/share/bochs/mas/
bochs -f bochsrc.txt

bochsrc.txt file
www.windows.za.pl/bochsrc.txt

It is similar to previous one.
All I want to do is:
(in api.asm)

	splash
	draw_screen
	point_bios	160, 100, 15

and then I get in bochs RIP... you know
the thing is, that that "vs", and "predator", word are made from point,
generated with bios interrupts.  "GOLOTA", is made with rect macro,
which uses point put directly into memory.
So there is 6 letters of that kind, which causes problem (i think so).
Try do point_bios 160, 100, 15, which creates at X160, Y 100, and white
color, point with bios interrupt, for me it is impossible. I always
get, RIP cs...
AFTER this screen, I want to draw anything! I can't.

When I put anything after
splash
draw_screen
I get RIP CS..

Maybe I`m so stupid that I don't see something 100% wrong.

%macro 	draw_screen 0
        mov 	ax,09000h
        mov 	ds,ax
        mov 	si,0

        mov 	ax,0a000h
        mov 	es,ax
        mov 	di,0

	mov	cx, 32000
	rep	movsw
%endmacro

Or maybe it is something wrong with this?


When I have changed this:
point word [wall_x], word [wall_y], byte [colorize]
to this:
point_bios word [wall_x], word [wall_y], byte [colorize]
It works, so I may write this:
	splash
	point	160, 100, 15
	clear_video_memory 0
	draw_screen
	clear_video_memory 1
	draw_screen
	clear_video_memory 0
	draw_screen

But how to use:
point word [wall_x], word [wall_y], byte [colorize]
and get the same result?

Following your code in bochs...

(0) Breakpoint 1, 0x7c15 in ?? ()
Next at t=726774
(0) [0x00007c15] 0000:7c15 (unk. ctxt): jmp far 8000:0000         ; ea0000
(0) [0x00080000] 8000:0000 (unk. ctxt): fwait                     ; 9b
(0) [0x00080001] 8000:0001 (unk. ctxt): fninit                    ; dbe3
(0) [0x00080003] 8000:0003 (unk. ctxt): mov ax, 0x7c0             ; b8c007
(0) [0x00080006] 8000:0006 (unk. ctxt): mov ss, ax                ; 8ed0
(0) [0x00080008] 8000:0008 (unk. ctxt): mov sp, 0x3fe             ; bcfe03
(0) [0x0008000b] 8000:000b (unk. ctxt): xor ah, ah                ; 30e4

000813fe: (                    ): mov di, 0x0               ; bf0000

at this point, your screen is fully drawn....
Where do we go from here?!?!?
next instruction:

00081401: (                    ): add byte ptr ds:[bx+si], al ; 0000
00081403: (                    ): add byte ptr ds:[bx+si], al ; 0000
00081405: (                    ): add byte ptr ds:[bx+si], al ; 0000
00081407: (                    ): add byte ptr ds:[bx+si], al ; 0000
00081409: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008140b: (                    ): add byte ptr ds:[bx+si], al ; 0000

yada yada yada

0008ffe9: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008ffeb: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008ffed: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008ffef: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008fff1: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008fff3: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008fff5: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008fff7: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008fff9: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008fffb: (                    ): add byte ptr ds:[bx+si], al ; 0000
0008fffd: (                    ): add byte ptr ds:[bx+si], al ; 0000

<bochs:14> lb 0x8fffd
<bochs:15> c
(0) Breakpoint 2, 0x8fffd in ?? ()
Next at t=1647610
(0) [0x0008fffd] 8000:fffd (unk. ctxt): add byte ptr ds:[bx+si], al ; 0000
<bochs:16> s
Next at t=1647611
(0) [0x0008ffff] 8000:ffff (unk. ctxt): add byte ptr ds:[bx+si], al ; 0000
<bochs:17> s
00001647611p[CPU0 ] >>PANIC<< prefetch: RIP > CS.limit
00001647611i[SYS  ] Last time is 1123600939
# In bx_win32_gui_c::exit(void)!
========================================================================
Bochs is exiting with the following message:
[CPU0 ] prefetch: RIP > CS.limit

Bochs is exiting with the following message:
[CPU0 ] prefetch: RIP > CS.limit
========================================================================
00001647611i[CPU0 ] real mode
00001647611i[CPU0 ] CS.d_b = 16 bit
00001647611i[CPU0 ] SS.d_b = 16 bit
00001647611i[CPU0 ] | EAX=0fff9000  EBX=00000000  ECX=0001013f  EDX=000000a5
00001647611i[CPU0 ] | ESP=000003fe  EBP=00000000  ESI=0000fa00  EDI=00000000
00001647611i[CPU0 ] | IOPL=0 NV UP DI PL ZR NA PE NC
00001647611i[CPU0 ] | SEG selector     base    limit G D
00001647611i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00001647611i[CPU0 ] |  CS:8000( 0000| 0|  0) 00080000 0000ffff 0 0
00001647611i[CPU0 ] |  DS:9000( 0000| 0|  0) 00090000 0000ffff 0 0
00001647611i[CPU0 ] |  SS:07c0( 0000| 0|  0) 00007c00 0000ffff 0 0
00001647611i[CPU0 ] |  ES:9000( 0000| 0|  0) 00090000 0000ffff 0 0
00001647611i[CPU0 ] |  FS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00001647611i[CPU0 ] |  GS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00001647611i[CPU0 ] | EIP=00010000 (0000ffff)
00001647611i[CPU0 ] | CR0=0x00000010 CR1=0 CR2=0x00000000
00001647611i[CPU0 ] | CR3=0x00000000 CR4=0x00000000
00001647611i[CPU0 ] >> 00
00001647611i[CPU0 ] >> 00
00001647611i[CPU0 ] >> : add byte ptr ds:[bx+si], al
00001647611i[CTRL ] quit_sim called with exit code 1

Your code doesnt terminate?? Segment limit is reached.
So bochs is doing the right thing.

I'd terminate it with a CLI
then a HLT instruction

I loaded the image in your .TAR file into bochs (mas.img)

The debugger is your best friend.

Further to my other post, if your code does terminate properly from what you 
can see in your source
( I am too tired to look through it all), perhaps you have neglected to load
a sector containing the rest of the code when you loaded it at 0x8000:0000 
or not all of your code was
written to the sectors that you have loaded (disk image is wrongly 
written/missing data).

johny_cage wrote:

> Maybe I'm too stupid, to write in nasm :(

Possible. I'm too stupid to play the piano. Tried it, and it sounded 
like crap. So I guess I'm too stupid. :)

You might not be *stubborn* enough...

> I will be trying to change from real mode to protected 32 bits mode :)

That'll be a test! I know roughly how to get into PM, but before you can 
*do* anything, you've gotta set up an Interrupt Descriptor Table, 
paging, scheduling, memory management...

I *might* be smart enough to write an OS. We'll never know, 'cause I'm 
*way* too lazy! :)

Best,
Frank

Alex wrote:

.....
> at this point, your screen is fully drawn....
> Where do we go from here?!?!?
> next instruction:
> 
> 00081401: (                    ): add byte ptr ds:[bx+si], al ; 0000

That's weird. The last instructions in the version I've got, before we 
fall into data, are:

000016E2  B80090            mov ax,0x9000
000016E5  8ED8              mov ds,ax
000016E7  BE0000            mov si,0x0
000016EA  B800A0            mov ax,0xa000
000016ED  8EC0              mov es,ax
000016EF  BF0000            mov di,0x0
000016F2  B9007D            mov cx,0x7d00
000016F5  F3A5              rep movsw
000016F7  E917EB            jmp 0x211

Which, I believe, is the "draw_screen" macro...

.....
> 00001647611i[CPU0 ] | EIP=00010000 (0000ffff)

Here's the problem, alright. How does eip get to be 10000h in real 
mode??? I'd expect it to "wrap around". Looks like a "Bochs issue" to 
me. No doubt, there's something wrong with the code, that we get to this 
state, but I don't think ip is ever going to exceed its segment limit in 
"real" real mode.

The investigation continues...

Best,
Frank

On Tue, 9 Aug 2005, Frank Kotler wrote:

> I *might* be smart enough to write an OS. We'll never know, 'cause I'm 
> *way* too lazy! :)

I wrote one a long time ago. Until the disk i/o routines ate my hard 
disk...

-- 
http://www.munted.org.uk

Bugger me bollocks!

Hello frank :)

How did you debug it to come to that conclusion? I loaded his image
into bochs and used boch's internal debugger.
That way I stepped through his code right from the
moment bios gave control to the bootcode.
Unless what he gave in his .img file
is different from the actual source code.

I doubt bochs is at fault. IP reached 0xffff
beyond this bochs made no attempt to execute any
further instructions, its dump of the registers
with EIP at 0x10000 is a little misleading.

his screen draw is only writing 64000 bytes to 0xa0000
which is perfectly legal, he can dump 65536 bytes there
if he chooses.

Debug it in bochs and u will see what I mean, set
a breakpoint at 0x813fe then step.

His code may be complete in the source, but perhaps
the way it has been written to the image is the problem,
OR his loading code has issues.

Regards,
Alex


Regards,
Alex

-=*[Its a big ahh yes]*=-



On Tue, 9 Aug 2005, Frank Kotler wrote:

> Alex wrote:
>
> ....
>> at this point, your screen is fully drawn....
>> Where do we go from here?!?!?
>> next instruction:
>> 
>> 00081401: (                    ): add byte ptr ds:[bx+si], al ; 0000
>
> That's weird. The last instructions in the version I've got, before we fall 
> into data, are:
>
> 000016E2  B80090            mov ax,0x9000
> 000016E5  8ED8              mov ds,ax
> 000016E7  BE0000            mov si,0x0
> 000016EA  B800A0            mov ax,0xa000
> 000016ED  8EC0              mov es,ax
> 000016EF  BF0000            mov di,0x0
> 000016F2  B9007D            mov cx,0x7d00
> 000016F5  F3A5              rep movsw
> 000016F7  E917EB            jmp 0x211
>
> Which, I believe, is the "draw_screen" macro...
>
> ....
>> 00001647611i[CPU0 ] | EIP=00010000 (0000ffff)
>
> Here's the problem, alright. How does eip get to be 10000h in real mode??? 
> I'd expect it to "wrap around". Looks like a "Bochs issue" to me. No doubt, 
> there's something wrong with the code, that we get to this state, but I don't 
> think ip is ever going to exceed its segment limit in "real" real mode.
>
> The investigation continues...
>
> Best,
> Frank
>
>

johny_cage wrote:

> http://myfilestash.com/userfiles/cage/api_linux_19.tar

Okay, I was looking at 18. There's still something very mysterious here. 
Your "bootsector.asm" does:

org 7C00h

start:
   mov	dl, 0
   mov ah, 2
   mov al, 10
   mov ch, 0
   mov cl, 2
   mov dh, 0
   mov bx, 0a000h
   mov es, bx
   xor bx, bx
   int 13h

   jmp 0a000h:0000h

As you know, A000:0000 is video memory, and *not* where you'd want to 
put your code! "bootsector.bin" was apparently built from this, but 
"BOOTSECTOR.BIN" loads/jumps to 8000:0000, and this is apparently what's 
going into "mas.img". Where's the *real* source code? :)

> make su, and then:
> (my directories, must change)
> #!/bin/sh
> set +e

I don't know what this does...

> cd api
> nasm -o bootsector.bin -f bin bootsector.asm

This is gonna make the A000:0000 version...

> nasm -o api.bin -f bin api.asm
> wine merge.exe bootsector.bin api.bin mas.img

Gotta be a better way to do this. Why would I emulate an outhouse in my 
comfortable indoor bathroom? :)

> cp mas.img /usr/share/bochs/mas/
> cd ../../..
> cd /usr/share/bochs/mas/
> bochs -f bochsrc.txt
> 
> bochsrc.txt file
> www.windows.za.pl/bochsrc.txt
> 
> It is similar to previous one.

Okay. I didn't get the Bochs file. I've downloaded Bochs a few times, 
but never installed it. I've seen too many posts about, "Bochs is giving 
me this message, and I don't know what it means." I'm sure it's better 
than no debugger, but I haven't gotten a great impression of it. But 
that's just me...

What I'd do, if I had the ambition to tackle such a project, is write 
some macros to dump registers, dump stack, etc. and sprinkle 'em through 
the code.

> All I want to do is:
> (in api.asm)
> 
> 	splash

Okay, this invokes "rect", which eventually writes to 9000:xxxx, right? 
And then some *_line macros, which use bios?

> 	draw_screen

%macro 	draw_screen 0	
         mov 	ax,09000h   		
         mov 	ds,ax       		
         mov 	si,0
	  		
         mov 	ax,0a000h   		
         mov 	es,ax       		
         mov 	di,0        		

	mov	cx, 32000
	rep	movsw		                		
%endmacro

Okay, you've left ds set to 9000h...

> 	point_bios	160, 100, 15

%macro 	point_bios 3
	mov	ah, 12
	mov	bh, 0
	mov	dx, %2
	mov	cx, %1
	mov	al, %3
	int	10h
%endmacro

..... and then??? In "mas.img" (version 19), I'm seeing a "jmp 0x11", 
which is just after you set video mode. You move 14h into ax, then move 
ax into [9000:xxxx] instead of [8000:xxxx] as you did the first time 
around. Hmmm... I take that back. You didn't set ds at all the first 
time around - it's whatever your bios (or Bochs) left you with. You 
probably want to fix that - lord knows where you're writing to. In any 
case, at this point you're writing to [9000:xxxx], which you're using as 
video buffer, no?

> and then I get in bochs RIP...

Well, from what Alex is seeing, you're "falling off the end of your 
code". The CPU doesn't stop, it just keeps executing whatever's next. 
Eventually, it'll get to 0FFFFh, and then wrap around to 0 and keep 
executing... Definitely not what you want! Probably crash, eventually - 
probably before it formats your hard drive. :) But I really think the 
"RIP exceeds CS.limit" is an artifact of Bochs. This may not be true of 
x86-64... is that what you're running?

But *I* don't see where you run off the end of your code...

> you know
> the thing is, that that "vs", and "predator", word are made from point,
> generated with bios interrupts.  "GOLOTA", is made with rect macro,
> which uses point put directly into memory.
> So there is 6 letters of that kind, which causes problem (i think so).

What make you think this is the problem? You write these rectangles to 
9000:xxxx, right? And then copy that buffer to A000:xxxx? I would expect 
this to overwrite any bios pixels you've written...

> Try do point_bios 160, 100, 15, which creates at X160, Y 100, and white
> color, point with bios interrupt, for me it is impossible. I always
> get, RIP cs...
> AFTER this screen, I want to draw anything! I can't.

Let me fool with it some more. I've only "looked at" version 19. Version 
18 booted fine, but it may have been hung... (rebooted with 
ctl-alt-delete, which isn't the case if you're *badly* hung)

> When I put anything after
> splash
> draw_screen
> I get RIP CS..
> 
> Maybe I`m so stupid that I don't see something 100% wrong.

More likely you're reading what you intended to write, not what you 
wrote. Perhaps I'm reading what I expect to read, not what you wrote, 
too. There's a *reason* your program isn't working as expected - and the 
usual reason is "you screwed up" - we just need to figure out where...

> %macro 	draw_screen 0
>         mov 	ax,09000h
>         mov 	ds,ax
>         mov 	si,0
> 
>         mov 	ax,0a000h
>         mov 	es,ax
>         mov 	di,0
> 
> 	mov	cx, 32000
> 	rep	movsw
> %endmacro
> 
> Or maybe it is something wrong with this?

Besides it leaves ds where you probably don't want it, it looks okay to 
me. Using cx = 16000 and movsd is slightly faster... but make it run, 
first. Then make it run fast.

> When I have changed this:
> point word [wall_x], word [wall_y], byte [colorize]
> to this:
> point_bios word [wall_x], word [wall_y], byte [colorize]
> It works,

Weird. Both macros are getting their input from ds:[wall_x], etc. The 
only difference is that "point" writes to 9000:xxxx and needs to be 
copied to the screen.

> so I may write this:
> 	splash
> 	point	160, 100, 15
> 	clear_video_memory 0
> 	draw_screen

I wouldn't expect this to work. You write to 9000:xxxx and then clear 
9000:xxxx before you copy it to A000:0000!

> 	clear_video_memory 1
> 	draw_screen
> 	clear_video_memory 0
> 	draw_screen

You probably want to stuff a couple "getkey"s in there, or it will go by 
too fast to see.

> But how to use:
> point word [wall_x], word [wall_y], byte [colorize]
> and get the same result?

Get your segment registers under control.

Maybe I can discover more...

Best,
Frank

alex@ahhyes.net wrote:
> Hello frank :)
> 
> How did you debug it to come to that conclusion?

Didn't. Just by "inspection", which as we know, isn't always reliable...

> I loaded his image
> into bochs and used boch's internal debugger.
> That way I stepped through his code right from the
> moment bios gave control to the bootcode.
> Unless what he gave in his .img file
> is different from the actual source code.

Well... take a look at "bootsector.asm"...

> I doubt bochs is at fault. IP reached 0xffff
> beyond this bochs made no attempt to execute any
> further instructions, its dump of the registers
> with EIP at 0x10000 is a little misleading.

Okay... that isn't what's going to happen in a "real" machine.

> his screen draw is only writing 64000 bytes to 0xa0000
> which is perfectly legal, he can dump 65536 bytes there
> if he chooses.

Sure, but he leaves ds=9000h...

> Debug it in bochs and u will see what I mean, set
> a breakpoint at 0x813fe then step.

Haven't got Bochs (see my reply to "johny_cage"... isn't he the guy who 
writes the weird music? :) I may wind up installing it, just to get to 
the bottom of this...

Here's what I'm seeing - ndisasm output - haven't got the offsets just 
right, but I think this'd be 0x813xx in Bochs...

000015E4  B80090            mov ax,0x9000
000015E7  8ED8              mov ds,ax
000015E9  BE0000            mov si,0x0
000015EC  B800A0            mov ax,0xa000
000015EF  8EC0              mov es,ax
000015F1  BF0000            mov di,0x0
000015F4  B9007D            mov cx,0x7d00
000015F7  F3A5              rep movsw
000015F9  E915EC            jmp 0x211
000015FC  0000              add [bx+si],al
000015FE  0000              add [bx+si],al

If you've got a valid instruction to put a breakpoint at, we may be 
looking at different code.

> His code may be complete in the source, but perhaps
> the way it has been written to the image is the problem,
> OR his loading code has issues.

That's always a possibility. I'm writing the image to a floppy, and it 
appears to boot okay, but there may be problems I'm not seeing...

Best,
Frank

Last instruction I have is

000813fe: (                    ): mov di, 0x0               ; bf0000

Beyond there, its the abyss. Perhaps it is  part of the same routine
you have shown below, but the rest of the code is missing. There may be
other issues with his code as well. I think this is the most major of them 
all though. To me, this is whats causing the fault under bochs. I havent 
tested on a _real_ machine. Does it just hang beyond the splash screen?
Perhaps on real hardware it just hangs after the spash screen, rather than
rebooting itself.


Regards,
Alex


On Tue, 9 Aug 2005, Frank Kotler wrote:

>
> That's weird. The last instructions in the version I've got, before we fall 
> into data, are:
>
> 000016E2  B80090            mov ax,0x9000
> 000016E5  8ED8              mov ds,ax
> 000016E7  BE0000            mov si,0x0
> 000016EA  B800A0            mov ax,0xa000
> 000016ED  8EC0              mov es,ax
> 000016EF  BF0000            mov di,0x0
> 000016F2  B9007D            mov cx,0x7d00
> 000016F5  F3A5              rep movsw
> 000016F7  E917EB            jmp 0x211
>
> Which, I believe, is the "draw_screen" macro...
>

Interestingly enough, the mas.img file in the 19.tar doesnt
crash for me in bochs now. it runs ok. I get a splash screen and
that is all.  Did you change something Johny?

btw my AV scanner said your .tar file was a possible TSR boot virus.
considering its running under a virtual PC and not a real one, it doesnt 
worry me.


"Frank Kotler" <spamtrap@crayne.org> wrote in message 
news:fbOdnaVZ24FK2mTfRVn-gw@comcast.com...
> johny_cage wrote:
>
>> http://myfilestash.com/userfiles/cage/api_linux_19.tar
>
> Okay, I was looking at 18. There's still something very mysterious here. 
> Your "bootsector.asm" does:
>
> org 7C00h
>
> start:
>   mov dl, 0
>   mov ah, 2
>   mov al, 10
>   mov ch, 0
>   mov cl, 2
>   mov dh, 0
>   mov bx, 0a000h
>   mov es, bx
>   xor bx, bx
>   int 13h
>
>   jmp 0a000h:0000h
>
> As you know, A000:0000 is video memory, and *not* where you'd want to put 
> your code! "bootsector.bin" was apparently built from this, but 
> "BOOTSECTOR.BIN" loads/jumps to 8000:0000, and this is apparently what's 
> going into "mas.img". Where's the *real* source code? :)
>
>> make su, and then:
>> (my directories, must change)
>> #!/bin/sh
>> set +e
>
> I don't know what this does...
>
>> cd api
>> nasm -o bootsector.bin -f bin bootsector.asm
>
> This is gonna make the A000:0000 version...
>
>> nasm -o api.bin -f bin api.asm
>> wine merge.exe bootsector.bin api.bin mas.img
>
> Gotta be a better way to do this. Why would I emulate an outhouse in my 
> comfortable indoor bathroom? :)
>
>> cp mas.img /usr/share/bochs/mas/
>> cd ../../..
>> cd /usr/share/bochs/mas/
>> bochs -f bochsrc.txt
>>
>> bochsrc.txt file
>> www.windows.za.pl/bochsrc.txt
>>
>> It is similar to previous one.
>
> Okay. I didn't get the Bochs file. I've downloaded Bochs a few times, but 
> never installed it. I've seen too many posts about, "Bochs is giving me 
> this message, and I don't know what it means." I'm sure it's better than 
> no debugger, but I haven't gotten a great impression of it. But that's 
> just me...
>
> What I'd do, if I had the ambition to tackle such a project, is write some 
> macros to dump registers, dump stack, etc. and sprinkle 'em through the 
> code.
>
>> All I want to do is:
>> (in api.asm)
>>
>> splash
>
> Okay, this invokes "rect", which eventually writes to 9000:xxxx, right? 
> And then some *_line macros, which use bios?
>
>> draw_screen
>
> %macro draw_screen 0 mov ax,09000h   mov ds,ax       mov si,0
>   mov ax,0a000h   mov es,ax       mov di,0
> mov cx, 32000
> rep movsw                 %endmacro
>
> Okay, you've left ds set to 9000h...
>
>> point_bios 160, 100, 15
>
> %macro point_bios 3
> mov ah, 12
> mov bh, 0
> mov dx, %2
> mov cx, %1
> mov al, %3
> int 10h
> %endmacro
>
> .... and then??? In "mas.img" (version 19), I'm seeing a "jmp 0x11", which 
> is just after you set video mode. You move 14h into ax, then move ax into 
> [9000:xxxx] instead of [8000:xxxx] as you did the first time around. 
> Hmmm... I take that back. You didn't set ds at all the first time around - 
> it's whatever your bios (or Bochs) left you with. You probably want to fix 
> that - lord knows where you're writing to. In any case, at this point 
> you're writing to [9000:xxxx], which you're using as video buffer, no?
>
>> and then I get in bochs RIP...
>
> Well, from what Alex is seeing, you're "falling off the end of your code". 
> The CPU doesn't stop, it just keeps executing whatever's next. Eventually, 
> it'll get to 0FFFFh, and then wrap around to 0 and keep executing... 
> Definitely not what you want! Probably crash, eventually - probably before 
> it formats your hard drive. :) But I really think the "RIP exceeds 
> CS.limit" is an artifact of Bochs. This may not be true of x86-64... is 
> that what you're running?
>
> But *I* don't see where you run off the end of your code...
>
>> you know
>> the thing is, that that "vs", and "predator", word are made from point,
>> generated with bios interrupts.  "GOLOTA", is made with rect macro,
>> which uses point put directly into memory.
>> So there is 6 letters of that kind, which causes problem (i think so).
>
> What make you think this is the problem? You write these rectangles to 
> 9000:xxxx, right? And then copy that buffer to A000:xxxx? I would expect 
> this to overwrite any bios pixels you've written...
>
>> Try do point_bios 160, 100, 15, which creates at X160, Y 100, and white
>> color, point with bios interrupt, for me it is impossible. I always
>> get, RIP cs...
>> AFTER this screen, I want to draw anything! I can't.
>
> Let me fool with it some more. I've only "looked at" version 19. Version 
> 18 booted fine, but it may have been hung... (rebooted with 
> ctl-alt-delete, which isn't the case if you're *badly* hung)
>
>> When I put anything after
>> splash
>> draw_screen
>> I get RIP CS..
>>
>> Maybe I`m so stupid that I don't see something 100% wrong.
>
> More likely you're reading what you intended to write, not what you wrote. 
> Perhaps I'm reading what I expect to read, not what you wrote, too. 
> There's a *reason* your program isn't working as expected - and the usual 
> reason is "you screwed up" - we just need to figure out where...
>
>> %macro draw_screen 0
>>         mov ax,09000h
>>         mov ds,ax
>>         mov si,0
>>
>>         mov ax,0a000h
>>         mov es,ax
>>         mov di,0
>>
>> mov cx, 32000
>> rep movsw
>> %endmacro
>>
>> Or maybe it is something wrong with this?
>
> Besides it leaves ds where you probably don't want it, it looks okay to 
> me. Using cx = 16000 and movsd is slightly faster... but make it run, 
> first. Then make it run fast.
>
>> When I have changed this:
>> point word [wall_x], word [wall_y], byte [colorize]
>> to this:
>> point_bios word [wall_x], word [wall_y], byte [colorize]
>> It works,
>
> Weird. Both macros are getting their input from ds:[wall_x], etc. The only 
> difference is that "point" writes to 9000:xxxx and needs to be copied to 
> the screen.
>
>> so I may write this:
>> splash
>> point 160, 100, 15
>> clear_video_memory 0
>> draw_screen
>
> I wouldn't expect this to work. You write to 9000:xxxx and then clear 
> 9000:xxxx before you copy it to A000:0000!
>
>> clear_video_memory 1
>> draw_screen
>> clear_video_memory 0
>> draw_screen
>
> You probably want to stuff a couple "getkey"s in there, or it will go by 
> too fast to see.
>
>> But how to use:
>> point word [wall_x], word [wall_y], byte [colorize]
>> and get the same result?
>
> Get your segment registers under control.
>
> Maybe I can discover more...
>
> Best,
> Frank
> 

I made "consensus":
www.windows.za.pl/mas.img

It works, not as I was expecting, but it works.
I  have not enought knowledge about nasm. In november I will be a
computer science student, so I will have access to the school library,
where will be huge amount of books. I must read, read and ones more
read. It is the only way to know excatly what I'm doing wrong. All you
are for me very very helpful. Thx :)

Alex Buell wrote:
 
| > I *might* be smart enough to write an OS. We'll never know, 'cause I'm 
| > *way* too lazy! :)
 
| I wrote one a long time ago. Until the disk i/o routines ate my hard 
| disk...

A well known story for all Os-developers (including temporary attempts),
so I always backup all vital data before I try any change on my disk-
write routines.  ;)

__
wolfgang

On Wed, 10 Aug 2005, wolfgang kern wrote:

> Alex Buell wrote:
>
> | > I *might* be smart enough to write an OS. We'll never know, 'cause I'm
> | > *way* too lazy! :)
>
> | I wrote one a long time ago. Until the disk i/o routines ate my hard
> | disk...
>
> A well known story for all Os-developers (including temporary attempts),
> so I always backup all vital data before I try any change on my disk-
> write routines.  ;)

I didn't have the heart to write it all from scratch all over again. 
Some of that code I wrote was *elegant*. That was over 15 years ago.

-- 
http://www.munted.org.uk

Bugger me bollocks!

alex wrote:
> 
> Last instruction I have is
> 
> 000813fe: (                    ): mov di, 0x0               ; bf0000
> 
> Beyond there, its the abyss.

Hmmm, 13FEh, and the bootsector loads 10 sectors, hmmm...

I believe you have discovered the problem!

We *are* looking at slightly different code, I think. The "version 19" 
of "mas.img" that I've got does the "jmp (drawing:)" a few bytes shy of 
the 10 sector limit. Any change to the code... go boom!

As is, it boots, but I don't see "vs Predator".

The first change I made was to alter "bootsector.asm" to load/jump to 
8000:0000, so I could use it, and at the end of "api.asm", instead of 
jumping to "drawing:", I wait for a key and do "int 19h", which reloads 
the thing and lets me watch it again without actually rebooting. If I 
look real close, I can see "vs Predator" flash by real quick before it's 
overwritten by "draw_screen". I'm only doing 300MHz - probably not 
visible at all on a fast machine. This is an argument for using Bochs!

Next thing I did was to change "line.asm" to use the "point" macro, and 
eliminate the bios "*_line" code. Booting this, I see *nothing*, and 
haven't been able to figure out why... the fact that it's 6840 bytes 
long, and I'm loading 10 sectors might have something to do with it!

Thank you, Alex! Back to the laboratory...

Best,
Frank

"Alex Buell" <spamtrap@crayne.org> schrieb im Newsbeitrag
news:Pine.LNX.4.63.0508101959060.10332@cpc2-horn2-3-0-cust140.cos2.cable.ntl.com
....
| On Wed, 10 Aug 2005, wolfgang kern wrote:
|
| > Alex Buell wrote:
| >
| > | > I *might* be smart enough to write an OS. We'll never know, 'cause I'm
| > | > *way* too lazy! :)
| >
| > | I wrote one a long time ago. Until the disk i/o routines ate my hard
| > | disk...
| >
| > A well known story for all Os-developers (including temporary attempts),
| > so I always backup all vital data before I try any change on my disk-
| > write routines.  ;)
|
| I didn't have the heart to write it all from scratch all over again.
| Some of that code I wrote was *elegant*. That was over 15 years ago.
|
| --
| http://www.munted.org.uk
|
| Bugger me bollocks!
|

Alex Buell wrote:

| > | > I *might* be smart enough to write an OS. We'll never know, 'cause I'm
| > | > *way* too lazy! :)
| >
| > | I wrote one a long time ago. Until the disk i/o routines ate my hard
| > | disk...
| >
| > A well known story for all Os-developers (including temporary attempts),
| > so I always backup all vital data before I try any change on my disk-
| > write routines.  ;)
| 
| I didn't have the heart to write it all from scratch all over again. 
| Some of that code I wrote was *elegant*. That was over 15 years ago.

so at least you got an idea of what can be done in ASM,
which will always be much more than any offer from what the 
LIBrary-users are restricted to.

__
wolfgang

On Thu, 11 Aug 2005, wolfgang kern wrote:

> Alex Buell wrote:
>
> | > | > I *might* be smart enough to write an OS. We'll never know, 
> | > | > 'cause I'm *way* too lazy! :)
> | >
> | > | I wrote one a long time ago. Until the disk i/o routines ate my 
> | > | hard disk...
> | >
> | > A well known story for all Os-developers (including temporary 
> | > attempts), so I always backup all vital data before I try any 
> | > change on my disk- write routines.  ;)
> |
> | I didn't have the heart to write it all from scratch all over again. 
> | Some of that code I wrote was *elegant*. That was over 15 years ago.
>
> so at least you got an idea of what can be done in ASM, which will 
> always be much more than any offer from what the LIBrary-users are 
> restricted to.

Yes, it's quite complex. One of my biggest annoyances with VMware is the 
lack of access to the disk images from the native platform which makes 
it difficult to test code through VMware.

-- 
http://www.munted.org.uk

Bugger me bollocks!

Alex Buell wrote:
[..  disk-write routines]

| > | I didn't have the heart to write it all from scratch all over again. 
| > | Some of that code I wrote was *elegant*. That was over 15 years ago.

| > so at least you got an idea of what can be done in ASM, which will 
| > always be much more than any offer from what the LIBrary-users are 
| > restricted to.
 
| Yes, it's quite complex. One of my biggest annoyances with VMware is the 
| lack of access to the disk images from the native platform which makes 
| it difficult to test code through VMware.

A plain disk-edit, similar to ye olde DOS variant will not be a big deal.
Only weird file-systems like windoze-NT and LinDoSwapMix spoil the game :)
My own tool allow me to access every byte on any HD, but it only supports
FAT12/16/32 beside my own 'FATless' FS and the direct LBA-read/write yet.

__
wolfgang

Frank Kotler wrote:

.....
> Back to the laboratory...

Many reboots later...

http://home.comcast.net/~fbkotler/api19f.tar.bz2

Mostly just had to push/pop cx and dx around the "point" macro, since 
they were being used in the "line" macros... And get sgregs under 
control (a little). I left some "debugging" stuff in there - you'll 
probably want to take it back out... eventually...

Doing everything with macros produces some horribly "bloated" code. You 
could still use macros, so you could write:

line 1, 1, 20, 20 7

but make the macro just set up a call to the code that "does the 
business", rather than repeating it all each time. You might want to 
look up "Bresenham's Algorithm" - for drawing lines. There are simpler 
ways than what you're using...

Best,
Frank

Alex Buell wrote:
> Yes, it's quite complex. One of my biggest annoyances with VMware is the 
> lack of access to the disk images from the native platform which makes 
> it difficult to test code through VMware.

Someone has made a program which mounts VMWare disk images as native 
drives. I forget the link, but it is on a website called "VMWare's back".

Cheers,
Nicholas Sherlock

On Fri, 12 Aug 2005, Nicholas Sherlock wrote:

> Alex Buell wrote:
>>  Yes, it's quite complex. One of my biggest annoyances with VMware is the
>>  lack of access to the disk images from the native platform which makes it
>>  difficult to test code through VMware.
>
> Someone has made a program which mounts VMWare disk images as native 
> drives. I forget the link, but it is on a website called "VMWare's 
> back".

It's Windows only. I run VMware on Linux. Any suggestions?

-- 
http://www.munted.org.uk

Bugger me bollocks!