Troubleshooting an Oak Solutions Classnet podule

discuss the archimedes & risc pc, peripherals and risc os/risc os on pi
Post Reply
Kazzie
Posts: 1590
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Troubleshooting an Oak Solutions Classnet podule

Post by Kazzie » Sat Sep 14, 2019 2:20 pm

(With reference to this existing thread)

I've bought a 16-bit Classnet ethernet card for my A420/1. I don't seem to be having much luck getting it to do anything, however.

I've removed the Econet and ZIDEFS cards from the system, so they're not causing any problems.

When doing a Delete-boot, I am shown the following message:
Warning: Station number not available
Error: AddressException:Address exception at &%0 (Error number &800000003)
and dropped at a * prompt.

Issuing a *podules command shows the podule is recognised ("Oak Ethernet Interface"), and *configure lists at least one option related to the card ("BootNet").

If I boot the macgine without holding down delete, the machine hangs with a black screen and blinking white cursor. Removing the ROM allows the machine to boot, but without recognising the presence of the ClassNet card, of course.

After a Delete-boot, on then continuing to the desktop, I can run !ClassNetC from a floppy disk, and get the same configuration screen as on the linked thread. (This won't run if the ClassNet card isn't present.) On restarting the machine I'm back to the same black screen and blinking cursor.

Any suggestions? [-o<
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
Acorn System 1 home-made replica

Kazzie
Posts: 1590
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Troubleshooting an Oak Solutions Classnet podule

Post by Kazzie » Sat Sep 14, 2019 8:13 pm

Some further observations:

IC5 is a ST 93C46AB1 1K serial EEPROM. When booting the machine with it removed, it hangs in the same manner. On doing a Delete-boot, I am told
Warning: Station number not available
EERrom data partition corrupt
And the machine continues to boot to the desktop. At this point successive boots or reboots (without holding delete) get me to the desktop just fine. Changing the station number in ClassNetC (and rebooting with Ctrl-Break) makes the machine hang again. Changing other settings (such as selecting Ethernet instead of Classnet) doesn't hang the machine, but they don't get stored either.

The EEPROM does appear to store settings correctly. Having delete-booted the machine (with the EEPROM on the card) I was able to use ClassNetC to set a password. On rebooting, I was then prompted for the password. After giving the correct password, the machine would hang. #-o (Getting rid of the password again involved Delete-booting without the EEPROM present, inserting it while the machine was running, and using ClassNetC to set a blank password!)

Delete-booting (to desktop) with the EEPROM present, powering off, and replacing the EEPROM leads to the Error: AddressException message at next boot.

---------

Another scenario:

Delete-booting the machine without the ClassNet present, powering down, and powering up with ClassNet (and EEPROM) inserted, I get the AddressException error as expected. Powering off and removing the card, the machine boots again, but is now configured to have one IDE drive present. :shock: (The A400/1 series shipped with an ST506 drive, but a Delete-boot sets it to just one floppy drive configured.)

An audit of all the chips on the card gives the following info:

IC1: Fujutsu MB86960 - main ethernet chip
IC2: "CNET16.01" st 16S25HB1 (GAL?)
IC3: ClassNet - 4.03 ROM (32-pin M27C1001)
IC4: 74HC174 - hex D flip-flop
IC5: ST 93C46AB1 1K serial EEPROM
IC6: 84256A-70l - 32K SRAM
IC7: 84256A-70l - 32K SRAM, socketed
IC8: MBL8392A - ethernet transciever chip
IC9: 74HC125 - quad bus buffer

-------------

At the moment, I'm suspecting that the ClassNet card is doing something screwy to the machine's CMOS when it is first loaded, or when I change the station number through !ClassNetC (when the EEPROM's absent).
Last edited by Kazzie on Sat Sep 14, 2019 8:14 pm, edited 1 time in total.
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
Acorn System 1 home-made replica

Kazzie
Posts: 1590
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Troubleshooting an Oak Solutions Classnet podule

Post by Kazzie » Sat Sep 14, 2019 8:30 pm

A possibly relevant link: https://web.archive.org/web/20040608192 ... kdci4.html
A DCI4-upgraded ROM image for the ClassNet podule. I've no idea if that's what's currently on my card or not.

Also: https://www.niftysoftware.co.uk/ns/index.htm
CMOS Fix
Fixes CMOS checksum, allows Oak ClassNet Cards to keep their station number after Power-on-delete. Also fixes problems with RISC OS 4 where expansion cards corrupt the CMOS checksum causing RO4 to reset the whole CMOS
Last edited by Kazzie on Sat Sep 14, 2019 8:42 pm, edited 1 time in total.
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
Acorn System 1 home-made replica

Kazzie
Posts: 1590
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Troubleshooting an Oak Solutions Classnet podule

Post by Kazzie » Sat Sep 14, 2019 8:55 pm

And one last message for the night:

With the ClassNet card installed and connected directly to the BNC socket of an EN104 ethernet hub, the EN104's BNC Active LED is lit when the A420/1 is OFF, and unlit when the A420/1 is on.

Removing LK1 (which enables T2, the 2VP5U9 step-up voltage transformer thingy) allows the machine to boot just fine! :mrgreen:

The only proviso is that it keeps introducing a non-existent IDE drive 4 to the CMOS settings, and I get a brief "bad drive" message during boot. That might require a bit more negotiation with the ClassNet ROM to deal with.

With LK1 removed, the hub's Active LED stays on. Alternatively, replacing LK1, and moving LK2-7 so that the MB86960 is connected to the AUI port instead also lets the machine boot, but the hub's Active LED is now off. So there's reason to suspect one of T1, T2, or IC8.

Still, at least there's some progress...
Last edited by Kazzie on Sat Sep 14, 2019 9:02 pm, edited 1 time in total.
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
Acorn System 1 home-made replica

Kazzie
Posts: 1590
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Troubleshooting an Oak Solutions Classnet podule

Post by Kazzie » Sun Sep 22, 2019 12:30 pm

I've had an experiment with replacing the ZIDEFS ROM that identified its drives as ADFS: while that stopped the ZIDEFS and ClassNet cards arguing and adding non-existent hard drives, it also trampled the existing ADFS filer, meaning my floppy drive wouldn't show up any more. So that seems to be a dead end.

The ClassNet card seems to have gotten more sulky, however. It now gives its UndefinedInstruction error on boot whether LK1 (ThinNet transciever) is on or off. As previously, I can issue the desktop command and get to a GUI on the first boot, but hard reboots now show "Warning: Station number not available" (which is unsurprising with no network connected) followed by a non-flashing[/] cursor.

I'm now looking at how to modify or manipulate the ClassNet ROM to get rid of the functionality I don't want. I also suspect that some of the grumpyness may be due to some corruption in the ROM: the label over the quartz window isn't quite aligned nicely as it happens. Maybe some light's gotten in, or maybe it's just showing its age. Even if some bits are dodgy, I only want the EtherO and internet functionality off the ROM.

I'm hampered slightly by the fact that my EPROM burner won't handle anything larger than a 27512. I may be able to jury-rig something up to read it a bit at a time, but before I get protoboarding...

Is it possible to read the contents of the podule ROM live under RISC OS, and write it directly to a file? I've come across examples of doing that with the OS ROMs, but I don't know where in the memory map I'd expect to find the podule ROMs.

Does anyone have an existing good dump of the ClassNet ROM, or the ability to make one?

Finally, I'd appreciate any recommended reading on ROM images for podules.
Attachments
IMG_20190922_1142284.jpg
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
Acorn System 1 home-made replica

User avatar
IanS
Posts: 1265
Joined: Mon Aug 31, 2009 7:02 pm
Contact:

Re: Troubleshooting an Oak Solutions Classnet podule

Post by IanS » Sun Sep 22, 2019 6:52 pm

Kazzie wrote:
Sun Sep 22, 2019 12:30 pm
Is it possible to read the contents of the podule ROM live under RISC OS, and write it directly to a file? I've come across examples of doing that with the OS ROMs, but I don't know where in the memory map I'd expect to find the podule ROMs.

Does anyone have an existing good dump of the ClassNet ROM, or the ability to make one?

Finally, I'd appreciate any recommended reading on ROM images for podules.
There is no standard way of reading the whole rom from within RISC OS, the best bet is to remove the chip and read it in something that can handle the appropriate chip.

Each podule only as 4Kwords of space, which has to contain the rom and the IO peripherals. A lot of podules split the space in half, 2K for ROM, 2K for IO. Roms that are bigger than 2K implement a paging scheme, each rom can do the paging differently. So each ROM needs to provide a loader (in the first page) which allows the OS to read the rest of the ROM.

See this viewtopic.php?f=16&t=13654&p=179234#p179234 for details on decoding the rom image.

Kazzie
Posts: 1590
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Troubleshooting an Oak Solutions Classnet podule

Post by Kazzie » Sun Sep 22, 2019 7:23 pm

Thanks for that link. In other news, I've found that the classnet will boot happily when the ThinNet interface is both enabled and terminated correctly.

Also, running !NoHard from the CRomEconet folder tells the ClassNet interface to hide ADFS drive 4 from view. Given that this is a non-existent drive that the ClassNet ROM is configuring on boot, it suits me fine for it to be hidden. That means there's just a passing "bad drive" error during boot.

(!NoHard and !HardInit both require me to run !ClassNetC first, even if I just open and cancel that application.)

The podule's ROMs provide the text-based commands ClassNet, Partitions, and Desktop_ClassADFS. (For context, part of Oak's ClassROM functionality is the ability to partition an ADFS hard drive into read-only and read-write portions, for protection from click-happy kids.)

ClassNet and Desktop_ClassADFS don't do anything interesting, but Partitions reports that:
Partition module cannot be killed
Computer is password protected
Boot configuration EEPROM protected
Filesystem configuration EEPROM protected
Econet station number EEPROM protected
and some details on it's non-existent partitioning of ADFS::4.

With the EEPROM removed, as well as the error during boot, I'm told:
Partition module cannot be killed
*Configure is disabled
Computer is password protected
Boot, Floppies and Bootnet config not initialised
Filesystem config not initialised
Fileserver config not initialised
Econet station config not initialised
A hairbrained idea that's floated into mind is to buy a new (blank) serial EEPROM, and see what happens then. Ebay prices are ₤5 for one from London, or ₤7 for 15 from Poland. There's a bagful on the way! :)
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
Acorn System 1 home-made replica

Kazzie
Posts: 1590
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Troubleshooting an Oak Solutions Classnet podule

Post by Kazzie » Sat Sep 28, 2019 6:46 pm

My bag of EEPROMs were collected from the sorting office this morning. I've wired up an Arduino Nano (clone) to communicate with the ST93C46AB along its serial microwire interface using an existing library:
IMG_20190928_1735598.jpg
Top side of EEPROM is power and setting 16-bit access mode.
Bottom is a microwire interface with the Arduino (with pull-up resistors on the data in and out lines)
Putting a blank EEPROM (all FFFFs) in the ClassNet card gives the same "corrupted" error at boot as having no EEPROM. Its contents aren't changed by the ClassNet card when booting, but it then writes values to some locations when !ClassNetC is opened and closed (without saving settings):

Code: Select all

Blank EEPROM:
	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--
0	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF
10	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF
20	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF
30	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF

Open and close (save) !ClassNetC:
	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--
0	FFFF	FFFF	FFFF	FFFF	DC86	FFFF	FFFF	FFFF	FFFF	FF	FFFF	FF	FFFF	FFFF	03	FF
10	FFFF	FFFF	FF08	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF
20	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	5A0F
30	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF
Twiddling settings in the !ClassNetC has led me to discover the following so far:

ClassNet station number and NetFiler on/off status don't seem to be stored in the EEPROM, they may share CMOS space with Econet settings.

Address 0x0F controls Classnet/Internet settings, whether ClassROM, ClassShare client and/or server are enabled:
bit 0: ClassShare client (0 = enabled)
bit 1: ClassROM (0 = enabled)
bit 2: ClassROM (0 = enabled)
bit 3: ClassShare server (0 = enabled)
bit 4: ClassShare client (0 = enabled)
bit 5,6,7: all on = ClassNet only, bit 5 on = Internet only, bit 6 on = Classnet and Internet

Setting ADFS Disc control (under ClassROM) changes the values of addresses 0x20, 0x21, 0x2F

0x10 stores the server address for the ClassShare client (xx.yy): the upper byte is the xx portion, lower byte is yy.

0x11 is The filing system cache size, stored in the two bytes (max 65535k)

0x12 (lower byte)is the filing system used by the ClassShare server (e.g. 08 is ADFS, AA is IDEFS)

0x12 (upper byte) indicates how many 64k blocks are allocated for user files.

The User and Apps disc options for ClassShare client are controlled by the lower byte 0x14: bit 0 is Apps, bit 1 is User (both active low).

The upper byte of 0x14 corresponds to the number of clients permitted by the ClassShare server (max 255)

Setting a password affects the values of 0x2A and 0x2F, but not in an obvious manner. The passwor dcan be up to eleven characters, but it's not stored in plaintext: that would be too easy! (I was hoping it would, as that would mean the purpose of eleven bytes could easily be identified. Oh well...)

For reference, the current contents of the EEPROM that was originally in the machine are:

Code: Select all

	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--
0	C000	10E9	EE01	FFFF	DC86	FFFF	5A	80A	FD00	04	A32	10	9C4	12C	03	51
10	FFFF	FFFF	FFAA	FFFF	FFFB	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF
20	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFB	FFFF	FFFF	5A0B
30	FF9B	1408	00	405A	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF
Further to-dos on the investigation front include setting passwords of varying length/contents to identify how they're stored, and seeing what happens when I twiddle bits on the EEPROM. The output of the Partitions command should tell me what some of them do.
Attachments
93c46ab1.pdf
EEPROM datasheet
(111.49 KiB) Downloaded 9 times
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
Acorn System 1 home-made replica

Kazzie
Posts: 1590
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Troubleshooting an Oak Solutions Classnet podule

Post by Kazzie » Sun Sep 29, 2019 1:22 pm

Having calmed down after the rugby(!), a few more discoveries, based on the differences in behaviour between a blank EEPROM and the one that was already installed:
  • Address 0x30 controls whether the boot configuration is protected by the EEPROM. I played around with a few permutations, but setting the contents to 0000 appears to disable the functionality: the "Partitions" command doesn't show the "config not initialised" message of a blank EEPROM, nor the "EEPROM protected" message that the original EEPROM did: just no message at all.
  • Zeroing out 0x31 likewise disables the filesystem configuration protection.
  • Zeroing out 0x32 disables fileserver configuration protection.
  • Zeroing 0x33 disables Econet configuration protection.
  • Zeroing addresses 0x34 to 0x39 seems to have no effect.
That leaves two status messages reported by Partitions: that the partitions module cannot be killed, and that the computer is password-protected (though with a blank password set that has no real effect).
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
Acorn System 1 home-made replica

Kazzie
Posts: 1590
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Troubleshooting an Oak Solutions Classnet podule

Post by Kazzie » Sun Sep 29, 2019 9:51 pm

Right then, I think I've nailed it.

First, some other important memory locations:
  • 0x00, 0x01, and 0x02 contain the MAC address for the network card (stored in little-endian format in each address.
  • The options for password protection and for locking the Partitions module in memory are somewhere in the 0x20-0x2F range
The reason that I don't know exactly where those last options are is that I just tried zeroing out the whole range, and found that the problem was gone. I think that they're in the 0x2D-0x2F range, but I didn't get a conclusive answer when I did a quick double-check.

An example blank EEPROM for anyone else that wants to cast off the padlocks is as follows:

Code: Select all

	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F

00	bbaa	ddcc	ffee	FFFF	DC86	FFFF	FFFF	FFFF	FFFF	00FF	FFFF	00FF	FFFF	FFFF	0003	003F
10	FFFF	FFFF	FF08	FFFF	FFFB	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF	FFFF
20	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	A5F0
30	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000	0000
The first three addresses need to be replaced with your desired MAC address aa:bb:cc:dd:ee:ff. You can check the MAC address in your existing EEPROM with the eoinfo command.

Doing a straight-swap from a locked-down EEPROM to this unlocked EEPROM will probably require a CMOS wipe, as the settings that the locked-down EEPROM writes to CMOS every boot will still be in there. A general guideline would be:
  • Do a Del-boot to clear the CMOS settings to default
  • Reconfigure the system settings you lost (e.g. time, ZIDEFS configuration)
  • Load !ClassNetC, change the station number (away from 1), and turn the NetFiler option on
I still need to check if the machine can actually contact others over Econet and Ethernet. But that's a task for another day. :)



And just to re-iterate, if you have a ClassNet card that is password protected, here's how to get rid of the password:
  • Insert the ClassNet card in your machine, and remove the 8-pin EEPROM
  • Boot your machine, disregarding the corrupt EEPROM warnings.
  • Run !ClassNetC with the EEPROM absent. If will open without asking for a password.
  • Reinsert the EEPROM while the machine is running (and !ClassNetC is open)
  • Select the option to set a new password, but leave the field blank
  • Click OK at the bottom of the window; a blank password will be written to the EEPROM :twisted:
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
Acorn System 1 home-made replica

Post Reply

Return to “32-bit acorn hardware”