Kroko

I think John did not want to make a new design, but use what already existed. I also can't think of any good reason to still use a PLD in a new design.

Why would that be necessary and how do you plan to make sure it powers up in bank 0 ? Would it be possible to make it work in case it starts in one of the other banks, too ?

Exactly

Now I am confused again... but nevermind. I think if you tell people which components they have to buy and if it works, thats fine.

Yes, definitely. Looks great now. Even I can understand it So the F8 PLD can do both standard F8 and F8SC, dependent on what board it is used with ? If yes, it would be nice if you write that in the PLDs description.

People should find a PLD which fits to the SARA boards in the store then. They can find the boards, the SARA chip, but no PLD that seems to fit. At least if I click on the PLDs, they look like the standard PLDs that do not support SARA RAM.

Don't worry. Maybe someone wants a few hacks to be played on the real thing. Like e.g. my dring controller hack of Sprintmaster. And maybe you should advertize using a list of games which require SC, so those who are not deep into Atari programming get a better understanding of your offer. Thanks Thomas, that is a great idea. I think you should really add the "newbies guide to SARA": When I was browsing through you store, I could not really figure out which parts are needed to make a complete SARA board. Does the SARA chip contain the bankswitching logic as well ? I think it would also make sense to show people a bit better what they do exactly need if they want to make a SARA game. And there have been F8, F6 and F4 games with superchip. Is this only for F8 or also for the other schemes ? So, ... which parts do I need to make an F8 SC game. Do I also need one of your PLDs ? Where are the F8SC PLDs ? What if I wanted to make a F6 game with the SARA chip. Would that work as well ? And how about F4 ? Maybe all this is 100% clear to other people, but unfortunately not for me ... Armin

Well, I had thought this might be the case ...

Please try to download the single DigDug binary to the Krokodile. Then try the Krokodile on the FB2. If DigDug does not run, then the FB2 has an incompatible bus timing (at least incompatible to the Krokodile) Please start the game and look if the playfield is constructed correctly. You can't really see if it works from the title screen ...

The Multicarts have a special bankswitching mode that is not supported by the current emulators. It combines a single switch 3F scheme with one other bs scheme. The multicart images will only work on the Krokodile cart until the Emulator authors decide to support the Krokodiles Multicart Bankswitching mode. The issue with the 7800 is the startup sequence. It does access the Krokodiles multicart bankswitching hotspot. Thats why the Krokodile immediately switches to game 0. There was no way to work around this without making the second Krokodile run incompatible to the first run ( which I didn't want to do) If the multicart does always switch back to the menu, then I think its not the same problem as on the 7800. It sounds more like a timing issue. Can you please try DigDug und the FB2 ? If that one works, it can't be the timing ... This happens if the hotspot is accessed by the menu, but the cart does not switch banks (which is the case in all emulators)

Maybe it is because the LINUX version was not available until now. So the "LINUX only" people were not interested in a Krokodile Cart. This will probably change now. And thanks again for spending so much time to enhance the Krokodile Cart

I don't connect the unnecessary pins, like A0, A1, A2 etc. but still, I/O is the most limiting factor on th XC95..XL that I am going to use. I was confused, of course this won't work I also like the idea, but now that I had some contact with this xsvf stuff I am a bit afraid of it. Its not really what I would call "simple". Maybe I am only missing a good teacher I just recorded stuff in iMPACT and downloaded it via the Xilinx xsvf player sample code. But writing XSVF myself may be not that easy ...

Thanks, this is not confusing at all But as you wrote, this approach will still cost me at least one I/O line. What would be possible is to first upload the "programmer" .jed file to the logic chip, then program the flash with this and finaly upload the bankswitcher .jed to the CPLD. This way I would probably not lose resources in the logic chip, but only add programming time. Well, maybe it would take longer than the "direct" JTAG method ... Do you think I could double use NOE and A12 ? Or do you see any problems with this. So I think the final decision would be to either have * programming header, but very quick programming times and a little more bankswitching power and not too much effort to develop the SW to programm it OR * no header, long programming times and a little less flexibility for the logic chip ( 1 line missing) and quite complicated programming SW Hm .... what would you do ?

Why ? the data and adresslines are available at the edge connector. We only need to influence the address lines that are not directly connected to the atari edge connector, or ? The programmer can set the "public" lines and JTAG sets the lines that are only available to the logic chip. EDIT: Ok, we would have to connect the NWE line to the logic chip, which we don't have to do if we have an extra connector, NCE is connected anyway and I am not 100% sure about NOE. spending two additional lines is not nice, i must admit ... maybe I can connect A12 and NOE ... but we would still lose one line

The XC9536XL has a 108-bit shift register, along with some associated logic, to allow any of the 36 I/O pins to be driven high, low, or tri-stated, and to allow the state on those pins to be read back. I have a bookmark at the office for the page where I got my information. The biggest limitation of using the JTAG for in-circuit programming of a flash is that changing any pin requires re-shifting all 108 bits of data. Thus, I highly recommend wiring the /OE and /WE pins directly to the programming connector; this will allow you to shift out the address and data, then pulse /WE, then shift out the next address and data, pulse /WE, etc. Otherwise, it would be necessary to shift out address and data with /WE low, then shift out the same address and data with /WE high, etc. Twice as many shifting operations, ergo twice as slow to perform the programming. I would only use the JTAG method to program the flash chip, if I can get entirely rid of the programming connector. If I need a connector, I would still think the pci connector is a good idea, because there I have everything I need and access is fast and easy. I don't see a good reason to change the connector, or ? I would probably look into this JTAG method, if the Atari edge connector was all I needed. Speed would then be priority 2.

Thanks ! I will have a look

Can you explain that a bit more please. I now know how to programm the logic chip (thanks to your help), but I have no Idea how I could programm a flash chip that is connected to the logic chip. Is it possible to influence the logic chips output pins by sending commands to its jtag interface ? That would be great and I could get rid of the second edge connector, or ? Would be great if you send me documents about this Or tell me where to find them ... And you are not worried, that we could accidentally reprogramm the logic chip, because of noise on the sground pin when the board is plugged into the vcs ? Or that the board could crash the game when programming mode is entered during the game ?

Yes, the logic chip is reprogrammed in circuit, but I am not sure that the flash chip I am using can be reprogrammed in circuit, at least probably not without connecting the complete bus. What Flash chip are you using ?

Hi Steve, The GUI looks really great ! What programming language did you use ?

I think is not only "almost" unplayable, it is absolutely unplayable Well, I am not a hardcore gamer ....

Thanks for clearing this up (and thanks for producing such a great bit of kit). I don't think I will risk programming directly on the 2600 for now... Chris Maybe you have a cheap junior where you may want to take the risk

Yes, true. Andrew did it more than 1000 times without problems. In my opinion, the only setup that does cause trouble is, if vcs power is off and extra power connected ...

I don't see any ambiguity. The power source should only be plugged in when you're programming the cart. The power source should NEVER be plugged in while the cart is inserted into the 2600. Instead, the cart will run off of the power provided by the 2600. The cart should NEVER be programmed while it's inserted into the 2600 for the same reason it shouldn't be plugged in. jbanes is absolutely right You should only use the cart in two modes: 1. Prog-Mode: Cart is NOT plugged into your Atari and is connected to the serial cable and its power supply 2. Play-Mode: The Cart is not connected to its external power supply. You may connect it to the serial cable, but picture quality may be degraded What you should NEVER do (if you love your console) is to reprogramm the cart while it is plugged into the 2600 with VCS power OFF, but external power supply connected.

Hi ! these two pages should answer most of your questions: http://www.atariage.com/software_page.html...areLabelID=2716 http://www.arminvogl.de/KrokodileCartridge/

There is no battery. It is using flash memory. It does not need to be charged. You only need to connect the power supply when you are programming it. It then keeps its content until you reprogram it. A multicart rom is just like any other rom. The difference is only that it contains a menu system to choose from the different games. You could say its one big rom with built in menu system You can put any rom file on the quick pick buttons by right clicking the button. It does not matter if you put a standalone ROM or a multicart ROM on the quickpick button. You download the rom by left-clicking the button. The software does not support cartridge erasing as a standalone operation. You simply replace the content when you write to it the next time. If you really want to erase it for some reason, make a file which contains 512K of rubbish and download it.