Some WHDLoad questions

[EctoOne]

Hi, I was tinkering with some games which don't have a slave already (at least I couldn't find any). They are all on dos disks (or available as lha packages on Aminet), so I tried the generic slave and the Workbench slaves.

The first one doesn't really fits my needs because you have to specify the binary in the tooltypes. Although I have not tried to use a disk image and I would like to avoid those anyway.

The Workbench 1.3 slave mostly works, but I have come across an issue that requires a bit more work to resolve. It is about when a game needs a certain disk name. I surely can add a line to the startup-sequence and, if needed, copy the assign binary. The default name of the disk is WHDLoad, and I was wondering if it would be possible to change that. Either in the source or maybe with a tooltype.

Speaking of assign, there is the following line in the source code:

;DOSASSIGN			;enable _dos_assign routine

What is the purpose of it? I thought it would remove the need to supply of the assign binary. But that doesn't seems to be the case. I got the unknown command error. And yes, I have removed the ; before compiling the source.


And I would also like to know if it would be possible to set slv_name, slv_copy and slv_info by using tooltypes. So that it would be possible to create an even more generic slave which can be simply altered without the need to compile the source.

[Aladin]

add assign in your startup-sequence in data/s

[EctoOne]

Yeah, I mentioned that I could do that. But I wanted to know if there was a way to avoid that.

[jotd]

DOSASSIGN enables the code that allows assigns

Enabling DOSASSIGN alone does nothing. you have to add this code

		lea	assign(pc),a0
		sub.l	a1,a1
		bsr	_dos_assign

where assign points to a volume name (ex: DF0)
A1 is null: means you're assigning to root dir (data dir)

[EctoOne]

I'm still not getting it sorry. In your example what volume name is assigned to which dir?

I don't have much knowledge about coding anything. I'm more the copy/paste type of guy, but I don't even know where to start with this cryptic source. There is basically no telling off how/where a Directory /File is determined. Everything seems to be just be short (hex?) values. I mean, for example: How does the Workbench slave know that it should be reading the startup-sequence? It is just mentioned in a comment that one part is suppose to do that (at least that's how I understand it).

I guess I'm just to stupid to understand this or can not find a better example which would help me.

[Wepl]

Originally Posted by EctoOne

I'm still not getting it sorry. In your example what volume name is assigned to which dir?

in the example you would have a

assign   dc.b "volname",0

So a0 has to point to the name of the volume (assign) and a1 points to the name of the directory (NULL = root).

Originally Posted by EctoOne

I mean, for example: How does the Workbench slave know that it should be reading the startup-sequence? It is just mentioned in a comment that one part is suppose to do that (at least that's how I understand it).

It just uses normal kickstart processing.

Originally Posted by EctoOne

I guess I'm just to stupid to understand this or can not find a better example which would help me.

There are many installs which include the source. There is also the whdload/src/sources/whdload/kick.readme in the dev package.

[EctoOne]

Originally Posted by Wepl

in the example you would have a

assign   dc.b "volname",0

So a0 has to point to the name of the volume (assign) and a1 points to the name of the directory (NULL = root).

So does it matter where that code is? Because your Workbench 3.1 slave has something like:

lea	(_name,pc),a0
		sub.l	a1,a1
		bsr	_dos_assign
		...
	  _name dc.b	"DataDisk",0

That's the example from the kick.readme.
But I couldn't see any difference when I un-/commented the DOSASSIGN line. Shouldn't SYS: have the name DataDisk in this case?

Originally Posted by Wepl

There are many installs which include the source. There is also the whdload/src/sources/whdload/kick.readme in the dev package.

I have looked at some packages but most of them didn't use the startup-sequence. And to be honest, the kick.readme is kinda hard to understand if you basically know nothing about all that Amiga tech stuff.
I actually was kinda surprised by that, because it was pretty easy to set up the dev environment with all the sources/includes/compiler and what not. But the code is something I can't figure out.

[Wepl]

Originally Posted by EctoOne

But I couldn't see any difference when I un-/commented the DOSASSIGN line. Shouldn't SYS: have the name DataDisk in this case?

No. This code adds an Assign like the assign command would do. You can have multiple of them if you need multiple disks to support.

Originally Posted by EctoOne

I have looked at some packages but most of them didn't use the startup-sequence. And to be honest, the kick.readme is kinda hard to understand if you basically know nothing about all that Amiga tech stuff.
I actually was kinda surprised by that, because it was pretty easy to set up the dev environment with all the sources/includes/compiler and what not. But the code is something I can't figure out.

Sorry, but if you like to dive deeper here you need to familiarize with this stuff.

[EctoOne]

Originally Posted by Wepl

No. This code adds an Assign like the assign command would do. You can have multiple of them if you need multiple disks to support.

Ah of course, that was a misunderstanding. But still, I noticed no difference when I ran the assign command myself after I changed something. Shouldn't the assign appear in the output if it would work? So, my guess is that this assign is located in a block of code that is not actually loaded when using the startup-sequence method.

But that does not answer my initial question. Is it possible to define a name for the mounted drive?

Originally Posted by Wepl

Sorry, but if you like to dive deeper here you need to familiarize with this stuff.

Sure, but I'm trying to figure out if it is even possible to do what I want before I spend more time on something that is impossible to begin with.

I mean if it's OK, I can write a list of what I want to achieve and someone who knows that can tell me if it would work. I'm not expecting that someone writes such a slave.

[jotd]

I suggest that you check various slaves using kickstart emulation, learn assembly, use a disassembler to understand executables & the way they are patched, read whdload documentation, practice assembly language, loops, tests, registers...

You can't learn all that stuff in 1 week. Not possible sorry.

[Asman]

Originally Posted by EctoOne

Hi, I was tinkering with some games which don't have a slave already (at least I couldn't find any). They are all on dos disks (or available as lha packages on Aminet), (...)

Can you just post some example games, I should find time to patch at least one of them. Thanks.

[EctoOne]

Originally Posted by jotd

You can't learn all that stuff in 1 week. Not possible sorry.

I understand that and I don't have a problem with it. But like I said, I would prefer it if I would know what even is possible with whdload. And since the couldn't find any slave/documentation about those things (I might have missed it or didn't understand that some bit of code does what I want), I thought asking would be fine.

I don't want to sound rude, but so far nobody has answered any of my questions/things I want to achieve from my first post. The discussion ended up talking about assigns which wasn't something I was looking for.

At this point, I'm giving up because I must assume that it's just not possible. I appreciate the efforts to help.

Originally Posted by Asman

Can you just post some example games, I should find time to patch at least one of them. Thanks.

Thanks for the offer but that's not the point here.

[jotd]

I think you imagine that a whdload asm file is a configuration file where you add/remove stuff. That's not it

That's a driver code to intercept the program at crucial points and redirect loading from ram. And you can also fix stuff at the same time

You seem to see it as a config file, rather see it as a driver.

[EctoOne]

I was expecting there to be some sort of functions which can easily be shared between different slaves. Like for loading stuff either from a diskfile or use the data folder. Or to set a specific name for the mounted data folder.

My current target is/was not to patch anything in particular. I just wanted a simple(r) slave to start an 1.3/3.1 environment from a data folder. Plus some additional information if certain things could be done to make it even more generic and easy to use for others.

For example, the wb 1.3 slave seems to work fine for games like Soul Crystal and Sim City Deluxe. The setup requires some manual work, like adding assigns for Soul Crystal, but they at least can run the games. People asked for slaves for those games. If it would be easier to set stuff like the name by using tooltypes for example (so that we don't end up with tons of workbench entries in iGame), maybe people would try such a slave beforehand and, I think, for a dev like you it would make things easier as well if people could tell you that something already works. But maybe you are fine to start over and over again for each game. Or you have an workflow which makes this already easy enough.

[Aladin]

I put 2500 games in Generic WHDL on the FTP server

[Wepl]

Originally Posted by EctoOne

Ah of course, that was a misunderstanding. But still, I noticed no difference when I ran the assign command myself after I changed something. Shouldn't the assign appear in the output if it would work? So, my guess is that this assign is located in a block of code that is not actually loaded when using the startup-sequence method.

If you added a dos assign via code in the slave it is also shown using the Assign command later. So if it's missing your code was not executed or wrong.

Originally Posted by EctoOne

But that does not answer my initial question. Is it possible to define a name for the mounted drive?

The name of the boot volume is defined in the source kickfs.s see label .volumename (is a BCPL string). You could change it there but would need to do this for each install then. The approach using the function dos_assign is more handy.

Originally Posted by EctoOne

I was expecting there to be some sort of functions which can easily be shared between different slaves. Like for loading stuff either from a diskfile or use the data folder. Or to set a specific name for the mounted data folder.

To load stuff there are the appropriate resload-functions (see autodocs). But you need to patch the games to use them.
Besides that you can use the wb13/31-slaves and build something using the startup-sequence.

Originally Posted by EctoOne

If it would be easier to set stuff like the name by using tooltypes for example (so that we don't end up with tons of workbench entries in iGame), maybe people would try such a slave beforehand and, I think, for a dev like you it would make things easier as well if people could tell you that something already works. But maybe you are fine to start over and over again for each game. Or you have an workflow which makes this already easy enough.

You have already assembled slaves so you can easily change the name. Changing the name via tooltypes doesn't make sense.
Usually games also need fixes to make it work on all configs. Because of that a custom slave is the standard way.

[EctoOne]

Alright, so basically what I want is either not supported or requires extra work.
That was all I wanted to know. Maybe I will try to learn more but for now I don't have a reason. I can stop spending time looking for something that doesn't exists.

Originally Posted by Wepl

If you added a dos assign via code in the slave it is also shown using the Assign command later. So if it's missing your code was not executed or wrong.

Hmm, does that mean that your code is wrong? I have changed nothing except un-/commenting the DOSASSIGN line in the Workbench 1.3/3.1 slaves to see what happens. That's why I assumed that the actual assign block is in a section that does not get executed. That's why I feel stupid, either I'm doing it wrong or there is "unnecessary" code.

I have seen some tutorials but they all skip stuff for beginners. Like, use this code to load a binary directly or use this to use the startup-sequence, then continue by adding assigns with this and so on. Instead it's about making a disk image, use a disassembler and what not.

[jotd]

kickstart emulation slaves are specific (and sometimes easier because no or very little hardware banging, no disk image to create, and sometimes no disassembly)

doesn't generic kick assign DF0 ? in that case just duplicate those lines to assign something else.

What would be cool would be a better generic kick with a config file where assigns and maybe some other stuff are configurable.

[Wepl]

Originally Posted by EctoOne

Hmm, does that mean that your code is wrong? I have changed nothing except un-/commenting the DOSASSIGN line in the Workbench 1.3/3.1 slaves to see what happens. That's why I assumed that the actual assign block is in a section that does not get executed. That's why I feel stupid, either I'm doing it wrong or there is "unnecessary" code.

The DOSASSIGN label just enables the code for the function _dos_assign. It doesn't cause any code to be executed. A call to _dos_assign with appropriate parameters must be done additionally. The example code in workbench13.asm which calls _dos_assign is inside the function _bootdos. But _bootdos is only enabled and executed if label BOOTDOS is active. Which isn't the case in workbench13.asm. The BOOTDOS functionality will replace executing the startup-sequence. Sorry if this is a bit complicated at first glance.

[EctoOne]

I have another question.

Is there a way to quit whdload from within whdload? Like a command I could run manually or add to the startup-sequence of games which normally would quit to workbench.