RomWBW FP Switches with no Front Panel?

[John McAleely]

Folks,

I enjoyed attending the RC2014 assembly, and saying hello to quite a few people who's names I now recognise on this group.

I've built up an RC2014 Zed Pro, and it seems to boot and run.

One puzzle is that the boot process seems to switch between the two serial ports on the SIO. Initial output is on port A, ending in:

  Console on Unit #1

I can then proceed with a conversation over Port B. (I can switch it back with I 0 if I want...)

This is inconvenient, so I've spent some time digging in to why this might be. I observe two things:

The line:

FP: IO=0x00 SWITCHES=0x7B

appears in the initial boot diagnostic, but I have not built or installed a front panel module. Is that expected?

Over many boots I observe several values for SWITCHES (including E5), but I am unaware of changing anything between boots.

My reading is that these values encourage the switch between ports. Is that correct?

If I had a front panel module, I think I could set switches to 'force' port a at all times. Alas, I don't have that module...

I noticed that there appears to be an option to set the values used here via NVRAM in the RTC module (which I have got installed). Reading the (excellent, thank you!) RomWBW docs, the tool sysconf appears to do this if I had version 3.5.1 installed. Alas, my ROM is 3.4.0.

I tried downloading sysconf from the 3.5.1 distribution, but on running it, it reported incorrect HBIOS version (fair enough, I think).

Is there an incantation I can type using my 3.4.0 rom to set the NVRAM to something useful? It looks like the RTC.com tool could do this, but my doc search didn't turn up enough information.

Or is a good course of action to start learning how to update my ROM to 3.5.1?

Thanks all in advance,

John

[Wayne Warthen]

Hi John,

So, the problem is that you do not have a front panel and the boot messages should NOT indicate that you do.  It should say something like "FP: IO=0x00 NOT PRESENT".

Unfortunately NVRAM configuration won't help because the front panel switches take priority over NVRAM.

The detection of the front panel is messy.  There is no absolute way to test for it's existence.  So, RomWBW uses a tricky test to try and determine if "something" exists at port 0x00.  If something seems to be there, it assumes you have a front panel.

First, do you have anything else in your system that might be at IO Port 0x00?

If not, I would like to see a port scan of your system.  If you boot from disk (CF Card), you will find an application called PORTSCAN.COM in user area 2.  If you could run that and let me know what it spits out for port 0x00, that would be helpful.  The output is long, but I only need the first few lines.  Here is an example from my system:

PORTSCAN v1.0, 16-Feb-2023
Copyright (C) 2023, Wayne Warthen, GNU GPL v3
CPU is Z80

00: 00 78 00 78
01: 01 78 01 78
02: 02 78 02 78
03: 03 78 03 78

Thanks, Wayne

[John McAleely]

Thanks Wayne,

I am unaware of anything installed in port 00, I have built the stock parts from z80kits in the default way. This is new to me though, so I can't answer with confidence.

I trimmed the cards in my system to be just the set that reproduces the problem. If I just boot:

CPU (Z80 v2.1)

RAM (512K RAM 512K ROM)

Dual Clock

Dual Serial (SIO)

then the problem does not occur. (FP: IO=0x00 NOT PRESENT). When I add the CF Card adapter (v2.1), *without* CF card present, again, the problem does not occur.

Once I insert the CF card, I start to see the FP reported.

Portscan reports:

PORTSCAN v1.0, 16-Feb-2023
Copyright (C) 2023, Wayne Warthen, GNU GPL v3
CPU is Z80

00: 11 11 11 11
01: 00 00 00 00
02: 00 00 00 00
03: 9C 9C 9C 9C
04: 05 05 05 05
05: 00 00 00 00
06: E0 E0 E0 E0
07: 50 50 50 50
08: 08 78 08 78
09: 09 78 09 78
0A: 0A 78 0A 78
0B: 0B 78 0B 78
0C: 0C 78 0C 78

This computer was constructed today, so I would have no particular reason to eliminate hardware problems in my construction, but I don't know if they can manifest in this way.

FWIW, I could not figure out how to boot in such a way that portscan appeared in USER 2, but I could xmodem transfer it to the RAM drive and execute it from there.

J

[John McAleely]

I didn't expect it to survive, but the RAM disk preserved files across reset, and me removing (with the system running) the CF card. With no card present, it reports:

A>portscan

PORTSCAN v1.0, 16-Feb-2023
Copyright (C) 2023, Wayne Warthen, GNU GPL v3
CPU is Z80

00: 00 78 00 78
01: 01 78 01 78
02: 02 78 02 78
03: 03 78 03 78

04: 04 78 04 78
05: 05 78 05 78
06: 06 78 06 78
07: 07 78 07 78

08: 08 78 08 78
09: 09 78 09 78
0A: 0A 78 0A 78
0B: 0B 78 0B 78
0C: 0C 78 0C 78

0D: 0D 78 0D 78
0E: 0E 78 0E 78
0F: 0F 78 0F 78
10: 10 78 10 78
11: 11 78 11 78
12: 12 78 12 78

With the card reinserted (just plugged in hot):

PORTSCAN v1.0, 16-Feb-2023
Copyright (C) 2023, Wayne Warthen, GNU GPL v3
CPU is Z80

00: A9 A9 A9 A9
01: 01 01 01 01
02: 01 01 01 01
03: 01 01 01 01
04: 00 00 00 00

05: 00 00 00 00

06: 00 00 00 00

07: 50 50 50 50
08: 08 78 08 78
09: 09 78 09 78
0A: 0A 78 0A 78
0B: 0B 78 0B 78
0C: 0C 78 0C 78

0D: 0D 78 0D 78
0E: 0E 78 0E 78
0F: 0F 78 0F 78
10: A9 A9 A9 A9
11: 01 01 01 01
12: 01 01 01 01

I do wonder if the apparently random FP reports are something to do with how this board responds to the CF card. It makes me suspect my construction, Does that make sense?

J

[Wayne Warthen]

This is very interesting.  The CF Card should be appearing in the IO range 0x10-0x17 (which it does).  However, it seems to be also appearing at 0x00-0x07.  Notice that when you insert the CF Card, you are seeing the same values starting at 0x00 and 0x10.  This does explain why RomWBW thinks you have a Front Panel board.

I would suggest that you carefully review the construction of your CF Board.  It sounds like there may be a solder bridge somewhere.

If you are not able to find an issue with your CF Board, it is possible to create a custom RomWBW ROM with the front panel functionality disabled.  However, I would suggest you focus on the CF Board construction initially.  A construction issue may cause other problems in the future.

Thanks, Wayne

[John McAleely]

Yes, I think this is a construction problem. It seems line A4 has a bad solder joint (see attached). I'm not sure what I've achieved, but it is resisting my attempts to rework. I do wonder if I have somehow removed the underlying pad on the board.

I will consider this with a fresh head in a day or two.

Thanks for your help!

[Wayne Warthen]

Possibly a bodge wire from pin 12 (A4) of the bus connector to pin 2 of U2 (74HCT138).

-Wayne

[John McAleely]

Thanks Wayne, that's very confidence boosting. I was just reading the data sheet, and thinking a wire between those pins might be correct.

Sadly, when I took the time to try it, it didn't bring the card to life, so (for now) I'm writing it off and getting a replacement sorted. I can come back to this another time, and have a second CF card in my machine if I get it working!

J

[Mark Pruden]

John,

You can check using a multimeter for continuity, specifically to ensure that traces (or bodge wires) are performing correctly, but secondly to ensure there are no shorts between adjacent pins

Mark.

[John McAleely]

Thank you Mark!

To update this thread, I elected to build another copy of the CF card module. It worked first time, and the boot sequence includes the 'not present' indicator for the front panel.

I will turn my mind to troubleshooting the earlier board in slower time, and likely modify it to live at the secondary io port. I hope I can then have two CF cards on my Z80.

John