BT 1 CBM64 roster file format
I did manage that and have VB6 classes to read D64 disks and also D64 disks with ProDOS structure on it. I am just too lazy to disassemble the BOOT disk to find the data access tables for the other disks, that do not contain directories on the C64 and thus can only mean to be plain data disks being accessed by direct block access.
- Quantum Reality
- Posts: 91
- Joined: Mon Mar 15, 2010 8:34 pm
Might be getting a bit over my head but I think what I'll do is post up the Applesoft BASIC code for how far I got in like 1993 and then abandoned :p
As for ANDing off the character attributes, I begin like so:
The 6502 source code to AND off all these attributes, assuming them to be stored in sequential memory locations $6000-$6003 (ideally I should use the zero page to speed up CPU cycles but the hell with it I'm on an emulator and I can make a 4 MHz Apple //e if I want. ), looks like the following. Results are stored, sequentially, in $6010-6014.
I tested it with the following "packed" hex digits 93 4D 62 CA and got back 18 13 13 12 11 (decimal, PEEKed in Applesoft) which are exactly the Strength, IQ, Dex, Cn and Luck of my lead character. Woo-hoo.
http://pastebin.ca/1845374
Enjoy. One thing I found out I didn't have to do was clear the carry before the bit-shift operations, because the ones I used always put a zero in the blank bit. Oh well. Better safe than sorry.
Nitpick: I could probably have modularized the code a bit more instead of hardcoding the addresses by using an indirect addressing mode with an index, along the lines of ($00),Y as the base address with 00 60 stored in 0 and 1 respectively.
Meh. I'll refine it all when I can find a copy of EDASM for DOS. *snerk*
As for ANDing off the character attributes, I begin like so:
Code: Select all
0000-0|000 00|0|0-0000| 0000-0|000 00|0|0-0000
ST IQ ? DX CN LK ? ?-????
I tested it with the following "packed" hex digits 93 4D 62 CA and got back 18 13 13 12 11 (decimal, PEEKed in Applesoft) which are exactly the Strength, IQ, Dex, Cn and Luck of my lead character. Woo-hoo.
http://pastebin.ca/1845374
Enjoy. One thing I found out I didn't have to do was clear the carry before the bit-shift operations, because the ones I used always put a zero in the blank bit. Oh well. Better safe than sorry.
Nitpick: I could probably have modularized the code a bit more instead of hardcoding the addresses by using an indirect addressing mode with an index, along the lines of ($00),Y as the base address with 00 60 stored in 0 and 1 respectively.
Meh. I'll refine it all when I can find a copy of EDASM for DOS. *snerk*
- Quantum Reality
- Posts: 91
- Joined: Mon Mar 15, 2010 8:34 pm
Sorry for the double post; I wanted to clarify something re the "hex packed" character attributes.
Had a Conjurer and Magician levelled up to 18s all across the board. The actual hex encoding was 94 92 94 88 and was the same for both of them. Conclusion: the ??-marked character traits are not used in BT1 and may have been left as "for future expansion".
Had a Conjurer and Magician levelled up to 18s all across the board. The actual hex encoding was 94 92 94 88 and was the same for both of them. Conclusion: the ??-marked character traits are not used in BT1 and may have been left as "for future expansion".
Hi Quantum, check out this (search for "Bard"):
http://victa.jamtronix.com/display/topics/1
In particular this article might be interesting for you:
http://victa.jamtronix.com/display/page/2355
Or, you can also hack in a BTIII editor for apple from
computist issue 64:
http://victa.jamtronix.com/display/page/2495
Maybe this is helpful too?
ftp://ftp.apple.asimov.net/pub/apple_II ... assembler/
http://victa.jamtronix.com/display/topics/1
In particular this article might be interesting for you:
http://victa.jamtronix.com/display/page/2355
Or, you can also hack in a BTIII editor for apple from
computist issue 64:
http://victa.jamtronix.com/display/page/2495
Maybe this is helpful too?
ftp://ftp.apple.asimov.net/pub/apple_II ... assembler/
- Quantum Reality
- Posts: 91
- Joined: Mon Mar 15, 2010 8:34 pm
Hi Darendor,
as you know, I moved all my resources to the other thread, where
I doc everything I know. There the C64 BT1 roster file format is complete, afaik.
So in this thread I think there is not much more to say about the BT1 roster file format on the CBM64...
Only, in this thread here are all the links for the APPLE stuff, that we relied on when we were investigating the chances for using BT3 on C64 as an engine.
as you know, I moved all my resources to the other thread, where
I doc everything I know. There the C64 BT1 roster file format is complete, afaik.
So in this thread I think there is not much more to say about the BT1 roster file format on the CBM64...
Only, in this thread here are all the links for the APPLE stuff, that we relied on when we were investigating the chances for using BT3 on C64 as an engine.
Last edited by ZeroZero on Sat Mar 20, 2010 4:11 pm, edited 1 time in total.
- Quantum Reality
- Posts: 91
- Joined: Mon Mar 15, 2010 8:34 pm
I'll look into that.
Meantime, a few words on this:
I've been trying to examine this a little, and there is a definite correlation with experience level, although not one I can mathematically determine yet.
MARKUS the ATEAM rogue on my character disk is exp level 2. Viewing the sector showed:
In the relevant bytes.
I loaded up my levelled-up rogue at exp level 17. His bytes are:
I don't know what these mean exactly (i.e. are they probabilities for whatever he's good at*, or...?) but I'm betting if you put all FFs in there your rogue would be basically The Man at disarming everything and could hide from Mangar himself.
--
* by this, I mean one possible usage could be that the probability of the Rogue's ability to do whatever ranges from 0 to 255, meaning 255 would be ~100% and 0 would be 0%. Until we get the definitive Bard's Tale source code, it will not be easy to tell.
Also, the binary representations don't look like they're AND-masked with anything.
Meantime, a few words on this:
Code: Select all
44 - 46 byte rogue values: HIDE, DETECT TRAP, DISARM TRAP, sequence????
MARKUS the ATEAM rogue on my character disk is exp level 2. Viewing the sector showed:
Code: Select all
Hex: 1D 18 1A
Binary: 00011101 00011000 0011010
I loaded up my levelled-up rogue at exp level 17. His bytes are:
Code: Select all
Hex: 65 65 60
Binary: 01100101 01100101 01100000
--
* by this, I mean one possible usage could be that the probability of the Rogue's ability to do whatever ranges from 0 to 255, meaning 255 would be ~100% and 0 would be 0%. Until we get the definitive Bard's Tale source code, it will not be easy to tell.
Also, the binary representations don't look like they're AND-masked with anything.
E D I T
I disassembled all long BT1 C64 event for the review board.
From that code I can tell about the rogue abilities this:
The rogue's values gain PER LEVEL advancement:
(1d8 - 1) + (1 per DX above 14) up to 0xff
Each rogue ability has its own dice roll.
This happens AFTER a random basic ability has been raised. So it
can happen, that first the DX is raised above 14, and then the
dice roll for the rogue abilities occurs.
I disassembled all long BT1 C64 event for the review board.
From that code I can tell about the rogue abilities this:
The rogue's values gain PER LEVEL advancement:
(1d8 - 1) + (1 per DX above 14) up to 0xff
Each rogue ability has its own dice roll.
This happens AFTER a random basic ability has been raised. So it
can happen, that first the DX is raised above 14, and then the
dice roll for the rogue abilities occurs.
- Quantum Reality
- Posts: 91
- Joined: Mon Mar 15, 2010 8:34 pm
EDITZeroZero wrote:E D I T
I disassembled all long BT1 C64 event for the review board.
From that code I can tell about the rogue abilities this:
The rogue's values gain PER LEVEL advancement:
(1d8 - 1) + (1 per DX above 14) up to 0xff
Each rogue ability has its own dice roll.
This happens AFTER a random basic ability has been raised. So it
can happen, that first the DX is raised above 14, and then the
dice roll for the rogue abilities occurs.
Ok, so each level gained the BT1 game will re-roll the three attributes for the character and add them to what's already there. Ok. Then storing all FFs is fine as long as you don't try to level the character up through the review board.
Last edited by Quantum Reality on Sat Mar 20, 2010 9:30 pm, edited 2 times in total.
I said, they GAIN
so the new value after level change is:
OldRogueVal + Rnd(0 - 7) + (DX - 14) > 0 ? DX - 14 : 0
E D I T
On C64 BT1 that values will remain even after review board. The only
values that you will loose in review board is drained levels.
After being advanced, the present level (in contrary to the "natural"
level) will become permanent as new natural level.
SO if a monster drained 3 levels from you (natural 17, present 14)
and you advance, your new level will be 15 and NOT 18.
E D I T #2
Even in BT1 the roster contains both values, natural and present levels.
I haven't checked yet, if healing in temples also restores drained levels.
Anyway this concept was originally meant to be able to have a way to
"heal" drained levels.
so the new value after level change is:
OldRogueVal + Rnd(0 - 7) + (DX - 14) > 0 ? DX - 14 : 0
E D I T
On C64 BT1 that values will remain even after review board. The only
values that you will loose in review board is drained levels.
After being advanced, the present level (in contrary to the "natural"
level) will become permanent as new natural level.
SO if a monster drained 3 levels from you (natural 17, present 14)
and you advance, your new level will be 15 and NOT 18.
E D I T #2
Even in BT1 the roster contains both values, natural and present levels.
I haven't checked yet, if healing in temples also restores drained levels.
Anyway this concept was originally meant to be able to have a way to
"heal" drained levels.
- Quantum Reality
- Posts: 91
- Joined: Mon Mar 15, 2010 8:34 pm
Yeah, I know about the natural level vs actual level. I used to sector edit my characters in the old days (late 80s early 90s ), so I know they occur twice for a reason in the actual sectorformat.
Speaking of which, if you have an Apple emulator and what to see what I've done so far, which I admit is a bit of a crappy job, check it out here:
http://www.megaupload.com/?d=LSBTZF99
Applesoft BASIC (Link expires in one week due to the transient nature of this coding process) code:
http://pastebin.ca/1846971
Speaking of which, if you have an Apple emulator and what to see what I've done so far, which I admit is a bit of a crappy job, check it out here:
http://www.megaupload.com/?d=LSBTZF99
Applesoft BASIC (Link expires in one week due to the transient nature of this coding process) code:
http://pastebin.ca/1846971
- Quantum Reality
- Posts: 91
- Joined: Mon Mar 15, 2010 8:34 pm
Verified with ZeroZero over MSN:ZeroZero wrote:@ Quantum:
Can you tell me, if on the apple II also only the boot disk contains a ProDOS directory, while the other disks have none?
Boot disk yes (well, ProDOS-like, I recognized filenames and a couple file types), Dungeon disks 1 and 2 no, Character disk no. Useful info for anyone else who wants to study BT3.