9" CRT vc 12" CRT

[dave_m]

ROM chips take some minutes to warm up, but I think they reach about 45-50°C, basing on my finger's inner thermometer

Those old NMOS ROMs run very hot. That is normal but probably a reason they fail every 30 years or so.
-Dave

 

[dave_m]

multimeter, yes; logic probe, no (to be honest I don't know what is it) but I love to learn if somebody have time and patience to teach me

Giovo,
Below is a link to a short description of a digital logic probe. They are fairly inexpensive and useful for troubleshooting main board problems if you do not have a scope.

You are doing very well and should find the cause of your PET problem soon as you have eliminated many problem areas already.

An easy way to check the complicated addressing circuit paths is to use a modified 40 pin socket to create a NOP Generator. One will place this socket under the 6502 CPU chip and it will have the effect of generating only NOP instructions which cause the address lines to increment forever. This makes it easy to trace the address paths with a scope or logic probe and look for problems. If you find a circuit node that is not pulsing, you have found an open or short circuit. Our friend Mike can tell us how to make the socket adapter by soldering a few wires to a normal 40 pin socket.

Digital logic probe

 

[MikeS]

Can't hurt to check the address lines but since it's initializing the display I suspect it's something else.

There are at least two approaches to NOP generators; the ROM socket:
http://www.6502.org/mini-projects/nop-gen/nop-gen.htm
http://homepinballrepair.com/Gottlieb80.htm
The problem with that approach is that the path to the ROM socket must be good and the data lines are still connected, which is problematic in a system like the newer PETs with soldered-in RAM.

I prefer the CPU shim socket approach:
http://home.germany.net/nils.eilers/nopgen.htm

 

[giobbi]

Can't hurt to check the address lines but since it's initializing the display I suspect it's something else.

If you mean to check every trace from pin #20 of every ROM to the DM74154N IC, I already checked them and they're ok.

I prefer the CPU shim socket approach:
http://home.germany.net/nils.eilers/nopgen.htm

Great, it seems easy, however it is in german and I don't understand which pins must to be soldered together. If you guys can give some infos about it, will be easier to me to build the socket in the right way!

Another little problem is the logic scope. To buy one will be easy, there are a lots on eBay, all cheap; the only problem is that I have to wait up to 60 days to receive it, since brazilian customs is really slow and they take up to 45 days to process a parcel. And I believe it will be quite hard to find one here in the city (I will take a look tomorrow, just in case...)

I was thinking to make one with some spare parts I have, using this schematics:

https://sites.google.com/site/lonewolfscircuits/sitefiles/LogicTester.jpg

do you think it will be good for me? And do you think I can substitute the 2n222a transistor with a 2n3904 or a bc547 I have here at home?

One more question: I read somewhere that you can also use a buzzer instead of a logic probe to identify the high or low signal? Is it correct, or is it a fake?

-- Giovi

 

[frank_DK]

Hi.
Try this thread to fix your faulty 3032.

http://www.vintage-computer.com/vcforum/showthread.php?24898-Frank-s-Danish-PET&highlight=Frank

Best regards.
Frank

 

[MikeS]

If you mean to check every trace from pin #20 of every ROM to the DM74154N IC, I already checked them and they're ok.

No, those are the chip select lines; we're talking about the 16 address lines which is what the NOP generator is for, to sequence through all possible addresses.

Great, it seems easy, however it is in german and I don't understand which pins must to be soldered together. If you guys can give some infos about it, will be easier to me to build the socket in the right way!

If Google can't translate:
"verbinde
Pin 33, 31, 29 mit 21 (GND) und
Pin 32, 30, 28, 27, 26 mit 8 (Vcc)"

Means:
"Connect
Pin 33, 31, 29 with 21 (GND) and
Pin 32, 30, 28, 27, 26 with 8 (Vcc)"
That wasn't hard, was it? ;-)
If you looked up the binary code for the 6502's NOP instruction you could even figure it out yourself ;-)

I was thinking to make one with some spare parts I have, using this schematics:

https://sites.google.com/site/lonewolfscircuits/sitefiles/LogicTester.jpg

do you think it will be good for me? And do you think I can substitute the 2n222a transistor with a 2n3904 or a bc547 I have here at home?

Not quite the way I'd do it (putting an LED and resistor directly across the test signal) but better than nothing.

One more question: I read somewhere that you can also use a buzzer instead of a logic probe to identify the high or low signal? Is it correct, or is it a fake?

Depends on what you mean by "buzzer"; we're looking at signals up to 1Mhz (1 million on-off transitions per second); I don't think the buzzer I use as a doorbell would be fast enough ;-)

I think you should look for the 2001/30xx/40xx version of the RAM/ROM diagnostic EPROM. Dave, Steve, anybody have a copy or a link? I assume that by now the F ROM is in a socket?

The thread that Frank references is an interesting read to be sure but I'm not sure it's relevant; it seems that the PIAs are good and we do have a good video system, but you never know...

 

[giobbi]

No, those are the chip select lines; we're talking about the 16 address lines which is what the NOP generator is for, to sequence through all possible addresses.
If Google can't translate:
"verbinde
Pin 33, 31, 29 mit 21 (GND) und
Pin 32, 30, 28, 27, 26 mit 8 (Vcc)"

Means:
"Connect
Pin 33, 31, 29 with 21 (GND) and
Pin 32, 30, 28, 27, 26 with 8 (Vcc)"
That wasn't hard, was it? ;-)
If you looked up the binary code for the 6502's NOP instruction you could even figure it out yourself ;-)

Well, at the address: http://home.germany.net/nils.eilers/nopgen.htm
I see a little bit different text:

Der Aufbau
Man nehme einen 40-poligen Sockel und verbinde mit zwei Dräten:
Pin 33, 31, 29 mit 21 (GND) und
Pin 32, 30, 28, 27, 26 mit 8 (Vcc)
Fertig!

and Google translated with:

the structure
Take a 40-pin socket and connect with two Dräten: (<-- ???)
Pin 33, 31, 29 to 21 (GND) and
Pin 32, 30, 28, 27, 26 8 (Vcc)
Ready!

That's strange indeed! However since in this part I'm a dummy (and it's an euphemism!) and I'm feeling a little insecure with it, I preferred ask to the Gurus

Not quite the way I'd do it (putting an LED and resistor directly across the test signal) but better than nothing.

so do you think it worth a try, or should I wait for the logic probe?
BTW, will a cheap one be ok for me? i.e. like this one with cmos/ttl and pulse/mem options?

http://www.ebay.it/itm/1pc-EISTAR-D...869?pt=LH_DefaultDomain_0&hash=item27d094a06d

if you think it's ok, I will order it immediately, so at least if after two months this thread will be open yet, I will be better equipped!

Depends on what you mean by "buzzer"; we're looking at signals up to 1Mhz (1 million on-off transitions per second); I don't think the buzzer I use as a doorbell would be fast enough ;-)

well, I intended they told about piezoelectric buzzer, but looking at facts from your point of view, it doesn't sound like a good idea

I think you should look for the 2001/30xx/40xx version of the RAM/ROM diagnostic EPROM. Dave, Steve, anybody have a copy or a link? I assume that by now the F ROM is in a socket?
The thread that Frank references is an interesting read to be sure but I'm not sure it's relevant; it seems that the PIAs are good and we do have a good video system, but you never know...

I found this interesting site:
http://www.dansretropod.com/commodore/pet-cbm-3032.aspx
telling about a diagnostic ROM, but there isn't any link to a .bin file. I sent an email to the guy asking the .bin file but I don't know if he dumped the ROM in a .bin file and/or he want to share it with us.

If somebody of you has a diagnostic .bin image, my eprom burner is waiting I looked on Zimmers but I didn't find anything. However I'm going to do a better search on the web right now!


--- Frank, thank you for the link, it's quite interesting and I bookmarked it. However my situation is a bit different... I already changed every chip on the board and I have replacement for all of ICs and a way to test RAM, PIA, VIA and CPU. But that thread gave me the idea to test the board on the 8032 case: we can now exclude the power supply (traf + huge capacitor) from the equation.


I will never get tired to thank you for the big effort and the help you're giving me, in the sunday too!
Giovi


-----------------EDIT----

A friend suggested me to put a reset switch from IC 555 pin 2 to the ground. It seems that somebody in the past did the trick, since there was evidence of solder on C68 capacitor. It didn't help a lot, since the screen remains black after tapping the reset button. At least we have one information more: the reset doesn't makes the garbage screen appear again

The reset button made me remember I read something in the past about a monitor switch, so I googled for a while and I found this info:

http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.cbm/2007-06/msg00431.html

that leaded me to this schematics:


I tried this with this result:

- the garbage stays on the screen until I tap the button, then it turns the display to black screen.
- keeping the button pressed, it doesn't enter in the monitor mode.

maybe this info would be useful for somebody that has enough knowledge to decipher it...

 

[Dr Jefyll]

Hi, everyone!
Giovi & I were yacking over on 6502.org, and he only just now admitted what a nice party is happening here on VCF! And Mike Stein! -- 'zat you? Jeff Laughton here! I'm VERY glad to see you on the case, as I have no CBM background, and have only been offering general advice.

well, I intended they told about piezoelectric buzzer, but looking at facts from your point of view, it doesn't sound like a good idea

Okay, this approach can't promise miracles, but I used to use it extensively in the old days. (Instead of a piezo buzzer, I connected to the input of a small guitar amp). Like a logic probe, the audio approach will give you an indication whether a signal is present or absent. But, like a logic probe, it offers almost no clue as to whether the signal is right or what it means. Still, "signal present or absent" can be darn useful information.

Unfortunately the audio approach (buzzer/guitar amp) will sometimes indicate there is no signal when in fact there is -- a false negative. But false positives are not a problem. Amp or buzzer, make your connection using a resistor -- 2K or 5K maybe? -- so as to minimize loading on the circuit you're trying to monitor.

As for logic probes, you can make one out of a one-shot IC such as 74LS221. Add a resistor, capacitor, LED; apply 5 volts...

I used to use the guitar amp approach to troubleshoot "Elka" brand electronic accordions -- which, as you may know, Giovi, are made in Italy! The digital data stream was in the hundreds of kilohertz range, which sounds as if it'd be impossible to hear, yet the ear was able to perceive the subharmonics I guess. These were complex signals, not just a monotonic square wave (such as the NOP generator will produce). OTOH, using the NOP generator will cause some of the CPU address lines (the most-significant ones) to produce signals that actually ARE in the audible range.

Cheers,
Jeff

 

[MikeS]

Hey, Dr. Jefyll! Fancy meeting you here; with you and Dave on board we oughta have this baby licked in no time. Hope we can get together over a cold one soon!

As a matter of fact I was going to try that very thing a little later this evening, probing address lines etc. with an audio amplifier to see if one could hear meaningful subharmonics, but I understood Giovi's "buzzer" to be a simple on/off tester that lets you focus on the test point, like an audible continuity tester. Sorry about my crack about the doorbell though ;-)

@ Giovi:

"the structure
Take a 40-pin socket and connect with two Dräten: (<-- ???)"

Actually translates as:
"Assembly:
Take a 40-pin socket and connect with two pieces of wire:"

I thought that was obvious so I left out the "pieces of wire" but you're right, one should never take things for granted even when they seem obvious.

Yes, a RESET button is very useful, especially a two-function one; I have one on several of my PETs. Unfortunately whatever is keeping your PET from starting fully is probably also keeping it from activating the monitor when the diagnostic pin is enabled, so, no, unfortunately that doesn't tell us anything useful.

I was hoping Dave, Steve or Eudi would check in because I believe they have versions of the RAM/ROM test EPROM; I'll attach some images that I have but I don't know what they are and can't test them at the moment; one is probably for the 4032/8032 with CRTC.

View attachment 2kpettest.txt
View attachment pet-memtest.txt
View attachment pet-memtestx.txt
View attachment 2kromshow.txt

I'm confused: doesn't the screen turn black by itself when you turn on the PET? Do you have to tap the RESET button?

Have you double-checked the pins and connections on the three I/O chips? Nothing bent or corroded?

What voltage do you measure on the CPU's SYNC pin (pin 7) ?

 

[giobbi]

A very quick answer to your last question, then I will read the last posts carefully and I will answer, if the noisy thunderstorm that's passing over my head will leave me to answer now

- Without the reset button connected, I have a 1" garbage, than black screen
- with the simple reset button (n.o. switch between 555 pin #2 and ground), again, I have a 1" garbage, than black screen (same behaviour)
- with the reset/diagnostic button (capacitor + switch) I have a garbage screen; I have to tap the reset button to get a black screen.

For not to change the environement during a diagnosis, I removed the reset/diagnostic and simply left the normal reset switch (that means no difference until the switch is pressed).

Cpu voltage: 1.28 at pin #7

I/O chips: are they the MC3446 ones? In this case I checked them (pin, integrity) and I tested on the 8032. No strange behaviour, but I didn't check if the user ports are working properly on the 8032 with these ICs.

 

[giobbi]

A very silly question about logic probe:

do you think it's possible to use a impedance transformer (or an opto-isolator) to transport the logic signal to the line-in of the Soundblaster and analyze it in some way, managing it as an audio wave? Something like this:

IC pin <------(((primary traf)))--/\/\es. 1kohm/\/\----> gnd
| |
PC line-in + ---(secondary traf)----PC line in -

Silly idea? Well, at least you are warned about my lack of knowledge

--EDIT: of course it's silly, we are talking about MHz, not udible and most probably not managed by the soundblaster line-in...

 

[giobbi]

Hi, everyone!
Giovi & I were yacking over on 6502.org, and he only just now admitted what a nice party is happening here on VCF!

Sorry, it took a while to realize I was being quite impolite splitting the thing on two different forums. I apologize for that...

Okay, this approach can't promise miracles, but I used to use it extensively in the old days. (Instead of a piezo buzzer, I connected to the input of a small guitar amp). Like a logic probe, the audio approach will give you an indication whether a signal is present or absent. But, like a logic probe, it offers almost no clue as to whether the signal is right or what it means. Still, "signal present or absent" can be darn useful information.

Unfortunately the audio approach (buzzer/guitar amp) will sometimes indicate there is no signal when in fact there is -- a false negative. But false positives are not a problem. Amp or buzzer, make your connection using a resistor -- 2K or 5K maybe? -- so as to minimize loading on the circuit you're trying to monitor.

As for logic probes, you can make one out of a one-shot IC such as 74LS221. Add a resistor, capacitor, LED; apply 5 volts...

Have you any schematics for that? I can take a look next days if in the local electronic store I can find one of those ICs...

"Elka" brand electronic accordions -- which, as you may know, Giovi, are made in Italy!

of course I know!

Well, it seems you're really determinated to help this poor dummy without knowledge to fix this 34 years old little boy
Thank you again! You can't imagine, after 12 years, how much will be huge my satisfaction when I will see the "READY" prompt on the screen ... probably you will never know because when it will happen I will die of heart-attack :D

 

[MikeS]

- Without the reset button connected, I have a 1" garbage, than black screen
- with the simple reset button (n.o. switch between 555 pin #2 and ground), again, I have a 1" garbage, than black screen (same behaviour)

Sounds good!

- with the reset/diagnostic button (capacitor + switch) I have a garbage screen; I have to tap the reset button to get a black screen.

Not sure if that's normal (I do it differently), but not relevant since it's disconnected.

For not to change the environement during a diagnosis, I removed the reset/diagnostic and simply left the normal reset switch (that means no difference until the switch is pressed).

Cpu voltage: 1.28 at pin #7

Sounds good. Looks like the system is running more or less normally but stuck in a loop somewhere that's keeping it from completing the startup sequence.

I/O chips: are they the MC3446 ones? In this case I checked them (pin, integrity) and I tested on the 8032. No strange behaviour, but I didn't check if the user ports are working properly on the 8032 with these ICs.

No, sorry, I meant the 6520s and the 6522; I know you've checked them, but you never know. The PET is apparently starting properly, initializing memory and the display, and then getting stuck; could be when it tries to initialize the I/O ports.

No problem cross-posting as far as I'm concerned; the point is to get the PET fixed and the more ideas the better.

 

[giobbi]

Not sure if that's normal (I do it differently), but not relevant since it's disconnected.

Have you any schematics about how to make a reset/diagnostic switch? I could make it and see if something happens (i.e. some diagnostic mode or something else).

No, sorry, I meant the 6520s and the 6522; I know you've checked them, but you never know. The PET is apparently starting properly, initializing memory and the display, and then getting stuck; could be when it tries to initialize the I/O ports.

Double check is never a bad idea
Well, since we can extract the two 6520 and we can assume the sockets can be stained but they can't be shortened, the only dubt is about the 6522, I think.
So, just to be sure, I changed the 6522 socket with a fresh one, and I checked the board without 6520 and with two different 6522 ICs.
Still alive, no heart attack: the board isn't working yet... :-(

Of course if any of you have any idea about some test/check I should do please tell me, I run out of ideas...

Mike, I downloaded the ROM images you attached in your previous post, but they aren't recognized by the eprom programmer software. I assumed you attached them as .txt file for some forum attachment rule and I renamed them as .bin archive... is it correct?

btw tomorrow I will try to take a time to search for a logic probe, downtown.

-- Giovi


-------EDIT:
not sure if it's useful, but may years ago I bought this: http://vic-20.de/x1541/hardware/petram.html and this: http://vic-20.de/x1541/hardware/2364.html
Can't remember why, maybe because that time it seemed an easier and cheaper way than eprom programmer.

 

[MikeS]

Have you any schematics about how to make a reset/diagnostic switch? I could make it and see if something happens (i.e. some diagnostic mode or something else).

I don't think it will help at this point; if you hold the diagnostic pin low when you release the RESET then the monitor program should come up (as it also will if the processor hits an invalid instruction IIRC) but in order for that to happen the CPU has to execute the relevant instructions and it looks like right now it's getting stuck in a loop somewhere, either because it's waiting for something or because it's read an incorrect instruction somewhere.

Yes, those should be .bin files except for the .A65 source file; what does your programmer expect? If it needs a HEX file there are conversion programs, but I'd be surprised if it can't handle a raw .bin file as well.

I don't have a 3032 myself and my 2001s are in pieces at the moment so I can only try out the CRTC (4032/8032) version

 

[dave_m]

Yes, those should be .bin files except for the .A65 source file; what does your programmer expect? If it needs a HEX file there are conversion programs, but I'd be surprised if it can't handle a raw .bin file as well.

I don't have a 3032 myself and my 2001s are in pieces at the moment so I can only try out the CRTC (4032/8032) version

Mike and Gioggi,

The petester.bin file can be downloaded here: petester.bin

This is the 4K version and needs to be programmed into a 2532 EPROM. If you can't program a 2532, I can send you a programmed chip.

It will work on 3032 class machines (no CRTC chip). The version I modified for 8032 PETs that initializes the CRTC apparently does not work according to someone who tried it (I hand assembled it and apparently messed it up). Now that you sent me the PET Assembler, Mike I need to redo the code.

 

[giobbi]

Mike and Gioggi,

The petester.bin file can be downloaded here: petester.bin

This is the 4K version and needs to be programmed into a 2532 EPROM. If you can't program a 2532, I can send you a programmed chip.

It will work on 3032 class machines (no CRTC chip). The version I modified for 8032 PETs that initializes the CRTC apparently does not work according to someone who tried it (I hand assembled it and apparently messed it up). Now that you sent me the PET Assembler, Mike I need to redo the code.

Dave,
thank you for that, I will do a try this evening. I can't program a 2532 but I will program a 2732 and use the 2732->2532 adapter... is it ok or are there some incompatibilites doing that? If not, what is the right way to proceed? Remove all the ROM (except for char ROM?) and put this one in which socket, Kernal?

I don't think it will help at this point; if you hold the diagnostic pin low when you release the RESET then the monitor program should come up (as it also will if the processor hits an invalid instruction IIRC) but in order for that to happen the CPU has to execute the relevant instructions and it looks like right now it's getting stuck in a loop somewhere, either because it's waiting for something or because it's read an incorrect instruction somewhere.

Ok I will ask you again about the reset/diagnostic button later, when it will be fix

Yes, those should be .bin files except for the .A65 source file; what does your programmer expect? If it needs a HEX file there are conversion programs, but I'd be surprised if it can't handle a raw .bin file as well.

My Eprom programmer accepts .bin, of course. I don't know why it doesn't recognize them. If we'll plan to use them, can you zip them and attach the zip file, just to be sure about the integrity?

I have to go, but I will be back in few hours

 

[giobbi]

The petester.bin file can be downloaded here: petester.bin
This is the 4K version and needs to be programmed into a 2532 EPROM. If you can't program a 2532, I can send you a programmed chip.

It will work on 3032 class machines (no CRTC chip). The version I modified for 8032 PETs that initializes the CRTC apparently does not work according to someone who tried it (I hand assembled it and apparently messed it up). Now that you sent me the PET Assembler, Mike I need to redo the code.

Dave,
thank you for that, I will do a try this evening. I can't program a 2532 but I will program a 2732 and use the 2732->2532 adapter... is it ok or are there some incompatibilites doing that? If not, what is the right way to proceed? Remove all the ROM (except for char ROM?) and put this one in which socket, Kernal?

I don't think it will help at this point; if you hold the diagnostic pin low when you release the RESET then the monitor program should come up (as it also will if the processor hits an invalid instruction IIRC) but in order for that to happen the CPU has to execute the relevant instructions and it looks like right now it's getting stuck in a loop somewhere, either because it's waiting for something or because it's read an incorrect instruction somewhere.

Ok I will ask you again about the reset/diagnostic button later, when it will be fix

Yes, those should be .bin files except for the .A65 source file; what does your programmer expect? If it needs a HEX file there are conversion programs, but I'd be surprised if it can't handle a raw .bin file as well.

My Eprom programmer accepts .bin, of course. I don't know why it doesn't recognize them. If we'll plan to use them, can you zip them and attach the zip file, just to be sure about the integrity?

I have to go, but I will be back in few hours

EDIT --- it seems for some reason a moderator need to approve my post, boooh? I hope you can read it.

 

[giobbi]

Mike and Gioggi,

The petester.bin file can be downloaded here:

petester.bin

This is the 4K version and needs to be programmed into a 2532 EPROM. If you can't program a 2532, I can

send you a programmed chip.

It will work on 3032 class machines (no CRTC chip). The version I modified for 8032 PETs that

initializes the CRTC apparently does not work according to someone who tried it (I hand assembled it and

apparently messed it up). Now that you sent me the PET Assembler, Mike I need to redo the code.

Dave,
thank you for that, I will do a try this evening. I can't program a 2532 but I will program a 2732 and

use the 2732->2532 adapter... is it ok or are there some incompatibilites doing that? If not, what is

the right way to proceed? Remove all the ROM (except for char ROM?) and put this one in which socket,

Kernal?

I don't think it will help at this point; if you hold the diagnostic pin low when

you release the RESET then the monitor program should come up (as it also will if the processor hits an

invalid instruction IIRC) but in order for that to happen the CPU has to execute the relevant

instructions and it looks like right now it's getting stuck in a loop somewhere, either because it's

waiting for something or because it's read an incorrect instruction somewhere.

Ok I will ask you again about the reset/diagnostic button later, when it will be fix

Yes, those should be .bin files except for the .A65 source file; what does your programmer expect? If it

needs a HEX file there are conversion programs, but I'd be surprised if it can't handle a raw .bin file

as well.

My Eprom programmer accepts .bin, of course. I don't know why it doesn't recognize them. If we'll plan

to use them, can you zip them and attach the zip file, just to be sure about the integrity?

I have to go, but I will be back in few hours

 

[giobbi]

Sorry for the long delay, I answered some hours ago but it told me I can't answer directly and I have to wait the forum moderator's approval. Boooh?
I will try just one more time changing a little bit the syntax, maybe it's just a forum bug...

>Dave - :The petester.bin file can be downloaded here:

Dave,
thank you for that, I will do a try this evening. I can't program a 2532 but I will program a 2732 and use the 2732->2532 adapter... is it ok or are there some incompatibilites doing that? If not, what is the right way to proceed? Remove all the ROM (except for char ROM?) and put this one in which socket, Kernal?

Mike - : don't think it will help at this point; if you hold the diagnostic pin low when you release the RESET then the monitor program should come up (as it also will if the processor hits an invalid instruction IIRC) but in order for that to happen the CPU has to execute the relevant instructions and it looks like right now it's getting stuck in a loop somewhere, either because it's waiting for something or because it's read an incorrect instruction somewhere.

Ok I will ask you again about the reset/diagnostic button later, when it will be fix

Mike - :Yes, those should be .bin files except for the .A65 source file; what does your programmer expect? If it needs a HEX file there are conversion programs, but I'd be surprised if it can't handle a raw .bin file as well.

My Eprom programmer accepts .bin, of course. I don't know why it doesn't recognize them. If we'll plan to use them, can you zip them and attach the zip file, just to be sure about the integrity?