[Techtoolslist] Bytek Fireman 8x new information

Mike Coates mike at the-coates.com
Fri Oct 6 13:43:01 EDT 2006


one of the address line buffers in the programmer itself - open it up, 
may be standard 74244's or 74245's - easy enough to sort out then ...

Cameron Rector wrote:
> What I did find was address 800h contains the same data as 000h and 801h 
> = 001h and so on. It appears that the programmer is resending the first 
> half of the ram to 800h and above.
> I only checked the first 8 addresses and the data matches, so I assume 
> that it continues.
> The programmer has internal memory and when I query 800h it has the 
> correct data stored there.
>  
> I looks like it programs the first 2048 in the bottom half of the eprom 
> and then programs the first 2048 in the top half of the eprom.
>  
> Anythoughts other than the trash can?
> 
> 
> */Martin White <martin at guddler.co.uk>/* wrote:
> 
>     Isn't this just sounding more and more like a simple case of a faulty
>     eprom that needs discarding?
> 
>     On Tue, October 3, 2006 1:53 pm, Cameron Rector wrote:
>      > First of all; I have to say my troubles are looking more and more
>     self
>      > induced.
>      >
>      > I talked to some people on the techtool fourm and got a tip to
>     watch A11
>      > with a logic probe while programming. Well intresting enough; A11
>     goes
>      > high right at 800h and stays high though the rest of the programming
>      > (that is what it shoud do). So this got me thinking of performing
>     a few
>      > more tests.
>      >
>      > 1. first I loaded a blank eprom into ram, then I viewed the ram
>     and saw
>      > it was filled with FF (which is correct). Then I performed a
>     verify and
>      > it passes (and it should). I next loaded my binary file (I am
>     assuming
>      > its binary) and re-ran verify and it fails (and it should). Then I
>      > program the ram (containing the file) into the eprom and the post
>      > program verify fails (and it should not). So I see it fails at
>     800h (as
>      > it always does) and it shows ram = 00 and the device = A2 (or
>     something
>      > simular, I forgot the exact number). So at this point I see from
>     800h on
>      > things don't match up. I next load ram again with FF just to make
>     sure
>      > it is clear and then download the device into ram. I then view
>     the ram
>      > at 800h and it says 800h = 00. I again run verify and again it
>     fails at
>      > 800h saying the same thing ram = 00 and the device = A2.
>      >
>      > Now how the heck can that happen? I just downloaded the device
>     into ram
>      > and verified it against its own contents and it fails showing it
>     has a
>      > different number than what it downloaded.
>      >
>      > 2. Just to test the hardware of the programmer. I verified a new
>     blank
>      > eprom and it passed all FF. I then loaded a constant 00 into ram and
>      > programmed the eprom and it passes. This tells me that I can take all
>      > highs at all pins and change them to all lows at all pins. This also
>      > tell me that the programmer must be doing the hardware thing
>     correctly.
>      >
>      > 3. I programmed another blank eprom with an abitrary constant CC
>     and it
>      > passes. CC is loaded in all locations.
>      >
>      > I hope you can follow all of this.
>      > Thank you for all the help folks!
>      > Cameron
>      >
>      >
>      >
>      > John Robertson wrote: Yes, Cameron, the 2532
>      > does go to FFFh, a 2716 fills to 7FFh.
>      >
>      >
>      > If you have a logic probe with a 'memory' you can use that on a
>     read to
>      > see if the A11 toggles. You can use a voltmeter as well...Pin 12
>     is Gnd,
>      > I would stuff thin wires into the two socket opening and clip the
>      > voltmeter to them.
>      >
>      >
>      > If it toggles on a read (it will start Low, then go High at 800h) but
>      > not on write (write FFs that you just 'read') then you have more
>      > information.
>      >
>      >
>      >
>      >
>      > John :-#)#
>      >
>      >
>      > At 6:02 PM -0700 10/1/06, Cameron Rector wrote:
>      > Rodger, Thanks for the input however, I believe the last address for
>      > the 2532 is FFFh. The 2532 is a 32k device arranged as 12bit address
>      > 8bit data or 4096x8=32k. I'm a little rusty at this but I also think
>      > that 7FFh = 2048 and 4096 = FFFh. With this said; I still think I
>      > have something wrong with my A11 signal or signal path. If you can
>      > think of something else, please let me know. Cameron
>      >
>      > Rodger Boots wrote:
>      > Cameron Rector wrote:
>      >> Hello all,
>      >> I am new to this site, so I will applogize for dumb questions up
>     front.
>      >>
>      >> I have a Bytek fireman 8x and I am having trouble programming
>      >> TMS2532A's. The programming part goes well until verify. It
>     seams that
>      >> at address 0800h it fails. It does this on every chip I try. I don't
>      >> know if this could be a configuration setting or it the unit has
>     a bad
>      >> solder joint or IC. I did a visual inspection from A11 pin 18 back
>      >> through the circuit traces and joints, however I didn't find
>     anything
>      >> wrong. I tried to call Bytek and their phone is disconnected and my
>      >> email bounced back.
>      >>
>      >> So, does anyone here know anything about this machine? Does
>     anyone know
>      >> where I can get the schmatic's for this programmer?
>      >>
>      >> I am a newbe at programming eproms, so don't overlook the fact I
>     could
>      >> have a software setting wacked out.
>      >>
>      >> The first verify error says "ADDS 0800h Ram 01 Device 00"
>      >
>      >
>      > That's OK, the last address in a 2532 would be 07FF, so at 0800
>     you're
>      > no longer inside the 2532.
>      >
>      > You have the end of buffer set too high, otherwise it would have
>     stopped
>      > at 07FF.
>      > _______________________________________________
>      > Techtoolslist mailing list
>      > Techtoolslist at flippers.com
>      > http://seven.pairlist.net/mailman/listinfo/techtoolslist
>      >
>      >
>      > _______________________________________________
>      > Techtoolslist mailing list
>      > Techtoolslist at flippers.com
>      > http://seven.pairlist.net/mailman/listinfo/techtoolslist
>      >
>      >
>      >
>      >
>      > --
>      > John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9
>      > Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
>      > www.flippers.com
>      > "Old pinballers never die, they just flip out"
>      > _______________________________________________
>      > Techtoolslist mailing list
>      > Techtoolslist at flippers.com
>      > http://seven.pairlist.net/mailman/listinfo/techtoolslist
>      >
>      > _______________________________________________
>      > Techtoolslist mailing list
>      > Techtoolslist at flippers.com
>      > http://seven.pairlist.net/mailman/listinfo/techtoolslist
>      >
> 
> 
>     _______________________________________________
>     Techtoolslist mailing list
>     Techtoolslist at flippers.com
>     http://seven.pairlist.net/mailman/listinfo/techtoolslist
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Techtoolslist mailing list
> Techtoolslist at flippers.com
> http://seven.pairlist.net/mailman/listinfo/techtoolslist


More information about the Techtoolslist mailing list