• Please review our updated Terms and Rules here

Old eprom programmer help.

>>> and the second file which is also 16k i will burn it on my 27256 because i dont have 27128.it is possible or not.

I have stated above that it IS possible - you either have to burn the 16K image into the upper 16K of the 27256 or burn two (2) copies of the 16K image into the 27256.

Dave
 
ok but i dont know how to burn the file to upper of the 27256, excuse my ignorance i just put on my programmer and burn or i have to do something else, usually i burn without touching anything.maybe i need assistance to write the file.
 
Waiting for your confirmation on how to write file 1 16k and file 2 16k on 27256.never done that.
 
Your EPROM programmer will have some form of offset you can add to the binary image you are trying to download.

The offset for 16K is 16*1024 = 16,384 (decimal) = 4000 (hexadecimal).

Select the offset option first and then load the binary file to be programmed.

The EPROM programmer should load the 16K binary image into the upper 16K of the 27256 image to be programmed.

Dave
 
Im on my computer now , how to set the offset.do i have to put 16*1024 value on the file offset?
 

Attachments

  • 17073129915143900216794302561562.jpg
    17073129915143900216794302561562.jpg
    1.4 MB · Views: 6
Its a bin file , were should i enter the value of 161024 in the box from the gq4x software? .
 
You don't, you enter 4000 (if it is in hexadecimal) and you enter it into the control identified as "File offset" (as I have stated).

Dave
 
My file its a BIN not a hex so i put 161024 like in the picture?
 

Attachments

  • 17073159057672698745169707201860.jpg
    17073159057672698745169707201860.jpg
    3 MB · Views: 4
  • 17073159323651756324772115865474.jpg
    17073159323651756324772115865474.jpg
    2.4 MB · Views: 4
I am not sure why you think that will work?

161024 is not 16384 (in decimal) or 4000 (in hexadecimal).

Dave
 
Same result after trying 27256.
I rechecked z80 i noticed that there is no activity IORQ and RD.
 
>>> My file its a BIN not a hex

Just to clarify, my use of the word 'hex' is to define the number system as base 16. This is nothing to do with a HEX file format.

Dave
 
samib71 said:
Same result after trying 27256.
I rechecked z80 i noticed that there is no activity IORQ and RD.
Click to expand...
So, what did you do in the end?

What number did you feed into the box marked "Device Offset"?

Was there activity on /IORQ and /RD last time (with the original EPROMs in place)?

Dave
 
I put in offset box the value of 4000. I see on pin RD and IORQ same thing.im not sure but i think that the original eproms files are not faulty.
 
Which is what I have said all along...

You would only really burn new firmware (especially if you didn't know whether it was for this particular revision of the EPROM programmer or not) if you demonstrated a problem with the original - or was really stuck and it was your last ditch attempt before giving up!

Can we go back to the original firmware and carry on with the diagnosis from where we left off?

You should see /IORQ signals though...

Dave
 
Yes sure tommorow will put the original files on their eproms and start all over, thanks for your patience dave.
 
Yep,

Let's have a look at the /MREQ, /IORQ, /RD, /WR and /M1 signals on the Z80. I am expecting to see activity on them all.

Whilst we are at it, let's also have a look at U7 pins 4 and 5 which access the two EPROM /CS pins. This will tell me what EPROMs are being selected.

Can you also look at U12 pins 4,5,6,7, 12,11,10 and 9. These are the first stage of the I/O decoding process for the display.

And U15 pin 15.

These pins should tell us whether the display controller is being accessed or not.

Dave
 
You must log in or register to reply here.
Back
Top