wizcfg using SC126 with W5500c config error

[jrlodden]

I have this cfg.sub under CPM 2.2 ROMWBW 3.01

C>submit cfg

C>WIZCFG M 00:AA:BB:CC:DE:02

C>WIZCFG G 192.168.178.1

C>WIZCFG I 192.168.178.25

C>WIZCFG S 255.255.255.0

C>WIZCFG N F0

C>WIZCFG 0 00 192.168.178.24 31100

C>WIZCFG
Node ID:  FCH
IP Addr:  10.10.250.0
Gateway:  192.168.178.0
Subnet:   255.255.255.0
MAC:      00:AA:BB:CC:DE:00
No Sockets Configured

The WIZCFG doesn't set the configuration correctly.
If I manually type the lines in the last byte of the IP address always set 0.

I do not have anything in SPI1 -- the W5500is in SPI2.

I can run WIZDBG GET for global 0 the last byte not set. The interface to the W5500 seems okay -- WIZDBG returns the same values on multiple runs. Not sure if this a problem with WIZCFG or the hardware/cabling

Thanks.

-jrl

[durgadas311]

I'm suspicious this might be related to the new routines that write data to the W5500 via the Z180 CSIO, it looks like MAC, gateway, IP (and possibly mask) all failed to write the last byte. Will send to David and if he does not respond, will look into debugging that new code.

[DavidJRichards]

Hi John, I wonder if the hardware is different somehow, my system does not behave that way - I've just rechecked. Can you describe the hardware you are using please? Kind regards, David.

[jrlodden]

Sure -- Hardware is as follows:

RomWBW HBIOS v3.0.1, 2020-10-21

SC126 Z8S180-K @ 18.432MHz IO=0xC0
0 MEM W/S, 2 I/O W/S, INT MODE 2
512KB ROM, 512KB RAM

ASCI0: IO=0xC0 ASCI MODE=115200,8,N,1
ASCI1: IO=0xC1 ASCI MODE=115200,8,N,1
DSRTC: MODE=STD IO=0x0C Thu 2020-12-24 18:58:42 CHARGE=OFF
MD: UNITS=2 ROMDISK=384KB RAMDISK=384KB
IDE: IO=0x10 MODE=RC
IDE0: 8-BIT LBA BLOCKS=0x0003DC50 SIZE=123MB
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT
SD: MODE=SC OPR=0x0C CNTR=0xCA TRDR=0xCB DEVICES=1
SD0: NO MEDIA

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ASCI0:      RS-232            115200,8,N,1
Char 1      ASCI1:      RS-232            115200,8,N,1
Disk 0      MD1:        RAM Disk          384KB,LBA
Disk 1      MD0:        ROM Disk          384KB,LBA
Disk 2      IDE0:       Hard Disk         123MB,LBA
Disk 3      IDE1:       Hard Disk         --
Disk 4      SD0:        SD Card           --

SC126 Boot Loader

Ethernet Module is: W5500 wired into SPI2 per the docs.

-jrl

[durgadas311]

I had one thought, as I don't see anything wrong with the code. Could there be some timing problem, such that the last byte is getting lost - perhaps due to the chip-select getting turned off too soon? I wonder if there could be some odd timing characteristic of the status bits, such that sending a byte does not immediately raise the CNTRTE and thus if it is checked too soon then it appears to be "idle" but is actually just not yet busy?

[jrlodden]

Thinking it may be a bad or out of spec W5500 -- I swapped the W5500 with another one I had -- same results.

[DavidJRichards]

Something to try, copy the cpmet files onto ramdisk and run from there leaving the c: drive idle. Which ide board are you using, I have a rc2014 CF board I could try here.

[DavidJRichards]

Trace showing part of wizcfg i 192.168.178.25 attached

I have compared the binary diff of the files I'm using and the ones just made by building the latest sources from this site, they are identical., my wizcfg attached.

wizcfg.com.tar.gz

[durgadas311]

I was looking over the Z180 user guide and the CSIO transmit timing, and noticed that it shows CNTRTE going to '0' before the last bit is transmitted. With a divide-by-20 clock setting, that would mean there must be at least 20 CPU clock cycles between detecting CNTRTE=0 and turning off the chip select. Based on the code, and the logic analyzer trace, it appears we're meeting this requirement. HOWEVER, if the CSIO clock divisor is set to anything higher, I think we have a risk of hitting this.

How does RomWBW setup the CSIO bit clock? Are both systems the same in this area?

I'm pretty sure the W5500 will ignore a byte if /CS is turned off before all 8 bits are received. Based on John's original data, it appears that even the single-byte data of the "Node ID" field did not get sent correctly - the command sends "F0" but the read-back shows "FC".

[DavidJRichards]

The CSIO divider is always explicity set to /20 by the code writing the divisor bits t 0 on every write to the TE and RE bits, my system runs at 18.4MHz , I have tested cp/net without problems with the dev version and the current release.

Disk: (0)MD1 (1)MD0 (2)IDE0 (3)IDE1 (4)SD0 

Boot Selection? 

RomWBW HBIOS v3.0.1, 2020-04-04

SC126 Z8S180-N @ 18.432MHz IO=0xC0
0 MEM W/S, 2 I/O W/S, INT MODE 2
512KB ROM, 512KB RAM

ASCI0: IO=0xC0 ASCI W/BRG MODE=115200,8,N,1
ASCI1: IO=0xC1 ASCI W/BRG MODE=115200,8,N,1
DSRTC: MODE=STD IO=0x0C Fri 2020-12-25 12:59:51 CHARGE=ON
MD: UNITS=2 ROMDISK=384KB RAMDISK=384KB
IDE: IO=0x10 MODE=RC
IDE0: NO MEDIA
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT
SD: MODE=SC OPR=0x0C CNTR=0xCA TRDR=0xCB DEVICES=1
SD0: SDHC NAME=SU16G BLOCKS=0x01DACC00 SIZE=15193MB

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ASCI0:      RS-232            115200,8,N,1
Char 1      ASCI1:      RS-232            115200,8,N,1
Disk 0      MD1:        RAM Disk          384KB,LBA
Disk 1      MD0:        ROM Disk          384KB,LBA
Disk 2      IDE0:       Hard Disk         --
Disk 3      IDE1:       Hard Disk         --
Disk 4      SD0:        SD Card           15193MB,LBA

SC126 Boot Loader

ROM: (M)onitor (C)P/M (Z)-System (F)orth (B)ASIC (T)-BASIC (P)LAY (U)SER ROM  
Disk: (0)MD1 (1)MD0 (2)IDE0 (3)IDE1 (4)SD0 

Boot Selection? 

[durgadas311]

I just realized that, in the original data, the IP address did not even get partially set correctly. So, that case at least is something more than just trashing the last byte.

John, did you get the same results every time you run the submit file? Can you post the output from WIZDBG (32 bytes at 0) as well? that might show more about how things are getting corrupted.

David, I'm not able to see in the code where the bit rate is getting initialized. The readbyte/writebyte routines do not alter the "baud rate selection" bits of the CNTR register. I don't see any other code that writes a value to CNTR.

[durgadas311]

I'm wondering if John's system differs in that he has no SDCard inserted. In that case, RomWBW may not initialize the CSIO control register (baud rate select bits), and so that system is trying to use "external clock", which could produce some strange results if there is no external clock connected.

[DavidJRichards]

Hi Dougles, you could be onto something there. If I remove the SD card interface then the CF interface doesn't see a card, something wrong there, Havnt tested cpnet in that configuration yet though. David.

[jrlodden]

The IDE card I have is the RFC2014 Compact Flash Card v1.0 -- with a 128MB card installed -- From rc2014. The output from the cold start follows:

C>WIZCFG
Node ID:  00H
IP Addr:  0.0.0.0
Gateway:  0.0.0.0
Subnet:   0.0.0.0
MAC:      00:00:00:00:00:00
No Sockets Configured

C>WIZCFG M 00:AA:BB:CC:DE:02

C>WIZCFG G 192.168.178.1

C>WIZCFG I 192.168.178.25

C>WIZCFG S 255.255.255.0

C>WIZCFG N F0

C>WIZCFG
Node ID:  FCH
IP Addr:  0.0.0.0
Gateway:  192.168.178.0
Subnet:   255.255.255.0
MAC:      00:AA:BB:CC:DE:00
No Sockets Configured

C>wizdbg g 0 0 32
00:0000 00 C0 A8 B2 00 FF FF FF 00 00 AA BB CC DE 00 00
00:0010 00 00 00 00 00 80 00 00 00 07 D0 08 28 00 00 00

[durgadas311]

I'm not at all familiar with this hardware, so can't tell how the CF interface might be affected by the CSIO. Is it possible to write a simple program to inspect the CSIO registers, that could be used to confirm whether things are setup correctly? John could also use that to get more info. Maybe RomWBW has a monitor with debug commands, and can perform I/O instructions already?

[DavidJRichards]

John, could you compare the binary I attached previously with the one you are using please - vbindiff is the utility I use for this task. David.

[DavidJRichards]

Another thing to check is that the power supply is adequate for the job, are you sure the board is getting a healthy 5V input.

[jrlodden]

Power supply is +5V 2 amp -- This is the standard power supply I use on my VOIP phones. SC126 has the CF card, the W5500 and the USB connection my PC. Don't think its a power issue.

Using your WIZCFG.COM -- Same results -- At least it is not a compile issue.

C>WIZCFG
Node ID:  00H
IP Addr:  0.0.0.0
Gateway:  0.0.0.0
Subnet:   0.0.0.0
MAC:      00:00:00:00:00:00
No Sockets Configured

C>WIZCFG M 00:AA:BB:CC:DE:02

C>WIZCFG G 192.168.178.1

C>WIZCFG I 192.168.178.25

C>WIZCFG S 255.255.255.0

C>WIZCFG N F0

C>WIZCFG
Node ID:  00H
IP Addr:  0.0.0.0
Gateway:  192.168.178.0
Subnet:   0.0.0.0
MAC:      00:AA:BB:CC:DE:00
No Sockets Configured

C>
C>wizdbg g 0 0 32
00:0000 00 C0 A8 B2 00 00 00 00 00 00 AA BB CC DE 00 00
00:0010 00 00 00 00 00 80 00 00 00 07 D0 08 28 00 00 00

[DavidJRichards]

John, Do you have an Arduino? The first test I did when I got my W5500 board was to try it using one of the supplied library examples. Or perhaps you have used your boards in other projects already and know they are good.. Although the board you have looks very much like the one I have the silk screen is a little different. David.

[jrlodden]

David, I don't have an Arduino I am more of a software guy -- I did a lot of porting of drivers to TurboDOS back in the day. I am currently looking at porting TurboDOS to RomWBW and the SC126 as the first target. The ethernet card was away getting a faster link back to my Linux boxes until I get TurboDOS Z80 drivers ported and bring up the TurboDOS networking drivers to the rest of my TurboDOS 8086 boxes and PCs. I will start looking at the SD driver and see if I can see anything.

-jrl

[jrlodden]

Another thought David, what is your configuration? -- Maybe I could match it and rule out the Ethernet card. I think we have the same card -- If you are using the same card as the one in the retro-comp group picture -- my card and yours have the same mis-spelling of power in the corner of the card. I just think they took the brand off when creating more common thing to do on eBay.

[DavidJRichards]

Hi John, I'm doing my testing on the ROM versions of the o/s boot using c command. Otherwise 4,4 on multiboot SD image. Again stock configuration. My w5500 card is very similar, I'll post a picture shortly. I've tested using latest and Dev versions of romwbw. I'll take a photo of my CPU at the same time ...

[durgadas311]

I did a looking poking around the RomWBW code. First, found a bug I think. When it goes to initialize CSIO at full speed, it uses the i8080 OUT instruction instead of Z180 OUT0. I believe this renders that ineffective, but maybe it works. David's trace shows full speed. But, that final initialization appears to only be done if an SDCard is found and initialized. So, it's possible that CSIO is left at the slowest speed if no SDCards are found. At slowest speed, I think we'd definitely have a problem with chip-select being turned off too soon.

[DavidJRichards]

Interesting what you have found Douglas,

[DavidJRichards]

Hi Douglas, it sounds as if one fix could be to initialize the CSIO inside wizzcfg, do you think that would be appropriate?. For a test a small standalone program could be used for this purpose I suppose.

[durgadas311]

I was thinking of just trying a simple test first. If we initialize CSIO in the CP/NET code, it might conflict with (future incarnations of) RomWBW. Using DDT, if you can boot CP/M, you can run a simple test to query the CNTR register and see what it's value is. Then, we can try with and without an SDCard inserted. Something like this:

A>ddt
DDT VERS 2.2
-s100
0100 01 ed
0101 BC 38
0102 0F ca
0103 C3 ff
0104 3D .
-g100
*0103
-x
C0Z1M0E1I0 A=00 B=0000 D=0000 H=0000 S=0100 P=0103 RST  07
-g0

A>

And then look at the value in A to see what the CNTR register is set to.

[DavidJRichards]

is this what you intended Douglas? -s100 0100 01 ed 0101 BC 38 0102 0F ca 0103 C3 ff 0104 3D . -l100 0100 ??= ED 0101 ??= 38 0102 JZ 3DFF

[durgadas311]

Yes, except you won't be able to use the L command, as DDT does not understand Z80 (let alone Z180) instructions.

[DavidJRichards]

Hi Douglas, the g command exited ddt back to cp/m without displaying anything, I've written it in C now.

wtest reads the contents of IO_CNTR and prints the result in hex to the console.

no .interface or card fitted:

B>a:wtest
Initial IO_CNTR = 06

interface with card fitted:

B>a:wtest
Initial IO_CNTR = 80

wtest.com.tar.gz

[durgadas311]

Strange, that should have worked... Unless the SC is somehow not running in Z180 mode?

Anyway, that confirms what I suspected. When no SDCard is inserted, the CSIO runs at the slowest speed. I believe that will cause problems because the chip-select will be turned off before the last bit gets clocked out.

[jrlodden]

Results from my SC126:

C>wtest

Initial IO_CNTR = 0e C>wizdbg g 0 0 32 00:0000 00 C0 A8 B2 00 00 00 00 00 00 AA BB CC DE 00 00 00:0010 00 00 00 00 00 80 00 00 00 07 D0 08 28 00 00 00

[DavidJRichards]

wtest-CSIO-set.com.tar.gz Hi John, run this one, it reads the CSIO, updates it by setting to 0, then re-reads it. Afterwards your system mite work, is that whats needed Douglas?

without sd card interface: Initial IO_CNTR = 0x06 Setting IO_CNTR to 0x00 Present IO_CNTR = 0x00

[durgadas311]

Looks like john is seeing the same thing, the CSIO speed is set to "6" which is the slowest (divide by 1280).

I opened RomWBW issue https://github.com/wwarthen/RomWBW/issues/171 to address the initialization of CSIO when no SDCards exist.

I opened RomWBW issue https://github.com/wwarthen/RomWBW/issues/170 to address the use of OUT vs. OUT0.

[durgadas311]

wtest-CSIO-set.com.tar.gz Hi John, run this one, it reads the CSIO, updates it by setting to 0, then re-reads it. Afterwards your system mite work, is that whats needed Douglas?

without sd card interface: Initial IO_CNTR = 0x06 Setting IO_CNTR to 0x00 Present IO_CNTR = 0x00

Yes, I was going to suggest the same thing. I'm not sure of the implications of this on other hardware, but based on how I think the current SD driver works I don't think it will ever run at a slower speed.

One possible hitch here is that insertion (or removal) of an SDCard later - without reset/reboot - might cause problems. For example, if RomWBW does handle "hot plug" of SDCards, removal might cause it to lower the speed to try and read the card and then it would leave it at the slower rate. There may be other problematic scenarios.

[jrlodden]

results from my SC126: C>wtest

Initial IO_CNTR = 0x0e Setting IO_CNTR to 0x00 Present IO_CNTR = 0x08 C>

[jrlodden]

Works after running wtest.com: C>WIZCFG N F0

C>WIZCFG I 10.10.250.3

C>WIZCFG G 10.10.250.2

C>WIZCFG S 255.255.255.0

C>WIZCFG M 02:00:5D:0D:F1:01

C>WIZCFG 0 00 10.10.250.2 31100

C>wizcfg Node ID: F0H IP Addr: 10.10.250.3 Gateway: 10.10.250.2 Subnet: 255.255.255.0 MAC: 02:00:5D:0D:F1:01 Socket 0: 00H 0.0.0.0 0 0

C>wizdbg g 0 0 32 00:0000 00 0A 0A FA 02 FF FF FF 00 02 00 5D 0D F1 01 0A 00:0010 0A FA 03 00 00 80 00 00 00 07 D0 08 28 F0 00 00

C>

[durgadas311]

Woo hoo!

David, Wayne got back on wwarthen/RomWBW#171 with a good point. The Wiznet code should probably be isolating itself from any speed requirements of other code. It's not pretty, but maybe there's a good way to implement this: save the current CSIO speed when "entering" WizNet code, force speed to "fastest" and perform function, then restore whatever the previous speed was before "exiting" WizNet code. It may not be pretty, but perhaps worth thinking about. Of course, interrupts may through a huge wrench into that idea.

[DavidJRichards]

Very nice, good detective work Douglas.

[durgadas311]

Woo hoo!

David, Wayne got back on wwarthen/RomWBW#171 with a good point. The Wiznet code should probably be isolating itself from any speed requirements of other code. It's not pretty, but maybe there's a good way to implement this: save the current CSIO speed when "entering" WizNet code, force speed to "fastest" and perform function, then restore whatever the previous speed was before "exiting" WizNet code. It may not be pretty, but perhaps worth thinking about. Of course, interrupts may through a huge wrench into that idea.

Maybe it's as simple as having 'cslower' save the speed and force "0", then have 'csraise' restore the speed.

[jrlodden]

Very nice! On to setting up the servers. Thanks for all your help!

[durgadas311]

Wayne also alluded to "this problem" only appearing on certain revs of the Z180 (he mentions "rev K"). I take that to mean this behavior of TE going to "0" before the end of the transmission. But, we probably have to address it no matter what, since at least some chips behave this way.

[DavidJRichards]

cs lower and raise need work anyway as the io port they use is shared with other devices but the port is write only, the bios has a mirror register to read from but this is not accessible from the cpnet code. At present it sets all other bits to 1 (inactive) and hopes for the best. For now I can easily do as you suggest and keep a local copy of the IO_CNRT.

[jrlodden]

Getting closer -- Looks like this SC126 is going to fight me the entire way. I can load CPNETLDR get the command prompt -- Issue the NETWORK command and I get a hang The Linux box server log shows a connect see below.

Once again thanks for all your help!

A>submit cpnet.sub

A>WTEST

Initial IO_CNTR = 0x0e
Setting IO_CNTR to 0x00
Present IO_CNTR = 0x08
A>WIZCFG N F0

A>WIZCFG I 192.168.1.110

A>WIZCFG G 192.168.1.1

A>WIZCFG S 255.255.255.0

A>WIZCFG M 02:00:5D:0D:F1:01

A>WIZCFG 0 00 192.168.1.32 31100

A>WIZCFG
Node ID:  F0H
IP Addr:  192.168.1.110
Gateway:  192.168.1.1
Subnet:   255.255.255.0
MAC:      02:00:5D:0D:F1:01
Socket 0: 00H 0.0.0.0 0 0

A>WIZDBG G 0 0 32
00:0000 00 C0 A8 01 01 FF FF FF 00 02 00 5D 0D F1 01 C0
00:0010 A8 01 6E 00 00 00 00 00 00 07 D0 08 28 F0 00 00

A>cpnetldr

CP/NET 1.2 Loader
=================

BIOS         E600H  1A00H
BDOS         D800H  0E00H
SNIOS   SPR  D300H  0500H
NDOS    SPR  C700H  0C00H
TPA          0000H  C700H

CP/NET 1.2 loading complete.

A>network o:=a:    <--- Hangs here on SC126

--log from CpnetSocketServer

CpnetSocketServer v1.2
Using config in cpnet.conf
Server 00 Listening on 192.168.1.32 port 31100 debug false
Connection from 192.168.1.110 (31100)
Remote 192.168.1.110 is f0
Creating HostFileBdos 00 device with root dir /net/common1/cpnet

[jrlodden]

After a power down -- can access the network drive once and then RomWBW crashes:

SC126 Boot Loader

ROM: (M)onitor (C)P/M (Z)-System (F)orth (B)ASIC (T)-BASIC (P)LAY (U)SER ROM
Disk: (0)MD1 (1)MD0 (2)IDE0 (3)IDE1 (4)SD0

Boot Selection? 2    Slice(0-9)[0]? 0

Booting Disk Unit 2, Slice 0...

Reading disk information...
Loc=D000 End=FE00 Ent=E600 Label=Unlabeled

Loading...

CBIOS v3.0.1 [WBW]

Configuring Drives...

   A:=IDE0:0
   B:=MD1:0
   C:=MD0:0
   D:=IDE0:1
   E:=IDE0:2
   F:=IDE0:3
   G:=IDE0:4
   H:=IDE0:5
   I:=IDE0:6
   J:=IDE0:7

   1932 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

A>submit cpnet.sub

A>WTEST

Initial IO_CNTR = 0x0e
Setting IO_CNTR to 0x00
Present IO_CNTR = 0x08
A>WIZCFG N F0

A>WIZCFG I 192.168.1.110

A>WIZCFG G 192.168.1.1

A>WIZCFG S 255.255.255.0

A>WIZCFG M 02:00:5D:0D:F1:01

A>WIZCFG 0 00 192.168.1.32 31100

A>WIZCFG
Node ID:  F0H
IP Addr:  192.168.1.110
Gateway:  192.168.1.1
Subnet:   255.255.255.0
MAC:      02:00:5D:0D:F1:01
Socket 0: 00H 192.168.1.32 31100 0

A>WIZDBG G 0 0 32
00:0000 00 C0 A8 01 01 FF FF FF 00 02 00 5D 0D F1 01 C0
00:0010 A8 01 6E 00 00 00 00 01 00 07 D0 08 28 F0 00 00

A>cpnetldr

CP/NET 1.2 Loader
=================

BIOS         E600H  1A00H
BDOS         D800H  0E00H
SNIOS   SPR  D300H  0500H
NDOS    SPR  C700H  0C00H
TPA          0000H  C700H

CP/NET 1.2 loading complete.

A>network k:=a:

A>dir k:
K: AUTOCPM  COM : BOOZ     COM : CCT      COM : CH       COM
K: CMP      COM

CBIOS v3.0.1 [WBW]

[durgadas311]

Was the "dir k:" output complete, or did it stop in the middle? I'm not sure what it takes on this platform to re-display the CBIOS cold-start message, but it's possibly something gone wrong in the CP/NET warm-start sequence - if the DIR output did finish.

It might help to enable 'debug' on the server, that will give more information about the messages being sent back and forth and might help pin-point just when it is crashing. You can add 'debug' to the server java commandline, or add the 'cpnetserver_debug' property to the config file.

Are there any oddly-named files in that server's sub-directory for it's A: drive?

[jrlodden]

It is hanging mid running the dir. The directory doesn't have anything weird in it for filenames normal 8.3 files. This is a hang I just got, look like the RomWBW tried to restart and hung. Something is causing a problem in RomWBW bios.

A>submit cpnet

A>WTEST

Initial IO_CNTR = 0x0e
Setting IO_CNTR to 0x00
Present IO_CNTR = 0x08
A>WIZCFG N F0

A>WIZCFG I 192.168.1.110

A>WIZCFG G 192.168.1.1

A>WIZCFG S 255.255.255.0

A>WIZCFG M 02:00:5D:0D:F1:01

A>WIZCFG 0 00 192.168.1.32 31100

A>WIZCFG
Node ID:  F0H
IP Addr:  192.168.1.110
Gateway:  192.168.1.1
Subnet:   255.255.255.0
MAC:      02:00:5D:0D:F1:01
Socket 0: 00H 0.0.0.0 0 0

A>WIZDBG G 0 0 32
00:0000 00 C0 A8 01 01 FF FF FF 00 02 00 5D 0D F1 01 C0
00:0010 A8 01 6E 00 00 00 00 00 00 07 D0 08 28 F0 00 00

A>cpnetldr

CP/NET 1.2 Loader
=================

BIOS         E600H  1A00H
BDOS         D800H  0E00H
SNIOS   SPR  D300H  0500H
NDOS    SPR  C700H  0C00H
TPA          0000H  C700H

CP/NET 1.2 loading complete.

A>network k:=a:

CBIOS v3.0.1 [WBW]

Configuring Drives...

   A:=IDE0:0
   B:=MD1:0
   C:=MD0:0
   D:=IDE0:1
   E:=IDE0:2
   F:=IDE0:3
   G:=IDE0:4
   H:=IDE0:5
   I:=IDE0:6 *** Insufficient Memory ***
   J:=IDE0:7 *** Insufficient Memory ***

   19 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

[jrlodden]

Just did a reset and got this panic back from RomWBW:

ROM: (M)onitor (C)P/M (Z)-System (F)orth (B)ASIC (T)-BASIC (P)LAY (U)SER ROM
Disk: (0)MD1 (1)MD0 (2)IDE0 (3)IDE1 (4)SD0

Boot Selection? 2    Slice(0-9)[0]? 0

Booting Disk Unit 2, Slice 0...

Reading disk information...
Loc=D000 End=FE00 Ent=E600 Label=Unlabeled

Loading...

CBIOS v3.0.1 [WBW]

Configuring Drives...

   A:=IDE0:0
   B:=MD1:0
   C:=MD0:0
   D:=IDE0:1
   E:=IDE0:2
   F:=IDE0:3
   G:=IDE0:4
   H:=IDE0:5
   I:=IDE0:6
   J:=IDE0:7

   1932 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

A>submit cpnet

A>WTEST

Initial IO_CNTR = 0x0e
Setting IO_CNTR to 0x00
Present IO_CNTR = 0x08
A>WIZCFG N F0

A>WIZCFG I 192.168.1.110

A>WIZCFG G 192.168.1.1

A>WIZCFG S 255.255.255.0

A>WIZCFG M 02:00:5D:0D:F1:01

A>WIZCFG 0 00 192.168.1.32 31100

A>WIZCFG
Node ID:  F0H
IP Addr:  192.168.1.110
Gateway:  192.168.1.1
Subnet:   255.255.255.0
MAC:      02:00:5D:0D:F1:01
Socket 0: 00H 192.168.1.32 31100 0

A>WIZDBG G 0 0 32
00:0000 00 C0 A8 01 01 FF FF FF 00 02 00 5D 0D F1 01 C0
00:0010 A8 01 6E 00 00 00 00 01 00 07 D0 08 28 F0 00 00

A>cpnetldr

CP/NET 1.2 Loader
=================

BIOS         E600H  1A00H
BDOS         D800H  0E00H
SNIOS   SPR  D300H  0500H
NDOS    SPR  C700H  0C00H
TPA          0000H  C700H

CP/NET 1.2 loading complete.

A>network k:=a:

A>dir k:
K: AUTOCPM  COM

CBIOS v3.0.1 [WBW]

Configuring Drives...

   A:=IDE0:0
   B:=MD1:0
   C:=MD0:0
   D:=IDE0:1
   E:=IDE0:2
   F:=IDE0:3
   G:=IDE0:4
   H:=IDE0:5
   I:=IDE0:6 *** Insufficient Memory ***
   J:=IDE0:7 *** Insufficient Memory ***

   19 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

CBIOS v3.0.1 [WBW]

>>> PANIC: @82B9[0493:0602:0202:FDBE:C887]  Continue? (Y/N):

[jrlodden]

Log from server:

CpnetSocketServer v1.2
Using config in cpnet.conf
Server 00 Listening on 192.168.1.32 port 31100 debug true
Connection from 192.168.1.110 (31100)
Remote 192.168.1.110 is f0
Creating HostFileBdos 00 device with root dir /net/common1/cpnet
00 00 f0 0e 00:00 00 00 00...
01 f0 00 0e 00:00 00 00 00...
00 00 f0 11 25:00 00 01 3f...
01 f0 00 11 20:00 00 41 55...
00 00 f0 12 01:00 00 41 55...
01 f0 00 12 20:01 00 42 4f...

Files in directory:

root@emul1:/net/common1/cpnet/a# ls
autocpm.com  d.com       hcat.com    pre280.com  slr180.com   uniq.com
booz.com     dif2.com    hexcom.com  prep.com    slrnk.com    uudecode.com
cct.com      field.com   lpr.com     rmac.com    sort2.com    uuencode.com
ch.com       find.com    ls.com      rz.com      sort.com     vsplit.com
cmp.com      gencom.com  mac.com     sh121.com   split16.com  wc.com
common.com   gencpm.com  merge.com   shbak.com   ssed2.com    zcal.com
cp.com       genepr.com  more.com    sh.com      sz.com
ctype.com    grep.com    pg.com      shsave.com  tr.com

[durgadas311]

OK, so does not always crash at the same place, but it appears to be somewhere around receiving the response message from the server. My guess is that the PANIC is basically the Z180 illegal instruction trap, and the other hangs/ROM-reentry are similar sorts of crashes, just with different memory contents.

Might be time to look through the SNIOS code and see if there is a stack breakage in some path - that would certainly send execution off into the weeds. Or possibly a stack overflow. I'll have to review how much stack space we have when the SNIOS is called.

Too bad we don't have a coredump facility. That might be something to talk to Wayne about - but won't help us right now.

[durgadas311]

I'm not seeing anything obvious in the code. I don't see any push/pop regions that can be escaped without doing the pop. Also, this is working for David, so unless it is something where "uninitialized" memory on David's system just happens to be innocuous - and fatal on John's system.

The NDOS uses a 30-level stack, which is also appended to the message buffer. So, it would take a pretty big stack explosion to overrun something critical - especially for the messages seen.

One thing might be to see if there is something corrupting the memory banking register. I'm not familiar with how this is done on the SC126, but at least some of the crashes appear to be re-entering the ROM and I wonder if something trashes that I/O register causing the crash. I also wonder if there could be an interrupt occurring, which then leads to the conditions whereby it crashes. Again, I'm not aware of how RomWBW, or the CP/M BIOS, uses interrupts here.

One thing you could try, but I'm not sure it gives us any new information, is to run "rdate" instead of the network/dir sequence. This sends and receives very small messages, and so if you still crash it might give us a little better picture of the problem characteristics. If the server ID is "0", then just "rdate" should do it. Otherwise, add the server ID to the command.

[jrlodden]

Ok -- rdate also hangs and returns to the RomWBW boot screen.

CBIOS v3.0.1 [WBW]

Configuring Drives...

   A:=IDE0:0
   B:=MD1:0
   C:=MD0:0
   D:=IDE0:1
   E:=IDE0:2
   F:=IDE0:3
   G:=IDE0:4
   H:=IDE0:5
   I:=IDE0:6
   J:=IDE0:7

   1932 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

A>submit cpnet

A>WTEST

Initial IO_CNTR = 0x0e
Setting IO_CNTR to 0x00
Present IO_CNTR = 0x08
A>WIZCFG N F0

A>WIZCFG I 192.168.1.110

A>WIZCFG G 192.168.1.1

A>WIZCFG S 255.255.255.0

A>WIZCFG M 02:00:5D:0D:F1:01

A>WIZCFG 0 00 192.168.1.32 31100

A>WIZCFG
Node ID:  F0H
IP Addr:  192.168.1.110
Gateway:  192.168.1.1
Subnet:   255.255.255.0
MAC:      02:00:5D:0D:F1:01
Socket 0: 00H 0.0.0.0 0 0

A>WIZDBG G 0 0 32
00:0000 00 C0 A8 01 01 FF FF FF 00 02 00 5D 0D F1 01 C0
00:0010 A8 01 6E 00 00 00 00 00 00 07 D0 08 28 F0 00 00

A>rdate
This program requires CP/NET.
A>cpnetldr

CP/NET 1.2 Loader
=================

BIOS         E600H  1A00H
BDOS         D800H  0E00H
SNIOS   SPR  D300H  0500H
NDOS    SPR  C700H  0C00H
TPA          0000H  C700H

CP/NET 1.2 loading complete.

A>rdate

SC126 Boot Loader

ROM: (M)onitor (C)P/M (Z)-System (F)orth (B)ASIC (T)-BASIC (P)LAY (U)SER ROM
Disk: (0)MD1 (1)MD0 (2)IDE0 (3)IDE1 (4)SD0

Boot Selection?

*** Invalid Selection ***

ROM: (M)onitor (C)P/M (Z)-System (F)orth (B)ASIC (T)-BASIC (P)LAY (U)SER ROM
Disk: (0)MD1 (1)MD0 (2)IDE0 (3)IDE1 (4)SD0

Boot Selection?

Server Log:

CpnetSocketServer v1.2
Using config in cpnet.conf
Server 00 Listening on 192.168.1.32 port 31100 debug true
Connection from 192.168.1.110 (31100)
Remote 192.168.1.110 is f0
Creating HostFileBdos 00 device with root dir /net/common1/cpnet
00 00 f0 69 00:00 00 00 00...
01 f0 00 69 04:55 3d 21 53...