Bringing up the RC2014/WOPRjr for the first time

[Michelle Lawson]

Yep, I named my 'server' app after the movie. Anyway, first time powered on and nothing on the terminal. I have the CPU and SIO/2 clocks set for 2.4576MHz and the Port A interface set for 38400 baud, N81, and no flow control; which I assume is correct. 

I brought out the scope and I notice that none of the upper four decode signals on the 74HCT138 ever go low. That would imply that the A2 input never goes high and is stuck low. When I first tried to scope that pin, while is did see pulses, then were never high enough to be a logic 1. All of the other logic signals on everything I scoped out were perfect square waves. A reseat of the chip didn't help, so my next step will be to reflow the joints, try a different chip (an 'LS' should work for testing), and maybe a bodge wire to see if there is a trace issue.

But, if my terminal settings or wrong, or if anyone has any ideas so I'm not barking up the wrong tree, please shout them out. Thanks

[Ed Silky]

When I see a signal that should be going to a logic high, but is only slightly going up, I look for a short to another logic line or to ground by way of a resistor. I don't have a schematic and board layout to help more than that.

-Ed

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/9f78279b-3374-4ec6-9fc7-3d6aeb6c18c9n%40googlegroups.com.

[Michelle Lawson]

Okay, I think I may have made 'some' progress. The solder joints associated with address bit 7 on the SIO/2 card looked suspicious, so I reflowed them. And, while the RS232 serial interface is so simplistic, it always finds a way not to be; along with having zero info on the dongles, short of the silkscreen, I did swap around the receive, transmit, and moved the RTS line to the CTS line on the dongle. Now I at least get gibberish on the screen initially, so I suspect I have a protocol error left to tackle. I'd like to get some confirmation as to what handshaking is required, as opposed to my shotgunning approach, besides the 38400, N, 8, & 1 I have set. Thanks

[Michelle Lawson]

Well, I bodged in a little 8 pin strip header that I hot glued to the top of the SIO-2 card so I could easily scope the RX, TX, CE, M1, RD, IORQ, C/D, and B/A signals, right on the SIO-2 chip. They all had good looks TTL level signals, and while I have no method of looking at more that two at a time, they were at least doing something. Except for the TX and IORQ signal. I expected TX would show nothing since nothing shows up on the screen. The RX line shows activity consistent with a key being depressed. Oddly though, the IORQ line is always high.

I scoped that back to the CPU and it never changes, even at the CPU; a good solid high all the time. I would expect that there should be some initial activity of the IORQ line when power is applied and the software starts to initialize the chip. So, I trying to figure out what I can kludge together next to keep troubleshooting this thing......I sure could use some ideas right about now...... Thanks

[Ed Silky]

As I mentioned, I don't have the same setup as you (as I use a Z80 SBC of my own design), but I can give you some general comments/suggestions.

The IORQ- line won't do anything unless interrupts are enabled on the SIO and something occurs that causes the SIO to generate an interrupt. Just starting things up and initializing things will not (necessarily) cause the IORQ- line to go active (low).

On the signals that you indicate that you brought out to be able to 'scope', you don't mention WR-. I would scope the SIO CE- and WR- together, sync on CE-.

With that ready (if you have a storage scope, do a single trace) - reset/restart the system. You need to see CE- active (low) and WR- active (low) at the same time. There should be about a dozen occurences of that. That would be the start-up initializing the SIO. If you don't see that, then you'll need to track things closer to the bus. For example, does the address decode generate the CE- and does the WR- signal come through from the bus.

If you do see those writes, then it could be that the initialization doesn't enable interrupts (it uses polling), or it is only enabling them for the port you aren't sending data to. It could also be that the data coming in on the RX pin isn't being recognized as valid serial data. If the SIO isn't configured to interrupt on errors, it won't generate an interrupt unless valid data is received.

If the SIO does get the CE- and WR- signals (indicating that it is probably getting initialized), I would think that you would see something on one of the TX lines (TXA or TXB), as most boot-ups will try to print something. If you can see signals on either of those, then (with the scope) you can try to figure out what communication parameters it is using (baud, data bits, etc.).

I'm sorry that I can't be more specific. Hopefully the folks that actually have a setup like yours will come back from their holiday soon and help you out.

Let me know if that helps at all.

-Ed

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/de743fb6-dccc-40b0-afe9-249f551600fan%40googlegroups.com.

[Ed Silky]

Hi Michelle,

Wishing you a Happy New Year! Just checking to see if you were able to solve your problem.

-Ed

[Michelle Lawson]

And the same Happy New Year to you Ed. Hope it turns out to be a great one too.... Well, so far, no joy on the RC2014 yet. I've kinda shelved it for a few days to see if I can come up with some new strategy, and maybe see if anyone else that has the base Pro system has any ideas. I don't have the ROM source, so I can't walk through it to see what things I should be looking at. About all I have as a potential is to kludge a protoboard that will put a 5(ish) MHz clock signal on each of the bus pins to see if there is anything bus related. I would have all of the even pins be inverses of the odd pins to see if there is any interference. Then scope each and every bus pin to check for purity of the signal, bleed over from an adjacent pin, etc. Past that, I'm lost.... Thanks

[Grant Colegate]

If you can't find anything obviously shorted on any of the cards, tracing for continuity across all slots on the bus as a sanity check might be a simple place to start. I've found with these kits it's more likely I've made a poor solder joint rather than it be something more fundamentally wrong.

[Phillip Stevens]

On Friday, 2 January 2026, Michelle Lawson wrote:

And the same Happy New Year to you Ed. Hope it turns out to be a great one too.... Well, so far, no joy on the RC2014 yet. I've kinda shelved it for a few days to see if I can come up with some new strategy, and maybe see if anyone else that has the base Pro system has any ideas. I don't have the ROM source, so I can't walk through it to see what things I should be looking at. About all I have as a potential is to kludge a protoboard that will put a 5(ish) MHz clock signal on each of the bus pins to see if there is anything bus related. I would have all of the even pins be inverses of the odd pins to see if there is any interference. Then scope each and every bus pin to check for purity of the signal, bleed over from an adjacent pin, etc. Past that, I'm lost.... Thanks

 

I can only suggest to start with a very simple, very standard system.

If you're already changing clocks and making modifications from original, then it becomes difficult to troubleshoot.

If you have a Classic II RC2014 then you can check that most of the components are working properly with MS BASIC, before you get into the complexities of CP/M.

But, if you don't have a Classic II then don't worry. See more below.

Just set the system to the standard 7.3MHz clock, remove all additional cards, etc, and start from there.

Ideally, use the USB dongles from 8086 Consultancy that Spencer recommends on his z80 kits site.

These are already connected correctly for a RC2014 with /RTS pinned out.

Almost all the common ones break out the /DTR pin for Arduino purposes, which prevents the RC2014 ACIA and SIO/2 hardware flow control from working.

 

Otherwise standard FTDI USB dongles can be simply hacked by carefully breaking pin 2 off the FTDI chip, and bridging pin 2 (DTR) and pin 3 (RTS) on the PCB, either at the chip if there are no breakouts (as in this picture), or at the breakouts.

If you do have a Classic II then you can check that the backplane, CPU, RAM, ROM and ACIA serial modules are working before proceeding with the CF and SIO/2 modules.

In a MSBASIC ROM for the Mini II (also works with Classic II), I do a short memory test to check things are working correctly before emitting a BEL character. You can use this process to scope which data or address lines are stuck (if there's a failure in RAM) and this will also check ROM (otherwise nothing will work). Looking for the BEL or errored character on the TX line will enable you to check that you've got the terminal set to the right speed.

Even if you don't have a Classic II, then you can burn a MSBASIC ROM to work with the SIO/2. This won't have the above memory self test code, but it will allow you to start with a simpler system, without the CF module.

And, in full agreement with Grant and Ed, it is usually a simple soldering issue.

Take the system apart, check every pin for continuity and for dry joints, including the backplane, and start with one module at a time.

Backplane and power supply, check correct voltages.

Clock Module, correct clock

CPU, check incrementing address lines,

ROM, activity on the data lines

RAM, still activity on the data lines

SIO/2, check everything as above again.

Good luck.

Phillip

[Michelle Lawson]

Thanks Phillip. What I have is the Pro version. From my previous scoping of the IORQ line at the CPU would suggest, it is always high indicating that It does not believe there is any reason to attempt any communication with an I/O device. That then implies that I/O is interrupt driven, and not polled. Given that I do not have the source code of the ROM, I cannot confirm that. That is kind of why I am hoping to hear from someone about how the initialization process is supposed to work, which may give me a better idea of what to zero in on.

[Ed Silky]

Hi Michelle, it's me again ;-)

I want to comment on your one statement regarding the IORQ- line... Many times transmit will be polled, with receive being interrupt driven. So, not seeing an IORQ- active (low) doesn't necessarily mean that it is not trying to send data out, and if received characters have errors (framing, parity, etc.) you will not get receive interrupts (unless the SIO is configured to interrupt on error).

I'm surprised that you can't get the source for the ROM. From what I've seen, most people have made their code open/available. Which ROM do you have (how is it labeled)?

-Ed

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/fcfb2f3a-4f3c-4331-8197-ebcd61c10c5dn%40googlegroups.com.

[Ed Silky]

I found this link to ROM source on the RC2014 page:

https://github.com/RC2014Z80/RC2014/tree/master/ROMs/Factory

The RC2014 page that pointed me there is: https://rc2014.co.uk/1716/basic-cp-m-romwbw-or-small-computer-monitor/

It indicated that the options are identified by the character in each position of the label.

What is on your label?

-Ed

[Michelle Lawson]

The ROM I have is marked 24886009... I'll check the link you just posted and see what I can find. Thanks, Ed....

[Michelle Lawson]

Looks like the files are all either .hex or .bin..... Oh well, it was worth a shot anyway

[Phillip Stevens]

Try downloading them from here.

http://searle.wales/

See CP/M on a Breadboard.

Download link.

You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/ubwL_h-SwpQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/0d472178-da82-4904-966d-bdeb62bc8e9bn%40googlegroups.com.

[Michelle Lawson]

Sorry, I forgot to say something about the possible data transmission concern; yes, actually I suspect that might be where the issue lies. That is kind of why I asked the question about how the interface is to be connected, and how the software side is to be configured; handshaking, etc. I'm still hoping someone with a working Pro system (with SIO/2 board) can chime in. Thanks

[Michelle Lawson]

Thanks Phillip. I did a quick check and it looks like the port addresses between the monitor.asm source, and what the SIO/2 cards comes configured as, are different. Wonder if that implies that either there is a card issue, or the code is modified for RC2104 SIO/2 use..... Hmmmmm

[Michelle Lawson]

Well, I wire-wrapped up a little protoborad; a 2.5MHz clock, a 74LS04 inverter, a couple of 74LS240 and a couple of 74LS244 chips. The octal drivers connect up to the 16 address lines, 8 data bits, and the other 8 control/etc lines. I wired it up in such a way that every other bus line had the inverse signal from the surrounding lines. Every one looked rock solid, albeit with a little undershoot since there was nothing terminating any of the lines. So, it kind of looks like the bus is not my problem.

My next step is to put once card in at a time and check all the bus lines to see if something weird shows up. So, stay tuned and maybe weirdness shows up.

[Michelle Lawson]

Another update; of sorts.... In digging through Grant's monitor.asm code, it looks simple enough: disable interrupts, jump to INIT, setup the Stack, output parameter values to the two sections of the SIO/2, enable the interrupts, and then display the "Press space to start" message. Since I am not seeing the message, it isn't even getting that far; or is it.... It seems that somewhere, I came across something awhile back, that talked about cutting a trace, and putting in a wire to select a different port? Maybe.... It might have even been for a different card. I only ask because the card is hard set for the port 8x range, and Grant's code is set for the port 0x range. That could certainly cause the problems I'm seeing. Any thought?

[Phillip Stevens]

On Sat, 3 Jan 2026 at 10:49, Michelle Lawson wrote:

Another update; of sorts.... In digging through Grant's monitor.asm code, it looks simple enough: disable interrupts, jump to INIT, setup the Stack, output parameter values to the two sections of the SIO/2, enable the interrupts, and then display the "Press space to start" message. Since I am not seeing the message, it isn't even getting that far; or is it.... It seems that somewhere, I came across something awhile back, that talked about cutting a trace, and putting in a wire to select a different port? Maybe.... It might have even been for a different card. I only ask because the card is hard set for the port 8x range, and Grant's code is set for the port 0x range. That could certainly cause the problems I'm seeing. Any thought?

I think (🤔) Spencer used the 128KB version unchanged. Compare the RC2014 repo distribution hex file with those in the Searle download.

Otherwise, Spencer can comment specifically on any differences.

[Michelle Lawson]

Just checked Spencer's 24886009.bin against Grant's monitor.hex, and they are different.

Grant's monitor.hex: F3 C3 8A......

Spencer's  24886009.bin: F3 C3 93.....

Yes, I think Spencer's wisdom will be key in this.

I'm still trying to figure out where I saw something about cutting a trace to change the base of a port range though. It's wracking my brain....

[Matt Callow]

Sorry to interject, but I'm a bit confused. Isn't IORQ Input Output ReQuest? This should go lo every time the processor tries to access an IO port, regardless of interrupts.  The interrupt lines are INT and NMI.

So I think that, assuming the serial port is IO mapped, you should see activity on the IORQ line whenever the CPU tries to communicate with the serial port.

 

Matt

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/CACc-QnJ8FeTfjcmJh3KFBWBRhtn70duidmM51HmULY%2BYxmc_qw%40mail.gmail.com.

[Ed Silky]

Wow, I can't believe I typed "IORQ-"!!! Yes, I was referring to the "INT-" line. And yes, the IORQ- line will be active regardless of interrupts.

Thanks for interjecting Matt!

-Ed

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/CAO%3Dbg_XMEfpkLDiCbeUKMzwTYbS4MdZ90NNsBigweMZD3Fr%2BXw%40mail.gmail.com.

[Michelle Lawson]

Well, it appears that I may just be on the trail of a hot tip..... The yellow trace is from the CLK signal right on the SIO-2 chip (pin 20), and the red trace is on the INT signal right on the SIO-2 chip (pin 5). I say, 'right on' as in the probe point is on the back side of the board at the soldered in pin. So, a bad chip? A bad socket? Or something external trying to keep it pulled high? I'll be checking those next.... Stay tuned....

[Michelle Lawson]

Guess it'd help if I actually posted the scope screenshot. Well, duh!

[Michelle Lawson]

My findings and conclusions after further testing:

1. The fluctuations on the red track mimic the Clock signal (yellow trace), indicating an open signal.

2. With the SIO-2 chip removed from the board, and the board plugged into the system, there is continuity from the INT signal on the bus, all the way to the front side of the SIO-2 socket (pin 5).

3. With pin 5 lifted, and the chip plugged in with the system powered on, pin 5 of the SIO-2 chip floats around zero volts.

4. Given the /INT (pin 5) signal of the SIO-2 is active low, and the bus fluctuations of the INT line on the bus, this would conclude that the SIO-2 chip is defective.

I am sure open to any insights or thoughts.... Thanks

[Spencer Owen]

Apologies for being late to the party here. I have been mostly offline over the holidays. Still got a lot to catch up on.

Just a few comments from skimming through this thread;

As Phillips suggest, the RC2014 Classic II is the simplest form of RC2014, and with your RC2014 Pro, running 32k BASIC on it is effectively the same. See the jumper settings for https://rc2014.co.uk/wp-content/uploads/2021/05/RC2014-Pro-24886009-Jumper-Settings.pdf Start with this, running at 7.3728MHz before trying anything else. It uses the bare minimum of components, and is the foundation that everything else is built on.

Secondly, pay attention to the jumper settings in the guide above. Seriously, almost every RC2014 that fails to boot is either a jumper issue or a duff solder joint somewhere. (I  think I saw earlier that you had been over every joint. But it doesn't hurt to do that again)

The source code on Grant Searles site is the closes that exists, along with the code for SCM (the "88" and "9" on the ROM).  All modifications that I made were done in the EPROM programming software at a HEX level.  

The "6" on the ROM does have a very simple pre-boot loader. Again, this was written in HEX on the EPROM programmer, but all this does is copy the contents of ROM (Grant Searles monitor) up to the high RAM, send a page command to page out the ROM and page in the lower RAM, then copy the code from high RAM to low RAM and start executing it.

Hopefully that helps.

Spencer

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/5c492ad7-f1e4-42da-8a91-b7f0fa1bdba1n%40googlegroups.com.

[Ed Porter]

On 03/01/2026 18:16, Michelle Lawson wrote:
> My findings and conclusions after further testing:

> 4. Given the /INT (pin 5) signal of the SIO-2 is active low, and the bus
> fluctuations of the INT line on the bus, this would conclude that the
> SIO-2 chip is defective.

/INT is an open drain output so it needs a pullup resistor. Having said
that the SIO is very easy to fry in my experience.

-ed

[Michelle Lawson]

That would be correct Ed. Given that the /INT signal on  the bus is always high, mimicking the adjacent CLK signal, and there is solid continuity from the bus all the way up to the chip side of the SIO-2 socket, it does certainly point to a failed device.....

[Mark T]

The red trace might be a herring. The Int line is only pulled up by a resistor on the cpu card so if its not actively pulled down so it could have some coupling from the clock from adjacent traces or through the 5v supply. You might also see the same ripple from the clock on the 5v supply.

[Michelle Lawson]

Thanks Mark. The power supply +5V rail is rock solid; I'm using a +5V at 10A switching supply and the bus and boards are loaded with filter and decoupling caps. That said, seeing that same signal all the way up to the pin side of the SIO-2 socket (on the chip side and not the back, solder side) still means that a) the chip is bad, or b) some code is not running properly. All board jumpers are set per Option "6" of the RC2014-Pro-24886009-Jumper-Settings document.

[Michelle Lawson]

I figure this will be another rabbit hole I venture down, but in looking at the jumper settings document, and the schematics, I'm wondering if any jumper settings are incorrect, or/and something is supposed to be done with the 'Page' jumper...... This is a photo of the actual boards I'm trying to get running in the CP/M configuration ( option 6) of my Pro system. Thanks for any thoughts or ideas....

[Ed Silky]

Michelle,

Do you have your system running yet?

-Ed

[Michelle Lawson]

As I continue testing to bring this thing to life, I noticed that the Pageable ROM board I have, does not match that the documentation shows. The documentation indicates either a 27C08/27C512 socket (28/24 pin devices) but my board seems to be set for a SST39SF040/020/010 (32 pin device). Three questions; do I have the correct board, can the board I have support 8K x 8 ROMs, and if so, where do I place the 8K x 8 ROM? Thanks

[Spencer]

Hi Michelle,

Yes, that is the right board and chip.  During the Great Chip Shortage of 2022, the 27C512 was totally unavailable, but with a minor change to the PCB, I was able to use 39SF010 chips https://rc2014.co.uk/2097/component-substitution-due-to-the-worldwide-chip-shortage/ This works in exactly the same way as the documentation, and the ROM image is exactly the same (Although the 64k ROM image only uses the first half of the 128k available on the 39SF010 chip).

This is almost exactly pin for pin compatible with the 27C512 if the top 4 pins of the footprint are ignored.  The only difference is Pin 28 on the 27C512 which is the Vcc pin is Pin 30 on a 39SF010 and is an address line and is tied to ground.  So you cannot just plug a 27C512 chip in without modifications.

Spencer

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/7e9179b4-bcef-4b4c-94c0-090aa4d4f3f4n%40googlegroups.com.

[Alan Cox]

Oh that explains a couple of people being very confused by the Fuzix on basic rc2014 pages setup and me not being able to work out why. I had instructions for using a 28Cxxx on the old board so you could use flash not single write devices

Alan

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/3Lt1Wycz_mz5Tz9LS0tar9jn3CjlOoSzRdmjfnyCBGQwfjUw-wM0SHTFv7SWW7ePug96UoK5OR-QOoigauYpgPX6qBTtrKtsV1hXjSe1FeA%3D%40z80kits.com.

[Michelle Lawson]

So then, I guess the answer to my question; " can the board I have support 8K x 8 ROMs " is a no. Baring some sort of physical board modification. That would also indicate that the website documentation is not current then? Thanks