• Please review our updated Terms and Rules here

Memory problem with PET 2001

grbrady

Experienced Member
Joined
Oct 10, 2020
Messages
101
Location
Baltimore, MD
Hi There,

I'm working on a PET 2001-16B (2001N motherboard with "business" keyboard, "CBM 2001 Series" branding on the front label.) After a long time of replacing bad ICs, sockets and remediating corroded solder, etc., it seemed like I had it all working and I was ready to put it back in the case. However, when I put it in the case, instead of showing ~15k bytes free it shows 45 bytes free. When I first started troubleshooting this the problem was intermittent and seemed like tilting the board one way or another would cause it to start up seeing the full complement of memory, which makes me suspect a bad solder joint or other poor connection somewhere. However, I can't seem to find it. All the address lines from the CPU, through the buffers, muxes and resistors seem to have good continuity and I've reflowed all those joints. I've swapped around and replaced the buffers and muxes as well and don't see any change.

I have also probed all of the address and data lines with an oscilloscope and don't see anything terribly unusual. Signals seem to be present where I would expect to see them, although the high logic level is only typically about 4 V, but I think this should be fine for TTL logic.

I've also run PETTEST v.4 on the machine. It got past the countdown and into the memory test, but finds an error shortly thereafter. However, the address and bit at which it finds the error seems kind-of random. Example output from a series of attempts:

mem fail 0 0 02f7 02 42!
mem fail 1 0 0275 80 7f!
mem fail 0 0 206e 20 20!
mem fail 1 0 0275 04 ff!
mem fail 1 0 042e 01 08!
mem fail 0 0 02f7 80 00!
mem fail 1 0 042e 02 09!
mem fail 1 0 042e 02 09!

Looking at this now, I see a few addresses up there multiple times which might be significant.

I have not replaced the memory yet, although I have piggy-backed 4116s on all of the memory chips without any change. Is my best bet to start socketing and swap out the memory? Is there anything more I should try short of that?

Can anyone suggest any strategies for figuring this out?

Thanks,
Greg
 
As this is your first post, welcome to VCFED...

Don’t forget to put your location in your profile. You may find some knowledgeable VCFED members close by.

Also, your posts will be moderated for a period of time, so there will be a delay between your post and it appearing. The mods. are busy people, and don’t get paid, but it keeps the spam very, very low as a result...

Did you download the PDF documentation that goes with my PETTESTER to enable you to decode the data bit at fault? If not, that will help. EDIT: You did specifically mention bit in your original post...

4V TTL signals are just too low though. They should be 4.75V minimum (ideally).

Have you checked all of the power supply rails for both dc voltage level and ripple?

You have a random smattering of bits (0, 1, 2, 5 and 7) with faulty bits both high and low.

I would checkout the power supplies first and then check the DRAM refresh signal and counters before swapping the RAM. That would be my recommendation at any rate. I will lookup the schematic later...

Dave
 
Last edited:
I added a little info on my profile. Also, I did download and read through the documentation, at least enough that I think I understand the output from the memory test error.

The power rails seem good. On a memory IC they are -5.1 V, +12.26 V and +4.99 V. The ripple on the +/- 5 V lines is around 10 mV and is about 30 mV on the 12 V line. At the far end of the board (near the CPU, other regulator than what supplies the memory, I believe) the +5V rail is 5.01 V and the ripple is about the same. Note that all the regulators are new as the old ones were badly corroded and, except for one of the two 5 V regulators, gave crazy voltages. So I replaced them all.

I have looked at the address counters and CAS and RAS signals in the past and didn't see anything too worrisome (other than low logic levels) but I will revisit them.

I was initially worried a bit about the low logic levels, but after a while I felt like I was chasing my tail trying to fix it when TTL spec is above 2.75 V for a high.

Things that I didn't mention that I find concerning but didn't think were core to this problem. When I measure the resistance between Vcc and GND on the socket of an arbitrary logic IC it's usually about 20 Ohms. Not a dead short and the regulators seem to be able supply enough current to keep the voltage at 5V. But, low enough that my meter thinks there's continuity between Vcc and GND. Should that resistance be higher?

Another possible anomaly is that the _INIT line is at a steady 2.6 V when measured at the low side of the pullup resistor R12 (and at the ICs I've measured it at.) This implies to me that the input impedance of at least one of the multitude of flip-flops, etc, that line is connected to is pretty low. Or there's a short in the board somewhere. Or something's trying to pull it low for some reason and can't. I haven't figured out a good way to figure this out, though.

Thanks again for any help,
Greg
 
4V TTL signals are just too low though. They should be 4.75V minimum (ideally).

That's wrong.
TTL valid High levels start at 2.7V. Often in these old machines, H levels are around 3.5V. 4V is a solid high and perfectly reasonable on mixed 74LS and 74 families.

Frank IZ8DWF
 
Thanks Frank.

Brain fade - too much turkey and wine I fear :).

You are 100% correct about the TTL levels.

I was obviously thinking about the power rails rather than the logic levels.

Dave
 
So, I have had a look at your error data posted back in #1 in a little more detail - and believe the problem is data reading/writing in a 'semi random' manner.

My testing for errors in pages 0 and 1 of the RAM is not very good - so I am going to introduce a more thorough test of these important memory locations in a later release. Unfortunately, the RAM in pages 0 and 1 can be working good enough to 'fool' the simple test - but not good enough to function correctly with the more thorough DRAM test. Generally, the test itself just fails - but there is the possibility of erroneous error reports - and it is this that I think is happening here...

For example, test 0 fills all of memory with a 'sea' of '0' bits and then checks to see if they are '0'. Conversely, test 1 fills all of memory with a 'sea' of '1' bits and then checks to see if they are '1'.

I would therefore expect a test 0 to return with some '1' bits in the byte reported and a test 1 to return with some '0' bits in the byte reported. At least one of those bits should match with the mask.

However, in some of your error reports this is not the case. For example:

>>> mem fail 0 0 02f7 80 00!

In this case (test 0) we are expecting a 00 byte and a 00 byte was reported. This is correct!

>>> mem fail 1 0 0275 04 ff!

In this case (test 1) we are expecting a ff byte and a ff byte was reported. This is also correct!

During both of these tests - the bit related to the mask (80 for the first case and 04 for the second case) must have read the opposite of what was expected - but it is subsequently reported correctly.

The test reads and detects the error and then reads the memory byte again to report the error. Somewhere in between these two reads the value has either changed, or the original value (the one read to perform the test) misread.

If you now view the error reports with this in mind - you can see a number of other discrepancies with the bits... Test 0 = 00 expected. Test 1 = ff expected.

>>> mem fail 0 0 206e 20 20!

Is this address a typo.? Should it be 026e by any chance.

Just out of interest, during the countdown phase, do the ROM checksums read consistently correct?

The fact that you have actually got BASIC to boot up (but it reports an incorrect amount of RAM) is also a good indication that something is marginal (to my way of thinking).

Starting with the power supply rails (dc voltage levels and ripple) is still a good way to proceed though.

You say you have been 'probing around with an oscilloscope' and looked at the MUX, buffers and RAM. But 'looking' just tells us if a signal is there or not (stuck bit) or looks 'horrid' indicating a faulty bit. Have you tried with (say) a NOP generator to generate the whole address range (in the address bus) and checked that each address line is correct as it traverses through the address buffers and RAM MUX devices?

Incidentally, the MUX and RAM buffers are known to be weak points - as is the 4116 DRAM devices (unfortunately).

Faulty refresh circuitry (schematic sheet 6 of 9) can also be problematic as the DRAM contents can become 'flakey'...

You may want to check the RAx signals and make sure they are all there, count correctly in binary and traverse through the RAM MUXes OK.

Dave
 
Last edited:
I've been working on this problem and seem to have made negative progress.

Using the PETTEST ROM I now don't get past the 0/1 page tests and get a screen showing most of that RAM to be bad. The characters shown in the second 256 characters aren't exactly random, but I get a long string of, for example, f's followed by a long string of reverse tone b's, sometimes @'s, sometimes reverse tone f's and regular b's, an occasional d and once in a while a the desired ".".

Regarding Dave's last post

> >>> mem fail 0 0 206e 20 20!
> Is this address a typo.? Should it be 026e by any chance.
No, I checked the screen photo I took and it was indeed 206e

> Just out of interest, during the countdown phase, do the ROM checksums read consistently correct?

The ROM checksums are steady and seemed to be correct the last time I got that far. I will pull them and verify again with my burner. Oh, except for the "B" ROM, which isn't installed on this machine. It fluctuates around a bit.

> Starting with the power supply rails (dc voltage levels and ripple) is still a good way to proceed though.
I had already double checked those and reported in an earlier post. On a memory IC they are -5.1 V, +12.26 V and +4.99 V. The ripple on the +/- 5 V lines is around 10 mV and is about 30 mV on the 12 V line. Near the CPU the +5V rail is 5.01 V and the ripple is about 10 mV.

> You say you have been 'probing around with an oscilloscope' and looked at the MUX, buffers and RAM. But 'looking' just tells us if a signal is there or not (stuck bit) or looks 'horrid' indicating a faulty bit. Have you tried with (say) a NOP generator to generate the whole address range (in the address bus) and checked that each address line is correct as it traverses through the address buffers and RAM MUX devices?

I put together a NOP generator and followed the address lines from the CPU through to the input of the address MUX and got the expected square waves with the frequency increasing by a factor of 2 with each higher address bit. The square waves looked clean and the logic levels went from about 0 to about 4 V. I also looked at the output of the refresh counters and saw generally the same thing up to the MUX. The output of the MUX is more complicated to understand since we're switching between multiple address sources, but it did not look horrid. The _RAS, _CAS and _WE signals all look sensible as well-formed square waves, as well.

What does not look very nice are the data bits between output of the 74LS244 buffers and the memory chips. The signals seem like they're either more or less stuck low or stuck high but with a lot of noise around the nominal logic level. I only have a simple analog scope, so what I can tell here is somewhat limited without being able to sample. However the waveforms look much, much worse than those on the other side of the buffers. To get this far with this board I already had to replace those buffers (old ones were totally dead) so it was easy to swap those as a test, but that didn't help. As another test I socketed and swapped one of the RAM chips (I2, the MSB I think) and it's waveforms seems to be cleaner than the others. I think I'm going to go ahead and socket the other 7 RAM chips. Really, after the number of chips that I've had to remove and socket to get this board this far, it's not a huge amount more work. Between fixing corrosion on the PCB, replacing badly rusted or corroded chips, replacing plain dead chips and replacing wonky sockets, I've probably had to do well over 20 chips so far.

In my last post I also commented on two unusual things. The first was that the _INIT line voltage was quite low, about 2.6V. I traced this to the character ROM. The CS3 pin seems to be trying to pull this line low. I'm not sure if that's by design or not. However, I did pull the ROM and burned another 2716 as a character ROM, but it behaves the same way. Without the character ROM the _INIT line is about 4.9 V. I have no idea if this is expected behavior.

The other anomaly was that the resistance between 5V and GND was only about 20 ohms. Feeling around the board, I found that 2 ceramic 0.1µF decoupling capacitors seemed a bit hot, so I cut the leads to those and the 5V-GND resistance increased to about 50 ohms, still lower than I might have expected, but at least my meter can tell that Vcc and GND are different lines now. Those caps measured about 70 ohms resistance. I can't feel any other suspiciously hot components, but I'm using this as an excuse to get an IR camera so I can look more systematically.

Again, any help anyone can offer is appreciated,
Greg
 
Continuing with the trend of making negative progress, now I can't seem to get it to talk to the ROM. I get random characters on the screen. If I use my Tynemouth ROM/RAM board it comes up ok, but I can't get PETTEST or the stock ROMs to work. I've checked the ROMs on my burner and they seem correct.

I'd be happy with the ROM/RAM board driving things, at least in the short term, but since this PET has the "business" keyboard it doesn't seem to read the keyboard matrix correctly.

I'm starting to lose my patience with this thing. I know it's probably something stupid I did, but I just wish I could figure out what! (Or, rather, which of the many stupid things I did are causing problems and which are benign stupid things.)

Greg


I've been working on this problem and seem to have made negative progress.

Using the PETTEST ROM I now don't get past the 0/1 page tests and get a screen showing most of that RAM to be bad. The characters shown in the second 256 characters aren't exactly random, but I get a long string of, for example, f's followed by a long string of reverse tone b's, sometimes @'s, sometimes reverse tone f's and regular b's, an occasional d and once in a while a the desired ".".

Regarding Dave's last post

> >>> mem fail 0 0 206e 20 20!
> Is this address a typo.? Should it be 026e by any chance.
No, I checked the screen photo I took and it was indeed 206e

> Just out of interest, during the countdown phase, do the ROM checksums read consistently correct?

The ROM checksums are steady and seemed to be correct the last time I got that far. I will pull them and verify again with my burner. Oh, except for the "B" ROM, which isn't installed on this machine. It fluctuates around a bit.

> Starting with the power supply rails (dc voltage levels and ripple) is still a good way to proceed though.
I had already double checked those and reported in an earlier post. On a memory IC they are -5.1 V, +12.26 V and +4.99 V. The ripple on the +/- 5 V lines is around 10 mV and is about 30 mV on the 12 V line. Near the CPU the +5V rail is 5.01 V and the ripple is about 10 mV.

> You say you have been 'probing around with an oscilloscope' and looked at the MUX, buffers and RAM. But 'looking' just tells us if a signal is there or not (stuck bit) or looks 'horrid' indicating a faulty bit. Have you tried with (say) a NOP generator to generate the whole address range (in the address bus) and checked that each address line is correct as it traverses through the address buffers and RAM MUX devices?

I put together a NOP generator and followed the address lines from the CPU through to the input of the address MUX and got the expected square waves with the frequency increasing by a factor of 2 with each higher address bit. The square waves looked clean and the logic levels went from about 0 to about 4 V. I also looked at the output of the refresh counters and saw generally the same thing up to the MUX. The output of the MUX is more complicated to understand since we're switching between multiple address sources, but it did not look horrid. The _RAS, _CAS and _WE signals all look sensible as well-formed square waves, as well.

What does not look very nice are the data bits between output of the 74LS244 buffers and the memory chips. The signals seem like they're either more or less stuck low or stuck high but with a lot of noise around the nominal logic level. I only have a simple analog scope, so what I can tell here is somewhat limited without being able to sample. However the waveforms look much, much worse than those on the other side of the buffers. To get this far with this board I already had to replace those buffers (old ones were totally dead) so it was easy to swap those as a test, but that didn't help. As another test I socketed and swapped one of the RAM chips (I2, the MSB I think) and it's waveforms seems to be cleaner than the others. I think I'm going to go ahead and socket the other 7 RAM chips. Really, after the number of chips that I've had to remove and socket to get this board this far, it's not a huge amount more work. Between fixing corrosion on the PCB, replacing badly rusted or corroded chips, replacing plain dead chips and replacing wonky sockets, I've probably had to do well over 20 chips so far.

In my last post I also commented on two unusual things. The first was that the _INIT line voltage was quite low, about 2.6V. I traced this to the character ROM. The CS3 pin seems to be trying to pull this line low. I'm not sure if that's by design or not. However, I did pull the ROM and burned another 2716 as a character ROM, but it behaves the same way. Without the character ROM the _INIT line is about 4.9 V. I have no idea if this is expected behavior.

The other anomaly was that the resistance between 5V and GND was only about 20 ohms. Feeling around the board, I found that 2 ceramic 0.1µF decoupling capacitors seemed a bit hot, so I cut the leads to those and the 5V-GND resistance increased to about 50 ohms, still lower than I might have expected, but at least my meter can tell that Vcc and GND are different lines now. Those caps measured about 70 ohms resistance. I can't feel any other suspiciously hot components, but I'm using this as an excuse to get an IR camera so I can look more systematically.

Again, any help anyone can offer is appreciated,
Greg
 
Are you able to substitute just $F000-$FFFF i.e. D9 using your ROM/RAM replacement board with your PETTEST ROM in D8?

You might have a bad Kernel ROM? Can you confirm which part# you currently have in D9?

There are other options too... the PET RAM could be contending with the PET ROM... there's not much logic there... B2 and G7 aided and abeited by I10 and I11...

Probably best to work incrementally with the ROM/RAM Board first.

Oh... and although it might be obvious... if you are making -ve progress then maybe you have dodgy/marginal sockets... particular D8 and D9... dodgy sockets or pins that don't register correctly (e.g. pins that get away from you and don't engage properly) are excellent ways to get odd behaviour...
 
Last edited:
Yes, the only thing that would prevent my PETTESTER from working would be the kernal ROM or an address selection fault.

When you say that you had problems with the voltage regulators, was the output voltage high or low? High could be bad news...

The voltage level of /INIT could be a problem. Having one pull-up resistor for so many ICs is just poor design! You could try reducing the value of this resistor a bit to increase the voltage. You can do this by paralleling the existing resistor with another one - suitably calculated.

Are you able to post a photograph of the oscilloscope trace of the RAM data bus you were seeing?

Be positive, we have got machines in a worse state than yours working... And that was with people who didn’t know anything about electronics before hand. You appear to know what you are talking about! We just have to work out what is going on in a systematic manner.

So, we appear to have good power rails?

Have you checked the /RESET line on power-up to ensure we are getting a healthy reset?

The data sheet for a 2716 states that pin 21 is VPP and this pin can draw 5mA from the supply. This is not a logic pin. On the original ROM it was an active high chip select logic pin... This may account for why the /INIT line is being dragged down. It may also affect the operation of the character generator?

Dave
 
Last edited:
Are you able to substitute just $F000-$FFFF i.e. D9 using your ROM/RAM replacement board with your PETTEST ROM in D8?

If he has the Tynemouth board with the nine switches, he can have switches 3,4,5 set to off, on, off which will replace all ROMs with the Tynemouth board except for the Editor in which he can place the PETTEST EPROM.

If this does not work, then you are right, he may have a bad D8 socket/connection. If it works, then with this same configuration, he can use an Editor ROM set up for the business keyboard in the D8 socket. The Edit file for this is called EDIT-2-b.901474-01.bin as found here. http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/index.html. This should be programmed into a 2716 EPROM which is pin-compatible with the D8 socket.

-dave_m
 
Are you able to substitute just $F000-$FFFF i.e. D9 using your ROM/RAM replacement board with your PETTEST ROM in D8?
No, the Tynemouth board is all the ROMs or none. Maybe I should get a Romulator?[/QUOTE]

You might have a bad Kernel ROM? Can you confirm which part# you currently have in D9?
I have 901465-03 burned on a 2532 EPROM. It's possible that it's good but it reads and verifies fine on my EPROM programmer. I'll burn another and see what happens, maybe it's a marginal part or something.

There are other options too... the PET RAM could be contending with the PET ROM... there's not much logic there... B2 and G7 aided and abeited by I10 and I11....
Right now I'd be happy getting the ROM working. I hadn't considered looking at B2 or G7 yet, although the address bus looks generally ok

Probably best to work incrementally with the ROM/RAM Board first..
Absolutely. In an attempt to do this I disconnected the RAM, and well everything but the PIAs, VIA, and ROMs, from the data bus by pulling E9 and E10. Is that a sound approach?

Oh... and although it might be obvious... if you are making -ve progress then maybe you have dodgy/marginal sockets... particular D8 and D9... dodgy sockets or pins that don't register correctly (e.g. pins that get away from you and don't engage properly) are excellent ways to get odd behaviour...
That's occurred to me too, I've installed new sockets at D9 and D8 and beeped all the pins out back to the CPU.

Thanks for the suggestions, a couple of things I can try there.
Greg
 
Yes, the only thing that would prevent my PETTESTER from working would be the kernal ROM or an address selection fault.
Ok, that's good to know.


When you say that you had problems with the voltage regulators, was the output voltage high or low? High could be bad news...
They were substantially high and between that and corrosion I've had to replace the majority of the ICs. But as I said, I previously had it working with the new regulators and the replaced logic ICs so I wouldn't expect widespread failures any more.

The voltage level of /INIT could be a problem. Having one pull-up resistor for so many ICs is just poor design! You could try reducing the value of this resistor a bit to increase the voltage. You can do this by paralleling the existing resistor with another one - suitably calculated.
Good suggestion and something I was considering, but since the character ROM was working fine I put it on the back burner.

Are you able to post a photograph of the oscilloscope trace of the RAM data bus you were seeing?
IMG_7195_data.jpegIMG_7193_data.jpg
I tried to upload a couple of traces. I just have an old analog scope so it's a crapshoot as to whether I can trigger on something to get a nice unambiguous trace at any given time.

Be positive, we have got machines in a worse state than yours working... And that was with people who didn’t know anything about electronics before hand. You appear to know what you are talking about! We just have to work out what is going on in a systematic manner.
Thanks for the encouragement.

So, we appear to have good power rails?
Agree, power rails are good.

Have you checked the /RESET line on power-up to ensure we are getting a healthy reset?
After the regulators, this is the first thing I did. New 555, tantalum cap and buffer were needed to get that going. It goes to a nice solid 5V a second or two after power on.

The data sheet for a 2716 states that pin 21 is VPP and this pin can draw 5mA from the supply. This is not a logic pin. On the original ROM it was an active high chip select logic pin... This may account for why the /INIT line is being dragged down. It may also affect the operation of the character generator?
Interesting, I hadn't considered that as a possible difference, but I'm glad to have an explanation as to why this loads the line so much. The character generator works fine, though. I will look at changing the pullup resistor or perhaps wiring pin 21 director to 5V since it's unlikely I'll ever get a real mask ROM.

One other observation. Looking at the CS line on the kernal ROM (D9) and on the other ROMs, it looks likes only the kernal ever gets selected. D8 never gets enabled, so it looks like its never getting out of the F000 address space.

Thanks again for your help.
 
If he has the Tynemouth board with the nine switches, he can have switches 3,4,5 set to off, on, off which will replace all ROMs with the Tynemouth board except for the Editor in which he can place the PETTEST EPROM.
The version I have only has 5 switches so I think I can only turn the ROM on or off: https://www.thefuturewas8bit.com/shop/commodore/petromram.html. Unfortunately it looks like Tynemouth is in hibernation right now due to the pandemic.

If this does not work, then you are right, he may have a bad D8 socket/connection. If it works, then with this same configuration, he can use an Editor ROM set up for the business keyboard in the D8 socket. The Edit file for this is called EDIT-2-b.901474-01.bin as found here. http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/index.html. This should be programmed into a 2716 EPROM which is pin-compatible with the D8 socket.
I've replaced both the D9 and D8 sockets with nice round pin sockets and checked all of their connections back through the address buffers, CS decoder, and CPU and everything seems to be connected and there aren't any shorts between pins on any of those ICs. There's a possibility that something could be shorted elsewhere, but I haven't been able to find it. I am using that exact ROM image from zimmers.net burned into a 2716 for this.

In addition to the data bus traces I put in the post above, here are a few address bit traces with the NOP generator in place. These were measured on a ROM, so after the address buffers:
IMG_7190_address_nop.jpgIMG_7189_address_nop.jpgIMG_7187_address_nop.jpg

And here is a trace of the CS line on D9. As I said, it seems like this is the only ROM that ever gets enabled:
IMG_7191_cs.jpeg

I forgot to mention, the scale is 1V/division here and in the data bus traces posted above.

Thanks again to everyone.
Greg
 
I am getting a little confused now...

With the NOP generator in place, you should see each ROM /CS pin being selected (in turn) for 1/16th of the time.

This should be the first step if you are suspecting problems with address decoding.

Of course, the EDIT ROM is only 2K, so that ROM should be a ‘half pulse’.

You should also observe the (effective) RAM /CS being operated at the appropriate addresses and the I/O devices being selected within the E8xx address space.

With the Kernel ROM and my PETTESTER in place, do you still only observe /CS pulses on the Kernel ROM?

It would be worth checking the CPU /IRQ and /NMI pins. These should be either high or pulsing, never permanently low. With my PETTESTER they should both be high.

Let’s get some answers to these questions first.

Dave
 
With the NOP generator in place, you should see each ROM /CS pin being selected (in turn) for 1/16th of the time.

Of course, the EDIT ROM is only 2K, so that ROM should be a ‘half pulse’.

Daver, no, SEL E will look like SEL F and all the other chip selects in the 2001 model PETs. There is no x8xx gate logic in the E socket like the 8032 models. All the pulses will be about 8.2 mS with a period of 131 mS.


With the Kernel ROM and my PETTESTER in place, do you still only observe /CS pulses on the Kernel ROM?

This may be the crux of the issue...
 
Last edited:
I haven't had a chance to try any of the suggestions, but just wanted to resolve your confusion due to my less-than well-organized post above. The /CS trace above wasn't taken with the NOP generator in place, it was with the CPU set up regularly. I just included it as an example of what I was seeing on the kernal ROM when the board was trying to boot. No activity on the other ROMs.

I hope to try some of the suggestions over the weekend.
Greg

I am getting a little confused now...

With the NOP generator in place, you should see each ROM /CS pin being selected (in turn) for 1/16th of the time.

This should be the first step if you are suspecting problems with address decoding.

Of course, the EDIT ROM is only 2K, so that ROM should be a ‘half pulse’.

You should also observe the (effective) RAM /CS being operated at the appropriate addresses and the I/O devices being selected within the E8xx address space.

With the Kernel ROM and my PETTESTER in place, do you still only observe /CS pulses on the Kernel ROM?

It would be worth checking the CPU /IRQ and /NMI pins. These should be either high or pulsing, never permanently low. With my PETTESTER they should both be high.

Let’s get some answers to these questions first.

Dave
 
nINIT being marginal will lead to a world of pain... at the character ROM (which I understand is currently a 2716)... lift pin 21 and bodge to pin 24.
 
Last edited:
Back
Top