I've been wanting to tackle a little amstrad translation project of Le Secret Du Tombeau, which was never released in English.
https://www.cpc-power.com/index.php?page=detail&num=1898
I started with the copy I had to hand from CPC-Power - the french cracked version on disk, but it appears to have some issues in that:
> The attract-demo is completely missing from the cracked version.
> Saving the game hard crashes the system
> Loading the game is impossible because of above.
The other issue I had was that I couldn't find where the mode 1 loading screen was and editable in a way that I could translate the loading page too.
I can do the strings just fine, but I don't want to do the translation to a cracked version that's broken and missing things.
The ideal situation is that I'd like to have a fully cracked version that I can extract to raw files (for usifac2/m4 use) as well for easier editing on PC.
The original disk dump appears to have a bunch of data near the end of the disk that is read while loading, but doesn't appear to have a file associated with it, so without editing the disk image directly which is its own unique headache.
I'd like to make some small edits to the game controls, such as changing the french o/n keys to y/n as per they would be in English.
Would anyone be willing to help me "fix" the game into a mass-storage friendly format?
The cracked version on CPCPower is pretty botched indeed. Here is a proper one.
The protection in SDT.bin checks for a GAP3 value of F7h on some sector on track 39 (standard value is 4Eh).
I just removed the conditional jump to make the test always valid. And I formatted track 39 with regular sectors.
org &19a3
;;jr nz,&19de
nop:nop
Quote from: Jean-Marie on 18:06, 25 November 24The cracked version on CPCPower is pretty botched indeed. Here is a proper one.
The protection in SDT.bin checks for a GAP3 value of F7h on some sector on track 39 (standard value is 4Eh).
I just removed the conditional jump to make the test always valid. And I formatted track 39 with regular sectors.
org &19a3
;;jr nz,&19de
nop:nop
Wonderful! Most of the game data is in a block(?) of data not actually marked as a file around track 36 on the disk?. Is it possible to turn that block of data into a file and tell the game to load that file instead of an arbitrary place on the disk? That would make it both mass storage friendly, and much easier for me to edit instead of manually hacking that one chunk of data on the disk.
Screenshot 2024-11-25 19.24.13.png
Here's the disk layout - you can see at the end of the disk where the not-file data is.
Le Secret du Tombeau was one of the many, many entries on my list of cracked games that need to be re-examined. Unfortunately I don't have the time to look at it at the moment, and I won't get a chance to do so for another 6 or 7 weeks - but I'll try to look at it again at some point.
You're right : those tracks are read by the program using the BIOS Read sector function (https://www.cpcwiki.eu/index.php/Programming:Reading_a_sector_from_a_disc).
It might be tricky to replace those calls with the standard Firmware function!
The broken crack managed it, but it was a copy from cassette using Amscopy 2 (the files have an amscopy header)
Hi
Perhaps you can have a look at the velus compactage version :
https://www.velus.be/cpc-2982.html
Quote from: dirtybb on 00:41, 26 November 24Hi
Perhaps you can have a look at the velus compactage version :
https://www.velus.be/cpc-2982.html
It looks like it's been trained and compressed, I wouldn't be able to get at the files to translate it. Once the translation is done I can pass it on to them to do the english version too if they so desire.
I have an idea, but it's a bit tedious cause you'll have to create one file for each sector of tracks 36/37/38, that is 22 files of 512 bytes (actually 1 Kb on disc).
You'll need to give them a name like T24SC1, for track 24h(36) sector C1h.
The files could be loaded with the following patch of 34 bytes long:
ORG &BE80
Filename: DB "T2?SC?"
@Loader:
push hl ;;save hl=buffer address
;;retrieve track number
ld a,d
add &10 ;;sub &20:add &30
ld hl,Filename+2
ld (hl),a
;;retrieve sector number
ld a,c
sub &90 ;;sub &C0:add &30
ld l,Filename+5 AND 255
ld (hl),a
;;Open & read the file
ld b,6 ;;length of Filename
ld l,Filename AND 255
call &BC77 ;;Open file
pop hl ;;hl=buffer address
call &BC83 ;;Read file
jp &BC7A ;;Close file & return
Then, you can just replace the Far Call to BIOS-Read sector with a call @Loader.
Before:
org &9435
push bc
ld de,&2400
ld hl,(&00e3)
push hl
rst &18
db &a7,&00
pop hl
...
After:
org &9435
push bc
ld de,&2400
ld hl,(&00e3)
push hl
call @Loader
pop hl
...
Using Winape, you can copy/paste a sector content to Excel or notepad.
The problem is that memory looks very tight, even for a small patch like this.
Even the BE80h area seems to be overwritten by the stack!
You could try using the VRAM at FFD0h maybe.
Quote from: Jean-Marie on 03:09, 26 November 24I have an idea, but it's a bit tedious cause you'll have to create one file for each sector of tracks 36/37/38, that is 22 files of 512 bytes (actually 1 Kb on disc).
You'll need to give them a name like T24SC1, for track 24h(36) sector C1h.
The files could be loaded with the following patch of 34 bytes long:
ORG &BE80
Filename: DB "T2?SC?"
@Loader:
push hl ;;save hl=buffer address
;;retrieve track number
ld a,d
add &10 ;;sub &20:add &30
ld hl,Filename+2
ld (hl),a
;;retrieve sector number
ld a,c
sub &90 ;;sub &C0:add &30
ld l,Filename+5 AND 255
ld (hl),a
;;Open & read the file
ld b,6 ;;length of Filename
ld l,Filename AND 255
call &BC77 ;;Open file
pop hl ;;hl=buffer address
call &BC83 ;;Read file
jp &BC7A ;;Close file & return
Then, you can just replace the Far Call to BIOS-Read sector with a call @Loader.
Before:
org &9435
push bc
ld de,&2400
ld hl,(&00e3)
push hl
rst &18
db &a7,&00
pop hl
...
After:
org &9435
push bc
ld de,&2400
ld hl,(&00e3)
push hl
call @Loader
pop hl
...
Using Winape, you can copy/paste a sector content to Excel or notepad.
The problem is that memory looks very tight, even for a small patch like this.
Even the BE80h area seems to be overwritten by the stack!
You could try using the VRAM at FFD0h maybe.
I've had a chance to examine the Velus crack a bit further, and it's the same as the "bad" tape crack - locks up completely when loading/saving the game.
I was thinking a somewhat more "out of the box" method:
Could it be possible to sort-of "merge" the disk/tape version, to make a sort of hybrid version? It'd come at the cost of the attract screen, but I think trying to get it playable with at least the core features working (and saves me editing a disk image directly and risking corruption because of sector boundaries and such)
My thinking is this (please feel free to call me out on my faulty brainworks):
- Locate and extract all the code that handles loading and saving of the game from the disk version
- Locate and replace *tape version's* load/save code with the disk routines
- test and possibly cry/cheer
At least, in this case I'd have a nice clean base to work with (and load/save is always useful for this kind of translation work), and if a future crack comes out that can "fix" the disk version into a translation friendly state, I'd be happy to revisit and go for a 1.1 based off the disk version.
Still super appreciating all the suggestions and help, though. I can use a hex editor and i've figured out a few little things related to the game's internal text system but I don't know how to Z80ASM so the advanced stuff is really bad.
Yeah, it sounds like a plan. I'll have a closer look at the tape version soon, to see if the save/load code can be changed.
I made some tests to put my theory in practice, and replaced the BIOS/read far calls with the Firmware Read function, but that won't work because at some point, some Data is loaded at offset A690h, which is the AMSDOS Data area used by this very function 🫤 That explains why they had to resort to direct sectors reading.
These are the changes I made and the DSK, for information :
;;load patch in VRAM from loader SDT.BIN
org &15db
call &bb06
jp @InstallPatch ;;jp &7e66
ORG &1A00
@InstallPatch:
ld hl,Patch
ld de,&FFD0
ld bc,34
ldir
jp &7E66 ;;postchaining
Patch:
db &54,&32,&3f,&53,&43,&3f,&e5,&7a
db &c6,&10,&21,&d2,&ff,&77,&79,&d6
db &90,&2e,&d5,&77,&06,&06,&2e,&d0
db &cd,&77,&bc,&e1,&cd,&83,&bc,&c3
db &7a,&bc
;;Replace Far Calls to BIOS - Read sector
ORG &7EAC file SDT.5
call &FFD6
ORG &943D file SDT.4
call &FFD6
By the way, I found the code to replace the prompt (O)ui/(N)on with (Y)es. It's located in SDT.4 file:
;;change keyboard O/N with Y/N
org &a1ae
la1ae:
call &92cb ;;scan keyboard
;;cp &4f ;;test O key
cp &59 ;;test Y key
jp z,&7e69
cp &4e ;;test N key
jr nz,la1ae
rst 0
org &a17e
la17e:
call &92cb
;;cp &4f ;;test O key
cp &59 ;;test Y key
jr nz,la186
rst 0
la186:
cp &4e
jr nz,la17e
Quote from: Jean-Marie on 00:21, 28 November 24Yeah, it sounds like a plan. I'll have a closer look at the tape version soon, to see if the save/load code can be changed.
I made some tests to put my theory in practice, and replaced the BIOS/read far calls with the Firmware Read function, but that won't work because at some point, some Data is loaded at offset A690h, which is the AMSDOS Data area used by this very function 🫤 That explains why they had to resort to direct sectors reading.
These are the changes I made and the DSK, for information :
[snip]
Ooh, that'll be really useful. Is that for every y/n prompt, or just one?
At the minute i'm working on just getting the strings translated of the cracked tape>disk conversion as it's the easiest way to go at the minute.
As for hacking - I think for the minute it's best to just get that cracked version at least loading and saving properly, as well as key prompts being changed to their english equivalents - then I can translate as I go more effectively.
If I had that much, I'd be super happy, and once it's done, looking further into hacking (I'd really love to translate the first loading screen, too!)
I've started making a document as well to gather my findings, and keep track of what I've done and knowledge i've put together from my hex editing and examination of the files
https://docs.google.com/document/d/1zfF-XnfZYAT7Wp--Nm54xr2JOAZYQPnqrcy2fi5EhOc/edit?usp=sharing
Quote from: Devlin on 11:57, 28 November 24Ooh, that'll be really useful. Is that for every y/n prompt, or just one?
The first one (A1AEh) is related to the game over. The second one (A17Eh) is when you complete the game, and when you give up. I'm not sure if I got them all. I saw a prompt in the text data asking you to pull a lever (High, Middle, Low), so I'll have to tackle this one too.
I tried to swap the Save/Load code on the tape version, but it's still crashing when function BC98 (CAS OUT DIRECT) is executed, and I'm clueless. The same function works seamlessly on the Disk version.
Another solution would be to store all the sectors in the extra 64 RAM, but that would let down 464 users 🫤
I've worked out a version where the sectors are stored in a single continuous file stored in extra-ram (bank 7). All calls to BIOS-Read sector are modified with a call to a patch in VRAM which reads the sector data from extra-ram.
ORG &FFD0
@Loader:
push bc:push de
push hl ;;save hl=buffer address
;;Offset in SDT.6=(((T-24h)*9)+(S-C1h))*512
ld a,d ;;a=track
sub &24
ld l,a
add a
add a
add a
add l
ld l,a ;;l=9a
ld a,c ;;a=sector
sub &C1
add l
add a
add &C0
ld h,a
ld l,0
pop de
ld bc,&7FC1
di
out (c),c
ld bc,512
ldir
ld bc,&7FC0
out (c),c
ei
pop de:pop bc
cp a ;;return with ZF & CF set
scf
ret
The advantage is that all sectors are now stored continuously in a single file (SDT.6) of 11 Kb, which should make your translation work easier.
I also patched the Lever prompt (H/M/B) with (H/M/L).
It needs to be tested, cause I'm pretty bad with this game. I keep on dying after a few seconds!
Oh, that's amazing.
I noticed a difference between the tape and disk versions too.
In the tape version, to save on storage space, control bytes (from my tinkerings, it's like 0x8* where * is the number of spaces to inject) are used instead of everything being padded with 0x20(spaces)
Text boxes are 25 chars x4, for 100 characters - Things like the air counter and trap timer are in fixed positions (which seems to be 8th and 9th characters on the third row, for a two character timer), but I can creatively edit around that.
I have a feeling that any modifications the game doesn't like will result in an immediate reset, so I think that it'll be okay.
a wee sneak of what's going on so far.
The loading screen is stored in file
SDT.0, under a compressed form (RLE).
I replaced the RLE unpacker code with the ZX0 one.
You'll just need to:
- save a 16Kb image
- compress it with ZX0 (without the header!)
- add an Amsdos header to the compressed file
- rename it SDT.0 and store it on the DSK
Or just send me the picture file.
You'll need a graphic artist; I can't help you with that ;D
Quote from: Jean-Marie on 14:34, 01 December 24The loading screen is stored in file SDT.0, under a compressed form (RLE).
I replaced the RLE unpacker code with the ZX0 one.
You'll just need to:
- save a 16Kb image
- compress it with ZX0 (without the header!)
- add an Amsdos header to the compressed file
- rename it SDT.0 and store it on the DSK
Or just send me the picture file.
You'll need a graphic artist; I can't help you with that ;D
I can do graphics just fine. Can I shoot you a 320x200 PNG to convert for me?
Quote from: Devlin on 15:18, 01 December 24Quote from: Jean-Marie on 14:34, 01 December 24The loading screen is stored in file SDT.0, under a compressed form (RLE).
I replaced the RLE unpacker code with the ZX0 one.
You'll just need to:
- save a 16Kb image
- compress it with ZX0 (without the header!)
- add an Amsdos header to the compressed file
- rename it SDT.0 and store it on the DSK
Or just send me the picture file.
You'll need a graphic artist; I can't help you with that ;D
I can do graphics just fine. Can I shoot you a 320x200 PNG to convert for me?
I've attached the PNG in question: Are the credits okay for you?
Waoo, it looks perfect. Bravo! I'll try to convert it with ConvimgCPC.
Lookin' good !
Top shelf stuff there! I'm doing a ton of testing but I'm getting there, I think!
This game is very intriguing.
I saw some screenshots in Spanish, so apparently this was translated over here.
And the gameplay style seems more or less unique... But it only got a 6.5 from French magazines at the time, and CPC Game Reviews gives it a 6.
BUT users in CPC Power give it very high scores... What's going on? Is it a very good game or only a decent one?
Quote from: cwpab on 18:39, 01 December 24This game is very intriguing.
I saw some screenshots in Spanish, so apparently this was translated over here.
And the gameplay style seems more or less unique... But it only got a 6.5 from French magazines at the time, and CPC Game Reviews gives it a 6.
BUT users in CPC Power give it very high scores... What's going on? Is it a very good game or only a decent one?
From what I've played of it, it is very fun, and an excellent little adventure game that's quite tough, but pretty much impossible to figure out the solution without knowledge of French (or Spanish), and I wanted to play it without having to engage in a ton of extra thinking translating it in my head.
And since it never got an English release, I decided I'd do a bit of translation as a little project for funsies.
At this stage, there's only a few more strings of text to convert, and then I can call it "done".
As part of my hacking efforts, I removed all the walls to help me get about the map and test things out.
This happens far too often :)
Quote from: cwpab on 18:39, 01 December 24And the gameplay style seems more or less unique... But it only got a 6.5 from French magazines at the time, and CPC Game Reviews gives it a 6.
BUT users in CPC Power give it very high scores... What's going on? Is it a very good game or only a decent one?
I wrote my review of
Le Secret du Tombeau (https://www.cpcgamereviews.com/review/1725/) in May 2021. I played the game again when this discussion was started, and I stand by what I wrote in my review.
The translation is done, but now the pain begins, getting it working on real hardware :)
which is to say, it doesn't, unless it's loaded off an actual disc.
Which isn't exactly ideal considering a lot of folks have some kind of mass storage solution(M4, USIfAC2 etc), and would likely be loading off a DSK image, which also doesn't work.
I can't test if it plays nice with a gotek as I don't have one, but I assume it does.
Yeah, any translation project for any decent game is really helpful.
Back to the game, I find the simple graphics strangely attractive and mysterious. The pixel art seems to create a perfect atmosphere of being in an ancient macro-tomb system. The need to understand the messages you mention is also intriguing. Will have to play it.
Once all the loading bugs are ironed out, so at least loading via M4/U2 disk "emulation" and at most directly off the USB stick of my U2, I'll deem it ready for release.
I want to open up the possibilities of this being playable on just about any CPC with some form of mass storage/disk emu. Wrangling 64k as a possibility is pretty much in Jean-Marie's court because I wouldn't (and don't know how) where to start.
I've made a small change to the Loader file (SDT.BIN), so that it can now be run from Drive B:
It also skips the protection test entirely, so it should load a tad faster.
Excellent! I'm running into one problem with it, though.
When it gets to the end of the loading of the main game (and beeps to tell you to press something) it gets stuck there and will not continue - It's definitely trying *something* but I'm not entirely certain what because I can only cause the issue on the real hardware.
Do you run it from Drive B or A ? Was the previous version working correctly ?
It's gonna be tough to find out, if the problem cannot be reproduced on emulators, as I have no real hardware!
Quote from: Jean-Marie on 01:49, 02 December 24Do you run it from Drive B or A ? Was the previous version working correctly ?
It's gonna be tough to find out, if the problem cannot be reproduced on emulators, as I have no real hardware!
Here's all the tests I did (and then re-did about 5 mins ago to confirm no gremlins were involved)
On my 6128:
stock, real disc A: - works
usifac2, mounted disc image - works
u2, direct USB loading - failed
On my 464: (I haven't got a DDI-1 or external disc drive)
u2 & ram exp, mounted disc image - failed
u2 & ram, direct usb loading - failed
It might be worth trying a different emulator, perhaps ACE-DL which has some pretty comprehensive debug tools, including one for fdc debugging? Might help nail down what might be holding it up without needing real hardware to hand.
Yeah, I just found a bug on emulators when launching it from B drive : the demo mode runs correctly, but then it tries to load the game files from drive A.
It might be because the AMSDOS data area is tampered. I'll have a look at it.
There's something mysterious with this game. It uses the well-known firmware functions to open/read the game files, and it's working correctly. But it shouldn't, since the AMSDOS data area around A700h is overwritten with some text data 🤔Really weird.
Are you editing a hacked/cracked version?
This is what a crack will often do:
- copy amsdos data area &a700-&c000 to screen, copy &0000-&0040 to screen.
- re-initialise firmware
- poke drive to a700
- load file(s)
- disable firmware interrupts.
- copy data back to a700-c000 and 0000-0040.
continue with game.
In this way a crack can load files/levels etc from amsdos.
No, I've worked from the original disk version. I thought it would have moved the Data area before & after the calls, indeed, but I had a quick look yesterday, and it doesn't seem to be the case. Also the content of BE7Dh (address of AMSDOS reserved area) still remains A700h.
I have to investigate further...
I noticed one thing watching a longplay of the original disk version - the game loads off the disk when accessing certain texts.
I think it's related to how the data is stored on the original disk, as text boxes are grouped in sets of 5 then have a 12-byte filler block at the end (sector size alignment, perhaps?)
I don't know if it relates to anything but it might be loading some initial state of the game using an un-caught method that trips up fdc emulation and mass storage drivers?
This is the video in question that I found:
Ok, no more mystery : there was a call to BCCEh that I had overlooked.
;;initialize Amsdos - SDT.4
org &98fb
ld hl,&ab51
ld de,&2a00
ld bc,&0060
ldir
ld c,7
ld de,&a660
ld hl,&abff
jp &bcceI replaced it with a call to a patch stored in the Restart table (RST 5 &6). It will call the original function, and then set the correct drive number in A700h.
;;initialize Amsdos - SDT.4
org &98fb
ld hl,&ab51
ld de,&2a00
ld bc,&0060
ldir
ld c,7
ld de,&a660
ld hl,&abff
jp &0028
ORG &0028
call &BCCE ;;prechaining
ld a,0 ;;get drive number (self-modifying code)
ld (&A700),a ;;store drive number in AMSDOS data area
retA bit funky, but now the game can be launched from Drive B. And the Save/Load options work too.
That is, with emulators. I dunno if it will work with all your modern gadgets 😶
Quote from: Devlin on 20:13, 02 December 24I noticed one thing watching a longplay of the original disk version - the game loads off the disk when accessing certain texts.
Those disc accesses during the game are direct readings from the end sectors. I mapped those sectors in extra-memory, so now it's a simple copy from extra-ram to ram, and the game will play faster as a side-effect.
I just want to say - great work so far!
I'll want to play this when finished, I stumbled across this doing my 'hidden gems' series on the Amstreams and this got voted in as one ('hidden gem') by the chat. Then I ended up doing more streams of this on Twitch I enjoyed it so much, but I ended up leaving it because yea... I didn't understand the Spanish/French and what was going on. And didn't have the patience to be constantly translating. So yea keep going!
Done the tests again with the new image, and I ended up with similar issues
On my 6128:
Real A: drive - works
U2, mounted DSK - works
U2, direct USB - failed at beep after game loads and does not start the attract mode when pressing a key to start it.
On my 464 +ramexp :
Mounted DSK - fails as above.
Direct USB - fails as above.
Something is absolutely happening in-between that beep after the first load and the attract mode that's causing it to bug out. that's my gut feeling - though I couldn't at all say exactly what it could be. Up to that point it seems to load completely fine. I think a clue might be in the fact it works when mounted on the 6128 though.
I'm afraid I can't be very helpful here : my good old 464 from 1985 is long gone, and I only use emulators nowadays. I understand nothing about those U2, M4, Gotek novelties !
But my thought is : if the game works fine from a real hardware, and it should from what I saw on various emulators, then it should also work with those extensions intended to simulate extra-RAM & disk drives.
If you have access to a debugger in ROM, or a Multiface 2, maybe you could check the RAM content.
Offset FFD0h should contain 45 bytes of instructions (the patch to read SDT.6 data).
Offset C000h in bank 7 (extra 64 Kb) should contain the SDT.6 file (11 Kb).
Quote from: Jean-Marie on 17:07, 03 December 24If you have access to a debugger in ROM, or a Multiface 2, maybe you could check the RAM content.
Offset FFD0h should contain 45 bytes of instructions (the patch to read SDT.6 data).
Offset C000h in bank 7 (extra 64 Kb) should contain the SDT.6 file (11 Kb).
I don't have either, sadly, or I'd have been able to have a look and see what's going on for you.
I think there's no point delaying any more, so here's the first release!
CREDITS:
Hacking and code fixes : Jean-Marie
Translation : me :)
Requires: 128K and a disc drive. (NOTE: If using mass-storage dsk emulation, a 6128 is required.)
If you can help make it mass-storage(usifac2 et al) friendly, get in touch in the thread, or drop a modified dsk in the thread and I will test and see about getting it added to the release.
Controls :
Keyboard
W - Up
A D - Left/Right
X - Down
Space - place/take mine, hold to jump across pits and hazards (hint: stand one space away, hold jump button and then press direction)
Enter - Shoot
I - Inventory
COPY - Open Load/Save menu
Joystick:
Joy UDLR - Move
Button 1 - Shoot
Button 2 - Mine/Jump
If you like this, consider leaving a donation on my ko-fi page, as I quite enjoyed this and it'd be a nice encouragement to tackle another project :)
https://ko-fi.com/magicbane
Thanks for your efforts!
Potential improovements:
- Use Cursor key instead of ADWX
- Game doesn't work with attached expansion ROMs, so initialize only ROM 7 instead all ROMs when loading.
Quote from: GUNHED on 13:02, 05 December 24Thanks for your efforts!
Potential improovements:
- Use Cursor key instead of ADWX
- Game doesn't work with attached expansion ROMs, so initialize only ROM 7 instead all ROMs when loading.
Kept the game as faithful to the original as I possibly could, so I didn't request controls being changed. Joystick works just fine though, for now.
But yes, changing controls to cursor would be a good change to make for a future update.
As for the ROM thing, I'm honestly not sure. Jean-Marie did all the good stuff regarding the new crack.
Quote from: Devlin on 13:53, 05 December 24- Game doesn't work with attached expansion ROMs, so initialize only ROM 7 instead all ROMs when loading.
Mmm, that's already the case actually 🤔
ORG &1958
jp &19AC
;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,&a660
ld hl,&abff ;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
ld (PatchDriveB+4),a ;;store drive number in RST 5 ;;initialize Amsdos - SDT.4
org &98fb
ld hl,&ab51
ld de,&2a00
ld bc,&0060
ldir
ld c,7
ld de,&a660
ld hl,&abff
jp &0028
PatchDriveB:
;;ORG &0028 - RST 5&6
call &BCCE ;;prechaining
ld a,0 ;;get drive number (self-modifying code)
ld (&A700),a ;;store drive number in AMSDOS data area
retQuote from: Devlin on 13:53, 05 December 24But yes, changing controls to cursor would be a good change to make for a future update.
Ah yes, I didn't think about it. What should be the fire buttons ?
BTW, I've made a small change to the loader, so that it displays an error message for 64k users.
Quote from: Jean-Marie on 14:09, 05 December 24Ah yes, I didn't think about it. What should be the fire buttons ?
BTW, I've made a small change to the loader, so that it displays an error message for 64k users.
The other controls are fine, they're space, enter, I and COPY - reasonable enough, I feel.