I think it's been covered, but just to be clear, the bank switching captures the address bits when you write to cartridge space (so it doesn't matter if you write a value or clear it). The least significant bit is ignored, because every access becomes two 8-bit accesses. Classic99's naming convention is documented in the PDF manual shipped with the emulator, although it doesn't go into detail on the banking itself.
Just to help with the ini, though, when you are specifying type 8 or type 9 in the INI, you actually are providing addresses in EPROM space rather than TI memory space. So your one example should have worked like this:
[usercart0] ; *** Lena name="Lena" ; this would become the first bank on the EPROM rom0=8|0000|2000|mods\lenac.bin ; this would be the second rom1=8|2000|2000|mods\lenad.bin ; this would be the third rom2=8|4000|2000|mods\lenae.binAnd Classic99 would end up with a 32k EPROM (rounding up to the next power of 2) with data in the first 24k and the last 8k unused. Since it's type 8 for non-inverted, >6000 would select the '0000' bank, >6002 the '2000' bank, >6004 the '4000' bank, and >6006 the empty '6000' bank.
Sorry it's so obtuse... it's a format that has grown too slowly over far too long a time.
I took a quick look at the Lena GIF too.. I got good results with the default options in Convert9918A, but the one change I'd recommend is change the "Fill Mode" to "Middle". This makes it zoom the image up to fill the screen and drop the edges ('left/top' and 'bottom/right' crop based on the listed position instead of the middle of the image). Having just a few extra pixels to work with makes a big difference.
Thanks for the clarification, Tursi. I also managed to get better results with the Lena pic by tweaking the Luma and turning on the histogram.
Yep, something like this. Either that, or use 8K of the 32K for the actual control routines (which aren't overwritten) and then use the other upper 16K for data in/out of the cart. We've proven that copy routines from ROM to RAM are pretty darn fast by implementing the "copy to 32K and run" cartridges.
I know it gets dicey when copying into lower 8K due to other stuff that's expected to be living there, but you might be able to get away with that as well if you can not stomp on whatever's expected to be there.
So, bottom line, something like:
Lower 8K: Maybe some character sets and other static stuff?
8K >A000, Control program
8K >C000->FFFE, data being copied from cart
Yeah, that's pretty good thinking. Right now I'm toying with keeping the control code and various common routines in lower 8k (like the music player -- there is also plenty of space leftover for character sets and what not) and then keeping the currently playing song in the upper 24k. This will make it easy to have one song play over multiple screens (and it's pretty much the only place a song will fit contiguously). Depending on the song, there will probably be some memory leftover for various screens to tinker with.
Edit: Also, Tursi, any clue why the following code isn't working when I have a psgmod 2.04 example song loaded at >A000?
LI R0,>A000 BL @SGPLAY SPIN LIMI 2 LIMI 0 JMP SPIN
Edited by orbitaldecay, Mon May 2, 2016 6:11 PM.