Hex editing games and software to use drive B

[simulant]

Does anybody know what would be involved to hex edit the code of an Amstrad CPC game or program to load from drive B?

As most people have found, a lot of games and software start to load from drive B fine (or an external Gotek etc) but then revert back to look for Drive A again.

I am planning to fit an ABBA switch anyway, but there used to be loaders out there such as this one:

https://www.cpcwiki.eu/index.php/Programming:An_example_loader

and

https://cpcrulez.fr/applications_util-loader_for_drive_b_ramdos_format.htm


The above examples got me thinking that someone talented in the community could possibly write an assembly program which allows disks to only work from the drive selected? So users could then add this small assembly program to a floppy disc, run that first, then it would ask what file to run next and ask what drive to use too. Wouldn't that be cool? It would also then mean we'd no longer need to do ABBA mods...

Let me know if anyone can help as I feel this would be a really useful and worthwhile project for the whole CPC (and maybe PCW) community.

[Prodatron]

Or just any todays mass storage device.
The CPCs DOS was primitive enough that a lot of game and demo developers thought they could just write an own fixed drive A FDC loader, and people even thought, that this is cool (lol!). I am not sure if this was common for other popular 8bit (or even 16) systems as well, but I know a lot of other systems like the Atari8, MSX, Enterprise where you didn't have this limited behaviour.

[eto]

I guess for most games there is now a version that can be loaded from B or mass storage devices. Except for original disks I can't remember having had any issues running stuff from B in the last couple of years. 

[simulant]

This is what I was hoping to learn too, how did the guys that have cracked and modified the originals go about it? Is it something we can all manage to do with a hex editor and a little direction?

[Prodatron]

This is what I was hoping to learn too, how did the guys that have cracked and modified the originals go about it?

A lot of these "crackers" just did a stupid dump with the Multiface II when the game was loaded (something like a .SNA from the 80ies/early 90ies) and saved it as a binary which then could be loaded in an easy way.

[eto]

A lot of these "crackers" just did a stupid dump with the Multiface II

So they didn't crack the game but the Multiface? ;-)

Is it something we can all manage to do with a hex editor and a little direction?

Maybe in some rare cases. But as soon as copy protection is involved or if the game just ignores AMSDOS, you need to understand the fundamentals, be able to decompile the binaries, read the source and find the areas where the floppy disc controller is accessed. 

[simulant]

A lot of these "crackers" just did a stupid dump with the Multiface II

So they didn't crack the game but the Multiface? ;-)

Is it something we can all manage to do with a hex editor and a little direction?

Maybe in some rare cases. But as soon as copy protection is involved or if the game just ignores AMSDOS, you need to understand the fundamentals, be able to decompile the binaries, read the source and find the areas where the floppy disc controller is accessed.

Cheers for the replies guys, I do find all of this very interesting - and the cracking stuff too.

So with the Multiface II, I was always under the impression you needed the Multiface to then load the game, how do you convert its save into a binary that you can run without the peripheral attached? That sounds like a very cool trick!

And for hex editing or changing the assembly, isn't there some sort of line that could be added to the game before the rest of the code, a bit like the loader examples I posted - where it sets the drive letter initially?

What's the actual assembly for drive access and drive letters, is there any reference material on this?

I still encounter a lot of stuff I can't load from drive B - even after trying various hacked versions and dumps from CPC Power etc, there's so much software out there still that could benefit from a mod or hack like this.

[Jean-Marie]

Here is a typical example of a recreated loader, for  the game Geoff Capes.
Basically, you need to :
* initialize AMSDOS with the correct Drive number.
* set the inks
* load the files!

Code Select Expand

org &BE80
;initialise_amsdos:
ld hl,(&be7d)    ;Get address where current drive number is stored
inc hl  ;Move forward 2 bytes to the address where the drive
inc hl  ;number of the most recently loaded file is stored
ld a,(hl)    ;Get drive number (A = 0, B = 1)
push af      ;Store drive number on the stack
ld de,&40
ld hl,&b0ff      ;Highest usable byte of memory
ld c,7  ;AMSDOS ROM is located in slot 7
call &bcce  ;Initialise the selected ROM
pop af  ;Get drive number
ld hl,(&be7d)    ;Get new address where drive number is stored
ld (hl),a    ;Set drive number
xor a
call &bc0e   ;Mode 0
ld bc,&0606
call &bc38   ;border 6
ld ix,palette
@setink:
xor a
ld b,(ix)
ld c,b
push af
call &BC32
pop af
inc ix
inc a
cp 16
jr nz,@setink+1
ld hl,&C000
call @loader
ld hl,&1100
call @loader
jp &1114
@loader:
push hl
ld hl,filename+5
inc (hl)
ld b,10
ld l,filename AND 255
ld de,&40
call &bc77
pop hl
call &bc83
jp &bc7a
palette:
DB  6,13,26,16,24,9,10,7,20,1,2,11,4,8,3,0
filename:  DB "CAPES0.BIN"

[Jean-Marie]

If that can be useful, here are a few games whose loaders I have remade, because I was not satisfied with current versions. Also, have a look at  Crackers Velus - Amstrad CPC : News. Lot of "modern" cracks which will run on drive B.

[andycadley]

Or just any todays mass storage device.
The CPCs DOS was primitive enough that a lot of game and demo developers thought they could just write an own fixed drive A FDC loader, and people even thought, that this is cool (lol!). I am not sure if this was common for other popular 8bit (or even 16) systems as well, but I know a lot of other systems like the Atari8, MSX, Enterprise where you didn't have this limited behaviour.

I think that part of the issue was Amstrad didn't exactly make it easy to push all the firmware out of the way and use DOS in a very minimalist environment. And games/demos didn't need all the firmware sitting around taking up precious RAM etc.

[Prodatron]

Yes, you had to remove all the firmware stuff from RAM especially in demos which use 48K for the screen in many cases. But IMHO it was more easy to reinitialize the firmware/Amsdos than coding own disc routines.

[BSC]

A lot of these "crackers" just did a stupid dump with the Multiface II

That's a bold claim, got any sources to back this up? Then the Multiface was not around from the start and it was also relatively expensive. Both limiting a wide adoption. 

[BSC]

just write an own fixed drive A FDC loader, and people even thought, that this is cool (lol!).

Yes, in the late 80s / early 90s, this was indeed seen as extremely cool - by the cool people 

[BSC]

The above examples got me thinking that someone talented in the community could possibly write an assembly program which allows disks to only work from the drive selected? So users could then add this small assembly program to a floppy disc, run that first, then it would ask what file to run next and ask what drive to use too. Wouldn't that be cool? It would also then mean we'd no longer need to do ABBA mods...

I think the issue with most of the games is that, when the loader is of the .BIN type, it will have to re-initialise Amsdos to go on loading from disk and if this is done without (re)storing the drive number, then the following load calls would go to drive A by default. You would basically need to adapt any loader which behaves like this and add that "store the drive number the loader was run from" code, something which you can only do manually, I suppose.  

Another way, instead of patching the loader, would be a new loader written in BASIC, because then there's no need to re-initialise Amsdos. But that's still a manual task and then there are situations where this would not be possible for a multitude of reasons.  

[Prodatron]

That's a bold claim, got any sources to back this up? Then the Multiface was not around from the start and it was also relatively expensive. Both limiting a wide adoption.

At least XOR was a very productive Multiface II cracker
E.g. he cracked Zap't'Balls quite quickly which was using some of your disc routines for protection, iirc?

[simulant]

Has anyone hacked the Multiface II itself yet? If there was a loader made that could simply load up Multiface II snapshot saves from Drive B - well, that would do the trick quite nicely!

[simulant]

Ah, it does seem it was hacked and a PD program was made to load Multiface saves: https://www.cpcwiki.eu/index.php/AntiMultiface

and here it is: https://cpcrulez.fr/applications_util-anti-multiface.htm

NOTE: Version 1.2 can run full 128k snapshots with a RAM addon (and for the English language version just run"antimv12.eng)

[Johnny Olsen]

It is possible to change a loader to read from the B drive by typing B: in front of the file name.

Also remember to change the file name length.
The length can be a maximum of 12.     
       
  ;  loader A drive

        ORG &bf00
        LD b,10      ;length of filename
        ld hl,navn   
        ld de,&1000
        call &bc77
        ld hl,&1000
        call &bc83
        call &bc7a
     
navn:  text "topgun.bin"
---------------------------------------------

  ;  loader B drive

        ORG &bf00
        LD b,12      ;length of filename
        ld hl,navn   
        ld de,&1000
        call &bc77
        ld hl,&1000
        call &bc83
        call &bc7a   
     
navn:  text "b:topgun.bin"

[simulant]

It is possible to change a loader to read from the B drive by typing B: in front of the file name.

Also remember to change the file name length.
The length can be a maximum of 12.     
       
  ;  loader A drive

        ORG &bf00
        LD b,10      ;length of filename
        ld hl,navn   
        ld de,&1000
        call &bc77
        ld hl,&1000
        call &bc83
        call &bc7a
     
navn:  text "topgun.bin"
---------------------------------------------

  ;  loader B drive

        ORG &bf00
        LD b,12      ;length of filename
        ld hl,navn   
        ld de,&1000
        call &bc77
        ld hl,&1000
        call &bc83
        call &bc7a   
     
navn:  text "b:topgun.bin"

Thank you    this is exactly the sort of solution I was looking for. Brilliant!

[andycadley]

It'll only work for code using the firmware to load though, which is probably less likely for anything that fails to load if you've already done a |B