[Techtoolslist] Bytek Fireman 8x new information

[Mike Coates]

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