Hi, new to the forum, fixing a Commodore PET

[dave_m]

Looking good so far!

Did you start the code using the Reset vector?

 

[GilesGoat]

Looking good so far!

Did you start the code using the Reset vector?

Yes .. and I just found a tiny mistake in my adapter .. checking one more thing .. if it works I means I accidentally swapped one connection ..

 

[MikeS]

Ok, so what you said in the beginning (#3 & #5)

I have Wiley's Eprom Programmer, it does support 2716/32

was really not in fact correct?

 

[GilesGoat]

Ok, so what you said in the beginning (#3 & #5) was really not in fact correct?

I bought that on Ebay from some Chinese source, I am not sure it's the "orginal" Willem programmer but is "based on", it came with basically no instructions or such much.

In my understanding there was 2 different PCB versions, one capable to read those eproms and one not and mine seems to be the 'not'.

I did tried to read the CBM eproms but was getting nowhere, it was simply not reading those.

I guess it could be easily solved anyway with a small adapter because from 2764 on it can certainly read those for sure.

However yesterday we found out it surely execute and runs code, but after a few tries to burn a proper set of roms there is still something not quite working.

At this point we are going to try a few simple "debug programs" to check if :

a) adress space is correctly addressed
b) if it is check if the ram works

Definitely the CPU runs, definitely it fetches the reset vector and such, definitely the E000-FFFF part of address space works.

We are going to do a small test program that starts around F400 then jumps into E000 then C000 then D000 printing different things on screen in different places to check all that works correct.

If It does then we are going to write something to check ram.

So far the attempt to burn basic and kernal+editor in those eproms just created a stable but full of random crap screen.

[edit] I used the .bin files with the same numbers like in the ROM ( i.e. like 9014465-03, 01, 02 and 901447-24 .bin ) putting them in the order the should be.

[edit2] I will be DEFINITELY going to make that adapter at some point to make that fit as it would be a 2764 or so so once for all we'll sort out this dilemma.

 

[GilesGoat]

Mini update and then I'll be busy preparing and cooking a turkey ..

First we run another test program, just to show you what here it is :

.ORG $c000
LDA #$03
LDX $BB
STA $8000,X
INC $BB
forever: ADC #$01
STA $8010
JMP forever

.ORG $d000
LDA #$02
LDX $BB
STA $8000,X
INC $BB
JMP $c000
.end

And this :

.ORG $e000
LDA #$00
LDX $BB
STA $8000,X
INC $BB
JMP $d000

.ORG $f000
SEI
LDA #$20
LDX #$00
cls: STA $8000,X
STA $8100,X
STA $8200,X
STA $8300,X
DEX
BNE cls
LDA #$00
STA $BB
JMP $e000

.ORG $fffc
.db $00
.db $f0
.end

And this stuff proven with no doubt my "rom adapter" works.

Then I finally made an adapter to read those roms .. and surprise surpirse they are all good and identical to those images I downloaded.

I then removed my adapter and put the original eprom back.

HOWEVER ..

They don't work, but what is CONSISTENT is they produce the same identical random crap when yesterday I burned into my EEPROM the same contents and tried to run it.

It proves anyway that definitely one of the 2114 was not well working, now we are writing some small programs to do a ram test and see if we find something else.

 

[dave_m]

It proves anyway that definitely one of the 2114 was not well working, now we are writing some small programs to do a ram test and see if we find something else.

You are making progress. Test main RAM from address 0000 to 3FFF hex (16K). Test the video RAMs from address 8000 to 83E7.

 

[MikeS]

[edit] I used the .bin files with the same numbers like in the ROM ( i.e. like 9014465-03, 01, 02 and 901447-24 .bin ) putting them in the order the should be.

I assume you meant 901465-xx?

So what order are they in then?

And how did we prove that a 2114 was bad?

 

[GilesGoat]

Well .. as I already pulled out the 2114 and put some sockets I am able to swap them, it does happen I did have a couple of new never used 2114, putting back the original rams in the sockets was showing crap, the same crap all started with.

Then we changed both 2114 .. all was OK ( I mean no more crap in the video, still basic not starting ).

Then we did try to put back one by one the old 2114 .. one seems ok, but one of the two appears to be failing.

Now the weird thing is we did run a number of tests, including a ram test program that shows us that ALL the 16K of ram are OK.

However there's something weird, which I believe is part of the same problem we started with.

It's like 'something is happening' around the address E000 + something, which, does not depend on my 'adapter' as well ( after I done the proper modifications with A11 and SELE ) because you get shit as well by simply putting back the original ROMS ( that now we know are perfectly fine ).

What we see is :

1. Put code at F000 ... all works
2. Put code at D000 .. all works
3. Put code at C000 .. all works

Ah it also confirms that the ram is 16K and that all it is.

but ..

4. Put code at E000 ... it's like it's executing 'some bytes of code' and then it stops.

In our Ram Test code ( see below ) it seems it's stopping somewhere after it cleared the screen and printed that char ( to say 'yes I am here' ) not sure yet precisely at what address it stops, the code of course is short and ends LOT before E800 ..

Now there's a thing .. chip UB2, the one close to that set of 'jumpers' SH2 has/had quite a bit of RUST around the pins, which I've done my best to polish.

It's the 7425 that should also generate the X8XX signal and such, there are 2 resistors around ( R49 e R51 ) one of which (R 49) by looking carefully it's lightly damanged, however by checking it with an analyzer still measures 1K.

Tried to check the chip under a strong light and such and with the analyzer as well I don't think there is any short circuit or such.

So it's quite puzzling, the CPU and all definitely runs, the ram seems to be OK but 'something happens' around E000 and something.

This is the ram test we were running, those #ifdefs I added them to try to understand where the program could be dying.

Of course while testing F000/E000 I can use only one rom but when I test C000/D000 I use two cause the Reset vector at FFFC e FFFD has to be set at the correct location.

The code, when tried to execute at E000 .. seems to stop "somewhere" after this :

LDA #$FF
STA $8200 ; just a check

Which we put to print a character on screen just to know "it's there".

So still a bit puzzling.

.ORG $C000

.db $ff

.ORG $D000

SEI

LDA #$0c
STA $E84C ; put in Uppercase mode

LDA #$4c
LDX #$00
cls: STA $8000,X
STA $8100,X
STA $8200,X
STA $8300,X
DEX
BNE cls
forever: LDA #$00
STA $BC
LDA #$01
STA $BD ; address $0100 at $BC
LDA #$FF
STA $8200 ; just a check

#ifdef STRAPPAPINE

LDX #$00
checkall: LDA #$00 ; error flag in $BE (400f)
STA $BE
LDY #$00
checkblock: LDA #$a5
STA ($BC),Y
LDA ($BC),Y

STA $8100,Y

CMP #$a5
BEQ NOERR ; disparity means error
LDA #$02
STA $BE
NOERR: DEY
BNE checkblock
LDA $BE
STA $8000,X
INC $BD
INX
TXA
CMP #$7f
BNE checkall
JMP forever

#ifdef BANANA

.ORG $F000
.db $ff

.ORG $0FFFC
.db $00
.db $E0



#endif


#endif

.end

[edit] those '.db $ff' I just need there has to be something here ( I am using TASM assembler ) so the asm will fill the remaining space with all FF, if I don't put that it assembles at ORG F000 but the code will be saved as that, using that 'ff' trick I force it to fill all the space between E000 and F000 ( in the rom ) with 'FF' and have the code at the correct address.

(i.e. tasm -65 -a -b -fFF -q Ramtest4.asm Ramtest4.bin )

 

[MikeS]

Originally Posted by GilesGoat

I used the .bin files with the same numbers like in the ROM ( i.e. like 9014465-03, 01, 02 and 901447-24 .bin ) putting them in the order the should be.

I assume you meant 901465-xx?
So what order are they in then?

You know, much as I enjoy reading about your various tests and experiments it is a little frustrating when you don't read our replies or reply to our questions, so humour me and let me ask again:

Now that we finally know after two weeks and 85 posts that the ROMs are apparently OK, what order are you putting them in, i.e. which ROM # is in which socket? Not in the sequence above, I hope...

And a belated Christmas greeting to you and everyone still following this thread!

 

[GilesGoat]

Originally Posted by GilesGoat




You know, much as I enjoy reading about your various tests and experiments it is a little frustrating when you don't read our replies or reply to our questions, so humour me and let me ask again:

Now that we finally know after two weeks and 85 posts that the ROMs are apparently OK, what order are you putting them in, i.e. which ROM # is in which socket? Not in the sequence above, I hope...

And a belated Christmas greeting to you and everyone still following this thread!

.. it may seem strange but I do have a life other than being all time in front of a computer, especially in those few days that are 'holidays'

Ok this morning :

1.) I got awake ( about 20 mins ago, yes I was sleeping cause too much food/tv/drinks/cakes/xmas food yesterday )
2.) I had someone calling me on the phone
3.) I am making tea ..
4.) I received a skype call
5.) I am still talking at skype while writing all this
6.) I have a dog trying to steal my biscuits under the desk that will jump on me if I don't give her at least a piece of what I am eating ( tea and bisquits )
7.) Yes I did read all this
8.) Yes I was thinking "I bet he gets the hump if I don't reply to .. "
9.) Yes I was thinking "OK I want to be sure I write it all correct including the fact that we tried all the possible ROM permutations JUST TO BE DOUBLY SURE
10.) Knowing that eproms are UD9 = F000, UD8 = E000 , UD7 = D000, UD6 = C000 we know that kernal is UD9, editor is UD8 ( which is 2K not 4 ) and 7,6 are the basic so that was the order
11.) Yes I was to write all this after the tea then my mate says "hey did you know that in that forum that guy said .. "

12.) .. *NGH* ..

All this was around slot '14' or so in the list of things "after the tea", being in Wales here we do not do anything in the morning before to morning tea

And before all this there normally is the 'feed the sheep' part and bring the dog out, we are sub zero temperatures here so the dog has to stay inside home during the evenings.

I hope this answers

Despite being a computer geek and spending already something around 12 hours a day in front of this PC ( working ) and even more "doing other things" ( like fixing this PET in fragments of time ) I could be not 'super fast' in keeping stuff up to date and especially in a forum like this I want to be sure that what is write is very correct and detailed as necessary.

The ROMS anyway are called :

basic-2-c000-901465-01.bin
basic-2-d000-901465-02.bin
kernal-2-901465-03.bin
edit-2-n-9014467-24.bin

As I said I managed to read the old roms and their contents seems to be identical to those files.

By applying a 'CSI tecnique' ( i.e. zooming on a high-res pic I took immediately after I cleaned the PET before to do anything else on it ) I can tell you that the roms where in fact in its original order as that :

UD9 = 03 ( which is in fact kernal at F000 )
UD8 = 24 ( which in fact is the editor )
UD7 = 02 ( which in fact is basic D000 )
UD6 = 01 ( which in fact is basic C000 )

( this is why I take pics before to touch things in case I forget how they were )

So again telling that the order is F,E,D,C

Look at this :

Now I am 99.99% convinced that my 'rom adapter' is correct, after the modifications /SELE and A11 been combined with NANDs to basically form an OR ( so basically is like /NEWSELE = /SELE OR A11 )

But as I said even removing my adapter and putting all back as it was does not work, I do not believe my adapter is wrong.

I hope those explanations are enough for now

 

[GilesGoat]

.. all this reminds me of what once a german (engineer) friend of mines was saying ..

He was saying that "all the time he ever worked with some italian engineers there always was a lot of chaos, however he never understood how but in the end things were always working" :mrgreen:

I am not an engineer anyway, I quit uni after 2 years, it wasn't for me, then I ended up in a place that was an ex dentist studio converted into an SW company in a very small room writing 68K ASM code for OS9 systems drinking coffee and eating canned sardines with much discomfort for colleagues cause the smell of fish.

But my other colleague in the same room was eating sandwiches of bolony and salame sometime with cheese so during lunch time it was a bit like to be in some strange deli :mrgreen:

It was good we did not have a coffee machine but the bar was just across the road so every now and then we had "5 mins espresso time".

Ah those were the times ..

 

[GilesGoat]

The following test, prints only 4 chars on the screen ( after the cleanup ).

Checking the dump this seems to say the program stops executing at address $E030 .. which is odd ..

Actually it could be more precisely $E02F because I don't think it fetched the STA after the last STA 8203 at all.

Hum ..

.ORG $E000

SEI

LDA #$0c
STA $E84C ; put in Uppercase mode

LDA #$4c
LDX #$00
cls: STA $8000,X
STA $8100,X
STA $8200,X
STA $8300,X
DEX
BNE cls
forever: LDA #$00
STA $BC
LDA #$01
STA $BD ; address $0100 at $BC
LDA #$FF
STA $8200 ; just a check

STA $8201 ; just a check
STA $8202 ; just a check
STA $8203 ; just a check
STA $8204 ; just a check
STA $8205 ; just a check
STA $8206 ; just a check
STA $8207 ; just a check

STA $8208 ; just a check
STA $8209 ; just a check
STA $820A ; just a check
STA $820B ; just a check
STA $820C ; just a check
STA $820D ; just a check
STA $820E ; just a check

STA $820F ; just a check
STA $8210 ; just a check
STA $8211 ; just a check
STA $8212 ; just a check
STA $8213 ; just a check
STA $8214 ; just a check

STA $8215 ; just a check
STA $8216 ; just a check
STA $8217 ; just a check
STA $8218 ; just a check

STA $8219 ; just a check
STA $821A ; just a check


.ORG $F000
.db $ff


.ORG $0FFFC
.db $00
.db $E0



;#endif


;#endif

.end

 

[GilesGoat]

A further test shows all is running.

In my opinion there has to be something wrong or with some I/O decoding or some chip itself, I was seeing the signal "SELE" is also used as "IO" combined with X8XX as chip sel for the 6520 and such.

I did remove both 6520 ( but let the VIA in ) and the program now seems to run doing all the 27 chars on the screen.

So "something goes odd somewhere" and when it reaches that address I believe 'starts one of those 2 chips' and creates a bus conflict.

Now as a test trying to burn on the eproms the basic again and see if I can get it run without the chips on.

[edit] - and of course removing all the chips ( 6520 and VIA ) was among the first tests I've done .. and yet NOTHING was working as well ..

[edit2] - trying to burn the basic and all does not work ( with the 6520 removed ) , it freezes somewhere. As well as tring to put the original roms in as they were and such.

So there must be some other address or thing where something fails, the fact that removing the 6520 chip 'does something' for my code running at E000 suggests me there must be some problem somewhere in decoding that I/O space, I get the impression someway the ROM gets disable ( or the I/O gets enabled ) when it should not.

[edit3] - I am going to try later a test, run that test program in E000 in loop and check with an oscilloscope X8XX and/or what goes into CS0, CS2 of the 6520, by running code in E000 I expect CS0 ( pin 22 ) to be always '0' and CS2 ( pin 23 ) to be always '0' as well, if for any reasons CS0 should go '1' then there's something odd.

Then I will check other chips as well.

I wonder if there could be any failure in some of those 74244 address buffers, in particular the higher one that drives A8-A15 ..

 

[MikeS]

I'm not rushing you, I just thought if you have the time to post these lengthy results etc. you'd have time to answer my and Dave's questions; if you'd checked which schematic you're looking at like he asked in the beginning you'd also have saved yourself some time.

I just thought the sequence in your post below was kind of odd, so I just wanted to make sure that it was not in fact the sequence you had them in on the board:

Originally Posted by GilesGoat
I used the .bin files with the same numbers like in the ROM ( i.e. like 9014465-03, 01, 02 and 901447-24 .bin ) putting them in the order the should be.

We all know which ROM does what and where they should be and didn't need that explained (several times) ; what we didn't know is where they were plugged in in your board. A simple

UD6 - 901465-01
UD7 - 901465-02
UD8 - 901447-24
UD9 - 901465-03

would have been sufficient. Thank you.

I wonder if there could be any failure in some of those 74244 address buffers, in particular the higher one that drives A8-A15 ..

Well, the NOP generator that Dwight and I suggested would tell you that, but as you say, we'll have to wait and watch you do it the Italian way ;-)

When I read things like this

...using that 'ff' trick I force it to fill all the space between E000 and F000 ( in the rom ) with 'FF' and have the code at the correct address.

I wonder again whether you're really correctly decoding the Exxx space; there is (or should be) NO ROM between E800 and EFFF.

 

[GilesGoat]

I wonder again whether you're really correctly decoding the Exxx space; there is (or should be) NO ROM between E800 and EFFF.

I can't draw a diagram right now however .

A11 - pin 18 PET rom -> pins 9+10 of 7400
SELE - pin 20 UD8 rom -> pins 4+5 of 7400

7400 pin 8 goes to pin 12
7400 pin 6 goes to pin 13

7400 pin 11 -> new SELE

Basically NEWSELE is '0' only when SELE is '0' and A11 is '0', '1' otherwise.

Whatever is in ROM from E800 to EFFF does not matter because the rom is never selected at that point, could be garbage but I just fill it up with FF.

When SELF is '0' all the other SELx has to be '1', can't be otherwise

 

[MikeS]

Just double-checking; sounds good.

 

[GilesGoat]

The NOP generator seems to tell me all the address lines past the buffers are OK.

However ( but this was someway expected ) it seems to tell me a couple of springs contact in the ROM sockets are a bit loose, with the old rom chips inserted they do a bit of a bad contact.

However I was expecting this to happen the moment I inserted my 'rom adapter' because my pins are lightly larger than chips pins and they certainly exerted a bit of 'extra stress' on the old springs.

But on my "adapter" all looks ok and all the lines A0 - A11 seems good.

There's "some noise" on the address lines, but that could be 'normal', strangely it looks like A0-A6 are more affected than A7-A15, instead of seeing a flat line on the squarewave the '1' side of it seems a bit 'wriggly' but the entity of the noise is all well above the '1' threshold and should be pretty small.

However this does not tell me a thing I am going to test with my program, as the NOP generator makes the CPU span throught the whole 64K address space it will go into the I/O space as well.

I need to try my "Loop" that stays on E000 only and see if that at some point 'accidentally' triggers some I/O address line because that is I was suspect is happening, the thing is that 'silly STA test program' definitely FAILS when the 6520 chip is inserted but works when it's not.

Which is odd.

 

[MikeS]

However this does not tell me a thing I am going to test with my program, as the NOP generator makes the CPU span throught the whole 64K address space it will go into the I/O space as well.

True; it was meant to resolve this other issue of yours:

I wonder if there could be any failure in some of those 74244 address buffers, in particular the higher one that drives A8-A15 ..

and check some of the chip select decoding.

...Which is odd.

What happens when you disable the 6520 chip select?

 

[GilesGoat]

I was about to say this but get caught by the timeout ( on the forum ).

Using my loop around E000 what I see is :

CS2 ( pin 23 ) of the PIA is identical to SELE ( it's a wave )

Pins SELF,C,D are all stuck to '1'

CS0 ( pin 22 ) of the PIA seems to be stuck in a '1' ( a bit dirty ) which is 2V, yes 2V not 5, in amplitude.

Not sure what this means, I suppose 2V is enough to be considered '1'.

Huh .. now thinking .. considering the 74154 is connected directly to the address lines and I am looping on the same range of addresses .. why /SELE is not constantly '0' ?

It shows a vaweform that is mostly 0 for all time but every now and then goes to '1' too.

[edit] - ah right, of course it does that, because it pokes in loop into the video memory which is 8000 and such.

[edit2] - I will try maybe later on to reinsert the PIA chip lifiting the CS0 pin and maybe forcing it at '1' with a resistor, but later, this were supposed to be 'holiday' I am debugging this stuff all time it's getting worse than job .. I am not taking a break with a cup of tea and a mince pie.

 

[dave_m]

CS0 ( pin 22 ) of the PIA seems to be stuck in a '1' ( a bit dirty ) which is 2V, yes 2V not 5, in amplitude.

This may be the problem. CS0 should only pulse high during the X8XX periods. The line may be open which would indicate about 1.6 volts.
-Dave