Open-source dos.library

[mfilos]

Originally Posted by Photon

mfilos: why not feedback instead of asking, if possible? It's open source.

You're absolutely right.

The only reason I'm only asking (which I rarely do) is to only save time
I'm making custom ROMS on regular basis tinkering around, but for my A4000 I only use the Deneb for flashing new modules.
If for example the new dos.library has issues with my system based on how Deneb flashes it... it will make my system unable to boot...
That will make me change the jumper on Deneb to force system boot without the flash... which will make my system not booting again due to many custom alterations to the booting process.
OFC I can always use an backup CF to boot without all these fancy updates etc into plain AGA mode WB, and then load Luciferin and remove the Dos.library for my system to load as before.

Not so much of a fuss really but that was the only reason I asked a simple question... To avoid all this

[Don_Adan]

Originally Posted by mfilos

Does Deneb relocates correctly then when flashing the modules in it's memory?

I don't know, how works Deneb exactly, but if it works similar to kickstart/ROM switcher, then it must works OK for all custom ROMs. Of course all custom ROM parts must be relocated correctly before custom ROM is created with Remus. All ROM parts from BB2 and open (my) dos library part are relocated correctly, for other ROM parts (relocated with Remus), I'm not sure. Of course open (my) dos library can be buggy by me, due many (over 130KB of texts) changes were done, but original dos library has some bugs too, some are still unfixed. Always the best is check first how new module works with LoadModule or with WinUAE, before creating/burning custom ROM.

[Don_Adan]

Originally Posted by Photon

Thread moved to the right place and renamed, to avoid confusion with the topic of opening the dos.library

And about relocation Don Adan: I don't know the code for BlizKick, but if the software for relocating is system-friendly, it must work just as good with your version as with the latest dos.library released by C= Amiga. But I think it will - and nobody expects code with fixed ROM addresses to work these days so don't worry Those days ended when we got Kick 1.3

mfilos: why not feedback instead of asking, if possible? It's open source.

Sorry you are wrong, many ROM code used jmp $Fxxxxx, jsr $Fxxxxx or lea $Fxxxxx,Ax. If software ROM relocation will be easy, WHDload will be done this without .RTB file. Next problem is that some ROM data can looks f.e. as dc.l $FF5040, and what reloc this value or not?

[Photon]

mfilos: ok, if all other roms do.library or at least orig kick 3.1 work with Deneb, it means the new dos.library is different in some way, but perhaps not reloc. Don Adan should only have to make it as compatible as the orig lib, and it's the responsibility of Deneb to do the rest.

Don Adan: I meant software outside ROM haven't accessed absolute ROM adresses in a long while, last time I saw such an atrocity was in the era of kick 1.2 and custom A1000 kickstarts...

I said what I said in your defense; your lib must only be as compatible as the kick 3.1 one, and it's the responsibility of any FastKick software to do the rest.

Any address that's in the disassembled source and points to an address in the source/ROM range must be changed to point to a label, of course. But I think you mean it points outside of dos.library to another part of the ROM you disassembled. You must then looking in memory and try to find what it points to. If you have luck, it's some pointer you can get with some library code/access not using absolute addresses. If you're unlucky, it's a pointer that needs more detective work. Try to relate it to some structure (or if it's code, some ROM vector) + a distance that likely be constant.

[Don_Adan]

Next version is available.
Reworked: Read, Write, SetFileSize, Seek, UnLockRecord, DupLockFromFH,
ParentOfFH, LockRecord. Optimised: WaitForChar, SetMode.

[_mandark_]

Originally Posted by Don_Adan

All ROM parts from BB2 and open (my) dos library part are relocated correctly, for other ROM parts (relocated with Remus), I'm not sure.

Ok, if I got you correctly, OS 3.9 BB2-only ROM parts are ok for building a custom ROM with Remus and for testing your dos.library?

I see your objections against using Remus have valid points. If the wrong relocations are caused by Remus itself this issue should be fixed in Remus. But I am far from being an expert in these areas and maybe my grasp of this issue is too simple.

But on the other hand building a custom ROM with the original dos.library works just fine. And I agree with Photon that an updated open-source dos.library should stay compatible to the original in this aspect too.

Using 3.1 ROM will be a regression on my OS 3.9 A1200. Boot time will be longer because of setpatch's romupdate and the system will be slower because it has to access the ROM instead of the fast RAM on my ACA1230.

This is not meant as critics on your very apprectiated efforts, it's only my non-technical point of view.

[Don_Adan]

Originally Posted by _mandark_

Ok, if I got you correctly, OS 3.9 BB2-only ROM parts are ok for building a custom ROM with Remus and for testing your dos.library?

Yes, all has good relocations. Of course perhaps can contains some original bugs too.

Originally Posted by _mandark_

I see your objections against using Remus have valid points. If the wrong relocations are caused by Remus itself this issue should be fixed in Remus. But I am far from being an expert in these areas and maybe my grasp of this issue is too simple.

I don't know if Remus is still developed, but if yes, then author can add (optional) support for use SKick .RTB files for relocation ROM parts.
Similar he can add (optional) .RTB files output for created custom ROM and every custom ROM can be easy tested with SKick too.

Originally Posted by _mandark_

But on the other hand building a custom ROM with the original dos.library works just fine. And I agree with Photon that an updated open-source dos.library should stay compatible to the original in this aspect too.

Using 3.1 ROM will be a regression on my OS 3.9 A1200. Boot time will be longer because of setpatch's romupdate and the system will be slower because it has to access the ROM instead of the fast RAM on my ACA1230.

This is not meant as critics on your very apprectiated efforts, it's only my non-technical point of view.

I don't think that your crash problem is related to Remus bug. I'm almost sure that this crash problem is related to ACAtune map ROM routine, which works badly (exactly mapped custom ROM is wrong relocated in fast memory). I'm against poor relocation ROM routine only. If you want you can make tests with LoadModule and all BB2 parts plus dos.library and check effects. Similar you can create custom ROM and check how it works under WinUAE. If it works you can burn new ROM and replace original ROM. Similar you can use SKick with .RTB file (of course Remus must have option for creating .RTB file). But never use mapping ROM for tests, this is very poor idea, especially for custom ROMs or your Amiga programs can crash or works badly, and you don't know why it crashes. If you want fast and safe way for move ROM to Fast mem, use SKick only, no other solution is recomended by me, but this is your choice.

[gulliver]

Originally Posted by Don_Adan

I don't know if Remus is still developed, but if yes, then author can add (optional) support for use SKick .RTB files for relocation ROM parts.
Similar he can add (optional) .RTB files output for created custom ROM and every custom ROM can be easy tested with SKick too.

Remus is still being developed. I am currently betatesting a december 2011 build sent by its author (Doobrey).

[Don_Adan]

Originally Posted by gulliver

Remus is still being developed. I am currently betatesting a december 2011 build sent by its author (Doobrey).

Then adding .RTB input/output is good option for me. Perhaps ACAtune can be updated for .RTB files too.

Next version is available.

Reworked: LockDosList, AttemptLockDosList, WriteChars.
Optimised: FreeCliObject, FreeDosEntry.
Fixed original bug (trashed A6 register) for DateToStr, StrToDate.
Restored D1 mirror output for: CurrentDir, SetProgramDir, SetArgStr,
SetFileSysTask, SetConsoleTask, SelectInput, SelectOutput, SetIoErr
GetProgramDir, GetArgStr, GetConsoleTask, IoErr, Input, Output, GetFileSysTask.

[gulliver]

Originally Posted by Don_Adan

Then adding .RTB input/output is good option for me. Perhaps ACAtune can be updated for .RTB files too.

For ACAtune, you should contact Jens Schoenfeld. For adding RTB support to Remus, I will contact its author and see what he says about it.

[Don_Adan]

Next version is available.
Reworked FRead, FWrite, VFPrintf.

[Bamiga2002]

Are you finished yet with this library Don?

[Don_Adan]

No, due I'm lazy. Also I have/found two problems inside current version. First (mentioned by mandark, and second (memory problem) related to RARv3 client for xadmaster library. I'm not 100% sure, but perhaps some problems are related to buggy programs, not to my version of dos library.

[_mandark_]

I hope I can help by testing out my startup-sequence thoroughly the next days. Had not much for Amiga time lately...

[Bamiga2002]

I should have begun testing this, but I've had some other things to concentrate on. I'll test this too this week. Can I use loadmodule to load dos.library?

[gulliver]

Originally Posted by gulliver

For ACAtune, you should contact Jens Schoenfeld. For adding RTB support to Remus, I will contact its author and see what he says about it.

I contacted the author of Remus, email quote follows:


>I was suggested to ask you if possible, to add (optional) support for use SKick .RTB files for relocation of ROM parts. In a similar way you may add (optional) >.RTB file output for created custom ROMS, so now every custom ROM can be easily be tested with SKick too (http://aminet.net
>/util/boot/skick346.lha).

Its possible, but there are a couple of big drawbacks that could stop it being useable for testing ROMs.

1. SKick won't work with 1MB or 2MB ROMs
2. I'd have to disable Blizkick patches when making the ROM.
There's just no 100% safe way to tell what a Blizkick patch has done to the ROM , they often add or remove absolute addresses which would need to be added/removed from the RTB file, and there's no simple way to find out.
So you could end up with a custom ROM image that works in a ROM/WinUAE etc , but fails and crashes if used with SKick

[Don_Adan]

Originally Posted by Bamiga2002

I should have begun testing this, but I've had some other things to concentrate on. I'll test this too this week. Can I use loadmodule to load dos.library?

Test version is available.
One step back, restored original lbC0220D0 routine. Present I don't know
what can be wrong in my version, I suspected wrong (from OS 4.x) parameters for DosObjects.

[Don_Adan]

Originally Posted by gulliver

I contacted the author of Remus, email quote follows:


>I was suggested to ask you if possible, to add (optional) support for use SKick .RTB files for relocation of ROM parts. In a similar way you may add (optional) >.RTB file output for created custom ROMS, so now every custom ROM can be easily be tested with SKick too (http://aminet.net
>/util/boot/skick346.lha).

Its possible, but there are a couple of big drawbacks that could stop it being useable for testing ROMs.

1. SKick won't work with 1MB or 2MB ROMs
2. I'd have to disable Blizkick patches when making the ROM.
There's just no 100% safe way to tell what a Blizkick patch has done to the ROM , they often add or remove absolute addresses which would need to be added/removed from the RTB file, and there's no simple way to find out.
So you could end up with a custom ROM image that works in a ROM/WinUAE etc , but fails and crashes if used with SKick

RTB tables (from Skick) support can be useful for relocate much more Amiga ROM parts from 3.0/3.1 series. Also ROM parts can be easy compared if (Remus or RTB) relocations was OK.
SKick can't load 1MB ROMs, but other programs (after updates) can load 1MB ROMs with RTB. Also my target is 0.5MB ROM, then SKick can be used for tests.

[Bamiga2002]

No probs so far with new dos.library ...

[mfilos]

Yep I tested this along with all the new mini modules in my A600 (kicking a custom Kickstart via ACA630's MapROM) and it works just fine.
Nice work Don mate. Keep us posted

[_mandark_]

Finally had the time to test your new dos.library and it's working again on my machine! even in a custom built ROM

Shall I still test the nonworking version with my startup-sequence?

[Bamiga2002]

OK it seems dos.library causes a recoverable alert in WB 3.1 when accessing font-list in Font-preferences.

[Don_Adan]

Originally Posted by Bamiga2002

OK it seems dos.library causes a recoverable alert in WB 3.1 when accessing font-list in Font-preferences.

Thanks for tests.
Fixed version is available.

[Bamiga2002]

Thx will test this and report back.

[Bamiga2002]

Font-prefs font-requester doesn't display alert now and no other problems have arised yet . Good work!

[Don_Adan]

Originally Posted by Bamiga2002

Font-prefs font-requester doesn't display alert now and no other problems have arised yet . Good work!

OK. Next version is available.
Reworked AllocCliObject and SetVBuf, added (again) reworked and fixed
lbC0220D0 routine.

[Bamiga2002]

Thanks, testing testing...and if something occurs I'll tell ya!

[Don_Adan]

Next version is available.
Reworked big routine CreateNewProc. SetVBuf routine optimised by Mcoder, thanks.

[_mandark_]

Originally Posted by Don_Adan

OK. Next version is available.
Reworked AllocCliObject and SetVBuf, added (again) reworked and fixed
lbC0220D0 routine.

Just run this version and it worked fine. lbC0220D0 routine seems really fixed now, thanks! should I test the version you PM'ed me too, or is it obsolete now? I don't log in too regularly

[Don_Adan]

Originally Posted by _mandark_

Just run this version and it worked fine. lbC0220D0 routine seems really fixed now, thanks! should I test the version you PM'ed me too, or is it obsolete now? I don't log in too regularly

Latest version is available on the WT page, you can ignore version from PM link.

[spoUP]

What's the benefits of this? Speed?

[Don_Adan]

Originally Posted by spoUP

What's the benefits of this? Speed?

Mostly size only plus some original bugfixes, but speed can be average 20% fastest too, dependent which dos routines are called.

[Don_Adan]

Next version is available.
Next my bug fixed, branches optimised, reworked NameFromLock, NameFromFH and CreateProc.

[_mandark_]

New version working fine. Played a game of Popolous and backuped my system-partition in a 41 MB lzx-file with nothing unusual happening so far...

I am curious how much is still left for reworking?

[Don_Adan]

Originally Posted by _mandark_

New version working fine. Played a game of Popolous and backuped my system-partition in a 41 MB lzx-file with nothing unusual happening so far...

I am curious how much is still left for reworking?

Perhaps a few (2-3) KB of C code only exist in latest version. But some original ASM routines can be reworked too, I thinked mostly about Time/Date related routines.

[Don_Adan]

Next version is available.
Reworked StartNotify.

[_mandark_]

The new version is running well so far.

[AndyF]

Originally Posted by Don_Adan

Final version of Amiga 0.5MB ROM credits. Thanks to MS for help.
We made it...
OS Group: Bryce Nesbitt, Michael Sinz, Peter Cherna, Darren Greenwald, Randell Jesup, Jerry Horanoff
GFX: Allan Havemose, Bart 'Kodiak' Whitebook, Spence Shanson, Steve Beats, Chris Green, Ray Brand, Jim Barkley
Special Projects: Eric Cotton, Martin Hunt, Bill Koester, Martin Taillefer, Brian Jackson, Kaori Kuwata, David Junod, Palmyra Pawlik, Kevin Klop
NET: Brian Jackson, Greg Miller, Kenneth Dyke
GUI: Peter Cherna, Martin Taillefer, David Junod, Kaori Kuwata
Others: Andy Finkel, Dale 'Duck' Luck, Jim 'Jimm' Mackraz, Jeff Porter, Carolyn Scheppner, David Haynie,
Lauren Brown, CATS (Commodore Amiga Technical Support), QA (Quality Assurance), SA (Software Assurance)
Thanks to: Bill Hawes, Software Distillery
Better than ever.

Hi.

A couple minor corrections: It was Barry 'Bart' Whitebook and Bob 'Kodiak' Burns.

How's the library working, btw ?


Andy Finkel

[gulliver]

Originally Posted by AndyF

Hi.

A couple minor corrections: It was Barry 'Bart' Whitebook and Bob 'Kodiak' Burns.

How's the library working, btw ?


Andy Finkel

Thank you for stopping by

The library is currently working and is indeed much faster now.

[Don_Adan]

Originally Posted by AndyF

Hi.

A couple minor corrections: It was Barry 'Bart' Whitebook and Bob 'Kodiak' Burns.

How's the library working, btw ?


Andy Finkel

Thanks for infos. Every information about Amiga ROM is useful for me, even correct or better label names in resourced dos library.

Fixed version of Amiga 0.5MB ROM credits. Thanks to MS and AndyFinkel for help.

We made it...
OS Group: Bryce Nesbitt, Michael Sinz, Peter Cherna, Darren Greenwald, Randell Jesup, Jerry Horanoff
GFX: Allan Havemose, Barry 'Bart' Whitebook, Spence Shanson, Steve Beats, Chris Green, Ray Brand, Jim Barkley
Special Projects: Eric Cotton, Martin Hunt, Bill Koester, Martin Taillefer, Brian Jackson, Kaori Kuwata, David Junod, Palmyra Pawlik, Kevin Klop
NET: Brian Jackson, Greg Miller, Kenneth Dyke
GUI: Peter Cherna, Martin Taillefer, David Junod, Kaori Kuwata
Others: Andy Finkel, Dale 'Duck' Luck, Jim 'Jimm' Mackraz, Bob 'Kodiak' Burns, Jeff Porter, Carolyn Scheppner, David Haynie,
Lauren Brown, CATS (Commodore Amiga Technical Support), QA (Quality Assurance), SA (Software Assurance)
Thanks to: Bill Hawes, Software Distillery
Better than ever.