Couldnt really find a section for this..

[festy]

you have a 35 byte bin for a 32 byte nvram so don't think it's the cluster's fault.
0D 0A is crlf, did you open the bin with notepad?

[jxx]

lol, no using hex editors, that's how it was dumped initially, opened with either funduc software hex editor or HxD they may be free but are quite good.I would've just ignored it and put it down to an error reading if i wasn't able to erase the nvram and put a 32 byte image there and have the cluster work then put the 35 byte image back, read/verify and have the strange display again, it was displaying that before i desoldered anything from the board, i know it shouldn't fit, it's logically impossible, 256 / 8 = 32.... but it's fitting on, running, powering up

[festy]

At a quick glance, your bin looks fine except that every 0A is prefixed by a 0D - take the 0Ds out and it should be a valid bin.
That sounds like your editor is doing a unix to dos (LF->CR/LF) conversion when it sees the 0As.
When you read the bin off the nvram, before opening with a hex editor is is 32 or 35 bytes?

edit: also, they're 16 bit arrangement, not 8 bit so you couldn't end up with an odd number of bytes - must be software

[jxx]

yes before opening it was 35bytes, the numerous attempts learning how to make a valid bin neither editor has added anything extra, not new to hex editing and never overwrote the original dump (actually dumped 3-4 times and compared them before i even started changing code i've learnt from past experiences of reading once and working with a corrupt bin)
here's some links to a series of photos, unedited, due to the filesize i'm not going to link them directly, going from a working image to reprogramming the corrupt image, powering the display on/off etc, after all that i read the chip again and ended up with a 35 byte image, the 32 byte image read at the start was 100% and fine, it's only the fubar code that is doing anything strange, hence why i posted about it otherwise i'd have shrugged it off and ignored it if it happened to another bin.

[festy]

Oh, you built that old x2444 circuit and are using the dos programmer software by the looks of it?
You running XP?

[jxx]

yeah, old school os on a shed pc, raided some old circuit boards and and knocked it up in a couple of minutes

[festy]

I didn't even try that program because of XP's lack of direct port access from dos.
What are you using to map LPT1 to the parallel port?

[jxx]

it's a serial device.... and upon investigation only thing i can see port related installed is driverlinx port i/o driver, no idea what i installed that for in the past but i needed it for something. i've used port95nt in the past on another pc, i guess that would work also

[festy]

doh! for some reason I had it in my head it was a parallel interface
It's the serial port doing the LF->CRLF translation. I know how to fix that in a *nix environment, but not windows sorry

[jxx]

0D's out and displaying proper odo numbers, thing is it was displaying the bugged digits before i removed the 24c44 chip, from ??3789 -> 378950
guessing the cluster glitched at some point when i was initially powering it up, interesting though, still can't understand how the 35byte image physically fits onto the 256 bit chip (unless it is a rebadged version of a higher capacity chip).... it's the only image out of a dozen that has been 35 bytes in the process of reading/writing

can display mls instead of km, dist to empty changes from 650 km -> 402 mls by swapping bytes 7 - 8

Code: Select all

01 E8 CA A8 00 FF 20 DF

to

01 E8 CA A8 00 FF DF 20