eprom burning question

[Mike Hooker]

im using a GQ-4x burner, its a willem type. im trying to burn 3 images to a single prom. the 1st at 0000, the second at offset 1000, the 3rd at 1800. i try the combine feature, but it tells me to close the application, re-open without choosing a device. that doesnt work,. its a 2764. i tried burning the 1st file, then the 2nd, then the third. i see all the code there, but not sure if thats the right way. i would rather combine into one file, and then burn.

thanks

[Dave Platt]

In article <8f3647e7-ff48-4bc0...@googlegroups.com>,

If you have access to a Linux system you can do the combining with
"dd" (one of many choices but it's straightforward).

One way to do this would be

dd if=/dev/zero of=combined.bin bs=1 count=8192
dd if=1st.bin of=combined.bin bs=1 seek=0 conv=notrunc
dd if=2nd.bin of=combined.bin bs=1 seek=$((0x1000)) conv=notrunc
dd if=3rd.bin of=combined.bin bs=1 seek=$((0x1800)) conv=notrunc

In plain language - create an 8k-byte file full of zeros, then copy
each of the three separate images into it, seeking to the appropriate
offset in the file first, and not truncating the file while copying.

[John Robertson]

Nice solution, I would only suggest editing the create function to make
it a 8K file of "FF"s so you aren't trying to burn 00s - this will speed
up the programming slightly. Afraid I don't know how, but I'm sure it is
easy to look up...

John :-#)#

--
(Please post followups or tech inquiries to the USENET newsgroup)
John's Jukes Ltd.
MOVED to #7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3
(604)872-5757 (Pinballs, Jukes, Video Games)
www.flippers.com
"Old pinballers never die, they just flip out."

[Mike]

In article <VLudndyc8sYAl3DC...@giganews.com>,

John Robertson <sp...@flippers.com> wrote:

>> dd if=/dev/zero of=combined.bin bs=1 count=8192

...

>Nice solution, I would only suggest editing the create function to make
>it a 8K file of "FF"s so you aren't trying to burn 00s - this will speed
>up the programming slightly. Afraid I don't know how, but I'm sure it is
>easy to look up...

Use /dev/one instead of /dev/zero :)

It would *only* speed up programming if the hardware/software used
optimizes things and skips/refuses to "program" locations that
are 0xFF (the default blank chip state).

Otherwise, there's no speedup there.

Serious answer, if you don't have /dev/one available, change the first
line to :-

cat /dev/zero | tr '\000' '\377' | dd of=combined.bin bs=1 count=8192

Omitting the "if=/dev/zero" takes input from stdin, and tr swaps
0 for 377 (Octal)/255(Dec)/0xFF(hex)
--
--------------------------------------+------------------------------------
Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk

[John Robertson]

On 2020/12/31 2:21 a.m., Mike wrote:
> In article <VLudndyc8sYAl3DC...@giganews.com>,
> John Robertson <sp...@flippers.com> wrote:
>
>>> dd if=/dev/zero of=combined.bin bs=1 count=8192
>
> ...
>
>> Nice solution, I would only suggest editing the create function to make
>> it a 8K file of "FF"s so you aren't trying to burn 00s - this will speed
>> up the programming slightly. Afraid I don't know how, but I'm sure it is
>> easy to look up...
>
> Use /dev/one instead of /dev/zero :)
>
> It would *only* speed up programming if the hardware/software used
> optimizes things and skips/refuses to "program" locations that
> are 0xFF (the default blank chip state).
>
> Otherwise, there's no speedup there.
>
> Serious answer, if you don't have /dev/one available, change the first
> line to :-
>
> cat /dev/zero | tr '\000' '\377' | dd of=combined.bin bs=1 count=8192
>
> Omitting the "if=/dev/zero" takes input from stdin, and tr swaps
> 0 for 377 (Octal)/255(Dec)/0xFF(hex)
>

Nice work!

I wasn't really worried about the speed, more changing FFs to 00s seemed
a bit pointless in the grand scheme of things, plus any unused space
(FFs) in the EPROM could still be used if the OP needed something else
in the future.

Or just erase and start over...which we've all done I'm sure!

[Mike]

In article <5MidnRQ0y7wJi3PC...@giganews.com>,

John Robertson <sp...@flippers.com> wrote:

>>> it a 8K file of "FF"s so you aren't trying to burn 00s - this will speed
>>> up the programming slightly.

>> It would *only* speed up programming if the hardware/software used
>> optimizes things and skips/refuses to "program" locations that
>> are 0xFF (the default blank chip state).
>>
>> Otherwise, there's no speedup there.

>I wasn't really worried about the speed,

Well, some programmers do optimise by "not-programming" 0xFF, which may
not make much odds on a decent programmer. I added this step to the
custom software for my EPROM programmer which talks over a 4800 baud
RS232 serial link, where every byte matters! :)

Same for a "Rapid blank check" (check 1024 bytes spaced through the chip
to check if they come up blank) for quick-sorting of blank vs programmed.

>plus any unused space
>(FFs) in the EPROM could still be used if the OP needed something else
>in the future.

Yes, that's actually a good point -- I've used 27512 parts where I
really needed only a 27128 (with two spare high address lines tied to
jumpers to ground/pullup resistors) to allow four goes at programming
the chip before having to chip-swap or erase!

>Or just erase and start over...which we've all done I'm sure!

Too many times :(

[Rob]

Dave Platt <dpl...@coop.radagast.org> wrote:
> In article <8f3647e7-ff48-4bc0...@googlegroups.com>,
> Mike Hooker <mhoo...@gmail.com> wrote:
>>im using a GQ-4x burner, its a willem type. im trying to burn 3 images to a single prom. the
>>1st at 0000, the second at offset 1000, the 3rd at 1800. i try the combine feature, but it
>>tells me to close the application, re-open without choosing a device. that doesnt work,. its
>>a 2764. i tried burning the 1st file, then the 2nd, then the third. i see all the code there,
>>but not sure if thats the right way. i would rather combine into one file, and then burn.
>
> If you have access to a Linux system you can do the combining with
> "dd" (one of many choices but it's straightforward).

First we need to know what file types Mike is using.
The proposed solution is OK for binary images, but actually in EPROM
burning it is more common to have HEX files, which have lines containing
an address, a number of bytes, and usually a checksum, all in ASCII HEX.

To combine those files, you would just need to cat them together.

[John Robertson]

If the OP is using osX I could recommend a little program I use quite a
bit - burning EPROMs many times a week - called Synalyze It! Pro. Easy
to merge files, do checksums of various levels of complexity and compare
binaries.

Here is the free version:

https://www.synalysis.net/

And I do recommend buying the Pro. I know I don't use all the features...