512K cart board (PLCC) - Troubleshooting

[+acadiel]

I'm going to try a little crowdsourcing here for the last version of the cart board that Ksurl, Tursi, and myself have been working on.

 

I've attached a zip file with two ExpressPCB files in it - a v4a (which is what the 512K Multicart working version is made from), and a V6d, which makes it a PLCC FEEPROM instead of a DIP EPROM.

 

The V4A board works great - I made around 10 prototype carts with it and an EPROM that Tursi and I worked on (has almost all 8K ROM carts ever made for the TI in it). It works by bank switching 128K x 4 with the help of two switches and Tursi's Multicart program (runs on an unexpanded TI, too!)

 

The V6D board - well, it's been kind of a bear. I've looked at it, Tursi's looked at it, and I don't think we've gotten far in the past year on it. I've flashed multiple AT49F040s on the V6D board with the same binaries that I burned into the 27C040 on the V4A. Verified them multiple times.

 

When I power up the V6D, I can now usually get MULTICART to show up (which means it's doing the right thing and powering up in the last bank), however, I am still getting quite a few lockups. Sometimes, Tursi's MULTICART logo (and "Made by Tursi") show up, and nothing else. Sometimes, I get a lockup and blank screen. Sometimes, I get the MULTICART logo and Made by Tursi as well as a list of around 7 or less programs and then a lockup.

 

Anyone want to take a stab at looking at these files and see what's going on? To me, it seems like a timing issue (something is being taken high/low too fast/slow or possibly data is being delivered too fast/slow).

 

I have a V6D board here, so I'm open to trying whatever with it. The only jumper I have is the one between pins #1-2 of JP2.

 

Also, the AT49F040 has a different pinout in the PLCC32-DIP32 adapter so I can't try the flash chip on a V4A board; however, like I said, it verified multiple times in my 844USB programmer.

 

Thanks, guys!

v6d-v4a.zip

Edited June 12, 2011 by acadiel

[marc.hull]

 

To me, it seems like a timing issue (something is being taken high/low too fast/slow or possibly data is being delivered too fast/slow).

 

Thanks, guys!

 

Do you have any provisions to sync the Atmega to the TI ?

[matthew180]

Do you have any provisions to sync the Atmega to the TI ?

 

In general, memory is asynchronous. At least all the memory in the 99/4A (and most computers.)

[matthew180]

Anyone want to take a stab at looking at these files and see what's going on? To me, it seems like a timing issue (something is being taken high/low too fast/slow or possibly data is being delivered too fast/slow).

 

It's always a timing issue. :-) Timing issues have caused me weeks of troubleshooting and headache. Can you provide the schematic in PDF, or some other format (an image maybe)? I don't have the ExpressPCB software installed or the time to learn it.

[marc.hull]

 

 

In general, memory is asynchronous. At least all the memory in the 99/4A (and most computers.)

 

There appears to be a micro controller on board as well. That is what my question was aimed at. I assume (dangerous word) that it is being used as a paging mechanism and for the GROM emulation ? Correct me if I am wrong here.

[matthew180]

The 99/4A uses the DBIN, *MEMEN, and *WE signals to indicate a memory operation, and the device (usually a RAM, ROM, GROM, etc.) has a specific amount of time to put the data on the bus (or store the data.) That's it. There is no clock driving the data exchange. The CPU sets the signals and expects the data to be available withing a certain amount of time. If the device is slow, the CPU has a READY line that the device can use to add wait states.

 

The microcontroller on their board needs to respond fast enough to have the data available, or use the READY line to add wait states.

[matthew180]

What is the difference between the V4 and V6 boards? Is the V6 board the only one of the two that uses a microcontroller? If so, how fast are you clocking the microcontroller?

[marc.hull]

The 99/4A uses the DBIN, *MEMEN, and *WE signals to indicate a memory operation, and the device (usually a RAM, ROM, GROM, etc.) has a specific amount of time to put the data on the bus (or store the data.) That's it. There is no clock driving the data exchange. The CPU sets the signals and expects the data to be available withing a certain amount of time. If the device is slow, the CPU has a READY line that the device can use to add wait states.

 

The microcontroller on their board needs to respond fast enough to have the data available, or use the READY line to add wait states.

 

Well that makes sense. The ready line may be a bit of an issue though.

[matthew180]

The cartridge port has the READY line available, the GROMs use it. But in general, the board they are working on should be fast enough to not need to use READY to cause wait states.

[marc.hull]

The cartridge port has the READY line available, the GROMs use it. But in general, the board they are working on should be fast enough to not need to use READY to cause wait states.

 

Is the GR same as the READY ?

[matthew180]

Is the GR same as the READY ?

 

Yes.

[matthew180]

Anyone want to take a stab at looking at these files and see what's going on? To me, it seems like a timing issue (something is being taken high/low too fast/slow or possibly data is being delivered too fast/slow).

 

You are not replying fast enough for me, what, do you have a day job or something?

 

This is what I think based on the assumption that the V6 board uses a micorcontroller (uC) and the V4 board does not. If that is the case, then you are subject to clock-domain issues. If not, then this post is a waste of time, but I can't wait.

 

When you have two clock domains, i.e. the 99/4A has a clock, and your uC has a different (and probably faster) clock, then any input signals from the 99/4A have to be synchronized before you can use them. I had to learn this the hard way during the initial F18A development, and you will have a very unstable and sporadic system until you work it out.

 

In the uC you are not really responding to the actual change in an input (#MEMEN, DBIN, #WE, etc.), you are "sampling" them at some rate based on the uC clock. Since the uC clock and 99/4A clock are not in sync, you *will* (not "might", you "will") sample the inputs from the 99/4A during a transition, i.e. while the 99/4A's input is actually going from high to low, or low to high. Until that that input settles it is invalid. This is particularly easy to do if your uC clock is a lot higher than the 99/4A, which I think it is.

 

At the 100MHz that the F18A runs at internally, I sample in the asynchronous inputs from the 99/4A four times each (minimum of 40nS) until I accept the input as a valid '1' or '0'. Usually you sync between clock domains with a double-flip flop that is clocked by the receiving system.

 

When you have a large discrepancy between the two systems, like I do in the F18A, then the back-to-back flip-flop may not be enough, and you need to sample multiple times. To do that, sample the input you need to watch in a loop, and only accept the logic value until you see the same input for a given number of samples. In the FPGA I use a shift register. Pseudo code would be something like:

SAMPLES := 4

one_time_init:
 we := 1
 dbin := 1


while forever

 if dbin == 0
   // Sample for a high level on the input signal
   if sig_dbin == 1
     dbin_cnt += 1

   // A low level resets the counter
   else
     dbin_cnt := 0
   end if

 else
   // Sample for a low level on the input signal
   if sig_dbin == 0
     dbin_cnt += 1
   else
     dbin_cnt := 0
   end if
 end if

 // Check if the signal was stable for X samples
 if dbin_cnt == SAMPLES
   dbin := sig_dbin
   break
 end if
wend

// At this point dbin would be set to the stable level of sig_dbin

 

The dbin variable would follow the sig_dbin, but be delayed by however ever long you needed to count to get a solid sample, which depends on your uC clock speed.

[Willsy]

Anyone want to take a stab at looking at these files and see what's going on? To me, it seems like a timing issue (something is being taken high/low too fast/slow or possibly data is being delivered too fast/slow).

 

You are not replying fast enough for me, what, do you have a day job or something?

 

This is what I think based on the assumption that the V6 board uses a micorcontroller (uC) and the V4 board does not. If that is the case, then you are subject to clock-domain issues. If not, then this post is a waste of time, but I can't wait.

 

When you have two clock domains, i.e. the 99/4A has a clock, and your uC has a different (and probably faster) clock, then any input signals from the 99/4A have to be synchronized before you can use them. I had to learn this the hard way during the initial F18A development, and you will have a very unstable and sporadic system until you work it out.

 

In the uC you are not really responding to the actual change in an input (#MEMEN, DBIN, #WE, etc.), you are "sampling" them at some rate based on the uC clock. Since the uC clock and 99/4A clock are not in sync, you *will* (not "might", you "will") sample the inputs from the 99/4A during a transition, i.e. while the 99/4A's input is actually going from high to low, or low to high. Until that that input settles it is invalid. This is particularly easy to do if your uC clock is a lot higher than the 99/4A, which I think it is.

 

At the 100MHz that the F18A runs at internally, I sample in the asynchronous inputs from the 99/4A four times each (minimum of 40nS) until I accept the input as a valid '1' or '0'. Usually you sync between clock domains with a double-flip flop that is clocked by the receiving system.

 

When you have a large discrepancy between the two systems, like I do in the F18A, then the back-to-back flip-flop may not be enough, and you need to sample multiple times. To do that, sample the input you need to watch in a loop, and only accept the logic value until you see the same input for a given number of samples. In the FPGA I use a shift register. Pseudo code would be something like:

SAMPLES := 4

one_time_init:
 we := 1
 dbin := 1


while forever

 if dbin == 0
   // Sample for a high level on the input signal
   if sig_dbin == 1
     dbin_cnt += 1

   // A low level resets the counter
   else
     dbin_cnt := 0
   end if

 else
   // Sample for a low level on the input signal
   if sig_dbin == 0
     dbin_cnt += 1
   else
     dbin_cnt := 0
   end if
 end if

 // Check if the signal was stable for X samples
 if dbin_cnt == SAMPLES
   dbin := sig_dbin
   break
 end if
wend

// At this point dbin would be set to the stable level of sig_dbin

 

The dbin variable would follow the sig_dbin, but be delayed by however ever long you needed to count to get a solid sample, which depends on your uC clock speed.

 

Sounds sensible to me. Either sample multiple times (sounds rather complex), or, could you not combine the #MEMEN, DBIN, #WE etc lines into some programmable logic (PAL device) and use that to trigger an interrupt on the uC when the condition is right to do so? That way, you'll have the uC running a tight NOP loop, and service the GROM port via the interrupt.

 

Mark

[+acadiel]

Man.. I leave for work this morning and there are no replies, and then come back home from work, and wow....

 

OK. Here's the deal: No Microcontroller on it right now. Just the 49F040 FEEPROM and the 74LS379.

 

Tursi thinks it might be power draw.

 

As soon as I get more time tonight, I'll reply a little more in depth.

[Tursi]

Like Jon says, ignore the microcontroller. That's my GROM emulator, and it actually works just fine (my demonstration cartridge at the Chicago faire last year was using this board with that chip). It's completely distinct from the ROM. It's the ROM-based memory that is having trouble.

[Tursi]

Is the GR same as the READY ?

Yes.

 

(This is tangential to the problem at hand - GROM is not an issue on this board - but!)

 

Not directly, though. GR is gated onto the READY line only during GROM access. GROMs actually pull that line to NOT READY all the time, and are only ready briefly after an operation is completed. The console isolates that line from READY during non-GROM operation.

[marc.hull]

Like Jon says, ignore the microcontroller. That's my GROM emulator, and it actually works just fine (my demonstration cartridge at the Chicago faire last year was using this board with that chip). It's completely distinct from the ROM. It's the ROM-based memory that is having trouble.

 

OK..... Nothing like wild speculation on a moot point.

 

Just out of curiosity. Is the flash memory accessed just like ROM or do you have to use the commands indicated in the data sheet ?

[matthew180]

The commands are used only for erasing and writing. In read-only mode, it acts just like an EPROM.

[marc.hull]

I'm going to try a little crowdsourcing here for the last version of the cart board that Ksurl, Tursi, and myself have been working on.

 

I've attached a zip file with two ExpressPCB files in it - a v4a (which is what the 512K Multicart working version is made from), and a V6d, which makes it a PLCC FEEPROM instead of a DIP EPROM.

 

The V4A board works great - I made around 10 prototype carts with it and an EPROM that Tursi and I worked on (has almost all 8K ROM carts ever made for the TI in it). It works by bank switching 128K x 4 with the help of two switches and Tursi's Multicart program (runs on an unexpanded TI, too!)

 

The V6D board - well, it's been kind of a bear. I've looked at it, Tursi's looked at it, and I don't think we've gotten far in the past year on it. I've flashed multiple AT49F040s on the V6D board with the same binaries that I burned into the 27C040 on the V4A. Verified them multiple times.

 

When I power up the V6D, I can now usually get MULTICART to show up (which means it's doing the right thing and powering up in the last bank), however, I am still getting quite a few lockups. Sometimes, Tursi's MULTICART logo (and "Made by Tursi") show up, and nothing else. Sometimes, I get a lockup and blank screen. Sometimes, I get the MULTICART logo and Made by Tursi as well as a list of around 7 or less programs and then a lockup.

 

Anyone want to take a stab at looking at these files and see what's going on? To me, it seems like a timing issue (something is being taken high/low too fast/slow or possibly data is being delivered too fast/slow).

 

I have a V6D board here, so I'm open to trying whatever with it. The only jumper I have is the one between pins #1-2 of JP2.

 

Also, the AT49F040 has a different pinout in the PLCC32-DIP32 adapter so I can't try the flash chip on a V4A board; however, like I said, it verified multiple times in my 844USB programmer.

 

Thanks, guys!

 

I looked at the PCB layout over lunch. It's a good looking board !

 

I am assuming these things, am I correct ?

 

JP1 has pins 1 & 2 tied together for WE. You didn't state that the jumper had been made but I am assuming it has and I imagine it needs to be to drive WE HIGH. If unconnected then it would be floating and could cause you grief.

 

JP2 has pins 1 & 2 tied together for *OE

 

ROMS drives the *CE signal directly from the TI ?? (this is how it appears.)

[+acadiel]

I looked at the PCB layout over lunch. It's a good looking board !

 

I am assuming these things, am I correct ?

 

JP1 has pins 1 & 2 tied together for WE. You didn't state that the jumper had been made but I am assuming it has and I imagine it needs to be to drive WE HIGH. If unconnected then it would be floating and could cause you grief.

 

JP2 has pins 1 & 2 tied together for *OE

 

ROMS drives the *CE signal directly from the TI ?? (this is how it appears.)

 

You know, Marc... I owe you a few beers in Chicago. JP1 was the culprit. (they didn't have a facepalm smiley) I've been banging my head on this board for quite a many months (try late last year), even sent it home with Tursi from Chicago. +1 for crowdsourcing help on the Internet!!!

 

I soldered Tursi's cap back on, put two switches, reinstalled the 22pf caps, and the thing works beautiful now.

 

You can thank Ksarul for remapping the board and putting a 512K chip on it. The next iteration has a GAL slot instead of the 74LS379 along with the 512K ROM flash. Yes, 512K of bank switchable cart space (not 128k x 4 like this one).

 

I need to buy an ATMega 128 now and have Tursi put E/A and some other GROM-only stuff on it (Demo, whatever - how many can I cram on there with REVIEW MODULE LIBRARY?) and test it out with the ROM installed now. Tursi, do you recommend a particular programming kit for the ATMega stuff for a hobbyist? I found the Mouser URL for what I think is the chip here.

 

I'm excited!!!! (And I need a long vacation. Work is killing me, so I'm surprised I'm still sane.)

Edited June 15, 2011 by acadiel

[Tursi]

I need to buy an ATMega 128 now and have Tursi put E/A and some other GROM-only stuff on it (Demo, whatever - how many can I cram on there with REVIEW MODULE LIBRARY?) and test it out with the ROM installed now. Tursi, do you recommend a particular programming kit for the ATMega stuff for a hobbyist? I found the Mouser URL for what I think is the chip here.

 

Amazing we missed that for so long!

 

The board is laid out for the ATMega1284, though several other AVRs should fit that footprint. I use the STK500 development board for it - it's worth about $85.

[Willsy]

You can thank Ksarul for remapping the board and putting a 512K chip on it. The next iteration has a GAL slot instead of the 74LS379 along with the 512K ROM flash. Yes, 512K of bank switchable cart space (not 128k x 4 like this one).

 

I want some of those boards! Count me in!

 

Mark

[marc.hull]

 

You know, Marc... I owe you a few beers in Chicago. JP1 was the culprit. (they didn't have a facepalm smiley) I've been banging my head on this board for quite a many months (try late last year), even sent it home with Tursi from Chicago. +1 for crowdsourcing help on the Internet!!!

 

I soldered Tursi's cap back on, put two switches, reinstalled the 22pf caps, and the thing works beautiful now.

 

You can thank Ksarul for remapping the board and putting a 512K chip on it. The next iteration has a GAL slot instead of the 74LS379 along with the 512K ROM flash. Yes, 512K of bank switchable cart space (not 128k x 4 like this one).

 

I need to buy an ATMega 128 now and have Tursi put E/A and some other GROM-only stuff on it (Demo, whatever - how many can I cram on there with REVIEW MODULE LIBRARY?) and test it out with the ROM installed now. Tursi, do you recommend a particular programming kit for the ATMega stuff for a hobbyist? I found the Mouser URL for what I think is the chip here.

 

I'm excited!!!! (And I need a long vacation. Work is killing me, so I'm surprised I'm still sane.)

 

No biggie, just required a fresh set of eyes. I know I tend to get tunnel vision on occasion. As far as the beer goes.... You will have to either show up Friday evening or stay Saturday night. Even I'm not much for the 9:30 AM. Budweiser .

 

Jim is a very excellent and under rated resource for the TI community ! Very generous with his time and skills.

 

Half a Meg of memory huh ? Exactly what the hell do you have planned here my boy ?

Edited June 15, 2011 by marc.hull

[+acadiel]

Marc, you can thank Matthew for the 512K GAL. He adapted his 379 replacement and just extended it with two more sets of I/o pins.

 

Anyone for making a TI megademo?

[marc.hull]

Marc, you can thank Matthew for the 512K GAL. He adapted his 379 replacement and just extended it with two more sets of I/o pins.

 

Anyone for making a TI megademo?

 

Well sure, Thanks Matthew....

 

How about we steer you guys towards a cart with some ram on it .....