CBM64 Bard's Tale 1 Disassembly
I T E M # 11
Last update: 2010-03-22
Expirable items...
Each item has a function code from a table at a4f7. Before each use
of an item, it is checked if that item has a function code < 0x30.
If yes, a random number is calculated and a chance of 1/64th exists,
that this item expires. If yes, it vanishes from the char's item list.
Anyway it will be used for a last time.
So in BT1 on the C64 there is no fixed amount of item usages nor
a calculated one. It is fully randomly. An item can last forever or
break on the first use.
Last update: 2010-03-22
Expirable items...
Each item has a function code from a table at a4f7. Before each use
of an item, it is checked if that item has a function code < 0x30.
If yes, a random number is calculated and a chance of 1/64th exists,
that this item expires. If yes, it vanishes from the char's item list.
Anyway it will be used for a last time.
So in BT1 on the C64 there is no fixed amount of item usages nor
a calculated one. It is fully randomly. An item can last forever or
break on the first use.
Code: Select all
48ef:48ef:0 c8 iny
48f0:48f0:0 b1 0f lda ($0f),y
48f2:48f2:0 88 dey
48f3:48f3:0 aa tax
48f4:48f4:0 bd f7 a4 lda $a4f7,x
48f7:48f7:0 29 7f and #$7f
48f9:48f9:0 aa tax
48fa:48fa:0 e0 30 cpx #$30
48fc:48fc:0 90 03 bcc $4901
48fe:48fe:0 4c f9 1a jmp $1af9
4901:4901:0 20 d2 18 jsr $18d2
4904:4904:0 a5 5b lda $5b
4906:4906:0 29 3f and #$3f
4908:4908:0 d0 e4 bne $48ee
490a:490a:0 4c f9 1a jmp $1af9
I T E M # 12
Last update: 2010-07-07
BT events disassembled listings...
Events are loaded from disk upon certain actions. They are plain
ML programs. It ain't hard to write own events with any C64
assembler and knowledge of the subroutines and variables tables
posted in this thread.
A T T E N T I O N
The webspace I used changed their account system, so I will not
longer host the files there. Most other webspaces require downloaders
to create an account, which I also do not want.
In case you want the diassembly files, pm me with an email address
and I send them to you.
Last update: 2010-07-07
BT events disassembled listings...
Events are loaded from disk upon certain actions. They are plain
ML programs. It ain't hard to write own events with any C64
assembler and knowledge of the subroutines and variables tables
posted in this thread.
A T T E N T I O N
The webspace I used changed their account system, so I will not
longer host the files there. Most other webspaces require downloaders
to create an account, which I also do not want.
In case you want the diassembly files, pm me with an email address
and I send them to you.
Last edited by ZeroZero on Wed Jul 07, 2010 11:14 am, edited 24 times in total.
I found a program on the C64 that Quantum Reality made me aware of which gives the beginning track and sector of any file on a C64 disk, as well as the beginning address.
I ran the BT1 Dungeon Disk through this program and it produced the following output:
TR=Track, SC=Sector, BLK=Blocks Used, START=Decimal start address.
24576 = $6000
15104 = $3b00
11776 = $2e00
16384 = $4000
8192 = $2000
4096 = $1000
49152 = $c000
Strange starting addresses.
I ran the BT1 Dungeon Disk through this program and it produced the following output:
TR=Track, SC=Sector, BLK=Blocks Used, START=Decimal start address.
24576 = $6000
15104 = $3b00
11776 = $2e00
16384 = $4000
8192 = $2000
4096 = $1000
49152 = $c000
Strange starting addresses.
1. The track/sector doesn't matter. You can access the files directly and then don't need to care, even not after adding, deleting, copying etc a file.
BT itself doesn't care for the t/s on the C64, while it does on the apple.
2. The load addresses are in no way strange, they are within the 64k address range of the C64. However, all load addresses are too low by $8000. I haven't checked yet, but I bet that BT adds a $80 to the high byte of the load address. E.g.: the events, that you find to have a load address of $3b00, are loaded in fact to $bb00.
3. Since I built my own class to read/write a standard D64 image, I am well aware of this structure of the BT1 disks for the C64. They are regular disks and even can be copied w/o any problem.
All in all, this is a strange disk anyway... It seems to be a dungeon disk, however it shouldn't have a NM0A on it...
E D I T
I tested to change the load address of an event file to the real address it belongs to, and all still worked perfectly. This means, that on the C64 either the load address is set by the program, depending on the file requested, or that the load address is or'ed by $80. I have not tested to change the load address to any stupid value...
BT itself doesn't care for the t/s on the C64, while it does on the apple.
2. The load addresses are in no way strange, they are within the 64k address range of the C64. However, all load addresses are too low by $8000. I haven't checked yet, but I bet that BT adds a $80 to the high byte of the load address. E.g.: the events, that you find to have a load address of $3b00, are loaded in fact to $bb00.
3. Since I built my own class to read/write a standard D64 image, I am well aware of this structure of the BT1 disks for the C64. They are regular disks and even can be copied w/o any problem.
All in all, this is a strange disk anyway... It seems to be a dungeon disk, however it shouldn't have a NM0A on it...
E D I T
I tested to change the load address of an event file to the real address it belongs to, and all still worked perfectly. This means, that on the C64 either the load address is set by the program, depending on the file requested, or that the load address is or'ed by $80. I have not tested to change the load address to any stupid value...
- Quantum Reality
- Posts: 91
- Joined: Mon Mar 15, 2010 8:34 pm
If that is Mangar's Level 6, the portal up will be in the room with the 2 black dragons.Quantum Reality wrote:When he wrote his program (he told me) he did it the hard way by directly reading the disk. I asked why he didn't just load them as binary files.
Also, PS: The extra file is probably his extra dungeon level he mentioned some time back.
And I dunno how to load them as binary files.
So this image isn't helpful then?