• Please review our updated Terms and Rules here

Commodore PET 4008 with strange issues?

Well I'll be damned, the shoddy little EPROM eraser I'd ordered some weeks ago finally arrived. I've tried erasing and writing countless times and alas each time there's one reliable issue: the first byte always seems to write 00 (which for this EPROM I'd assume is high? Whatever the opposite of empty is!) instead of 4C. This happens every time.

I managed to find the exact datasheet for my 27C16s and have set as many parameters as I can find to match, and tWC I've set to tWP + address setup time + address hold time + data setup time + data hold time - this I considered to be 58uS with a 50uS tWP. I've attached the datasheet I found.

Does anyone have any idea why this specific fault may occur? The rest of the file writes exactly as expected.
Cheers
 

Attachments

  • NMC27C16Q-45.pdf
    641.6 KB · Views: 2
BowmakerFox said:
Well I'll be damned, the shoddy little EPROM eraser I'd ordered some weeks ago finally arrived. I've tried erasing and writing countless times and alas each time there's one reliable issue: the first byte always seems to write 00 (which for this EPROM I'd assume is high? Whatever the opposite of empty is!) instead of 4C. This happens every time.

I managed to find the exact datasheet for my 27C16s and have set as many parameters as I can find to match, and tWC I've set to tWP + address setup time + address hold time + data setup time + data hold time - this I considered to be 58uS with a 50uS tWP. I've attached the datasheet I found.

Does anyone have any idea why this specific fault may occur? The rest of the file writes exactly as expected.
Cheers
Click to expand...
Presumably this programmer is different than the first one you got with the parallel port ? So you are saying that both the eprom programmers you got appear to put in an 00 in the 27C16's first location ? It sounds like all 27C16's are defective ? Is it the same host computer in both cases ? I can see that you had this issue with the Willem programmer in post #36. What happens with the vintage Japanese 2716 ?

Were the 27C16's erased prior to attempted programming ? I cannot recall now, but when empty (erased) I think they should be FF at all locations, check this, if they start out as 00 before programming, the programmer cannot change that.
 
I believe he is saying he received an eprom eraser. He blanked his EPROMs and reprogrammed them but is always getting 00 in the first byte.

Have you heard of this problem with old programmers…
 
dave_m said:
I believe he is saying he received an eprom eraser. He blanked his EPROMs and reprogrammed them but is always getting 00 in the first byte.

Have you heard of this problem with old programmers…
Click to expand...
I have never heard of this problem and nor has Daver2 by the look of it.

It must some sort of timing anomaly in his Willem programmer that is corrupting the first byte, almost as though the correct data is not placed on the data lines in time, or at the right time for the write of the first byte. The remaining addresses are programmed correctly.

I would be suspecting buggy firmware in the programmer, especially if it does this with different variants of the 2716, like the vintage Japanese ones.

I'm a little suspicious of the cheaper programmers because I think what might happen is that the makers of them didn't write the firmware themselves, that would deal with any particular timing vagaries of their particular hardware, they just get the files from other Willem machines and expect them to work on their variants of hardware. Probably most times they will work, but they might not for some of the IC's they are supposed to support. Not a lot different in many ways from the cheap chip testers that don't support some TTL IC's, even though they are on the supported lists.

I assume the eraser is successfully blanking the 27C16's and that they are passing the blank check prior to programming ?

I guess one thing to try, is another type of Uveprom, like a 2732, to see if the problem is still there or if it is a problem specific to programming variants of the 2716.

My advice is to get the GQ-4x, even though more expensive, at least they work, and the extra expense is probably inversely proportional to the number of headaches possible with cheaper programmers.

I think the GQ-4x must have very minimal bugs, because when it comes to software/firmware issues I am jinxed and if there is a bug it tends to find me in no time. And I have never had any problems at all with it.
 
Last edited:
Hugo Holden said:
I would be suspecting buggy firmware in the programmer, especially if it does this with different variants of the 2716, like the vintage Japanese ones.
Click to expand...
You may be on to something. He is using the very latest version of the software with a very old version of hardware. I would look for an older version of the software that would be more compatible with his hardware.
 
Hugo Holden said:
I have never heard of this problem and nor has Daver2 by the look of it.

It must some sort of timing anomaly in his Willem programmer that is corrupting the first byte, almost as though the correct data is not placed on the data lines in time, or at the right time for the write of the first byte. The remaining addresses are programmed correctly.

I would be suspecting buggy firmware in the programmer, especially if it does this with different variants of the 2716, like the vintage Japanese ones.

I'm a little suspicious of the cheaper programmers because I think what might happen is that the makers of them didn't write the firmware themselves, that would deal with any particular timing vagaries of their particular hardware, they just get the files from other Willem machines and expect them to work on their variants of hardware. Probably most times they will work, but they might not for some of the IC's they are supposed to support. Not a lot different in many ways from the cheap chip testers that don't support some TTL IC's, even though they are on the supported lists.

I assume the eraser is successfully blanking the 27C16's and that they are passing the blank check prior to programming ?

I guess one thing to try, is another type of Uveprom, like a 2732, to see if the problem is still there or if it is a problem specific to programming variants of the 2716.

My advice is to get the GQ-4x, even though more expensive, at least they work, and the extra expense is probably inversely proportional to the number of headaches possible with cheaper programmers.

I think the GQ-4x must have very minimal bugs, because when it comes to software/firmware issues I am jinxed and if there is a bug it tends to find me in no time. And I have never had any problems at all with it.
Click to expand...
I suspect the firmware is at fault too, this thing is honestly a bit sketchy. I've tried both the latest and oldest version of the software I could find and alas both reproduce the same error.
I'll see if I have any luck with the Vintage Hitachi one tomorrow when I'm back in the workshop. They passed a blank test in the software after each erase so I assume all good.
I was looking at a relatively cheaply listed Batronix BX32 I've found at about the same price but frankly have no clue if they're any good either and if I'm spending that much maybe the GQ-4X is best (if I can find one-).
EDIT: If not, I have managed to find a GQ-4X for not much more. Sadly nothing used available, but there's a listing for a GQ-4X4 PRG-055 which I can probably warrant the cost of, if it's the same thing.
 
Last edited:
Right.
I've bought a GQ-4X4...

Due to arrive tomorrow, but we'll see about that - with any luck, should have an update by wednesday if there's any progress.
Thanks for the link dave, that was useful for checking compatibilities etc.
Cheers all

P.S: Tried the hitachi with the PCB5.0 Willem and unsurprisingly nothing useful - failed on the first bit in the same way and then wrote nowt else.
 
I hope that Hitachi ROM of yours is ok, it really is a beautiful part; "they don't make em like that any more"

I would predict there will be no trouble with the GQ-4X, plus the manufacturers are super helpful and respond to suggestions & questions if you had any issues. And it is a much better arrangement in a professional housing.
 
Well I'll be damned.
This little thing is remarkable (at the very least, by comparison). Managed to write to and successfully verify both the 27C16s, and everyones' favourite!
First time too, it just... works-

IMG_20240606_123605.jpg

It has verified successfully. I'll shove it in the edit ROM socket and see what happens.
 
Now you know to go on personal recommendations...

Just shove it in the right way around now you have felt all if this pain in programming it!

It was an interesting fault though...

Dave
 
Yes I'll admit, it would indeed have been much cheaper and quicker overall to have gone with the recommended option from the start. At the time I couldn't afford it anyway though, but I do realise it would've been so much easier.

I put the programmed ROM in UD8 and when it was switched on, this happened-

Screenshot_20240606-135223.jpg

There was also a great deal more interference / noise in the display than usual. I'm no expert but that really doesn't seem right. The ROM verified correctly and seems to match the PETTEST V4 Binary, so I don't expect the ROM to be the fault. Perhaps the socket is knackered? - That is one of the original white shoddy ones, though it did make continuity before.
 
What it is telling me is that you have some problems with the VIDEO RAM or VIDEO RAM buffers or support circuitry.

The 'second half' of the RAM looks suspect.

You will have to qualify what you mean by interference/noise. I suspect that you have some VIDEO cells that are changing data and (as a result) you get two (or more) characters superimposed in some of the display cells. Perhaps a short video of the screen?

Dave
 
daver2 said:
What it is telling me is that you have some problems with the VIDEO RAM or VIDEO RAM buffers or support circuitry.

The 'second half' of the RAM looks suspect.

You will have to qualify what you mean by interference/noise. I suspect that you have some VIDEO cells that are changing data and (as a result) you get two (or more) characters superimposed in some of the display cells. Perhaps a short video of the screen?

Dave
Click to expand...
I've attached a video.

It occurred to me that I've also got some spare 2114s lying around, so I tried it with them as well.

IMG_20240606_152240.jpg
Above: the original spec ICs

IMG_20240606_152220.jpg
Above: the replacement ICs too, shown in the sockets as was the case when filming the second video.

View attachment VID_20240606_151850.mp4
Above: with the original VRAM ICs

View attachment VID_20240606_152134.mp4
Above: with the replacements.

Neither seem to make much sense. I'm suspecting that my replacement ones aren't actually compatible for some reason and the old ones have failed - that'd be my guess.
In terms of the second half looking dodgy with the original ICs, I agree entirely. The reason, however, is unbeknownst to me.
 
Er, the second video shows that it worked!

You could always try reading my documentation for PETTESTER of course...

The second video has moved on from the VIDEO test to the page 0 and 1 DRAM test.

The first set of 'b' and 'g' characters indicate a bad memory address and a good memory address respectively for addresses $0000 to $00FF. The second set of 'b' and 'g' characters are for addresses $0100 to $01FF.

You should video the start-up screens (from a soft reset) and post it. You should be able to step through the video frame by frame to see the screens of PETTESTER as they PASS and move on to the tests in order. Version 5 of PETTESTER (not released yet) has an increased delay between tests for the human to view the results!

Dave
 
Last edited:
daver2 said:
Er, the second video shows that it worked!

You could always try reading my documentation for PETTESTER of course...

The second video has moved on from the VIDEO test to the page 0 and 1 DRAM test.

The first set of 'b' and 'g' characters indicate a bad memory address and a good memory address respectively for addresses $0000 to $00FF. The second set of 'b' and 'g' characters are for addresses $0100 to $01FF.

You should video the start-up screens (from a soft reset) and post it. You should be able to step through the video frame by frame to see the screens of PETTESTER as they PASS and move on to the tests in order. Version 5 of PETTESTER (not released yet) has an increased delay between tests for the human to view the results!

Dave
Click to expand...
Oh I see haha, I hadn't expected it to even reach that point. I'll check the documentation overnight. I've left the workshop today but tomorrow I'll video the start up screen. If that's what it's supposed to do, I'll assume that the new VRAM ICs are working.

If it's a dodgy memory address that'll either mean that I failed at soldering the sockets or one of the "tested working" ICs I've bought is DOA! Neither would surprise me, but it's mildly annoying if that's the case. Will have a look tomorrow.
 
Note that the memory I am referring to here (as faulty) is the CPU RAM and not the video RAM that you have exchanged and is working OK!

Dave
 
daver2 said:
Note that the memory I am referring to here (as faulty) is the CPU RAM and not the video RAM that you have exchanged and is working OK!

Dave
Click to expand...
Yes indeed, I swapped the main memory and socketted it too. For that reason, I fear I've either messed up soldering the sockets or been sold some failed 4116s
 
Gotcha.

The sequence of b and g characters and the returned character will give us a clue as to any pattern that is occurring, and should point us to any faulty DRAM (assuming the fault is not with the supporting logic).

See what you can work out from reading my documentation...

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