How to boot adf from RAD?

[olesio]

Hello.

I want to boot some nondos game from adf image. How to do this?
I read about RAD: and have mount examples, but how to insert an
adf image to RAD: is it possible? What devices or other apps from
Aminet I need? Is it possible to load two disks game in that way?
I want to incrase speed of reading - so I do not want to use real
floppies. For test I want to do this temporary under WinUAE. And
I know diskimage packet on Aminet but how to mountadf to RAD:
and boot it on startup to have faster access to disk than DF0 etc.
Thanks in advice for all tips. And finally sorry for my bad English

[Amiga1992]

It is not possible, as soon as the game tries to access your disk drive, it will crash.
You could transfer an ADF to RAD using any ADF writing program, instead of using df0: for output, use rad:

But as I said, your game will not work.
Only games that use teh system can be run from RAD:
(you also need at least 2MB of RAM though I recommend more)

[alexh]

Pretty sure this is not possible in software.

The only possibility for similar functionality is an SDCard HxC Floppy Disk Emulator available for £60

http://cgi.ebay.co.uk/SD-CARD-Floppy...-/180515130238

[olesio]

Thanks for answer, dos disk works when transfered to rad by transadf.
And 60 £ it is to expensive and only works under real Amiga - not by
emulator. So WHDLoad slaves authors must analize bootblocks on non
dos adfs and write assembl (for them it is easy) code to load a game?

[ppill]

It's possible but few games will work since most of them use custom disk formats and access routines.

The simplest way would be to mount RAD:, put the disk in DF0: then in shell type

diskcopy from df0: to rad:

when finished, reboot, enter the 'early startup menu' and in boot options choose RAD as the boot device...

But like I said just a handful of games will work.

[Amiga1992]

Originally Posted by ppill

The simplest way would be to mount RAD:, put the disk in DF0: then in shell type

diskcopy from df0: to rad:

That doesn't work for NDOS disks which is what the original poster wants to do.

As I said, yo can trick the RAD to get an NDOS disk image written onto it but this just will NOT work.

[olesio]

I tested RAD: with one dos game but it does not work. In meantime I did following
script in attachment in case to make dms files faster under ClassicWB. And I have
other question. Maybe you guys can explain me how to wait when dms open by run
command in new window (run is needed to execute dms program without pressing
enter key) is finished. I have following piece of script and is it possible to execute
remrad force when dms finish work? Wait command is not too precise method imo.
Btw to transfer adf to RAD: I'm using transadf and under ClassicWB it works fast.

; ...
LAB MAKE_DMS
run dms READ $DmsFile FROM $DeviceName CMODE BEST
SKIP REMOVE_VIRTUAL_FLOPPY
SKIP MAKE_DMS BACK

LAB REMOVE_VIRTUAL_FLOPPY
run >nil: CentreQuest CX_PRIORITY=1 AUTOQUIT=NO CENTRE=SCREEN TEST=NO
requestchoice "Confirm remove $DeviceName" "Press OK when you see 'All done!' text in*NDMS window, to remove mounted device $DeviceName" "OK"
remrad force
SKIP END
SKIP REMOVE_VIRTUAL_FLOPPY
; ...

[ppill]

Not sure what you mean Olesio (napisz mi PM jeżeli źle Ciebie zrozumiałem).

You want to know when DMS finished writing to RAD, right? If that's the case you can try checking for the RC (Result code) of the DMS command in the main script.

[ppill]

Originally Posted by olesio

(run is needed to execute dms program without pressing
enter key) is finished.

There's a way around that. Use FakeKey. It emulates pressing a defined key (Enter in this case) after a delay in scripts. Like this:

run fakekey 2 return

Just add it before you start DMS. You'll just have to see if 2 seconds is enough in your case

Also why are you using:

(...)
SKIP CHECK_ADF BACK
(...)
SKIP SELECT_DMS BACK
(...)

when they're never executed? You don't need those. Also instead of:

assign >NIL: C: $CurrentDir/C
assign >NIL: Devs: $CurrentDir/Devs
assign >NIL: Libs: $CurrentDir/Libs
(...)
assign >NIL: C: Sys:C
assign >NIL: Devs: Sys:Devs
assign >NIL: Libs: Sys:Libs

you should use:

assign >NIL: C: $CurrentDir/C ADD
assign >NIL: Devs: $CurrentDir/Devs ADD
assign >NIL: Libs: $CurrentDir/Libs ADD
(...)
assign >NIL: C: $CurrentDir/C REMOVE
assign >NIL: Devs: $CurrentDir/Devs REMOVE
assign >NIL: Libs: $CurrentDir/Libs REMOVE

It's more system friendly that way.

Hope that helps

[olesio]

Originally Posted by ppill

There's a way around that. Use FakeKey. It emulates pressing a defined key (Enter in this case) after a delay in scripts.

At start big thanks for your help. Yes. You exacly undestand good what I wanted to do.
I'm glad Polish dudes are also active here, not only at ppa.pl I searched at Aminet for
something like press key or send key, the correct word was fake. It work fine with dsm
even when delay time is set for 0 seconds and dms create file with lowercase extension.

Also why are you using:
(...)
when they're never executed? You don't need those. Also instead of:

I'm newbie in AmigaDos scripts and I thought after end of LAB section I always must add
SKIP <LAB_NAME> BACK - I seen this method used in the ClassicWB installation scripts.

(...)It's more system friendly that way.

Thanks for suggestion. I didn't know and didn't remember all assign switches. And now
everything works fine in this script. Once again big thanks for your comprehensive help.

[ppill]

As for someone new to Amiga scripts (hey, I'm no expert myself) you're doing fine

AFAIK Lab doesn't have to end with anything like in the case of if/endif. SKIP just jumps where the label was defined. SKIP <Label> BACK should be used when you're calling a label that was defined before SKIPping to it

[olesio]

OK, thank you for answer. Now I know what do this back.
Maybe author of ClassicWB used it in case when in future
some script needs to jump for some previous lab section.

[Retro1234]

As far as I know RAD will not hold a custom Boot block can anyone confirm this?

[Amiga1992]

Originally Posted by Boo Boo

As far as I know RAD will not hold a custom Boot block can anyone confirm this?

No, it won't.
That's why only AmigaDOS disks (with regular bootblocks) would work (partially).