BRAM Library

[Bonknuts]

Seems I'm running into a problem using the same BRAM libs from a CD project. Looking at the emulator, it's not unlocking bram. It works fine as a hucard project and the exact same routines. Is the emulator looking for something specific to CD games? Is there some different hardware unlock process for the CD unit or sys card that the emulator is looking for?

[ccovell]

Who knows?  Are you banking in BRAM to an "oddball" location?  Did you try it on a real CD system yet?

[Bonknuts]

No. I stuck with the system card protocol (logical address range, etc), as well as used Neutopia as a guide. Even did the long string to port $1807 instead of just $80. I think it might be an emulator thing. I haven't tried it on the real system yet.

 Guess I'll just switch over to using the sys card routines for the CD project, for now. I wanted to use my own lib because it's faster and cleaner than switching to MPR1, MPR7, and maintaining two stack pointers (as well as different VDC IRQ routines for each).

[TheOldMan]

Silly question: Did you format the BRAM? I vaguely remember having to do that to create the BRAM file for <Mednafen?> Look and see if theres a 2K file in with the emulator stuff.

Also, do you drop to low-speed mode?

[Bonknuts]

Yeah. That's the first function that is called. Check for valid header, format if absent. Yup, in low speed and interrupts disabled (extra caution). I mean, everything that I did for the hucard project that worked fine in mednafen, now appears to do nothing in the CD project for mednafen. I'm assuming the emulator must have some other check or such for its bram emulation code when in CD mode.

[TheOldMan]

Seems I'm running into a problem using the same BRAM libs from a CD project.

It seems to me that if it works for a Hucard project, it should work for a CD project.
The only difference might be where the routines are located. I know the syscard version
is in the $00 bank, and mapped in at page 7 ($e000-$ffff). Possibly something is un-mapping your
routines / data. Or the emulator won't unlock BRAM from any other page.

[The system card routines use indirects to save to BRAM, since the data-to-save could be anywhere in the cpu address space. And the same for BRAM, iirc.]

[dshadoff]

Is the BRAM function on the CD project your own function, or the CDROM card's function ?

I seem to recall ccovell identifying a more complex 'unlock' requireement several years ago... if I recall correctly, it needs a 3-write unlock sequence rather than 1-write.

Of course, this only applies if you are writing your own.  In HuC projects, the library automatically chooses between HuC code and CDROM card functions based on the target type.

-Dave

[ccovell]

I seem to recall ccovell identifying a more complex 'unlock' requireement several years ago... if I recall correctly, it needs a 3-write unlock sequence rather than 1-write.

It's on the 1st page of this same thread, in fact.

[Bonknuts]

Is the BRAM function on the CD project your own function, or the CDROM card's function ?

I seem to recall ccovell identifying a more complex 'unlock' requireement several years ago... if I recall correctly, it needs a 3-write unlock sequence rather than 1-write.

Of course, this only applies if you are writing your own.  In HuC projects, the library automatically chooses between HuC code and CDROM card functions based on the target type.

-Dave

Yeah, it's my own BRAM code (for both hucard and CD project). I definitely took note of the 3 byte sequence Chris mentioned and I'm using it.

Seems I'm running into a problem using the same BRAM libs from a CD project.

It seems to me that if it works for a Hucard project, it should work for a CD project.
The only difference might be where the routines are located. I know the syscard version
is in the $00 bank, and mapped in at page 7 ($e000-$ffff). Possibly something is un-mapping your
routines / data. Or the emulator won't unlock BRAM from any other page.

[The system card routines use indirects to save to BRAM, since the data-to-save could be anywhere in the cpu address space. And the same for BRAM, iirc.]

Actually, yeah. On the hucard project, I'm doing the bram access from bank $0 and MPR 7. And in the CD project the bram code is in bank $69 and MPR 2. I'll MPR7 and see if that has any effect.

[TheOldMan]

And in the CD project the bram code is in bank $69 and MPR 2. I'll MPR7 and see if that has any effect.

Hunh? MPR2 is the $4000 cpu range, iirc.  I'd have to trace through that stuff again, but I think thats actually where the BRAM 'appears' (I could be wrong, though)

Can you re-build the HuCard project as a cd, and see if it works? That will let you know if its a bank placement problem.

[TheOldMan]

MPR2 is the $4000 cpu range, iirc.

My bad. I was just looking at something else, and noticed the syscard bram functions
save the entire memory layout. And then map actual BRAM data to MPR4 ($8000 range).

[Bonknuts]

Yeah, $8000 range.

Ok, so I just tried it with bank $69 in mpr7 and bank $f7 in mpr4. Still no luck. I really think this is an emulator issue. Guess I'll just stick with sys card routines for CD projects. The BRAM lib code work for hucard projects, so I guess it's not a total loss.

[TheOldMan]

Ok, so I just tried it with bank $69 in mpr7 and bank $f7 in mpr4.

Okay. One more silly observation, then I'll leave it alone.
As I was tracing through the routines, I noticed that the bram re-lock routine turned the interrupts on.
So I went back and checked, and the bram unlock routine turns them off before going to low speed mode and unlocking bram.


[That's why one of the routines does some processing og the interrupts on it's own, I think. ]

[Bonknuts]

It's definitely an emulator thing with mednafen. I switched over to using the sys card bram routines instead, and stepping through the code - it won't show any changes to bram (bm_format). So something with the emulator itself when running a CD game. Because stepping through BRAM code (my own, or an official hucard), in the emulator works find with hucards. It's like one of those quantum physics things; observing it changes the behavior ;>_>

As I was tracing through the routines, I noticed that the bram re-lock routine turned the interrupts on.
So I went back and checked, and the bram unlock routine turns them off before going to low speed mode and unlocking bram.

Yeah, I followed that procedure. I figured it was extra safe guards when accessing BRAM - because handling save data is pretty important. Though I do the PHP, SEI, CSL and CSH, PLP. Just in case any higher up functions already had interrupts disabled.   

[Bonknuts]

Also, the CDREAD routine is annoying. I can only read in as many free banks as I have logical address range for (32k at a time). Loading in 256k results in multiple calls to CDREAD. I'm using the docs from syscard 1.0. Is there an update to the CDREAD routine with more parameters?

I don't want to waste a full 8k just to use the updated CDREAD lib routine I ripped from Seiya monogatari.