ralphb
-
Content Count
828 -
Joined
-
Last visited
-
Days Won
1
Posts posted by ralphb
-
-
I always wondered ... When I plug in a pristine cartridge board into the TI 99, and then remove it, the connectors on the cart feel greasy or oily.
Is this just gunk, or is the cartridge port "greased" to make insertion of carts easier? How would that even work?
If the "grease" is insulating, wouldn't that prevent the cart from connecting to the bus? And if it is conducting, well, wouldn't that short everything?
-
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.
-
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.
-
8
-
-
Here's an improved bank test that (1) also checks the correct switch order and (2) displays ERROR permanently if an error occurred at one point in time. The latter is useful for unattended long-time checks.
-
1
-
-
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.
-
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.
-
Careful, Matt! With still so many people waiting for their cart, you may trigger cart envy outrage.
-
1
-
-
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.
-
That's some bad timing, Omega, as I was to post an update this weekend, with more information about that cap.
The "rewire fix" you did will work on some systems, but on most systems it breaks bank switching and image selection completely.
My latest recommendation is to simply remove the capacitor, on all board revisions -- this fixes the disk issues, and should work on all TI consoles. In fact, I've been building all my latest carts without cap.
-
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.
-
You have the SRAM OE* connected to GND ... Wouldn't OE* low and WE* low at the same time be undefined?
-
1
-
-
As for the file names, I believe in the KISS rule. I get the 32k denomination, but the other "codes" just seem to confuse, especially for what's supposed to already be formatted for use with the FR99.
Well, I was thinking of something simple, like attaching "_32k" for programs that require 32K, and "_conv" or "_converted" for converted programs.
Another reason I would like to flag converted programs is that some conversions alter the original program is more or less subtle ways. GROM conversions, for example, suddenly have an additional menu step to go through. "_conv" would indicate that the program might not show 100% of the original behavior.
And I like the C, D, G, 3, 8, 9 convention, as that indicates if the image is split, does contain GROMs, or is inverted. This isn't required as long as a file is known to be good for the FlashROM, but if you get a file out of context you won't know if it works or not.
-
1
-
-
It's been a while I looked at this thread and ... Holy cow, you guys are amazing!
I cannot believe what kind of programs you were able to convert to ROM cartridge format! 
Once the dust settles, I would have two suggestions, though:
1. Mark the filename if the program requires 32K (I think someone mentioned this before)
There are so many people without 32K who would need this information.
2. Mark the filename if the program was converted from a different, original format (such as GROM, disk image, side port cartridge, etc.)
This will keep historians happy and make people aware of what the original experience was.
I'd do (1), but I cannot do (2) when I haven't created the image.
-
2
-
-
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.
-
1
-
-
Yeah, I heard those complaints before ...
A name like that would suggest that those images are only good for the FlashROM, when, in fact, they are unmodified dumps that simply have been joined.But I get your points, so sure, go ahead. I don't have access, though.
-
How's that for starters? (TI Vision prototype)
With a Raspi? Not bad.
I can offer an Arduino for my Frankenflash (working, BTW):
-
2
-
-
I'm so sorry, Shane, about this confusion ... I can feel your pain.
Yeah, behind the scenes we're still discussing about that capacitor: where should it be connected, what value should it have, do you even need it?
My personal opinion right now is that it should simply be removed. Several people have confirmed that this works. Also note that the original design with the wrongly placed capacitor made the board work, but messed with the disk -- if you rewire it properly then it's just the other way around.
But still, removing the cap is against years of experience with the multi-carts, so I was hesitant to suggest it officially just yet.
I'll have another go at the problem this weekend. (Would've liked to do this earlier, but I lost two weeks due to a hospital stay.)
Anyway, thanks for your report, and have fun with your carts now!
-
3
-
-
May I ask how you programmed the 8515? Most solutions presume an ISP setup yet there is no header on the PCB.
I didn't want to clutter the board any further, as I figured reprogrammig will be an extremely rare thing.
Personally I'm using a USB programmer for €20 and a breadboard (the blue wires in the setup are not required for programming).
BTW, the entire development of the FlashROM was done without a development board or debugging capabilities. Instead, I wrote the code so that compiling with gcc instead of avr-gcc will yield a plain executable file that simulates the menu generation and yields a BIN file that can be tested in MESS.
-
4
-
-
Modified in all banks. I can't test it myself on real hardware, but JS99er only shows one menu item with the modified version, which is what I expect.
Sorry, I was just checking.
Besides, the cart looks at the first bank only.Could you post the image (or send it to me)? Now I'm really curious ...
-
I also have a technical question about the FlashROM 99. Since it's obvious that the cartridge can load all the different programs residing on the cartridge, I'm wondering, could a secondary program installed on the cartridge use the same protocols to load other individual files?
You mean "load into the cartridge"? Yes, with a modified firmware that would be possible. Loading arbitrary files is almost as easy as bank switching. In fact, it's exactly the same mechanism
, so bank switching and file loading may interfere with each other.That's why loading an image is a one-shot operation; after loading is complete, it's only bank switching. But you could go back into "file listening" mode.
Loading can be done from assembly, but AFAIK you cannot provide new BASIC subprograms without GROMs (right?). This will make it difficult to provide a "master control program" that manages loading images.
In any case, you need to reprogram the 8515.
-
With my Internet Browser, that has three menu items in the cartridge header so appears as three items in the Flash ROM menu. I've been trying to do a modified version for Omega where only one menu item is displayed, so I modified the linked list in the cartridge header and for the first menu item, changed the 'link to next program' field to >0000 to terminate the list, and set the 'number of programs' field to >01. In JS99er this works and only one menu item is displayed, but Omega is still seeing all three menu items in the Flash ROM menu. Is it still managing to find all three menu items even though the linked list in the cartridge header is terminated after the first item?
Well, no, I follow the chain of linked menu items, and stop at >0000, just like the TI menu does. Are you sure that your modified image does show three items? What do you see in the TI menu if you press FCTN-=? Have you modified the menu in all banks?
The "number of programs" byte is ignored, as most sources indicate that this is "optional".
-
you could also make the board project at OshPark publicly visible
Sure, go ahead, but please update the project to use board revision 2!
-
I got my card yesterday. Not having much luck with it so far. I got Defender to run, but any other carts don't load or are corrupted after loading ... I have a new, smaller SD card on the way, though, just in case it is an SD card issue.
Sorry to hear that.
Your SD seems to work just fine. If that were the issue you'd get the Red Blinking of Death (or whatever your color of LED is).
The first thing to do is try the Bank Test: banktest.bin
Then we'll see from there. (My first guess is that you're using bad images -- see here for a collection of good ones.)
-
There's a new, fixed Revision 2 of the PCB layout on GitHub now where the wiring has been swapped.
I also created a page that describes how existing Revision 1 boards can be fixed, i.e., converted to Revision 2 boards. Same as described here.
Finally, the homepage has been updated.
-
5
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Greasy cartridge port?
in TI-99/4A Computers
Posted
Thanks, I'll do a clean-up at some point in time ... So there is oil in there, but it's supposed to not coat the connector? Or should the slot pins squeeze out any remaining oil?