Search the Community

I have been working on my first 2600 game ROM and have already supported 4 x 4 Kbyte banks using the Atari F6 mapper with a Pixels Past ATARI Banking PCB and a PLC. When I try to change up from F6 to F4 banking, I re-flash the PLC but my ROM file doesn't work on real hardware or the 2600+ (though it runs on Stella emulator with F4 settings). My EPROM chips are 32Kbyte, so using F6 banking and duplicating my 16 KByte ROM feels like I'm throwing away 16K. Any ideas of what I am doing wrong with the PLC or pixels past PCB?

What is temp7's purpose when bankswitching? .L08 ; goto _bank2 bank2 sta temp7 lda #>(._bank2-1) pha lda #<(._bank2-1) pha lda temp7 pha txa pha ldx #2 jmp BS_jsr BS_jsr lda bankswitch_hotspot-1,x pla tax pla rts It looks to me like it's just used to push what's currently in the accumulator to the stack, and that you also push x to the stack, is that just so you can continue your code in another bank? There's no way to ldx or lda (without also assigning it to a variable) in bB, and even if there where, wouldn't it be faster to just sta temp1 stx temp2 and load them after the bankswitching lda temp1 ldx temp2 If I don't need to keep what's in a and x would this work lda #>(._bank2-1) pha lda #<(._bank2-1) pha ldx #2 lda bankswitch_hotspot-1,x rts Just tried it and I got error: Unknown Mnemonic 'bankswitch_hotspot-1,x'. Is bankswitch_hotspot a table? I can't find it anywhere.

Hi all, I have created the following post yesterday: Someone just told me that I should have created it in this subforum. I don't want to duplicate the post but I have also not found how to move the post here. Any suggestions? Also, if you can comment on the bankswitch schemes you currently use in your programs and any experience you can share on how to implement a bankswitch controller on a 8bit Microchip PIC will be much appreciated. Cheers!

Hi all! Last month I saw the following ad on eBay: I thought the appeal of this kit for homebrew development was very limited: No bankswitching/mapper (only 2K games or 4K games with further modifications on the board) It required messing around with UV lamps, programmers, etc Required some knowledge of electronics Buying the parts separately would probably be less expensive Not possible to ship as a product to customers It would be probably easier and faster to use one of the existing USB/SD carts to test on a real hardware. This did make me think though that I had never seen a development kit for the 2600 which would allow homebrewers without knowledge of electronics to self publish their games. If a mapper is required, then that knowledge need goes up real fast. As in Europe we have very limited offers of good homebrew games available (most of them are from the USA and shipping quickly becomes a problem), I thought about making this my next project. The idea is to have blank carts (populated with all required components but without any game image in them) and a simple to use cable and PC software which would allow the user to create a cart ready to be shipped to customers as well as test games in a real atari. Is this something that would interest the homebrew community? Here are some requirements I have come up with: The final product must cost under 10€ (populated cart PCB) All components must be easy to find. Preference should be given to components still in production Must be usable by people with no experience in electronics No soldering Must support mappers (the ones used by batari Basic at a minimum, as a lot of people seem to use bB) No physical alterations to select the desired mapper (or no mapper) Must fit in a standard Atari cartridge case Components should be SMD to keep production cost as low as possible All comments will be appreciated!! Cheers.

Hi everybody, Talking to a homebrewer here at AtariAge the topic of large ROMs (128KB+) came up. One part of the bankswitching schemes which always put me off is the amount of memory used by routing overhead and the hotspots. Yes, I know that in the great scheme of things that may end up being negligible, but the whole point of using bankswiting is to have more memory available and large ROMs require a larger number of hotspots So I was thinking if a trade off with RAM could be acceptable, why not have a hotspot in RAM and bankswitch according to the value saved in that hotspot. The idea is that a write to that specific address would trigger the bankswitch. A read to that address would not do anything as the bank is already selected. Using a full byte in RAM, the cart could have 1MB of ROM available (256 * 4096). Coding would be as simple as loading the accumulator with the desired bank number and storing it into the hotspot address in RAM. With one additional RAM byte, the BS routine could route a call to 256 distinct subroutines in the new bank (see diagram below). And a relatively simple one-size-fits-all solution could be created by using another RAM byte and a single dispatch sub-routine: Does anything like this exist already? Would it make sense to use it for very large ROMs?

I suppose everyone who ever had to use standard Atari bankswitching sooner or later developed some kind of pattern how to use it. And there are numerous ways to do it. But most of have to be used very carefully and are often not easy to maintain. So I came up with the idea of using macros to make things as convenient as possible. The price for that convenience are more CPU cycles and destroyed registers and flags. So here they are: BANK_SIZE = $1000 ; Use at the start of each bank, required by JMP_LBL macro MAC START_BANK ; bank number BANK_NUM SET {1} ; this is not related to bankswitching, but nevertheless useful BANK_ORG SET $8000 + BANK_NUM*BANK_SIZE BANK_RORG SET $1000 + BANK_NUM*BANK_SIZE*2 SEG code ORG BANK_ORG, $55 RORG BANK_RORG ECHO " start of bank", [BANK_NUM]d, ", ORG", BANK_ORG, ", RORG", BANK_RORG ENDM ; Insert code for executing the bankswitch, ; should be put at the very end of each bank, right before the hotspots MAC SWITCH_BANK ORG BANK_ORG + $ff4 - BANKSWITCH_SIZE RORG BANK_RORG + $ff4 - BANKSWITCH_SIZE, "before bankswitching code" SwitchBank = (. & $fff) | $1000 pha txa pha lda BANK0,y ; e.g $fff8 rts BANKSWITCH_SIZE = ((. & $fff) | $1000) - SwitchBank ENDM ; Define a label which can be used by JMP_LBL macro ; Example: ; DEF_LBL Foo MAC DEF_LBL ; address {1} {1}_BANK = BANK_NUM ENDM ; Jump to a label in other or same bank. The assembler will take care if the ; code has to bankswitch or not. ; Example: ; JMP_LBL Foo MAC JMP_LBL ; address IF {1}_BANK != BANK_NUM ; convenience IF ldy #{1}_BANK lda #>({1}-1) ldx #<({1}-1) jmp SwitchBank ; always at the same address in each bank ELSE jmp {1} ENDIF ENDM As of now only JMP is supported, but macros for JSR could be created that way too.

I'm looking into some bankswitching shemes from the hardware level and when I got to the FE banswitching I got into somewhat of a puzzle. In this documentation "http://www.classic-games.com/atari2600/bankswitch.html" you will read that FE uses 2 hotspots "01FE" and "11FE". However, in the stella debugger you can read: FE cartridge, two 4K banks Doesn't support bankswitching with hotspots, but instead watches A13 of called addresses: Bank 0 @ $F000 - $FFFF (A13 = 1) Bank 1 @ $D000 - $DFFF (A13 = 0) This confuses me, does or does not EA use hotspots? And if A13 is used, how does the hardware/cartridge detect this since there is no a13 line on the cartridge. in the end I want my dumping hardware be able to trigger bankswitching on this cartridge. So accurate knowlage is needed.

In trying to come up with a strategy to win back memory for Alex Kidd, I was thinking about stuffing some code in a cartridge, so I can win back some of that 32kb expansion memory. Given that I'm currently already at nearly 16k of executable code (including constants), and that I still need to add a good number of features, I need to find a way to create bank switching software with gcc. What follows is a write-up of my ideas, not everything has been tested, and I'm looking for a sanity check: will this work, am I missing something that could simplify things? 1. Multiple pieces of code at the same location The first thing we need to do when hacking support for banked memory (such as bank switched cartridges) in gcc, is to tell the compiler that specific pieces of code will run from the same physical address space. In the case of a program designed to run from cartridge, this would be 0x6000. By default, gcc will put all executable code into a section called .text, and you can tell the linker to position this code at any location in memory by using command line options (--section-start .text=0x6000), or by creating a bespoke linker script and adding a properly configured SECTIONS section: SECTIONS { . = 0x6000; .text : { *( .text ) } . = 0xa000; .data : { *( .data ) } .bss : { *( .bss ) } } (Note: the above example requires a system with 32k memory expansion installed, since it puts all variables in expanded memory. It also requires a crt0 implementation that copies the initialization values for variables in the .data segment from somewhere in ROM or from disk to 0xa000) Since all code is in the .text segment by default, the linker will just start filling up memory with code from 0x6000 onwards, blasting past 0x7fff if the code segment happens to be larger than 8k and in the process creating a useless image for our purposes. At the very least, we can define our memory layout in the linker script to get a warning when one of our blocks exceeds the maximum size. We can do this by adding a MEMORY section to the linker script (there's no command line equivalent of this), and changing the SECTIONS section accordingly: MEMORY { cart_rom (rx) : origin=0x6000, length=0x2000; /* cartridge ROM, read-only */ lower_exp (wx) : origin=0x2080, length=0x1F80; /* 8k - 128 bytes */ higher_exp (wx) : origin=0xa000, length=0x6000; scratchpad (wx) : origin=0x8320, length=0x00e0; /* 32b is for workspace */ } SECTIONS { . = >cart_rom; .text : { *( .text ) } . = >higher_exp; .data : { *( .data ) } .bss : { *( .bss ) } } Now, whenever the .text section exceeds 8k, the linker will throw an error and abort. At least we'll know our program is too big to fit in the 8k, but it would be even better if we could stuff more code in other parts of memory. Unfortunately, ld will not do this for us, and we'll need to explicitly assign code to different sections in our source files by adding attributes to the function definitions. Supposing we already have filled our 8k of cartridge ROM, we could for instance decide to put additional functions in the lower 8k of the 32k memory expansion. First we add the section attribute to each function we want to put in the lower memory expansion area: void somefunction(int somearg) __attribute__ ((section ( .moretext ))); void somefunction(int somearg) { // some code } We now have code that will get put in the .moretext section, so we need to tell the linker where to put this code (assuming the same MEMORY section as in the example above): SECTIONS { . = >cart_rom; .text : { *( .text ) } . = >lower_exp; .moretext : { *( .moretext ) } . = >higher_exp; .data : { *( .data ) } .bss : { *( .bss ) } } (Note: again we need to remember that the cart will need to load the contents of section .moretext from somewhere in ROM or from disk and copy it to the lower memory expansion at 0x2080) In theory, we could automate the annotation of functions by doing two compilation passes: one with all code in the standard .text segment to discover the size of each compiled symbol, and one that uses that info to assign individual functions to the two available sections. In practice, I imagine this is doable enough by hand for most programs. Also, on our platform gcc doesn't seem to support calculating the size of individual compiled symbols, so by hand it is. So now we are able to put code into two different physical locations in the TI's memory, but that still doesn't allow for bank switching. As we said at the very beginning, for that we need to tell the linker that two or more sections of code need to target the same memory area. Turns out that we can do this with the OVERLAY command: SECTIONS { OVERLAY >cart_rom : AT 0x0000 { .text { *( .text ) } .moretext { *( .moretext ) AT ALIGN(0x2000)} } OVERLAY >higher_exp : AT ALIGN(0x2000) { .data : { *( .data ) } } .bss : { *( .bss ) } } Running the linker with a script with the above SECTIONS section will give us a binary that contains three 8k banks: .text, .moretext and .data (we ignore .bss, because those are just zero-initialized variables and are taken care of by our crt0 implementation). The code in the first two banks will expect to run at 0x6000, and expects to find the initialized data from the .data section at 0xa000. Given all this, we should be able to generate binaries in the right format to support bank switching. 2. Actually switching banks in code That was the easy part, after all, it didn't require any coding . However, the trickiest part to bank switching is to write code that can cope with switching from one bank to another (and have that new code return). There are a couple of ways to do this (some more cumbersome than others), but they will all share a common requirement: you need to keep a "bank switching stack" (for lack of a better term). That is to say, when code in bank 1 calls a function in bank 2, we need to save the return bank "location" (i.e. what enables "bank 1") somewhere. If that function in bank 2 then in turn calls a function in bank 3, we need to do the same thing without overwriting the first return bank location. This is a recursive problem, so we need a stack. The idea location for the bank switching stack seems to be in scratchpad, since it will be relatively small and that part of memory is always available. By putting the pointers to this stack in a separate section, we can use the linker script to put it there (or wherever else is convenient). The management of the stack needs to be done right before calling a function in another bank, and right before returning to the calling bank at the end of a function. On a select number of platforms, GCC supports so-called 'far' and 'near' pointers and/or function attributes, which could be used to implement two different function prologues/epilogues depending on the type of function call that needs to be done. Unfortunately, the tms9900 platform implementation does not support these attributes. GCC also has support for instrumenting each function call and return via the -finstrument-functions command line option. You need to implement your prologue and epilogue code in the following two functions somewhere in your code: void __cyg_profile_func_enter (void *, void *) __attribute__((no_instrument_function)); void __cyg_profile_func_exit (void *, void *) __attribute__((no_instrument_function)); However, the call to and return from __cyg_profile_func_enter happens /before/ the call to the actual function, so it would take some serious wrestling with the C call stack to transparently implement bank switching in these functions. Our last option is to instrument individual functions and function calls. This is certainly the most cumbersome implementation of all, but it is the only one which does not need embedded support in the compiler implementation itself. Instrumentation of the function call is relatively easy, keeping in mind that all manipulation of the bank switching stack needs to be done from within the calling bank and the absolute last command needs to be the one that triggers the switch to the next bank. The following process could be a usable implementation: The caller (code runs in bank 1): Writes the address and bank location of the intended callee in two registers (e.g. r0 and r1) Invokes the trampoline The trampoline (code runs in scratchpad/expmem): Saves the current bank on the bank switching stack Loads the new bank Makes the call using the info in (e.g.) r0 and r1 The callee (code runs in bank 2): Does stuff Returns to the trampoline The trampoline (code runs in scratchpad/expmem): Loads the original bank (which is popped from the bank switching stack) Returns to the caller Or, in other words, every function call should be structured as follows: caller calls trampoline(), trampoline calls callee, callee returns to trampoline, trampoline returns to caller. Using this type of construct, the trampoline function needs to transparently pass on all arguments to the callee. The easiest way to accomplish this is the have a bespoke trampoline function for each "far" function we're looking to call (with a "far" function being any function that runs from a bank switchable piece of memory). Something like the following example: // Our "far" function, in bank 2 int far_somefunction(int someint) __attribute__ ((section ( .bank2 ))); int far_somefunction(int someint) { // do something return somevalue; } // Our trampoline function, in non bankable memory (e.g. scratchpad) int somefunction(int someint) __attribute__ ((section ( .nonbankable ))); int somefunction(int someint) { // Set to bank 2, and push caller's bank on the stack push_bank(2); // Call far function retval = far_somefunction(someint); // Set caller's bank pop_bank(); return retval; } Using this, we can safely call somefunction() (our trampoline function for far_somefunction()) from anywhere in our code, no matter which bank we're currently in and no matter where the calling code resides in memory. Furthermore, we can also still call far_somefunction() directly from within the same bank if we want to avoid the overhead of the bank switching and the trampoline function. The big downside of course is that we now have one trampoline function for every "far" function we want to call, all with nearly identical function bodies, eating at our available non-bankable memory. Not a big deal if you plan on banking code in big chunks, but problematic if you have lots of little functions that you need to call from everywhere in your program. We could opt to create one generic trampoline function, using variable argument lists and function pointers, if we're really strapped for memory. The downside is that it would create even more overhead for every "far" function call you're looking to make. Even with bespoke trampoline functions for each far function, it's a good idea to limit the number of bank switching calls you need to do, especially if you're writing an action game that needs to retain a high frame rate, given the fairly high overhead the bank switching introduces. If the compiler had support for naked functions (functions without prologue and epilogue), we could probably reduce the overhead to an absolute minimum, similar to what you'd get with pure assembly code, but unfortunately gcc doesn't support that attribute on our target. I think the above is a sound strategy?

A few questions regarding the Intellivision and memory... Are there any games/demos/ROMs available that use cartridge RAM? Is the RAM typically 16 bit? Are there any games/demos/ROMs available that use bankswitching? I know some of the "LTO" games do... are they still using a simple scheme, or is it a more complicated scheme? Are there any non-LTO games that use bankswitching? What is the method used? ... I'm just laying out the next version of my Intellivision game PCB, and adding an option for RAM (and thinking of utilizing the unused half of the ROM chip). Thanks in advance!