dos.library v40.4 beta series
 

zz

dos.library v40.4 beta 1 (38 728 bytes)


:lol

Sadly I can't get a system to boot with the new dos.library my friend :(
Black screen forever.

It doesn't even boot a simple Install3.1.adf under WinUAE where I have a clone environment of my A600.

All is fine here : tested with WinUAE and my A1200

I use these versions :

exec_45.20(A1200-A500)_1Mo
icon.library_46.4.197(020+)
KingCON-handler_40.4(020+)
workbench.library_45.131(020+)
audio.device_37.10
battclock.resource_39.3
battmem.resource_39.2
bootmenu_44.7(68020)
card.resource_40.4
carddisk.resource_40.1
cia.resource_39.1
console.device_44.10
disk.resource_37.2
dos.library_40.4
DummyCDstrap
expansion_40.2(A1200)
filesystem.resource_45.10
filesystem_45.16
gadtools.library_40.4
graphics.lib_40.24(AGA)
input_40.1
intuition.library_40.85
keymap.library_40.4
layers.library_40.1
mathffp.library_40.1
mathieeesingbas.lib_40.4(020)
misc.resource_37.2
potgo.resource_37.4
ram-handler_39.4
ramdrive_39.35
ramlib_40.2
romboot_40.1
shell_45.27
timer.device_39.4
trackdisk.device_40.2
utility.library_40.1(020)
wbtask_39.1
scsi_43.47b1_A600_A1200


And you ?

Except the normal Kickstart 3.1 (40.63) modules... I'm using the following on my A600 WinUAE clone environment (030 no FPU, 64MB RAM, 2MB Chip):

• Exec 45.24 (instead of 40.10)... [Cosmos]
• BootMenu 44.7 68020 (instead of 40.5)... [OS3.9 BB2]
• Card.resource 40.5 (instead of 40.4)... [Cosmos]
• Console.device 44.10 (instead of 40.2)... [OS3.9 BB3]
• Datatypes.library 44.48 (instead of 44.47)... [OS3.9 BB4]
• Dos.library 40.4b1 (instead of 40.3)... [Cosmos]
• Filesystem.resource 45.10 (instead of 40.1)... [OS3.9 BB2]
• FastFilesystem 45.16 (instead of 40.1)... [OS3.9 BB4]
• Graphics.library 42.8b11 (instead of 40.24)... [Cosmos]
• KingCON-handler 40.4 (instead of Con-Handler 40.2)... [Cosmos]
• Icon.library 46.4.220 (instead of 40.1)... [PeterK]
• RAM Handler 44.24 (instead of 39.4)... [OS3.9 BB3]
• Ramlib 40.3 (instead of 40.2)... [Cosmos]
• Romheader 45.21 (instead of BlizKick module)... [Cosmos]
• SCSI.device 43.46b8 (instead of 40.5)... [Cosmos]
• Shell 45.27 (instead of 40.2)... [OS3.9 BB3]
• Trackdisk.device 40.2 (instead of 40.1)... [Cosmos]
• Workbench.library 45.131 (instead of 40.5)... [OS3.9 BB3]
• BBlank... [For Black Borders]
• HRTModule 2.30... [HRTmon using ACA630's NMI header]

All these work just fine without the new Dos.library.
Also even without your new Graphics.library, it has the same results

Working for me so far!

Working fine on real A1260 using RemApollo.
Still no joy with your latest version of exec.

@mfilos

And with the exec v45.20 ??


@all

Good news : I found two bugs in the dos.library v40.3 (Kickstart 3.1)

Wrong arg registers ! Will be fixed in the beta 2...

Hi Cosmos,
if you're going to fix a bug in dos.library, please check the DeleteVar() function, too. It seems to trash memory in the case that the supplied variable doesn't exist or could not be found by DeleteVar(). I would expect that trying to delete a non-existing variable should simply do nothing instead, but not trashing memory. I didn't analyze the code yet. Maybe you could check it and fix that issue. Thank you!

Tried with exec 45.20 (including 1MB_ROM+old romheader) and I get Red screen and reboots. With HD out of the system, I get the kickstart screen (as it did before with your own exec). It might be some patch or software from ClassicWB. I will investigate tomorrow and report back

@coders


1st bug :

move.l a6,-(sp)
move.l 4.w,a6
jsr R_FreeVec(a6)
move.l (sp)+,a6 ; d0 is trashed here : R_FreeVec return nothing
moveq #$69,d1
rol.l #1,d1
bra.b JL_0_241FE
JL_0_241F8
move.l #$000000D9,d1
JL_0_241FE
bsr.w AJL_0_204E6
...
...

AJL_0_204E6
move.l d2,-(sp)
move.l d0,d2
moveq #-1,d1
bsr.b JL_0_204F8
move.l (sp)+,d2
rts

JL_0_204F8
bsr.b JL_0_20484
lea $38(a0),a0
tst.l d1
bne.b JL_0_20516
move.l (a0),d1
move.l d1,d0
rts

JL_0_20516
move.l (a0),d1
move.l d2,(a0)
move.l d1,d0
rts

JL_0_20484
move.l 4.w,a0
move.l $114(a0),a0
add.w #$005C,a0
rts

The issues are 'moveq #$69,d1/rol.l #1,d1' and 'move.l #$000000D9,d1' : must be d0, of course !

It's a big bug, because this subroutine is called by a lot of functions into the dos.library...




2nd bug :

R_ExNext
moveq #$18,d0
tst.l d1
bne.b JL_0_243A4
move.l #$000000D3,d1
bsr.w AJL_0_204E6
moveq #0,d0
rts

JL_0_243A4
move.l d2,a0
clr.l $E0(a0)
move.l d2,-(sp)
lsr.l #2,d2
move.l d2,-(sp)
move.l sp,a0
bsr.w JL_0_22440
addq.w #4,sp
move.l (sp)+,d2
rts


JL_0_22440
link a5,#-$18
movem.l d2-d7/a2-a3,-(sp)
move.l d1,d7
move.l d0,d6
move.l a0,-$14(a5)
move.l -$14(a5),a0
move.l (a0),d0
...
...



AJL_0_204E6
move.l d2,-(sp)
move.l d0,d2
moveq #-1,d1
bsr.b JL_0_204F8
move.l (sp)+,d2
rts

'moveq #$18,d0' is for JL_0_243A4. 'move.l #$000000D3,d1' must be 'move.l #$000000D3,d0'


So, coders, are you agree with me ?

I resourced ROM 3.0/3.1 some months ago, I don't think that DOS library has a lot of unused code.

This code has no sense, but it can be C compiler problems, better check/compare a few other/older version of DOS library. F.e ROM 3.0 has less C compiler bugs than ROM 3.1.

or maybe just:

this would mean, there was only ONE mistake and not FOUR bugs,
but of course, I don't know the rest of the code in this function.

JL_0_204E6 is called more than 60 times (and all the time with arg_d0), so I changed d1 by d0...

I'll see & trace R_DeleteVar...


>I resourced ROM 3.0/3.1 some months ago, I don't think that DOS library has a lot of unused code

I removed all functions who haven't any entry point...

Wrong idea, especially if you don't have correctly resourced version of DOS library. DOS library is the hardest for resourcing part of Amiga ROM. For me DOS library is pseudo protection for hacking Amiga ROM, if you make something wrong (f.e. change or remove some parts, it will be crash or don't works correctly). But if you have 100% correctly resourced version of DOS library, then you can make every changes/fixes.

No entry point = code not called = code not used => deleted...

You are so wrong (well, I'm not surprised...) about that. There are so many ways to call routines which don't have any entry point that it's quite a bold move to delete these routines. Anyway, I'm not going to use any of your "fixed" libraries anyway so I guess I shouldn't care.

@StingRay

Do not read my threads, do not read my posts and go in hell...

I will not repeat...

Haha, amusing. :) If your patches would have the same quality as your cursing they'd be quite usable. But yeah, I won't comment here anymore, have fun "optimising" all the system libraries. :D

That's not very nice. Leave Stingray alone. This thread stinks like ein knoblauchschwert! :D