• Please review our updated Terms and Rules here

Netronics Explorer 85

Just post the image of the serial bitstream you capture on your oscilloscope.

A character will consist of a start bit, some number of data bits, an optional parity bit and some stop bit(s).

We should be able to work out what the bitrate is from the oscilloscope trace (and a knowledge of which character you pressed would be useful).

The "bad RAM" is a guess - something amiss with the hardware may be a more accurate description.

Dave
 
Here's a video of me scoping it. The screen is too high up to capture alongside the scope, if you need to actually see it I can rearrange tonight.

Funny enough, probing the pins caused it to mostly get the prompts right - Memory Size came up correctly, and the full BASIC 'welcome' screen came up. Terminal width did not. After every entry, the machine immediately began backspacing. I called it out in my video as it happened so hopefully that's clear enough.
 
I've done a lot of reading on this... things seem to point back to needing capacitors at C100 and C101. There's no evidence any were ever installed on this machine, nor on another unit I have. But the other unit I have was only designed for hex keypad use, so probably didn't need them since it didn't need stable serial. This machine - I think it's clear the previous owner made some mistakes with their build and mods they did later, maybe it somehow worked without the caps but then degraded later?

I also see in various photos of other EX 85s that sometimes the crystal has a resistor across it.. can't really make out the color bands to figure out what value it is... the ones that have it don't have the caps installed though.
 
I posted above that the official Intel documentation states that an 8085 does not require any capacitors providing the frequency is greater than 4 MHz and the CORRECT specification of crystal is used.

If an incorrect specification of crystal is used (i.e. buying any old stuff from eBay) then all bets are off...

You can check on the stability by using your oscilloscope on the 8085 clock output pin.

Dave
 
Sorry Dave, forgot that! Yeah I've got four crystals here available for testing.. all are 6.144mhz. I've tested with three of them, outcome is same.. seems to be pretty stable 2.5mhz off pin 37 of the 8085. Am I just going off track here worrying about it not being 3MHz? Some of my reading suggested BASIC itself is really sensitive with serial comms, and a difference of 20% might be enough to throw it off kilter - the monitor being a bit more tolerant of that.
 
There are only four (4) possibilities:

1. Power supply stability to the 8085 CPU.

2. All the crystals you have are the same (wrong) type. Fitting any of them should, therefore, result in the same problem.

3. The 8085 CPU is faulty.

4. There is some flux (or other contamination) on the pins of the CPU/crystal. Contamination can affect the frequency.

Take your pick...

Dave
 
Thanks Dave!

1) I will figure out how to check the power supply properly on my scope here. I think I did see a bit of ripple previously while checking +5V, but not sure if it was ripple or settings on the scope not quite right. I'm getting better with the scope but I sometimes get a bit lost on which settings to use, and then how to find them on this thing.

2) When you say 'type' of crystal, beyond being potentially wrong frequency (these are clearly marked though), what other types are there? I've attached a pic of the original.

3) Based on what you said, it sounds like the 8085 is pretty robust, even 40 years later, and I've now tried four of them. So I'll mark that down as 'unlikely'.

4) That is quite possible, have to check that, although bending out pins 1 and 2 and running the crystal directly off those I would think negates that concern?
 

Attachments

  • 20260106_110223.jpg
    20260106_110223.jpg
    295 KB · Views: 0
1. Set your oscilloscope 20 ms/div for ripple. Remember back to our power supply lessons? Ripple will be either at the mains frequency or twice the mains frequency.

2. I posted the Intel requirements for the crystal back in post #74. As well as the frequency, there is the maximum load capacitance, maximum shunt capacitance, maximum equivalent series resistance (ESR), drive level and whether the crystal operates at the fundamental or (e.g.) third overtone.

I went onto the Mouser website and looked up two potential candidates from a manufacturer. On could be used, the other not (because it was outside the Intel specifications). Now, it probably would have worked - but that is another matter... We had to go through the justification for the use of the crystal we selected on our project. I will look up what we used.

Look up the specification sheet for a random 6.144 MHz from a manufacturer - there are more parameters than just the frequency...

4. Clean any 'crap' off with isopropyl alcohol (or flux cleaner). But your idea sounds sensible also.

Dave
 
Just thinking out for the box (at the usual issues that mess up people using oscilloscopes).

Let us assume that the oscillator is oscillating at the correct frequency...

Is it possible that your oscilloscope is telling you lies due to the configuration?

Dave
 
daver2 said:
Just thinking out for the box (at the usual issues that mess up people using oscilloscopes).

Let us assume that the oscillator is oscillating at the correct frequency...

Is it possible that your oscilloscope is telling you lies due to the configuration?

Dave
Click to expand...
I am suspecting the scope settings may be incorrect. Scopes are a lot to wrap a beginner's head around. I am just figuring it all out again here to make sure I'm getting an accurate signal. I just tested on my lunch break and it was showing 3.4mhz, so something isn't right. I had it on 100ns.
 
So, at the expected frequency (3.5 MHz ish) what is the period (1/frequency) where the period is in seconds and the frequency is in Hertz. Convert the obtained period (in seconds) into microseconds or nanoseconds.

Set the oscilloscope timebase to the nearest setting of the calculated period/div, and adjust accordingly.

If you are not careful (with an oscilloscope) it will lie to you...

Think about stagecoach wheels in a Western going backwards when watching them on the TV. We know the wheel isn't actually going backwards, because the stagecoach is moving forwards!

You have to know what you should be expecting, and set the oscilloscope up accordingly.

Also, are you going from a frequency indication that the oscilloscope is giving you, or are you deriving the frequency from measuring the period (from the oscilloscope time axis) and then calculating the frequency from that (i.e. old school it).

Incidentally, your serial video above shows your oscilloscope presenting a frequency and period value when these are clearly rubbish based upon the displayed waveform!

Dave
 
Last edited:
Hi Dave,

The scope has a frequecy indicator, so I have been relying on that. I believe I have the settings dialed in correctly, and yeah, it consistently comes out as 2.5mhz. Going to mess about with it more this weekend and test it on some known working machines to make triple sure I've got it. The scope is a course in and of itself.

I will note that while pivoting to another machine I just got (a loaded ELF II with first revision fastvid terminal), I connected the terminal, once I had it working, to the Ex85 just to see if anything different happened. Figured it would harm nothing. I can actually see the Ok prompt now. But I think there is something else going on here that may not be serial comm related. Even when I can clearly see the memory and terminal width prompts, it crashes and goes right back to them after the truncated BASIC message. I think BASIC may not be initializing properly.
 
Going back to what I said in a previous post...

Does the machine work well with the debug monitor?

If so, are we just looking for a fault with the BASIC EPROMs?

By 'work well' I mean have you fully checked out the functionality of the debug monitor operation, including running a memory test of some description? You may have to do this in two parts (if you have to load the RAM test program into the memory you are testing)...

You can also write a test program to checksum the BASIC EPROMs (a 16-bit sum of all of the bytes in the EPROMs), and compare this with an online copy of the same BASIC interpreter. This would validate the code you have in the EPROMs, and whether it can be successfully read by the CPU.

If the debug monitor doesn't work correctly, there may be a fault with the CPU hardware itself, and trying to run BASIC is going to be a fruitless exercise!

Dave
 
daver2 said:
Going back to what I said in a previous post...

Does the machine work well with the debug monitor?

If so, are we just looking for a fault with the BASIC EPROMs?

By 'work well' I mean have you fully checked out the functionality of the debug monitor operation, including running a memory test of some description? You may have to do this in two parts (if you have to load the RAM test program into the memory you are testing)...

You can also write a test program to checksum the BASIC EPROMs (a 16-bit sum of all of the bytes in the EPROMs), and compare this with an online copy of the same BASIC interpreter. This would validate the code you have in the EPROMs, and whether it can be successfully read by the CPU.

If the debug monitor doesn't work correctly, there may be a fault with the CPU hardware itself, and trying to run BASIC is going to be a fruitless exercise!

Dave
Click to expand...
Not sure if this answers your question, but as far as I can tell all monitor functions work and it almost never becomes unstable. I've tested everything from setting stack pointer to filling memory with different data and then dumping it to verify. There was one area I did the filling (i forget the exact addresses but it was the little bit of RAM the 8755 provides except where the monitor itself lives).. it would not fill a big range without locking up. Had to do like f880-f99f. Little at a time.

As far as the ROMs go I have removed each one, loaded the BIN file for each ROM that I downloaded from a site online into my programming software, and then ran verify to confirm the contents from online were same as what chip was holding. No issues reported. But I don't know enough about EPROM failure modes to know if simply reading and verifying the chip is enough to prove it works.
 
It should be OK for the EPROM chip itself, but not whether the CPU can actually read it correctly. That was the purpose of my check.

If you are using the debug monitor, then you can't 'gate crash' the RAM that is being used by the debug monitor, but is that the same RAM that is being used by BASIC? I think not...

Level A RAM went from $F800 up to $F8DC.

Level D added 4K of 2114 from $0000 to $0FFF.

I am guessing that this is what BASIC uses. So, have you tested this RAM?

Do you have any other S-100 RAM boards installed?

Just checked the BASIC manual...

The stack pointer should be set to $F880 before executing BASIC. ROM BASIC is invoked by executing $C000.

RAM memory from $F000 to $F87F appears to be used as a potential stack.

RAM memory from $0000 upwards for system RAM and user programs.

Therefore, both areas of memory need to work properly for BASIC to operate.

Dave
 
Last edited:
I ran the FF command to fill all of 0000 to 0FFF with various numbers, 01, AA, FF, 11, 55 etc.. and then (D)umped and confirmed the changes were as expected, I watched very carefully to note if any bytes were incorrect.

I believe I did the same test - F800 up to F8DC, and that's where I ran into problems. I could not fill the whole space in one go. It would crash if I did. Let me retest that again.
 
Just did a (FF)ill command of 11s from F800 to F8DC (.FFF800,F8DC 11), it worked up to F8CA. After that it was random.
 
You must log in or register to reply here.
Back
Top