Flash ROM Cart

[+jedimatt42]

I believe Ralph said he tried a file per bank format the same as what is inside those rpks, but it created a slow user experience.

 

I haven't considered these yet another format, a s they are the same as you would burn into an ubergrom or red board's rom section, just limited to 32k instead of 512k.

 

The fun thing is, it is convenient to pack individual EA5 programs into this too, and it doesn't require the expertise that went into Gazoo's multicart offerings.

 

-M@

[+OLD CS1]

Make sure I understand this correctly: I can just clip the capacitor off my pre-assembled board?

[+arcadeshopper]

directory is now Cartridges\FlashROM99

 

Greg

[+arcadeshopper]

also uploaded an atariage.zip with all the conversions from the other thread to that directory

[00WReX]

Make sure I understand this correctly: I can just clip the capacitor off my pre-assembled board?

 

I would say that if you board is working perfectly fine then you do not need to do anything.

If you are having issues / niggles then I don't think it hurts to remove it completely...that appears to be what Ralph is indicating.

He did also indicate he will be doing some more testing. So maybe best if he gives the final call on this.

 

My FlashROM's were almost not usable until I removed the 1nf capacitor...but my experience is not like others, who do not seem to have had any issues with the 1nf in-place.

 

Here is one of my boards with the 1nf, and then with it removed. I did not cut any tracks on the underside for the initial mod.

 

Cheers,

Shane

Edited July 3, 2016 by 00WReX

[ralphb]

Make sure I understand this correctly: I can just clip the capacitor off my pre-assembled board?

 

Your board was an early one, where I placed the cap incorrectly (according to canon) so it didn't hit the board. It's almost like it is already clipped off. But ...

 

I would say that if you board is working perfectly fine then you do not need to do anything.

If you are having issues / niggles then I don't think it hurts to remove it completely...that appears to be what Ralph is indicating.

 

Absolutely!

 

If you don't experience any issues, just wait and see what the final recommendation will be.

[dphirschler]

Been meaning to comment on this since I got my Flashrom cart. The little spinning dots animation is a nice touch, and obviously required some effort to pull off so well. So I want to let you know, Ralf, that I think it looks terrific and is useful info (file is loading) too. Thanks for your attention to detail on the software side.

 

Darryl

[+MacRorie]

Hello,

 

I am hoping someone can help me get past a hurdle. I have flashed the ATMEGA and it sort of works. If I load backtest.bin AND ONLY THAT all four banks check out (well, after booting a bit to get all 4 banks to show up). However, if I put any other images on there, it just goes to a loading screen and locks up the TI.

 

Okay, so I clipped the 1nF cap off. I had left it on thinking it was not a worry. NOW, I can load the banktest.bin and I get all four banks OK at once. Also, if I select any other file, I get a loading animation and then it goes to a blank blue screen and . . .locks up.

 

If I put no SD Card in there, it blinks about 1/sec (like it should).

 

I have tried recompiling everything on a windows machine (as opposed to the Mac I was using) and I get stuck trying to compile the .hex file. I get the following:

 

Any help would be appreciated. Thanks

[ralphb]

First of all, what kind of images are you using? Have you tried those? Some games need 32K, do you have a PEB/nanoPEB?

 

You're right about the cap. And here's the "official" HEX file, but if the banktest is working, your 8515 should be fine.

 

flashrom99_100.zip

 

[+MacRorie]

First of all, what kind of images are you using? Have you tried those? Some games need 32K, do you have a PEB/nanoPEB?

 

You're right about the cap. And here's the "official" HEX file, but if the banktest is working, your 8515 should be fine.

 

flashrom99_100.zip

 

 

Thanks. DO you know why the file would not compile? I would love to fix that so if/when a new version comes out I can update easily.

 

Yes, I tried some of those images pulled from the threads themselves, so I am pretty sure they are good. I will keep at it.

[ralphb]

Not sure about the compilation issue. I'm using avr-gcc 4.8.2, maybe your version 4.3.3 does a poor job in optimization? And how large (number of lines) is your menu.c?

 

Here's an improved banktest: BANKTESTv2.BIN

 

Please run this first, and then check again that other thread. Most images linked at the top require the 32K memory expansion -- do you have one on your system? If not try, try the classic carts in here, most should work without 32K.

 

 

[+MacRorie]

Not sure about the compilation issue. I'm using avr-gcc 4.8.2, maybe your version 4.3.3 does a poor job in optimization? And how large (number of lines) is your menu.c?

 

Here's an improved banktest: BANKTESTv2.BIN

 

Please run this first, and then check again that other thread. Most images linked at the top require the 32K memory expansion -- do you have one on your system? If not try, try the classic carts in here, most should work without 32K.

 

 

 

 

Cool. Will play with the new BANKTEST.

 

So, I fixed the problem. (I am presuming).

First: I installed a newer version of avr-gcc. This allowed me to make the flashrom.hex without a problem

Second: I got a(n?) USBasp and used avrdude with that.

Worked GREAT. All images, no problems

 

Exception: the GitHub file says fuses should be "In the end, the lower, higher, and extended fuse bytes should have values E4, FF, and D9, respectively." But, avrdude reports E4, D9, FF (in the same order). I could change the fuse bits to what you have in GitHub, but the ATMEGA gets VERY cranky after that (i.e., gets warm, refuses to be recognized, etc etc) until I put it back.

 

So, ANYHOO, thanks for the help. I am now good to go. I also now have some extra flashcarts since I had to get a minimum number of PCBs!

[+jedimatt42]

Multiple flashrom carts is awesome!

 

Why change sdcards, when you can still keep that cartridge swapping feeling!

 

#1 - favorite utils,

#2 - favorite games,

#3 - all of everything else

 

-M@

[ralphb]

Careful, Matt! With still so many people waiting for their cart, you may trigger cart envy outrage.

[Asmusr]

Ralph, is the mechanism for loading an image from the TI side documented anywhere?

[ralphb]

There's a high-level description on the homepage:

 

The 377 also buffers the serial one-way communication from the TI 99 to the FlashROM 99 that relays the image selection. The >6800 address line transmits the bit data and the >7000 address line transmits the clock. Currently, 9 bytes of data are transferred, containing the filename of the selected image.

 

For details have a look at the sources, starting at label "loader", the actual entry point is "send". The received side is here, function "receiveData".

 

The TI side sends the filename while running from scratchpad, as we need to make room for the image being loaded. More specifically, while the image loads, the cart is offline so that the 8515 can fill the SRAM.

 

When the TI sees that >6000 contains valid image data, meaning that loading completed and the cart is back online, it branches to the starting address of the selection that was determined while scanning the SD card.

 

Not sure if that explains what you're looking for, so please ask if you want to know something specific.

 

[Asmusr]

Thanks, I was wondering if it was possible to switch to another image from the TI side after one image has already been loaded?

[ralphb]

Not with the present code, because the "listener" in the 8515 goes to sleep after loading an image. But you could simply go back to listening mode, and then you'd have that feature, and with almost zero effort.

 

There's a catch, though: Some programs are not very specific when switching banks, but use arbitrary values in the upper bits, e.g., CLR >6AA2 instead of >6002 (IIRC, Pacman does something like this). This fact is already an issue when you load a 16K program into the 32K RAM -- the original cart ignored A13, but the FlashROM doesn't, which is why I mirror smaller images into unused banks.

 

But because of those "ill-programmed" images, the listener could never be sure if writing to >6800 is meant to transmit image selection data, or to switch banks.

 

If you know that you only use "nice" programs, however, then such a modification would work.

[Asmusr]

I know that the Atarisoft games are using all kind of crazy addresses for changing banks, so I guess there would have to be a key for going back to listening mode.

[ralphb]

I'd like to give an update on the "disk issue" and the correct placement of the capacitor for different board revisions.

Background

Both 1 nF capacitor and 68 Ohm resistor originate from the bank switching circuitry found in Atarisoft cartridges. Since then, that circuit has been used countless times, e.g., in all of the multicarts. That's where I borrowed the design from.

Bank switching is done by writing to specific addresses in cartridge space. For each such write, some address bits are stored in a register such as the 377, 378, or 379. Until the next write happens, the stored value is used for selecting the right bank in the RAM or ROM chip.

When data on the bus is to be written, the TI 99 will put the WE* signal LOW as long as data and address are valid. Thus, whenever WE* goes LOW, and the address on the bus is in cartridge space, the register should latch the address.

The addressing of cartridge space is indicated by the ROMS* signal, so the bank switching circuitry connects ROMS* to the data enable pin E* of the 37x. Without ROMS* going LOW, the 37x will keep its current value indefinitely. The WE* signal is connected to the clock pin of the 37x, but that's not a perfect fit: The address is valid when WE* is LOW, but the 37x latches when WE* goes from LOW to HIGH. In other words, the 37x stores the address just when it is about to become invalid again.

Because of the muxer/demuxer translating the 16 bit data from the CPU to 8 bit data on the bus, each CPU write actually comprises two consecutive writes of one byte each on the bus. Each byte will cause the 377 to latch the address, but only the second write determines the final value of the register.

When you look at the signals with an oscilloscope you can see that the time window to latch the address during the second write is actually quite short:

The graph shows WE* and ROMS*. The latching of the address must happen before ROMS* goes HIGH, but it cannot start before WE* goes from LOW to HIGH. This leaves a window of around 80 ns.

Now the engineers back in the day apparently thought that 80 ns is not enough to latch the address reliably. They thus added a capacitor and a resistor to the register in order to delay the WE* signal. Strictly speaking, the signal is not delayed, but mangled: logical HIGH corresponds to a certain voltage level that is now reached later.

The second WE* transition is delayed until ROMS* is HIGH again, and the 37x won't read its input. This means that the address is latched during the first byte write, where the window to latch the address is much longer: the muxer keeps most address lines stable between the first and the second write.

TL;DR

For some reason not fully understood yet, the delay of the WE* signal causes issues with the FlashROM 99. On the other hand, there's consensus that latching by the second byte write is safe.

Thus, the recommendation is to remove the 1 nF capacitor. The 68 Ohm resistor should stay in place, although it could be replaced by a wire.

This applies to all current board revisions v1, v1a, and v2. If you applied the "disk fix" by cutting one trace and adding a wire, you can leave those in place, as they won't have any effect without capacitor. But do remove the capacitor.

If you have a working FlashROM with capacitor, you can of course also keep the capacitor. Keep in mind, though, the your cart may not work in a different TI 99 system!

My thanks go to Jim, Jon, Stuart, Michael Becker, and my real-life friend KP, for discussing the bank switch with me.

[dvallet]

Hello, i'll build my flashrom within a couple of weeks. I'll be interested in a case for this card.

Do you know if there's a stl file somewhere to protect this card ; to 3d print it.

Thanks

[ralphb]

Do you know if there's a stl file somewhere to protect this card ; to 3d print it.

 

No, I don't think there's an open source solution for that yet. Here's someone who sells 3d-printed cart shells on ebay, maybe you can contact him.

Edited July 11, 2016 by ralphb

[+MacRorie]

Folks,

 

I have some extra kits. If you want all the parts and solder it together yourself, $30+shipping. If you want it soldered together & tested, add $10. This, of course, includes a programmed 8515.

 

PM me if interested. I live in the United States (California)

[+jedimatt42]

 

No, I don't think there's an open source solution for that yet. Here's someone who sells 3d-printed cart shells on ebay, maybe you can contact him.

 

Note: I just received one of these shells, and realized that it doesn't fit, because I socketted my SRAM. Easy enough to fix on my end, by removing the socket from the board... But I just didn't think about it with these shells. When I assembled my boards, I chose to socket the SRAM because a normal TI shell is taller at that point already and I imagined any shell would be.

 

-M@

[c0d3m4st4]

 

Note: I just received one of these shells, and realized that it doesn't fit, because I socketted my SRAM. Easy enough to fix on my end, by removing the socket from the board... But I just didn't think about it with these shells. When I assembled my boards, I chose to socket the SRAM because a normal TI shell is taller at that point already and I imagined any shell would be.

 

-M@

 

ah... sorry to hear that

 

Didn't think of the posibility of people adding sockets to any other chip apart from the included one... so did it just to make sure current PCB with included components would fit.

 

Thanks for the note. Will add it to my listing.

 

Luckily it was an easy fix.