BRAM Library

[Bonknuts]

I know there are some existing libs out there for BRAM support (HuC), but I've written a set of my own. I'm just cleaning everything up and reducing the code/data/bss/zp footprint. This is mostly for Hucard projects, but it should be compatible with any CD project as well.

 I tried to offer a little more support than what the syscard bios funcs provided. I know mednafen had an option to allow up to 8k of BRAM. So I added compatibility for that, as well as upgrading the BRAM header to 8k size. BRAM doesn't mirror, so it should work in theory. IIRC, Ryphecha said one game didn't like it (but only one). I know people have been talking about making BRAM boosters for their systems, so would work with that - if that ever comes to pass (larger than 8k).
 
 I going to do some tests over the next couple of days and then I'll release the lib. I would definitely appreciate feedback on it (suggested support, interfacing, etc).




Edit: (old)
Ok, I was wondering if anyone out there with some experience with bram interfacing could help out?

 I have Dragon Warrior for the PCE that I promised to release for Bernie, but I don't want to release it without BRAM support. I have very-very little time, so I'm seeing if anyone else could help out with the explanation of how to interface with it (the save file interfacing)? I also remember someone (Ccovell?) saying that HuC had a bug in one of its support functions.

 Anyone interested in helping out?

[Bonknuts]

So, here's the info I gathered so far:

 The bram entries are made up of ID num + text header; the FCB. The BRAM search function has a pointer to this ID in BX (ID for compare is in local memory). I'm not quite sure what _AL is (number of file from top=1), but I'm guessing that's the number of instances of this ID string?

 So it appears BRAM Write is also for creating new files as well as updating existing ones.

 So something like BRAM search (pointer, instance). If exists (call $1D returns $00), then update it (call $1B with pointer to data and ID), if not - check for free memory (call $19 returns amount in CX). If enough, write update (call $1B with pointer to data and ID).

 Edit: Also, I'll need some brave souls to try out this Dragon Warrior BRAM stuff. Any takers?

[MooZ]

Dude, I'm knee deep into BRAM atm
The BRAM starts with a 16 bytes header.[ul][li]00-03 - Header tag (equals to "HUBM")[/li][li]04-05 - Pointer to the first byte after BRAM storage[/li][li]06-07 - Pointer to the next available BRAM slot (first unused byte)[/li][li]08-0f - Reserved (set to 0).[/li][/ul]A BRAM entry is formatted as follow:
[ul][li]00-01 - Entry size. This size includes the 16 bytes of the entry header[/li][li]02-03 - Checksum. The checksum is the sum of the entry bytes starting from byte #4 (i.e all bytes except the entry size and checksum). The value stored is the opposite of the computed checksum. This way the consistency check only consists in adding the stored checksum and the newly computed one. If this sum is 0, the entry is valid[/li][li]04-0f - Entry name.[ul][li]00-01 - Unique ID[/li][li]02-0b - ASCII name padded with spaces[/li][/ul][/li][/ul]
If I understood what was written in the Develo Book, the bm_files routine of the system card fetches the nth entry (n stored in _al). _bx stores the address where the entry information will be stored (id,name,size). At the end _si will contain the address of the matching entry.

[nodtveidt]

The bug was/is in bm_delete().

[ccovell]

I think there's a HuC/MKit library interface in my BRAM manager that you can use. 

Also, one thing I suspect is that the HuC BRAM_Detect / Unlock code may be faulty (at least the version that I have.)  It writes $80 to $1807, when it really needs to write $48,$75,$80 to that register.  CD systems work with the faulty code, but TennoKoe2s don't.

[Bonknuts]

I think there's a HuC/MKit library interface in my BRAM manager that you can use. 

Also, one thing I suspect is that the HuC BRAM_Detect / Unlock code may be faulty (at least the version that I have.)  It writes $80 to $1807, when it really needs to write $48,$75,$80 to that register.  CD systems work with the faulty code, but TennoKoe2s don't.

 Ohh, that's good to know. For DW, I'll be using the syscard functions, but for the hucard version and two other nes2pce hucards, I'll need to directly access bram.

[Bonknuts]

Dude, I'm knee deep into BRAM atm
The BRAM starts with a 16 bytes header.[ul][li]00-03 - Header tag (equals to "HUBM")[/li][li]04-05 - Pointer to the first byte after BRAM storage[/li][li]06-07 - Pointer to the next available BRAM slot (first unused byte)[/li][li]08-0f - Reserved (set to 0).[/li][/ul]A BRAM entry is formatted as follow:
[ul][li]00-01 - Entry size. This size includes the 16 bytes of the entry header[/li][li]02-03 - Checksum. The checksum is the sum of the entry bytes starting from byte #4 (i.e all bytes except the entry size and checksum). The value stored is the opposite of the computed checksum. This way the consistency check only consists in adding the stored checksum and the newly computed one. If this sum is 0, the entry is valid[/li][li]04-0f - Entry name.[ul][li]00-01 - Unique ID[/li][li]02-0b - ASCII name padded with spaces[/li][/ul][/li][/ul]
If I understood what was written in the Develo Book, the bm_files routine of the system card fetches the nth entry (n stored in _al). _bx stores the address where the entry information will be stored (id,name,size). At the end _si will contain the address of the matching entry.

 This seems easy enough. I should be able to write my own interface code.

 So what about the linked list system? Is there a WORD pointer at the end of an entry?
On that note: does the system card take care of defragmenting the entries?

[TheOldMan]

So what about the linked list system? Is there a WORD pointer at the end of an entry?

Don't believe so. It adds up the entry sizes. Recognizes list end by comparing to next available byte.

On that note: does the system card take care of defragmenting the entries?

<lol>. No, I don't think it does.

[TheOldMan]

On that note: does the system card take care of defragmenting the entries?

I take my comment back. I just checked, and it looks like it shifts the directory/data blocks backwards, over writing the old data, and adjusts the available pointer.

Must have been thinking of the HuC version....

[Bonknuts]

On that note: does the system card take care of defragmenting the entries?

I take my comment back. I just checked, and it looks like it shifts the directory/data blocks backwards, over writing the old data, and adjusts the available pointer.

 Cool. I think I have all the info that I need (and it all checks out from looking at an existing near full bram file in hex editor). For the hucard libs I'll make, I'll be sure to reorganize the blocks if I add a delete option.

[Arkhan]

On that note: does the system card take care of defragmenting the entries?

I take my comment back. I just checked, and it looks like it shifts the directory/data blocks backwards, over writing the old data, and adjusts the available pointer.

Must have been thinking of the HuC version....

^^^^^ Yeah

[Bonknuts]

Updated the main post. I'll be posting the library and any updates to it in this thread.

 Note: I'm using fast 16bit compares (cmp+sbc), but man.. that inverse logic of the carry flag always trips me up :/

[Arkhan]

Updated the main post. I'll be posting the library and any updates to it in this thread.

 Note: I'm using fast 16bit compares (cmp+sbc), but man.. that inverse logic of the carry flag always trips me up :/

I'm over here writing z80 and laughing at you.

[Bonknuts]

Haha, you can keep that z80. I'm not a fan.

[Bonknuts]

Ok. Preliminary BRAM support tested out fine. I tried to cover as much safety and bounds checks as I could (not sure how much the sys card handles). Lots of error reporting (more than sys card functions, and more detailed/specific). I don't have as fully featured set as the sys card ones (specifically for partial updates to an entry vs full updates/writes), but they work out great so far. I'll probably post an example suite, but it's more for musings than anything else at this point. Currently implementing this BRAM lib into Dragon Warrior.