Bankswitching Demos/Templates

[Wickeycolumbus]

what are some good places that I can find some info about f4sc bankswitching? and any places to order boards as well?

 

To my knowledge, it is the same as F4 (8 hotspots from $1FF4-$1FFB), but there is an extra 128 bytes of RAM mapped from $1000-$107F for writes, and $1080-$10FF for reads, but for some reason, I could never make a working demo for this scheme.

 

 

That's essentially all it is yeah. What problems did you have with making the demo? I'm going to assume it was intended to just to the same flashing bars on the non-SCed version of F4 (like how F6 & F6SC were similar)

 

Thats why I am stumped. I tried to make my F4SC template the same way I made my F6SC demo, I just filled the first 256 bytes with $00 and used some RAM for the background colors, but that did not work for some reason I will revisit the problem soon, and if I can't figure it out, I will post my source so hopefully some of you guys can help me out.

[SeaGtGruff]

Thats why I am stumped. I tried to make my F4SC template the same way I made my F6SC demo, I just filled the first 256 bytes with $00 and used some RAM for the background colors, but that did not work for some reason I will revisit the problem soon, and if I can't figure it out, I will post my source so hopefully some of you guys can help me out.

Be sure you fill the RAM area in all eight of the banks with $FF (I think that's better than $00), and I guess maybe be sure you don't put a copy of the start vector in the NMI vector ($FFFA-$FFFB), otherwise the emulators may have trouble with auto-selecting the correct bankswitching scheme to use.

 

You can test wjether that's the issue-- the emulator's ability to correctly auto-detect the intended bankswitching scheme-- by *manually* telling the emulator to use the F4SC scheme. If it runs correctly that way, then the emulator isn't able to correctly auto-detect which bankswitching scheme to use. And since the emulators have to look for specific types of clues when trying to figure out the correct bankswitching scheme, you need to stick to those expected clues. Remember, most bankswitching schemes don't have rules that say "Put a value of XYZ in memory location $1234 to instruct the Atari that it's supposed to use bankswitching scheme A1B2 whern running this cart," because that's not how it worked/works on the real hardware, because the bankswitching is handled by the cart's board, not by the Atari. Emulators are a different story, because they don't have a cart with a board to control the bankswitching-- they just have a ROM image, and they need to know what the bankswitching scheme is because they have to handle the bankswitching logic themselves. So they've been programmed to look for clues-- certain characteristics in a ROM image that would normally be found in a ROM image for a specific bankswitching scheme. And in most of the (few) ROMs that I've looked at, the expansion RAM area/s was/were filled with $FF rather than $00. So if you filled the RAM with $00, maybe the emulator thinks the ROM is for F4, not F4SC?

 

Michael

[Wickeycolumbus]

Thats why I am stumped. I tried to make my F4SC template the same way I made my F6SC demo, I just filled the first 256 bytes with $00 and used some RAM for the background colors, but that did not work for some reason I will revisit the problem soon, and if I can't figure it out, I will post my source so hopefully some of you guys can help me out.

Be sure you fill the RAM area in all eight of the banks with $FF (I think that's better than $00), and I guess maybe be sure you don't put a copy of the start vector in the NMI vector ($FFFA-$FFFB), otherwise the emulators may have trouble with auto-selecting the correct bankswitching scheme to use.

 

You can test wjether that's the issue-- the emulator's ability to correctly auto-detect the intended bankswitching scheme-- by *manually* telling the emulator to use the F4SC scheme. If it runs correctly that way, then the emulator isn't able to correctly auto-detect which bankswitching scheme to use. And since the emulators have to look for specific types of clues when trying to figure out the correct bankswitching scheme, you need to stick to those expected clues. Remember, most bankswitching schemes don't have rules that say "Put a value of XYZ in memory location $1234 to instruct the Atari that it's supposed to use bankswitching scheme A1B2 whern running this cart," because that's not how it worked/works on the real hardware, because the bankswitching is handled by the cart's board, not by the Atari. Emulators are a different story, because they don't have a cart with a board to control the bankswitching-- they just have a ROM image, and they need to know what the bankswitching scheme is because they have to handle the bankswitching logic themselves. So they've been programmed to look for clues-- certain characteristics in a ROM image that would normally be found in a ROM image for a specific bankswitching scheme. And in most of the (few) ROMs that I've looked at, the expansion RAM area/s was/were filled with $FF rather than $00. So if you filled the RAM with $00, maybe the emulator thinks the ROM is for F4, not F4SC?

 

Michael

 

I tried manually selecting F4SC, but still no luck I will try again soon, it has to be something I overlooked.

[SeaGtGruff]

I tried manually selecting F4SC, but still no luck I will try again soon, it has to be something I overlooked.

Post the code for your F4SC demo so we can look at it. It's probably something pretty simple, but it's amazing how hard it can be to find the simple problems if you've been looking at your own code for too long. A fresh pair of eyes can help.

 

It's like something I read once about proofreading your own writing. After you finish writing something-- be it lengthy, or just a short post/email/letter-- put it aside and go do something else for an hour or two. Then go back and read it from beginning to end, as if it had been written by someone else and you've never seen it before. You'll be surprised how your typos or spelling errors, grammatical errors, and awkward sentence constructions will be more likely to jump out at you, when just a few hours before it seemed perfectly okay when you were reading it (i.e., as you were writing it, or just after you finished writing it).

 

Michael

[Wickeycolumbus]

I tried manually selecting F4SC, but still no luck I will try again soon, it has to be something I overlooked.

Post the code for your F4SC demo so we can look at it. It's probably something pretty simple, but it's amazing how hard it can be to find the simple problems if you've been looking at your own code for too long. A fresh pair of eyes can help.

 

It's like something I read once about proofreading your own writing. After you finish writing something-- be it lengthy, or just a short post/email/letter-- put it aside and go do something else for an hour or two. Then go back and read it from beginning to end, as if it had been written by someone else and you've never seen it before. You'll be surprised how your typos or spelling errors, grammatical errors, and awkward sentence constructions will be more likely to jump out at you, when just a few hours before it seemed perfectly okay when you were reading it (i.e., as you were writing it, or just after you finished writing it).

 

Michael

 

Here is today's try, I have absolutely no idea what I did wrong, hope you guys can help

Archive_5.zip

[cd-w]

Here is today's try, I have absolutely no idea what I did wrong, hope you guys can help

 

It looks OK to me, and it does appear to work fine in z26. Running through using the debugger in Stella it seems that the instruction "sta $FFF4" is not triggering a bank-switch, which causes the code to fail. This could be a bug in Stella, or I could be using the debugger wrong?

 

Notes: you can use "nop $fff4" etc to avoid corrupting any of the registers when bank-switching, and you can use "ds.b 256, $FF" instead of the "repeat 256 .byte $FF repend" sequence.

 

Chris

[Mord]

Here is today's try, I have absolutely no idea what I did wrong, hope you guys can help

 

It looks OK to me, and it does appear to work fine in z26. Running through using the debugger in Stella it seems that the instruction "sta $FFF4" is not triggering a bank-switch, which causes the code to fail. This could be a bug in Stella, or I could be using the debugger wrong?

 

Notes: you can use "nop $fff4" etc to avoid corrupting any of the registers when bank-switching, and you can use "ds.b 256, $FF" instead of the "repeat 256 .byte $FF repend" sequence.

 

Chris

 

On the other hand, every time I try to compile these asm files the dasm I'm using freaks out. What's the latest dasm and vcs.h/macro.h files? I tried downloading from sourceforge for dasm and it wouldn't let me download. It'd just reload the page whenever I clicked on the download link.

 

*edits*

 

As a quick test tho, on the "Swch7" section, add another 3 nops before the rts and see how it goes.

Edited May 1, 2009 by Mord

[+batari]

Here is today's try, I have absolutely no idea what I did wrong, hope you guys can help

 

It looks OK to me, and it does appear to work fine in z26. Running through using the debugger in Stella it seems that the instruction "sta $FFF4" is not triggering a bank-switch, which causes the code to fail. This could be a bug in Stella, or I could be using the debugger wrong?

 

Notes: you can use "nop $fff4" etc to avoid corrupting any of the registers when bank-switching, and you can use "ds.b 256, $FF" instead of the "repeat 256 .byte $FF repend" sequence.

 

Chris

You are correct. I replaced all of the STA $FFF4 with NOP $FFF4 and it works. It must be a Stella bug, as either should work.

[+stephena]

Here is today's try, I have absolutely no idea what I did wrong, hope you guys can help

 

It looks OK to me, and it does appear to work fine in z26. Running through using the debugger in Stella it seems that the instruction "sta $FFF4" is not triggering a bank-switch, which causes the code to fail. This could be a bug in Stella, or I could be using the debugger wrong?

 

Notes: you can use "nop $fff4" etc to avoid corrupting any of the registers when bank-switching, and you can use "ds.b 256, $FF" instead of the "repeat 256 .byte $FF repend" sequence.

 

Chris

Thanks for the report and the PM. I'll look into this right away.

 

EDIT: Doh, I found the bug and fixed it. It seems that in cleaning up the bankswitch code for the last release, I was a little too zealous, and deleted a line by mistake. I'm going to go over all the other BS schemes and make sure they don't have similar problems, and then do a quick bugfix release this evening.

 

For those who are interested, the code was inspecting for values in the range 0xff4 to 0xffb, but not masking the address by 0xfff first. This was done correctly in the peek method (so NOP worked), but not in the poke method (so STA failed).

Edited May 1, 2009 by stephena

[+stephena]

Thats why I am stumped. I tried to make my F4SC template the same way I made my F6SC demo, I just filled the first 256 bytes with $00 and used some RAM for the background colors, but that did not work for some reason I will revisit the problem soon, and if I can't figure it out, I will post my source so hopefully some of you guys can help me out.

Be sure you fill the RAM area in all eight of the banks with $FF (I think that's better than $00), and I guess maybe be sure you don't put a copy of the start vector in the NMI vector ($FFFA-$FFFB), otherwise the emulators may have trouble with auto-selecting the correct bankswitching scheme to use.

 

You can test wjether that's the issue-- the emulator's ability to correctly auto-detect the intended bankswitching scheme-- by *manually* telling the emulator to use the F4SC scheme. If it runs correctly that way, then the emulator isn't able to correctly auto-detect which bankswitching scheme to use. And since the emulators have to look for specific types of clues when trying to figure out the correct bankswitching scheme, you need to stick to those expected clues. Remember, most bankswitching schemes don't have rules that say "Put a value of XYZ in memory location $1234 to instruct the Atari that it's supposed to use bankswitching scheme A1B2 whern running this cart," because that's not how it worked/works on the real hardware, because the bankswitching is handled by the cart's board, not by the Atari. Emulators are a different story, because they don't have a cart with a board to control the bankswitching-- they just have a ROM image, and they need to know what the bankswitching scheme is because they have to handle the bankswitching logic themselves. So they've been programmed to look for clues-- certain characteristics in a ROM image that would normally be found in a ROM image for a specific bankswitching scheme. And in most of the (few) ROMs that I've looked at, the expansion RAM area/s was/were filled with $FF rather than $00. So if you filled the RAM with $00, maybe the emulator thinks the ROM is for F4, not F4SC?

 

Michael

I just want to reiterate the importance of what SeaGtGruff says above. The autodetection code in Stella is quite robust as long as you stick to the few predefined rules that almost all ROMs adhere to. In Stella's internal database of approx. 3200 ROMs, only 5 don't work with autodetection, and that because they're bad dumps (and hence don't follow some of the common rules).

 

I know this isn't the problem you were experiencing, but it bears repeating for everyone; for all intents and purposes, you don't need to worry about bankswitch format for Stella anymore (except for those cases where it isn't implemented yet). If anyone has a ROM that doesn't autodetect correctly, please let me know ASAP.

[cd-w]

EDIT: Doh, I found the bug and fixed it. It seems that in cleaning up the bankswitch code for the last release, I was a little too zealous, and deleted a line by mistake. I'm going to go over all the other BS schemes and make sure they don't have similar problems, and then do a quick bugfix release this evening.

 

That was quick work - many thanks!

 

Chris

[+stephena]

Here is today's try, I have absolutely no idea what I did wrong, hope you guys can help

 

It looks OK to me, and it does appear to work fine in z26. Running through using the debugger in Stella it seems that the instruction "sta $FFF4" is not triggering a bank-switch, which causes the code to fail. This could be a bug in Stella, or I could be using the debugger wrong?

 

Notes: you can use "nop $fff4" etc to avoid corrupting any of the registers when bank-switching, and you can use "ds.b 256, $FF" instead of the "repeat 256 .byte $FF repend" sequence.

 

Chris

OK, I just wanted to let everyone know that Stella 2.7.7 was just released, which fixes this bug.

[Wickeycolumbus]

E0 has me stumped

E0.zip

[+stephena]

E0 has me stumped

Oops, this one isn't autodetected correctly in Stella; it's determined to be F8 instead. For now, you'll have to manually force E0 bankswitching. Also, you can view the current BS type by pressing Alt-L (Shift-Cmd-L for OSX), which will immediately show the BS in use, and whether or not it was autodetected.

 

EDIT: I just thought I should add that autodetection for the more esoteric BS formats (E0, E7, etc) has been tuned to ROMs currently out there, and not so much to new ones being created. Since there are very few new E0 ROMs being created, this was a fair tradeoff. Put another way, the signatures searched for to determine E0 take some shortcuts, in that they only look for a few specific known triggers, as follows:

   { 0x8D, 0xE0, 0x1F },  // STA $1FE0
  { 0x8D, 0xE0, 0x5F },  // STA $5FE0
  { 0x8D, 0xE9, 0xFF },  // STA $FFE9
  { 0xAD, 0xE9, 0xFF },  // LDA $FFE9
  { 0xAD, 0xED, 0xFF },  // LDA $FFED
  { 0xAD, 0xF3, 0xBF }   // LDA $BFF3

If you use anything other than that, obviously the autodetection will fail. When I add the following, your ROM is autodetected correctly:

   { 0x0C, 0xE0, 0x1F },  // NOP $1FE0
  { 0xAD, 0xE0, 0x1F },  // LDA $1FE0

The main problem is, I can't add all possibilities, as the signatures sometimes overlap with other BS schemes. So I suggest to stick to one of the above.

 

Also, there seems to be other problems in your test ROM. Even when I fix the autodetection (or force it), the ROM still doesn't run correctly some of the time.

 

EDIT2: Oops again, there seems to be further problems in Stella wrt this ROM. It starts up fine in z26 each time, but is intermittent in Stella (sometimes it works, other times it gives garbage). I'll need to research this further. Unfortunately, this isn't going to be easy, as the KrokCart doesn't support E0 ROMs, so I can't definitively determine whether z26 is correct or not.

 

EDIT3: And finally, I wanted to say, keep the test ROMs and reports coming. This thread has perhaps done more for BS issues in Stella than all the reports I've received in the past 2-3 years on the subject.

Edited May 3, 2009 by stephena

[Wickeycolumbus]

3F also seems to be giving me trouble.

3F.zip

[+stephena]

3F also seems to be giving me trouble.

OK, this one is also puzzling. It doesn't seem to work in any emulator I try, but it does work on the KrokCart. Or at least I think it's working. I'm getting 4 bands of colour from top to bottom: grey/white, light green, darker green, yellowish. Is this what I'm supposed to be seeing?

 

EDIT: Interestingly enough, if I force the ROM to 3E format, it does show 4 bands of colour (although not the colours mentioned above). Really weird ...

Edited May 4, 2009 by stephena

[+stephena]

3F also seems to be giving me trouble.

OK, I've looked into this, and it seems to be a problem with documentation. The Stella docs indicate that any write to addresses 0x00 - 0x3f will switch banks. And that's exactly what Stella was doing. However, the instruction 'STA VBLANK' is such an instruction, which was (possibly) erroneously causing a bankswitch.

 

So now I don't know what's going on. Is the documentation correct, and Stella should do a bankswitch on 'STA VBLANK'? Or is it just an error in the docs?? In any event, if I only do a bankswitch on 'STA $3F', then the test ROM works fine (but doesn't give exactly the same colours, which I'm looking into right now).

 

EDIT: I should also mention that the colours I'm getting now are the same as when forcing '3E' scheme. This makes sense, as 3E is basically 3F with extra RAM, and if you never enable the RAM, then they're essentially doing the same thing.

Edited May 4, 2009 by stephena

[GroovyBee]

You need to define TIA_BASE_ADDRESS before you include vcs.h. I haven't tested it with that modification to your source tho.

[+stephena]

You need to define TIA_BASE_ADDRESS before you include vcs.h. I haven't tested it with that modification to your source tho.

I was thinking the same thing, as the 'STA VBLANK' in the disassembly should have been 'STA VBLANK.40'. Doing as you suggest fixes the issue. However, there's now another problem. The original ROM worked on the KrokCart, so that means it's not entirely accurate with 3F (and 3E) bankswitching.

[Wickeycolumbus]

This is probably unrelated to the issue, but when you select the BS mode in Stella, 3F comes up as '3F (512K Tigervision)'. Isn't 3F 8K only? I thought it was 3E that can be expanded to 512K.

[Wickeycolumbus]

You need to define TIA_BASE_ADDRESS before you include vcs.h. I haven't tested it with that modification to your source tho.

 

I just tried it like that, and it worked Thanks a lot.

 

Included in this .zip are:

 

F0 (Mega Boy)

F8

FA + RAM

0840 EconoBanking

F8SC

UA Limited

F6

F6SC

F4

128K SuperBanking

EFSC

EF

E7

F4SC

E0

3F

256K SuperBanking

Bankswitching_5.zip

[+stephena]

This is probably unrelated to the issue, but when you select the BS mode in Stella, 3F comes up as '3F (512K Tigervision)'. Isn't 3F 8K only? I thought it was 3E that can be expanded to 512K.

You're right in that basically all available 3F ROMs are 8K in size. However, like 3E, the scheme is defined for up to 512K (and Stella will handle such files), so the label is appropriate.

 

I've checked with the programmer of the KrokCart and also on the Stella mailing list, and it seems the problem was as mentioned in post #43 above. Writes to any address in the range $00 - $3F will trigger bankswitching, and your first call to 'STA VBLANK' (which in hex is 'STA $1') will switch to bank 1. This is exactly what should happen. If you define TIA_BASE_ADDRESS to $40 before you include vcs.h, the 'STA VBLANK' will become 'STA VBLANK.40' (or 'STA $41), and everything will work fine.

 

I'm still working on the E0 issue. I suspect this one is more involved, and seems to be a problem in the CPU emulation itself (vs the bankswitching code).

 

EDIT: WRT the 3F/3E issue, this means that the KrokCart will sometimes run ROMs that technically would fail on a real 3F/3E cart. I've confirmed this with the KrokCart developer, so you should probably keep this in mind if you're using a KrokCart for 3F/3E development.

Edited May 5, 2009 by stephena

[+stephena]

You need to define TIA_BASE_ADDRESS before you include vcs.h. I haven't tested it with that modification to your source tho.

 

I just tried it like that, and it worked Thanks a lot.

 

Included in this .zip are:

 

F0 (Mega Boy)

F8

FA + RAM

0840 EconoBanking

F8SC

UA Limited

F6

F6SC

F4

128K SuperBanking

EFSC

EF

E7

F4SC

E0

3F

256K SuperBanking

I can confirm (at least for now) that your E0 test ROM is fine. It works in two other emulators I tried, but not in Stella, so I suspect it's a Stella problem. However, since it doesn't work with the KrokCart, I can't test it on a real system. Tracking down the bug may take some time. What's really weird is that the ROM runs differently each time I start Stella. This makes me think it's related to randomization of memory somewhere (RIOT, TIA, etc).

[GroovyBee]

I don't think the E0 example is correct. From what I can see you are mapping a slice into $F000. Thats where you are currently executing code from! When the rts in the newly mapped in slice is executed the return address is in the new slice and not the old one. Try changing the "rorg $F000" to "rorg $FC00" just before the label Slice7 and see what happens.

[+stephena]

I don't think the E0 example is correct. From what I can see you are mapping a slice into $F000. Thats where you are currently executing code from! When the rts in the newly mapped in slice is executed the return address is in the new slice and not the old one. Try changing the "rorg $F000" to "rorg $FC00" just before the label Slice7 and see what happens.

This could be related to the issue at hand. After tracing the code in Stella and other emulators, the differences seem to be after the RTS instruction executes. In Stella, running the ROM multiple times results in different values for the program counter after RTS completes.

 

EDIT: Confirmed that making this change allows the ROM to run correctly in Stella. If this is the correct functionality, I'm just wondering why it even worked at all in the other emulators. And it would be interesting to see what would happen on a real system.

Edited May 5, 2009 by stephena