modelrail.otenko Trains, computers, vintage, retro, model railways… the lot…

PC-98 – 110-Pin Cables And External I/O

This was something I had always wanted to try: I had my trusty PC-9801N NS/A and the 110-pin port worked, as I'd tested it with both an Ethernet Adapter and SCSI Adapter.

What else can you do with this port? Well, it turns out that it's a full interface to the PC-98's C-BUS. I mean, that's why the Ethernet and SCSI adapters work so easily... they're actually mini C-BUS cards built to fit the portable asthetic of the 98-Note and its 110-pin connector.

It turns out that NEC released an entire external chassis, known as the PC-9801N-08 External I/O Unit, to hold three C-BUS cards. This connects to any 98-Note with a 110-pin port (later 98-Notes have a much larger port!) via a chunky cable, of which I've never seen one in the flesh. What I have seen are 110-pin to Floppy Drive cables, but these have a centronics 50-pin plug at the far end, instead of the required 110-pin at both ends.

The moons aligned: The right items appeared on Buyee at the right time for the right place... so I collected them.

Can I make a cable?

I set off to find the appropriate 110-pin connectors, but the best I could gather were 'external floppy cables' for the 98-NOTE. Fortunately, these have the correct connector on one end!

Look at that tiny-centronics goodness! Before-long, I had the casing off and the plugs dismantled with minimal damage.

The plastic casing can be prised off...

As expected, the floppy interface didn't need to use all pins, so only a small amount of wiring existed. The plugs are actually crimp-style, so further dismantling occurred to get them apart.

Ok, we're torn-down with minimal damage... a few broken clips, but nothing structural! I grabbed the nearest 50-pin IDC SCSI ribbon and tried to make it fit...

And it was never going to work as the cable was too thick. I couldn't think of viable alternatives... so I went down the solder route. DON'T DO THIS!

I ended up wrecking that plug, so jumped back on the auction site and shelled out too much for yet another 110-pin to floppy cable... it's in the mail.

The proper way to re-wire!

I ended up murdering a few data cables, that had been happily chilling in my box'o'junk, whilst looking for appropriately-girthed wires of a proper length. First up was a 50-pin Centronics SCSI cable... how could that not be tiny-strand?

Crap photo... but that far-left light-blue is the SCSI wire and you can see it's double the thickness. What else? Apple Serial cables were also too thick...

And then I hit the gold mine! DVI cables! Who doesn't have 6 million of the ugly things sitting in a box? And so I got started...

Some of the internal wiring of the DVI cable was twisted pair, probably for the colour video signals. These could still be used, you just needed to strip back more shielding...

The wires locked in to the rail nicely and even happily bent 90-deg, as required for the plug.

And look at that! It happened. I then realised I hadn't recorded the colouring, or even started on the other end... so I had to BEEP OUT the entire thing to wire it up. I mean, this was also a good quality verification process!

Meanwhile, as that I'd murdered the plug for the other side with solder, I couldn't even finish it. 75% done though!

Why was it never going to work?

Whilst waiting for the next cable to arrive, I decided I should investigate the I/O Unit end. Whilst beeping out the pins on the 110-pin connector, I realised that both extremeties of both rows of pins were ALL grounded. ALL GROUNDED. Looking at the pinout of the 110-pin port, these should all be +5v or other signals.... there's no way that these should be grounded on the I/O end?

A quick further googl' pointed out the obvious. In this Japanese forum post, one user asks if they can connect the unit straight through and is quickly told (via googl's bad translator):

However, looking at itp's post, it seems that there are cables (2 pieces) and an interface adapter for the expansion box. Without this, it is practically impossible (to connect a laptop directly). If you look closely at the connector on the back of the I/O Unit, it is not 110 pins. The manual says "100-pin connector".

It's what?

Haha... that's one of my 110-pin Ethernet modules lined up against the 100-pin (Yes, NOT 110-PIN!) connector on the I/O side. All that hard work above was NEVER going to work. Then again, maybe I'll finish the cable as it could still function as one-of-two of the cables needed if I ever manage to find/build the interface box! But then I'll still need a 100-pin amphenol plug!?

We'll chalk this one down as a huge (mildly-expensive) time-sinking failure!

3Com EtherLink II 3C503 – Boot ROMs

The XT-IDE Universal BIOS is a very cool project, enabling older hardware to support much newer storage devices. The safest way to use it is with a dedicted 8-bit ISA controller card, but there are other ways to get started. If you have an Ethernet card with a spare ROM slot on it, you can program an EPROM with their BIOS and boot from there! Or so I thought... enter the 3Com 3C503.

Willem EPROM Burning: 101

I've discussed using the Willem Programmer before and, since working out the caveats, it's relatively straight-forward. Firstly, make sure you have a known-working version of the burning software installed on a known-working machine with a known-working parallel port. Next, check that you have the EPROM-specific dip switches correct, the power at a suitably-high (with enough current!) level and TOTALLY erased EPROMS. I usually leave my EPROMs to cook for around 20 minutes in my super-dodgy Ultra-Viole(n)t eraser.

Another good note is to make sure that you write them more-than-once when programming. Press the program button on the programming software again and again... so that the EPROM is written and verified multiple times. The software will write a byte and check it, and I've had it where the second programming run will fail. The usual reason is that the EPROM wasn't erased well enough, and that the initial write tinkered with residual data/current in the chip's cells, which then settled. The second write will write/read/check and fail as that cell has changed to another value. Erasing and programming again might work, else that chip needs to go in the bin.

Preparing an XT-IDE Boot EPROM

The default ROM can be downloaded from here. Choose the folder whose name begins with an 'r' and has the highest number. This'll be the most-recent release of the software and should be bug-free on all supported hardware. There's a miriad of flavours of the software, so you'll need to choose the one that's right for your hardware.

Burn it to an EPROM. I chose a 27C256 as I had a spare truckload.

Testing it in known hardware

This is paramount. Don't just slap this in marginal hardware and expect things to work. I found a boring Realtek PCI 8139 NIC and slapped the freshly-minted EPROM in.

It was installed in my PIII-500 workhorse and worked first time!

Just for fun, I inspected the area of system memory where it mentioned the ROM was hosted:

Microsoft(R) Windows 98
   (C)Copyright Microsoft Corp 1981-1999.

C:\WIN98JP\DESKTOP>debug
-d d000:0000
D000:0000  55 AA 10 E9 B5 03 58 55-42 32 31 30 2D 3D 58 54   U.....XUB210-=XT
D000:0010  49 44 45 20 55 6E 69 76-65 72 73 61 6C 20 42 49   IDE Universal BI
D000:0020  4F 53 20 28 41 54 29 3D-2D 00 00 00 72 36 32 39   OS (AT)=-...r629
D000:0030  20 0A 28 32 30 32 34 2D-30 37 2D 32 30 29 00 00    .(2024-07-20)..
D000:0040  61 FC 00 00 04 00 00 00-02 80 00 01 00 00 F0 01   a...............
D000:0050  F0 03 00 0E 1D 00 00 00-00 00 1D 00 00 00 00 00   ................
D000:0060  70 01 70 03 00 0F 1D 00-00 00 00 00 1D 00 00 00   p.p.............
D000:0070  00 00 E8 01 E8 03 00 00-1D 00 00 00 00 00 1D 00   ................
-d d197:0000
D197:0000  89 55 12 89 5D 14 31 C9-89 4D 16 C7 45 18 00 02   .U..].1..M..E...
D197:0010  2D 01 40 81 DA EC 00 19-CB 73 04 80 4D 02 02 26   -.@......s..M..&
D197:0020  8A 54 0A 30 F6 89 55 08-89 4D 0A 26 8A 54 0B 89   .T.0..U..M.&.T..
D197:0030  55 0C 89 4D 0E 26 8B 54-0C 89 55 04 89 4D 06 91   U..M.&.T..U..M..
D197:0040  E9 4F FB 81 7E 18 AA 55-75 14 C6 46 1F 21 F7 56   .O..~..Uu..F.!.V
D197:0050  18 E8 0D 00 89 4E 1C 80-66 24 FE E9 3A FB E9 CD   .....N..f$..:...
D197:0060  FA B9 01 00 80 7D 14 04-73 03 80 C9 04 C3 FF FF   .....}..s.......
D197:0070  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................

Nice, there it is. I dumped it (great tutorial on dumping over here at MESS) for safe-keeping, so I could use it for any comparison in the future:

-n pci-d000.bin
-r bx
BX 0000
:0000
-r cx
CX 0000
:2000
-m d000:0 2000 0100
-w 0100
02000 BYTES WRITTEN
-q

Note that you need to hit enter at the end of any line starting with "-". 0x2000 is 8kb (aka 8192) in HEX. Debug also only cares for 8.3 filenames, so don't give it anything longer.

3Com EtherLink II 3C503

The actual card to test was this 'trusty' 100yen purchase from a Hard Off in Japan. The 3Com 3C503 was detected and installed under Win98 and worked fine. I then put in the EPROM and nothing happened during a restart!

This card has one thing going for it: configurable jumpers. The ROM location can be easily specified and I'd put it at 0xCC00.

I have no idea if this was a good location, but I went for it. A reboot saw absolutely nothing get executed! To test if it had actually been loaded into memory, I used debug once more:

Microsoft(R) Windows 98
   (C)Copyright Microsoft Corp 1981-1999.

C:\WIN98JP\DESKTOP>debug
-d cc00:0000
CC00:0000  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
CC00:0010  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
CC00:0020  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
CC00:0030  FF FF FF FF FF 00 00 00-00 00 00 00 00 00 00 00   ................
CC00:0040  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
CC00:0050  BF 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
CC00:0060  08 00 45 00 CA 00 8F 02-60 E8 12 01 00 00 32 FF   ..E.....`.....2.
CC00:0070  8A DA 66 D1 E3 66 50 66-BA D4 03 66 B8 1F 57 66   ..f..fPf...f..Wf
-q

Ah yeah, that's not it. I tried a few other locations, landing on D800, but it seems that Windows 98 was stealing the memory back after DOS had loaded. I ended up having to F8 to DOS when booting and debug from there:

That's still not it! But at least it's blank. What am I doing wrong? Turns out this card only supports 27C64 EPROMs and I've shoved a 27C256 in it! Ok, lift the address pin that could be conflicting:

And what do we see?

We're literally a half-step closer! I spent a lot of time googlin' what the @#$ was going on, but then I looked at the card again:

DATA MODE has an option between 16 and 8. I had thought this was Twisted Pair or BNC... but I was wrong. Setting it to 8 (finally) revealed:

Ok, the 'top end' looks good... what about the rear end? The ROM is 8kb, but there's a bit of filler at the end. The ROM data is around 1D7 bytes:

Ok good, but what about the very end? The ROM is 8k, and that's 0x2000 in hex. It's based at 0xD800, so we also need to check up to 0xD9FF:

What... what is that 0x04 0x04? I only had to ask the internet, because... as I keep saying, nothing is new on the internet. Someone has almost always had an issue in the same vein as anything and everything I've ever encountered. The strange thing with this forum thread is that they say that the 3C503 returns 0x80 0x80 as the last two bytes. Above, as you can see, we're getting 0x04 0x04. How broken are we? I dumped the ROM and compared everything with HxD and we're not bad! It really just is the last two bytes.

Ok, so there are the two bad values right at the end. The card is always reporting them and we need to find a work around.

BIOS Option ROM Checksums

We know the EPROM data is being loaded into memory, but we don't know why the system BIOS isn't executing it. I had to dig a bit to find a thread on Option ROM checksums which lead me to a great howto on Etherboot ROM booting. This latter document contained a great list of dot-points that need to be met for an Option ROM to be seen and booted:

How does the main BIOS know that the code in the ROM is to be executed and why does it not execute some random code by accident? The ROM code has several conditions placed on it:

1. The ROM must start on a 2kB boundary in the memory space, between 0xC8000 and 0xEE000, although some main BIOSes scan outside these limits.
2. The first two bytes of the ROM must be 55 AA hex.
3. The third byte of the ROM should contain the number of bytes in the ROM code divided by 512. So if the ROM code is 16kB long, then this byte would hold 20 hex (32 decimal).
4. All the bytes in the ROM (specified by the length byte just mentioned) must checksum to 8 bits of binary zero. The sum is formed by 8 bit addition of all the bytes, throwing away the carry. Note that there is not a particular location designated as the "checksum byte". Normally the ROM building process alters an unused byte somewhere to fulfil the checksum condition.

From the dump above, we can confirm that we tick the first and second point. For the third point, our third byte is 0x10, meaning that we're 8192 bytes long. This means that if we add together every byte in our 2k ROM, we need to sum to a total of 0. Fortunately, we don't have to do this manually! If we use the checksum calculator over here, it'll run throught the ROM and adjust the last byte to fulfil the checksum zero-sum requirement.

I fed it the ROM dumped from memory, as loaded by the 3C503. Why bother using the correct binary on disk if that's not the way it'll show in RAM?

C:\Users\steve\Downloads>romcksum32.exe \\yadayada\....\3comd800.bin

ROM Checksum Calculator  VER: 0.2 REV: D
Copyright (C) 1998-2021 Microprogramming TECHNIQUES
Programming/PC Code: Alexandru Groza
All rights reserved.

ROM file     : 3comd800.bin
Disk size    : 8192 (8 KiB)
ROM usage    : 100.00% (8192/8192)
ROM checksum : 0x4h (8-bit)

ROM file checksum updated.

So, what's it done?

It replaced the final 0x04 with an 0x49? So it decided that, once summed, we were missing 0x45 to sum back around to zero... sure... but our card is going to whack that final 0x49 back to 0x04. We'll need to 'spread' this checksum'd difference around spare bytes, but they're all 0xFF, so let's change the third-last byte to 0x00 and use it to store the remainder. Running the checksum again after making this change saw:

So, with an 0x00 instead of 0xFF, we now have a final byte value of 0x48. So the FF was worth 0x01? Regardless, if we know the last 0x48 will become 0x04 in the physical machine, we can store the 0x44 difference in the third-last byte:

And you know what? I wrote this version of the binary to an EPROM, inserted it into the 3C503 and IT BOOTED! Of course, this was a stock-standard XT-IDE BIOS ROM. What you ACTUALLY need to do is to run the XTIDECFG.COM file from a floppy with a machine-relevant BIOS loaded and then customise it to the configuration on your machine. This default BIOS tries to load a second ATA controller and causes no end of lock-ups as the hardware isn't actually attached!

I can't believe it worked.

Apricot Xi PC

This Apricot Xi (further info) (Service Manual) appeared on eBay and the seller was willing to ship it! He descibed it as the following:

It was tested to power up only. The hard drive spins up and a red light is visible inside through the floppy drive slot. It did not appear to boot. A minute or so after first powering up some caps blew in the power supply, likely filter capacitors. It did not stop and later could be powered up again to the same state.

That latter concept of why not try turn it on again after it exploded left me a little bemused... but what could I lose by trying to get it going?

The tear-down was nice and simple. A few screws here and there and things just nicely came apart.

The power supply was out first and the damage was blindingly obvious.

Those two nuts on the wall were not fun to remove, but with them out the base board came out cleanly.

With the new capacitors back in, the unit was re-assembled.

Of note, in the middle shot above, make sure to line up the carry-handle with the slot it fits through. In the last shot, make sure to re-connect the speaker cable to the motherboard before screwing down the drive-bay plate.

With it all together, voltages were checked and the 12v rail was quite high! With no load, this was mildly expected. I slapped in a sacraficial HDD and hit the power... it spun up and the motherboard speaker even beeped! I was good to continue the testing.

Video Out

Long-story-short... it's a 71.9hz vertical sync signal at 15.978khz horizontal. This doesn't match MDA, CGA or EGA... let alone anything higher.

The video port is a 9-pin male DB-9 with both syncs, video and a dangerous -12v pin. Don't just hook this up to anything non-Apricot!

I attempted with some logic to invert the vertical sync as it was mentioned somewhere that it might be negative and needs to be positive, but that didn't work.

The GBS-8200 didn't work either! So, what to do? Let's test something that's been on the shelf for a while...

I hadn't tested out the oscilliscope before and I still don't know how to use it. I was happy to see it seeing signals... but I couldn't work out if the frequencies were at the numbers I needed. I then realised my retro-corner LCD supports 15khz and threw together a test-wire straight through to VGA plug:

Hello there! It's totally failing to work out the vertical refresh rate... but that's fine... this thing is running a VGA vertical refresh with an EGA horizontal... it was never expected to 100% work without some kind of conversion. Just for fun, here's the specifications:

----CRT DATA DISPLAY SPECIFICATIONS---
PHYSICAL CHARACTERISTICS
Dimension	174mm max.
Height	241 ±1.5 mm
Width	226±5.0 mm
Depth	6.2 Ibs (2.8 kg)
Weight	240AMB39 polish
Picture Tube	Visual 9" 90° def. 20 mm dia.
Tilt	10° ± 1°
ELECTRICAL CHARACTERISTICS OF CRT DISPLAY MONITOR
Power Requirements	DC 11.8V 1.0A
Video Input Signal Requirements	Black level = 0 + 0.4 -O.OV White level = 4 ± 1.5V
Input Impedance	300 ohms min 40pF max.
VERTICAL INPUT SYNC SIGNAL REQUIREMENTS
Active Polarity	Positive
Pulse Rate	71.9 Hz
Pulse Width	158us
Amplitude	Low = 0 + 0.4 -O.OV High = 4 ± 1.5V
Input Impedance	1 Kohm min. 40pF max.
HORIZONTAL INPUT SYNC SIGNAL REQUIREMENTS
Active Polarity	Positive
Pulse Rate	15.79 kHz
Pulse Width	8.0us
Amplitude	Low = 0 + 0.4 -O.OV High = 4 ± 1.5V
Input Impedance	2 Kohms min. 40pF max.
Video Amplifier Band Width	25 MHz typ
Resolution	>= 800 TV Lines at center >= 650 TV Lines at corner
Vertical Character Area	120 ±5mm
Horizontal Character Area	150 ±5mm * According to the attached timing chart * +B = 11.8 ± 0.05V
BLANKING TIME REQUIREMENTS
Vertical	1200us min.
Horizontal	lOus min.
Vertical Deflection Linearity	10%
Horizontal Deflection Linearity	10% ((max - min)/(max + min) x 100)

So, what next? Find someone else that's built a 15khz VGA adapter. Writing this now, after building the MCEBlaster, I can't help but wonder if I should not have gone the simpler route and built the qiqitori analog-RGB to VGA adapter?

The MCEBlaster is multi-purpose for MDA/CGA/EGA, but none of those suit this display output! MDA is close, but it's still a reach from the resolution this unit is outputting. Using qiqitori's adapter, I could've just customised the code directly for this machine.

REGARDLESS, I didn't have this hindsight and built the MCEBlaster. In fact, I built it to the the schematic... expecting my video pin display data to be fed into all three coloured RGB TTL lines at once...

This was wrong, and with code changes forcing the EGA lines to 72hz vertical (which the code was picking up as the input signal, correctly), I got the following:

With a silly amount of tinkering (as this was never going to work as EGA is too limited to display the full EGA picture), I eventually got quite a bit of the picture to display!:

As mentioned, trying to fit 800x400 in 320x240 was never going to work. We're an MDA-esque signal and the board had full provision for such. I should have, from the start, fed the image into the input as if it was an MDA plug. This meant we needed to input video data on pin 7 and intensity on pin 6.

Unfortunately, the Apricot doesn't output an intensity pin, so pin 6 can be grounded. My wiring between the 74LVC245 and Pico could stay, as per the schematic, as the Pico knew to look on pins 26 and 27 if the vertical frequency was correct. I adjusted the MDA modeline config to look for 72hz (rounded-up) sync and we started getting somewhere...

I already had that encroaching feeling of Why am I doing this? If/when it works, what will I do with it?... so this was a good enough video output to test the rest of the peripherals. The error shown above is Error 31 and it means that Keyboard diagnostics failed.

Keyboard Input

As always, someone has already done this before. I built the circuit and plugged everything together expecting things to just-work, but I still got Error 31!

With the arduino connected, there was no data showing as coming from the Apricot? I checked the MAME source code for the Apricot keyboard and you could see that the keyboard was meant to receive a reset command from the computer and respond with an ACK:

		case CMD_KEYBOARD_RESET:
			logerror("System requests keyboard reset\n");
			transmit_byte(ACK_DIAGNOSTICS);
			break;

The computer stayed silent towards everything I threw at it. No amount of forced-sending of control codes from the keyboard to the computer worked, so I hooked up the oscilloscope to the data pin 2 of the keyboard port and yeah, the transmit signal from the computer to the keyboard was held high and had a not of noise. Interestingly though, pressing CTRL+ALT+DEL on the keyboard actually did reset the Apricot? The apricot-kbd arduino code has a special block where sees a reset request and holds the transmission line to ground for 100ms. Is this the required signal? I checked the schematics again and noticed that there was a special path for a system reset request.

Above, you can see the keyboard connector in the green box on the left. The two standard paths are orange and blue and they travel through respective MC1489/MC1488 paths to the Z80 SIO/0. I'm getting nothing from, and seemingly sending nothing to, this chip... so the only reason reset would work is via the purple path down the bottom.

Just for fun, I dismembered the trace between the SIO and the MC1488 on the outbound TX line to see if the MC1488 was the issue. Doing so still saw a high and messy voltage on the Z80A SIO/0 side, meaning something was wrong it, or with a chip further towards the CPU. Whilst doing all this, I happened to press my finger down on the SIO and found that it was hot enough to fry an egg! No wonder it's lid is so smooth and shiny.

It was a very quick removal. A socket was installed and... I found a pair of ICs (supposedly new-old-stock) on eBay. The machine was put back in the corner of the room... unscrewed, but neatly stacked. The ICs came in due course and one was installed.

And...?

PS2 to Xi
Value FA - Status Bits 0  Code 0xFA [�]   --  .
Value AA - Status Bits 0  Code 0xAA [�]   --  5F
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
----------From Apricot:
0 [] 
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 11E - Status Bits 1  Code 0x1E []   --  40
Value 811E - Status Bits 81  Code 0x1E []   --  FFFFFFC0
----------From Apricot:
E8 [�] 
----------From Apricot:
E8 [�] 
----------From Apricot:
E2 [�] 
----------From Apricot:
D0 [�] D4 [�] AA [�] E3 [�] 0 [] E2 [�] 81 [�] 52 [R] 41 [A] 4D [M] 20 [ ] 35 [5] 31 [1] 32 [2] 4B [K] 
Value 11E - Status Bits 1  Code 0x1E []   --  40
Value 811E - Status Bits 81  Code 0x1E []   --  FFFFFFC0

Wowzers... it's reporting 512K RAM to the non-existent Keyboard LCD! The paired values are from the PS/2 Keyboard keypresses and the data from the Apricot is self-explanatory once you've read the opcodes over here.

  if (Serial1.available()) {
    Serial.println("----------From Apricot:");
    while (Serial1.available())
    {
      uint16_t b = Serial1.read();
      Serial.print(b, HEX);
      Serial.print(" [");
      Serial.print((char)(b & 0xff));
      Serial.print("] ");

      switch (b)
      {
        //keyboard reset. just ACK
        case 0xe8: Serial1.write(0xfb); break;

      }
    }
    Serial.println("");
  }
}

Above is the only bit I changed when compared to the git repo.

Floppy Disk

This thing is a monstrosity, and didn't work at the start. It wasn't until I replaced the ZIO above that the floppy started seeking on boot and showing other signs of life. I haven't got a floppy disk formatted for this unit yet, but it really does seem that a catastrophic event occurred to wreck a whole bunch of chips in this machine. With one fixed, the data bus may well have been free'd up to communicate. It does still seem that once the machine has warmed up, that more faults start occurring. I'm guessing RAM? Either way, here's the beast of a drive:

If I can get it working more-consistently then I'll use apridisk to write disk images and have fun... but that's for another post. This one has gone on long enough!

Heat-Activated Gremlins

It seems that there are still issues with this machine. With the keyboard responding with an ACK, the system is finally reporting System OK on a cold boot, but starts to lose it once it's warmed up. After hitting enter at the prompt, the following message was displayed:

You can tell it's coded into the autoexec.bat file. Whilst trying to search for files on the Winchester Disk that others may have left behind, I initially received proper disk directory listings... until I didn't.

Letting the machine cool down again saw those same error'd directories list fine... so it's not the HDD itself... it's heat. I left the machine on for 20 minutes and touched all the chips... only the main CPU and its friend were (burningly) hot.

Could I be bothered replacing it? Should I heatsink the crap out of it to test further? Why am I even doing all of this? No idea.

PC-98 – Window Accelerators

Thanks to the complexity of Kanji characters, early Japanese 'DOS' machines needed high-resolution text displays. This requirement resulted in the PC-98's 640x400 standard console mode. The video cards to run this were purposely-built and were never really meant to run Windows.

Due to these limitations, companies started coming out with "Window Accelerators" which provided a secondary video device, of which could produce much higher resolutions at higher colour depths. I happened to get my hands on an IO-DATA GA-1280A-2, capable of 1280x1024 @ 256 colours.

Being a secondary video device, these cards require a passthrough cable from the primary machine video output to their 'input' port. When the machine is displaying standard PC-98 graphics, accelerators will route this output straight to the monitor. Once the card is initialised, you'll hear the internal relays 'click' and video will be displayed from the card's internal ram buffer, which specific software is now sending the graphical data to.

Unfortuantely, my specimen came as-is with no cable... so a trip was made to Jaycar for a male and female set of ribbon-crimp IDC 15-pin plugs.

The card was mounted in the machine and the wiring was hooked up...

With no drivers, the card will just pass the standard video through. This is what happened until I installed the drivers for DOS and Windows 3.1. And then? Reboot... a beautiful "CLICK" from the relay on the card and...

Windows 3.1 at a ridiculous resolution.

Does it play Doom?

By default, a PC-9801 can't play doom with it's in-built EGC video card. The settings only give you the following options:

And yeah, GA-1280* is there and it works perfectly.. not even needing other drivers! Well. It runs terribly on the PC-9801VX, even with the 486 Upgrade. The shots above were taken with the card installed in my newly-acquired FC-9801K with 486-Overdrive processor and Doom runs nicely!

PlayStation 2 – Linux And VGA

Back in University, our fourth year project was a Billiards game on the PlayStation 2. I still don't know how we wrangled making games as an educational experience, but it was fun nonetheless. We used PS2 Dev Kits that came with a linux distro, mouse and keyboard. There was also a VGA adapter which only worked with sync-on-green monitors and I specifically remember having to make a lot of desk space for the 21" Sony Trinitron. Since I'd been mucking around with the 'fake' HDD adapters for the old PS2s recently, it came to me that I should try install Linux and get VGA-out going... turns out it's not as easy as one might think!

Third-Party HDD Adapters Won't Work

If you've got a SATA adapter by PPH, or something similar, and the ethernet port is covered, or totally missing, then you're out of luck. The Linux distributions I've tried require the Original Sony HDD Adapters (or one of the original clones that HAD ethernet) and will just freeze up and stuggle if you try anything else.

Fortunately, I'd secured one for AU5$ from a Hard-Off somewhere in the bowels of Japan. Currently they're going for AU50$ on eBay AU, or ~AU20$ on Yahoo Auctions Japan.

Free MCBoot As A Bootloader

You'll need Free MCBoot installed on a memory card, unless your PS2 is already physically modded. Some versions of the PS2 work with a simple "DVD" method to install Free MCBoot and you can follow these instructions if your that happens to be the case.

I disregarded the warnings and tried to use the ISO that lined up with my 5000x version, as per the version info:

It threw the expected error...

The alternative method is to make the HDD bootable to, in turn, make the Memory Card bootable. It's all a little chicken-and-egg, but it worked in the end. I downloaded the FHDB installer 1.966 and used the HDD Raw Copy Tool to flash the IMG from the archive over the HDD I indended to use in the PS2.

This disk was connected to my PC via a USB adapter to do so. Note that I was using a blank HDD here... don't use a drive with precious data! Slap the freshly formatted HDD in your PS2 and boot it up. At the same time, copy the guts of this zip file to a folder on a USB key, as we want to run the installer to get the software installed onto a Memory Card. On the PS2, scroll down to uLE/wLE and navigate to MASS and then the folder you used above. Select the installer and hit the circle button.

After it's done, shut the unit down and unplug the HDD. Reboot with just the memory card in to make sure that it works. From here plug the HDD back into your PC and format it with WinHIIP so that it wont try to boot from the HDD again!

Linux Live DVD

You'll find a miriad of Linux Live DVDs here. We'll go with Version 3. You'll then find a huge list of ISOs to choose from. We'll take the PAL Large No Modchip. Download and burn it to a DVD. Whilst that's happening, grab Kernel Loader 3.0 and copy it to a USB drive. We'll need to copy this to the Memory Card...

Disregard the jump to the kloader folder. In fact, disregard that that folder even exists. Just use the R1 shoulder button and paste the kloader file in the root of MC0. Once it's done... insert the DVD and run the loader!

I was joking... don't insert it yet. As you can see above, they've added a DVD video folder with a static image to tell you that the DVD ain't bootable... thanks for the warning! So, boot into Free MC Boot, scroll down to the Loader, open it and, whilst it's opening, put the DVD back in. You can then select the kernel loader from the memory card and go for gold.

We're up, and we can ping! The experience is as slow as molasses from the DVD and sound doesn't work... but let's get installed first.

Installing to the HDD

There's a great tutorial here that I followed to get this done. Download INITRD.GZ, VMLINUX.GZ, ps2fdisk and fstab and send them to a USB Key. Boot into the Linux Live DVD and open xterm.

As above, insert the USB key into the PS2 and mount SDA1 in Linux. Copy ps2fdisk from the SDA1 to a usable folder and partition the disk. Note that you cannot use the already-included ps2fdisk from the Live DVD.. it just wrecks your HDD setup. Meanwhile, since we're using a memory card to bootstrap the HDD, we can wipe the entire HDD and use the lot for our Linux partitions. Just make sure to not try and fill the entire disk with the second partition as you'll get out-of-space errors. Next, mount it and copy everything over. Finally, copy FSTAB from the USB key to the hdd's /etc/ folder. Once all that's done... reboot. It's now time to configure kloader!

Finally, reboot and copy INITRD and VMLINUX to your Memory card.

As above, reset the configuration and then set the Ramdisk, kernel and root partition. Save the configuration the Memory card and boot. Excuse the shitty video quality as my internal HDMI capture card stopped working and I had to switch to a crappy USB HDMI capture device. Also notice how much quicker that boot was when compared to the DVD boot above. And yeah, still no sound. Let's fix that...

Getting Sound Going...

Seems the 'drivers' are IRX files and we can borrow them from game discs. Unfortuantely, the newest versions don't work, so use these files: LIBSD.IRX and SDRDRV.IRX. Copy them to your USB Thumb drive and insert it.

Follow the above steps to copy them to a folder called kloader on MC0.

Next open up kloader and configure the modules. Choose the configuration rows with upper-case file-names, just because. Sound! Network! We're up! But the video quality is awful...

VGA Output

So, officially, the PS2 outputs R+Sync-On-G+B. This means that your monitor needs to understand that the green channel is a combination of video synchronisation and green data. If it doesn't then you won't get a picture. Fortunately, and since this whole topic is already 20 years old, there's numerous people online who have already solved the problem for us: use an LM1881N sync-splitter.

                      LM1881(M or N)
                         ========       
 VGA PIN 13   -----------|1    8|-----  +5v PS2 PIN 10
                         |      |
 VGA PIN  2  --\   0.1uF |      |
 PS2 PIN 12  --+----||---|2    7|    
                         |      |          ____ 680 kOhm Resistor 
                         |      |    /----|____|----\
 VGA PIN 14  ------------|3    6|----|              |-----\
                         |      |    \------||------/     |
 PS2 PIN  8 --+----------|4    5|          0.1uF          |
 VGA PIN  6 --|          ========                         |
 VGA PIN  7 --|                                           |
 VGA PIN  8 --+-------------------------------------------/ (GROUND)

PS2 PIN 11 ------------- VGA PIN 1 (RED)
PS2 PIN  9 ------------- VGA PIN 3 (BLUE)

PS2 PIN  4  -- AUDIO RIGHT                                      PS2 PIN  7  -- SVIDEO CHROMA
PS2 PIN  3  -- AUDIO RIGHT GROUND                               PS2 PIN  5  -- SVIDEO LUMA
PS2 PIN  2  -- AUDIO  LEFT                                      PS2 PIN  8  -- SVIDEO GROUND
PS2 PIN  1  -- AUDIO  LEFT GROUND                       (Share PIN 8 with GROUND in above circuit)

PS2 PIN  6  -- COMPOSITE VIDEO OUTPUT

So, it's all pretty self-explanatory above. The PS2 AV port provides +5v, so I've used that... regardless of everyone saying to use an external source? I've also used a 680kohm resistor as the original 585k was nowhere to be found. Finally, tie all the video grounds together, leaving the audio grounds separate. Also note that PS2 Pin 1 is left-most as you're looking at the PS2.

I built up a crappy prototype and tested it out... haphazardly...

And it worked beautifully! So I mounted it a little more safely in a crappy ziffy box from Jaycar...

And gave it a spin on a real monitor...

And yes, your success may vary. You'll need to configure two variables in the boot loader and if you only configure X and not the console, you'll get the distortion as above.

Oh yeah, to configure VGA output, just press R2 when you're at the kernel boot loader and it'll cycle through the video modes. Then you just need to edit your kernel parameters to include the following: crtmode=vesa0,60 xmode=VESA,1024x768x24. Note that you may have to manually create an xmode config file in /etc/ with the contents VESA,1024x768x24 if X doesn't listen to the command line argument.

Success! I've started productionising the adapter, so tell me if anyone wants one!

Still waiting for a few parts.

What's next?

Of course, after doing all this, I find there's a newer version of Gentoo for the PS2? Learn how to build a bootable USB here. Unfortunately, the newer version doesn't support sound?.

I wonder if I can build OTTD, like I did on the PowerCenter 180.

Sony HitBit HB-F1 II – Power Supply Modifications

Whilst picking this up from a Hard-Off in DenDen Town, Osaka, I was told by the cashier that there was no power supply and that finding one would be a challenge. I wasn't too worried about this as using a 110v power supply in AU is just painful. Secondly, there seemed to be enough information on the internet to rig something together once I'd found time to do so back home.

So yeah, the power supply is a three-pin jack with AC 18v, DC 9v and Ground. This is confirmed on my unit by the voltage ratings inscribed on the base of the unit.

Finding an external supply with these two voltages would be an expensive task, so the better answer was to review the two links above to see what they did to convert. After a quick scan, it seemed that the AC voltage was used to create a -12v rail for the cartridge port and a +12v, which also was only for the cartridge port?. It seems that the MSX itself only needed the 9v DC, which it then also converted to 5v DC to run the entire system. Let's open'er'up! There are six screws under in the base that need removing. The lid will then lift off. The keyboard can then be removed, being gentle with the mylar ribbon cable.

You're then presented with the RF shielding. They've used a plastic-coated foil and it's quite soft! It's held down by screws around the bottom half, so find them all and remove them.

From here, it's the usual Sony-esque work of art. The PCB is so clean and tidy and the layout is precise. All the power paraphenalia is top-left and most of it will be redundant once we're finished with it. We're removing the power socket, so I went ahead and removed the motherboard from the case. There's 3 screws holding this down.

They went out of their way with the PCB graphic layer. They've actually drawn the connecting circuit lines on the underside of the board. There's no need to constantly flip it over if you're trying to trace a connection! There's also amazing information on pins of important ICs... and, for that note... DC sockets?

Seeing this written on the underside of the power plug threw me! Can I just supply the above voltages and get away with it? I won't need a complex supply for AC voltage if this is the case? I wired in the 12v line and, well, nothing came out! Hah. This seems to be a mis-print on the PCB? Those are NOT the voltages required.

So, I could go on about how I tested voltages in random locations and got some things going, whilst others stopped... and vice versa... but I wont, I'll just present the answer for this unit. You'll need a power supply that has +5v, +12v and -12v. Officially, you don't need the latter two if you're just using boring game cartridges. The unit only makes +12v and -12v to send to the cartridge port, and these are only used for "special" carts.. such as RS-232, etc.

Because I'm a perfectionist, I wanted to not 'downgrade' this machine... so I chose a Pico-ATX supply, as it had all the required supply voltages and an easy-to-use DC socket.

I de-soldered the ATX plug as it was just going to consume vital space inside the MSX.

On the MSX board, there's a large horizontal cable marked +/-12v. Desolder this from the left end and solder the appropriate wires to the associated supply voltages on the PicoATX.

Finally, there are two 7805 regulators that need to be removed. There's one that's bolted to the heatsink on the left and I de-soldered the wires from the mainboard. There's another nearby with a tiny heatsink on it that also needs to be removed.

With them both out, just flip the board and solder a wire into each of the OUT pins.

These need to be fed with 5v. I love how, even though the top regulator doesn't have the OUT pin described, that you can follow the traces easily from the IN of the lower regulator. The jumper wire, on the other side of the board, in the top-left of the image is drawn on this side of the board!

Once you've de-soldered the power socket, print out my personally-designed DC socket mount and use it to mount the DC socket to the board.

Finally, de-solder the power switch cable from both ends. Using one side of the power switch (it's DPST), connect one pin to ground and the other to PS_ON on the PicoATX.

Jam the lot back into the case.

When re-assembling, make sure to not screw the latches on the printer port. Try not to slice your fingers as you pinch them together and feed the board into the case.

Don't forget the two screws on the back of the case which hold the RCA socket and DC socket in place. These poor connectors get a lot of punishment. Before totally closing up this machine, I threw all the parts I removed into a zip-lock bag and stuck it under the lid. You never know, someone in the future might want to restore it to original condition?

And then it was done! Test? Of course...

Unfortunately, this unit doesn't have cursor keys! It's only got the gamepad directional arrows, and so I can't even play my favourite game.

Atari 7800 Controller Button Replacement

This Atari 7800 Gamepad came to me with one of the plastic buttons missing. They're held into the shell via two 2x2mm lugs and they must have perished after decades of abuse.

Without waiting around, I popped open the case and measured up the surviving button.

The button has a slight gradient on top, which I'm sure my 3D printer will struggle with...

And underneath there's a small tab to press on the rubber membrane inside the controller. Anyway, straight into Tinkercad I went to design a replacement.

I didn't even bother with the tab on the base... it's all just flat. The rubber membrane in the controller has a flat top anyway.

It printed OK! Could do with a sand, but I didn't have any wet-dry.

Not the prettiest... but it works perfectly! Here's the STL.

Random HDMI Capture Cards

I can't believe I'm calling these cards retro, but they are! They're all early 00s and the drivers are only for Windows XP and Vista? How random... I had no idea there were cheap PCI-E HDMI Capture cards back then. I would not have had any reason for them back then, and hardly do today, but I'd picked them up in a Hard Off somewhere across Japan for 1$ each and thought I should finally test them out.

DRECAP DC-HC1

First up is a DRECAP DC-HC1. It's tiny and came with a low-profile case bracket. I unscrewed the bracket and loosely placed it in my machine, making sure to NOT move the HDMI cable once connected.

Whilst looking for drivers... actually, prior to that, whilst trying to ID the card (there are no valid serial numbers or other identifying marks), I found other cards that also seemed to be identical. I then stumbled across this blog post which indicated that the base card was a Timeleak HD72A and that the drivers could be found here.

With the correct drivers installed, everything worked nicely!

KEIAN DM626 H3

The second card was identified via Yodobashi Camera product listing! How cool. Out of stock! Knowing the product name, I then went googling for drivers. It turns out the original site is long gone and, since their support page had ugly javascript, webarchive can't help to find drivers.

I stumbled across this blog post with great info on installation. It turns out you can use the Monster X3A drivers here for this card. The X3A only has one port, so it seems we'll only use the closest port to the motherboard? ... it actually turned out that any port on the card worked! Unfortunately, sound didn't.

Mucking around with Composite Signals

As that I couldn't get audio from the second card, I went with using the bracket of it on the first card! I wasn't ready to have a loose card hanging around inside my PC's case.

The HDMI port, by total fluke, lined up 98% and cables were securely connected. From there, I purchased this little beast for AU12$ on eBay...

And you know what? It works nicely! Here's a Sega Master System II hooked up. I've got a switch to toggle the PAL/NTSC pin, so when you see (and hear) it switch from PAL 60 to PAL you'll know why!

Nice... No more mucking around with other TVs... I can now use this to continue the long chain of Atari and Sega mods/repairs.

Christmas ’94, Tandy-Style!

This turned up on eBay and I couldn't resist! Recently I'd found stamp books and Australia Philotelic Assoc orders forms, amongst Lego Catalogue order forms (unfulfilled, I must admit!), but nothing from Tandy. I saw this for sale and new it needed to be preserved!

SALE ENDS CHRISTMAS EVE, 1994.

Hey BeBox, My SMB Network Hates You!

Sheesh. After getting the machine up and running, getting it on the network was next-level shite! The BeBox, with BeOS 4.5 PPC, comes with an optional folder and, included in there, is an experimental folder containin an application known as WON. This stands for World 'O Networking (I REALLY blame this use of O' for my apostrophicities in this entire blog as I was introduced to WON back in '99) and is a CIFS implementation. Running the setup app easily installs it, but opening the newly placed World 'O Networking icon on the desktop does nothing but tell me that my CIFS Master Browser didn't exist.

Do excuse the crappy photo...

In this day'n'age, there's no #@%#$%'n reason for a CIFS browser to exist on anyone's network. We have random french-named services to say 'hello' to eachother and list eachother in eachother's network lists. There's no need for this (now inappropriate) client/server (master/slave) relationship. Of course, should we expect BeOS 4.5 PPC to be up with the times? No. So? Let's just try the cifsmount call from the command line.

$cifsmount \\\\192.168.1.61\\public [user] [password] ./testMountFolder
General OS Error -1

General OS error? Awful. Fortunately, my NAS can log the snot out of Samba, so I turned on verbosity. Whenever BeOS tried to access the share, the following was visible:

[2022/12/19 14:37:58.602852,  2, pid=6552, effective(0, 0), real(0, 0)] ../../source3/smbd/reply.c:708(reply_special)                                                                                                                                                     
  netbios connect: name1=AS6604T-BDE6   0x20 name2=BEBOX          0x0                                                                                                                                                                                                     
[2022/12/19 14:37:58.603018,  2, pid=6552, effective(0, 0), real(0, 0)] ../../source3/smbd/reply.c:749(reply_special)                                                                                                                                                     
  netbios connect: local=as6604t-bde6 remote=bebox, name type = 0                                                                                                                                                                                                         
[2022/12/19 14:37:58.613129,  0, pid=6552, effective(0, 0), real(0, 0)] ../../source3/smbd/negprot.c:600(reply_negprot)                                                                                                                                                   
  negprot protocols not 0-terminated

Nice! It actually says BEBOX!. Somehow, samba does nothing after that line. It doesn't say "ERROR"... but it also doesn't continue? Checking the code...

	if (req->inbuf[size-1] != '\0') {
		DEBUG(0, ("negprot protocols not 0-terminated\n"));
		reply_nterror(req, NT_STATUS_INVALID_PARAMETER);
		END_PROFILE(SMBnegprot);
		return;
	}

Oh yup. That's a hard-stop. It seems that the CIFS implementation on BeOS hasn't null-terminated a string as it sent it to Samba. We'll need to build the code and rip this out, or rollback to an older version. SMB is running as a package on my NAS and ... I assume there's source somewhere, but every time I've SSH'd into that console the tools I need don't exist, so let's virtualise this shit.

Samba Proxies or Virtual Box?

We have two options here. Spin up a RedHat Linux (~7.0) version and just start Samba on that (it works, I tried it!) or spin up a possibly awesome docker image and "re-share" our existing security-conscious shares. Yes, I got the VM going, but I wasn't happy with an entire VM running endlessly for no reason when my retro machines were off. I also hated the need to cleanly bring-up and shut-down the machine, not to mention the speed of interaction.

So, I went for a Docker image. I'm running an Asustor Lockerstor AS6600T which has a neatly packaged version of Docker and Portainer running. It's currently doing all sorts of things and adding a samba container wasn't going to hurt. The only real consideration was that, even though I was using a macvlan to get real IPs for my containers, I still had not successfully managed to get the NAS to talk directly into the hosted docker containers. I was initially surprised by this, but it turns out that's by-design... docker images aren't 'allowed' to see the metal they're hosted on. Although there's articles mentioning how to fix this (and a slightly different one here), I couldn't get it to work. Therefore, a 'samba proxy' wont actually work... as it needs to be able to SMB mount the host's share(s) and share those forward via it's own SMB server.

Fortunately, we don't have to fret yet. It occurred to me that I can simply mount the host's drives in the docker image and use David Personette's Samba Server container to share those! There's no need to actually proxy anything.

Samba Versions

This negprot 0-termination check has been in Samba since r24001, which was around 15 years ago, which equates to something around Samba 3.1. Docker can run older Linux versions, but only until around 8 years ago. Centos 5 might work, but you'll be hard-pressed finding functional package repos once it's installed. Alpine Linux is the way to go, but there's only docker images going back to 3.1, which doesn't line up with Samba 3.1! If we can't use a version of Samba (in Docker, anyway) that doesn't include the check, then maybe we can remove the check from a newer version? We just need to make sure the newer version supports SMB v1.0 (LANMAN, CIFS, etc..) and it turns out support for these older protocols was removed in version 4.11+.

As that David's container is build on the latest Alpine, it includes Samba 4.18 and this is obviously too new. It turns out that the last version of Samba before 4.11 is v4.18.10 and it's conveniently included in Alpine v3.10. Thanks for Docker's customisable recipes, we can modify David's Dockerfile, adjusting the top line to peg the Alpine base image version to this. Finally, we also need to make sure that the install scripts don't get Samba from the base Alpine 3.10 repo as we actually want to custom-build the APKs and carve out the zero-termination check.

I was initially going to download the source of Samba and try to build/install it myself in a new docker container... but I realised that it would be a tonne of extra work as there's probably distro-specific guff that needs to be configured/carried-out. So instead, as above, I chose to roll my own APK using the APK recipe from the Alpine repo.

Adding a package to Alpine Linux to make Docker better again

If you want to actually build the APK yourself, then here's a basic run-through. I've taken the package recipe from the alpine packages store and made a few changes. You'll find them here. Mainly just a sed script to hack out the 0-termination check.

If you don't want to bother compiling your own APK with this modification, then you can just download the already-compiled APK here. The only reason you'd want to do the next chunk yourself is if you don't trust my hard work. I wont be offended if that's the case.

I started by spinning up a new docker container...

sudo docker run --name apk-builder -v /volume1/Public:/public-share  -it alpine:3.10

Note that I've mapped a local drive. You'll want to do this as otherwise you'll have to work out a better way to get the compiled APKs out. Once up, you'll be already at the console and you can get started...

apk add --update alpine-sdk wget nano sudo
adduser builder

At this point you'll need to give builder a good password. Once done, continue to set up the APK build environment. Note that the sed line injects the rule to sudoers for the user builder at line 80. If you're doing this on a tainted Docker container (not the fresh one I just built) then you might want to be wary as to which line you insert on.

sed -i "80i builder ALL=(ALL) ALL" /etc/sudoers
sudo -lU builder
addgroup builder abuild
mkdir -p /var/cache/distfiles
chmod a+w /var/cache/distfiles
chgrp abuild /var/cache/distfiles
chmod g+w /var/cache/distfiles

We've done all we need to as root, so switch to builder:

su builder

And then generate your signing keys which'll be used when compressing the APK...

abuild-keygen -a -i

You'll need to type in builder's password for the key storage. Finally, go into the dir and download the APKBUILD files from my server. Please do check out the files downloaded... specifically APKBUILD! The hack to remove the 0-term if statement is already contained inside. It's simply a sed line requesting the deletion of lines 599-605 in negprot.c.

cd /tmp
wget https://modelrail.otenko.com/assets/samba-negprot-hack/samba.zip
unzip samba.zip

Finally, kick it off. Go grab a coffee.

abuild -r

The build takes around 20 minutes on my quad core i3 NAS. The build is nice as it tells you the progress via the files-completed numbers at the start of each line.

...
[3287/5138] Linking bin/default/source3/libads-samba4.inst.so
[3288/5138] Linking bin/default/source3/libsmbd-conn-samba4.inst.so
[3289/5138] Linking bin/default/source3/libsmbd-base-samba4.inst.so
[3290/5138] Linking bin/default/source3/libprinting-migrate-samba4.inst.so
[3292/5138] Linking bin/default/source3/libnet-keytab-samba4.inst.so
[3294/5138] Linking bin/default/source3/libtrusts-util-samba4.inst.so
[3295/5138] Linking bin/default/source3/libsamba3-util-samba4.inst.so
[3297/5138] Linking bin/default/source3/libxattr-tdb-samba4.inst.so
[3299/5138] Linking bin/default/source3/libCHARSET3-samba4.inst.so
[3301/5138] Linking bin/default/source3/liblibcli-lsa3-samba4.inst.so
[3303/5138] Linking bin/default/source3/liblibcli-netlogon3-samba4.inst.so
[3306/5138] Linking bin/default/source3/libcli-spoolss-samba4.inst.so
[3308/5138] Linking bin/default/source3/pysmbd.inst.cpython-37m-x86_64-linux-gnu.so
[3310/5138] Linking bin/default/source3/pylibsmb.inst.cpython-37m-x86_64-linux-gnu.so
[3312/5138] Linking bin/default/source3/auth/libauth-samba4.inst.so
[3313/5138] Linking bin/default/source3/auth/libauth_module_unix.inst.so
[3316/5138] Linking bin/default/source3/auth/libauth_module_script.inst.so
[3318/5138] Linking bin/default/source3/auth/libauth_module_samba4.inst.so
[3320/5138] Linking bin/default/source3/modules/libnon-posix-acls-samba4.inst.so
[3323/5138] Linking bin/default/source3/modules/libvfs_module_audit.inst.so
[3325/5138] Linking bin/default/source3/modules/libvfs_module_extd_audit.inst.so
[3327/5138] Linking bin/default/source3/modules/libvfs_module_full_audit.inst.so
[3329/5138] Linking bin/default/source3/modules/libvfs_module_fake_perms.inst.so
[3331/5138] Linking bin/default/source3/modules/libvfs_module_recycle.inst.so
[3333/5138] Linking bin/default/source3/modules/libvfs_module_netatalk.inst.so
[3335/5138] Linking bin/default/source3/modules/libvfs_module_fruit.inst.so
[3337/5138] Linking bin/default/source3/modules/libvfs_module_default_quota.inst.so
[3339/5138] Linking bin/default/source3/modules/libvfs_module_readonly.inst.so
...
(93/105) Purging tevent (0.9.39-r0)
(94/105) Purging talloc (2.2.0-r0)
(95/105) Purging tdb-libs (1.3.18-r0)
(96/105) Purging libbz2 (1.0.6-r7)
(97/105) Purging gdbm (1.13-r1)
(98/105) Purging xz-libs (5.2.4-r0)
(99/105) Purging readline (8.0.0-r0)
(100/105) Purging sqlite-libs (3.28.0-r3)
(101/105) Purging lz4-libs (1.9.1-r1)
(102/105) Purging keyutils-libs (1.6-r1)
(103/105) Purging libverto (0.3.1-r0)
(104/105) Purging libsasl (2.1.27-r4)
(105/105) Purging db (5.3.28-r1)
Executing busybox-1.30.1-r5.trigger
OK: 184 MiB in 56 packages
>>> samba: Updating the /x86_64 repository index...
>>> samba: Signing the index...

Once built, you'll end up with a bunch of APKs in /home/builder/packages.

~/packages/x86_64 $ ls
APKINDEX.tar.gz                            samba-dev-4.10.18-r0.apk
libsmbclient-4.10.18-r0.apk                samba-doc-4.10.18-r0.apk
libwbclient-4.10.18-r0.apk                 samba-heimdal-libs-4.10.18-r0.apk
pam-winbind-4.10.18-r0.apk                 samba-libnss-winbind-4.10.18-r0.apk
py3-samba-4.10.18-r0.apk                   samba-libs-4.10.18-r0.apk
samba-4.10.18-r0.apk                       samba-libs-py3-4.10.18-r0.apk
samba-client-4.10.18-r0.apk                samba-pidl-4.10.18-r0.apk
samba-client-libs-4.10.18-r0.apk           samba-server-4.10.18-r0.apk
samba-common-4.10.18-r0.apk                samba-server-libs-4.10.18-r0.apk
samba-common-libs-4.10.18-r0.apk           samba-server-openrc-4.10.18-r0.apk
samba-common-server-libs-4.10.18-r0.apk    samba-test-4.10.18-r0.apk
samba-common-tools-4.10.18-r0.apk          samba-winbind-4.10.18-r0.apk
samba-dc-4.10.18-r0.apk                    samba-winbind-clients-4.10.18-r0.apk
samba-dc-libs-4.10.18-r0.apk               samba-winbind-krb5-locator-4.10.18-r0.apk

Copy these all somewhere to your local drive, as we'll need to use them for the Docker container creation. If you are rolling this yourself, then your Dockerfile/docker-compose.yaml will need to map a local volume to the folder where all of these files are. If you're not rolling them yourself, then use the zip that's in this Dockerfile.

The container script uses David's as a base, but sets Alpine to 3.10 and uses Samba from my APKs. It also does a lot of mucking around with smb.conf. Prior to that configuration mucking around, BeOS would get past the negprot issue only to bring up another error:

Allowed connection from 192.168.1.131 (192.168.1.131)
init_oplocks: initializing messages.
Transaction 0 of length 72 (0 toread)
netbios connect: name1=192.168.1.46   0x20 name2=               0x0
netbios connect: local=192.168.1.46 remote=, name type = 0
Transaction 0 of length 51 (0 toread)
switch message SMBnegprot (pid 1071) conn 0x0
Requested protocol [NT LM 0.12]
reply_negprot: No protocol supported !
Server exit (no protocol supported)

Seems that NT LM 0.12 is NT LAN Manager 2.1, or somesuch. I'd thought about digging back into negprot.c and checking the reply_negprot function, but a quick google lead to something very obvious... configuration!

SERVER MIN PROTOCOL

As always, someone has already faced this issue and it seems that all they had to do was set the 'lowest' protocol that the server would accept, via a setting? David's smb.conf had a default minimum of SMB2_10, which seems to mean that we only supported Windows 7 and above? Wowzers. For those not clicking links, here's the protocol limitation options:

Option	Description
LANMAN1	First modern version of the protocol. Long filename support.
LANMAN2	Updates to Lanman1 protocol.
NT1	Current up to date version of the protocol. Used by Windows NT. Known as CIFS.
SMB2	Re-implementation of the SMB protocol. Used by Windows Vista and later versions of Windows. SMB2 has sub protocols available.
SMB2_02	The earliest SMB2 version. (Windows Vista and higher)
SMB2_10	Windows 7 SMB2 version.
SMB2	By default selects the SMB2_10 variant.
SMB3	The same as SMB2. Used by Windows 8. SMB3 has sub protocols available.
SMB3_00	Windows 8 SMB3 version.
SMB3_02	Windows 8.1 SMB3 version.
SMB3_11	Windows 10 SMB3 version.

There's actually a really cool piece of code explaining all this in the negprot.c source file:

/* these are the protocol lists used for auto architecture detection:

WinNT 3.51:
protocol [PC NETWORK PROGRAM 1.0]
protocol [XENIX CORE]
protocol [MICROSOFT NETWORKS 1.03]
protocol [LANMAN1.0]
protocol [Windows for Workgroups 3.1a]
protocol [LM1.2X002]
protocol [LANMAN2.1]
protocol [NT LM 0.12]

Win95:
protocol [PC NETWORK PROGRAM 1.0]
protocol [XENIX CORE]
protocol [MICROSOFT NETWORKS 1.03]
protocol [LANMAN1.0]
protocol [Windows for Workgroups 3.1a]
protocol [LM1.2X002]
protocol [LANMAN2.1]
protocol [NT LM 0.12]

Win2K:
protocol [PC NETWORK PROGRAM 1.0]
protocol [LANMAN1.0]
protocol [Windows for Workgroups 3.1a]
protocol [LM1.2X002]
protocol [LANMAN2.1]
protocol [NT LM 0.12]

Vista:
protocol [PC NETWORK PROGRAM 1.0]
protocol [LANMAN1.0]
protocol [Windows for Workgroups 3.1a]
protocol [LM1.2X002]
protocol [LANMAN2.1]
protocol [NT LM 0.12]
protocol [SMB 2.001]

OS/2:
protocol [PC NETWORK PROGRAM 1.0]
protocol [XENIX CORE]
protocol [LANMAN1.0]
protocol [LM1.2X002]
protocol [LANMAN2.1]

OSX:
protocol [NT LM 0.12]
protocol [SMB 2.002]
protocol [SMB 2.???]
*/

/*
  * Modified to recognize the architecture of the remote machine better.
  *
  * This appears to be the matrix of which protocol is used by which
  * product.
       Protocol                       WfWg Win95 WinNT Win2K OS/2 Vista OSX
       PC NETWORK PROGRAM 1.0          1     1     1     1     1    1
       XENIX CORE                                  2           2
       MICROSOFT NETWORKS 3.0          2     2
       DOS LM1.2X002                   3     3
       MICROSOFT NETWORKS 1.03                     3
       DOS LANMAN2.1                   4     4
       LANMAN1.0                                   4     2     3    2
       Windows for Workgroups 3.1a     5     5     5     3          3
       LM1.2X002                                   6     4     4    4
       LANMAN2.1                                   7     5     5    5
       NT LM 0.12                            6     8     6     6    6    1
       SMB 2.001                                                    7
       SMB 2.002                                                         2
       SMB 2.???                                                         3
  *
  *  tim@fsg.com 09/29/95
  *  Win2K added by matty 17/7/99
  */

#define PROT_PC_NETWORK_PROGRAM_1_0		0x0001
#define PROT_XENIX_CORE				0x0002
#define PROT_MICROSOFT_NETWORKS_3_0		0x0004
#define PROT_DOS_LM1_2X002			0x0008
#define PROT_MICROSOFT_NETWORKS_1_03		0x0010
#define PROT_DOS_LANMAN2_1			0x0020
#define PROT_LANMAN1_0				0x0040
#define PROT_WFWG				0x0080
#define PROT_LM1_2X002				0x0100
#define PROT_LANMAN2_1				0x0200
#define PROT_NT_LM_0_12				0x0400
#define PROT_SMB_2_001				0x0800
#define PROT_SMB_2_002				0x1000
#define PROT_SMB_2_FF				0x2000
#define PROT_SAMBA				0x4000
#define PROT_POSIX_2				0x8000

#define ARCH_WFWG     ( PROT_PC_NETWORK_PROGRAM_1_0 | PROT_MICROSOFT_NETWORKS_3_0 | \
			PROT_DOS_LM1_2X002 | PROT_DOS_LANMAN2_1 | PROT_WFWG )
#define ARCH_WIN95    ( ARCH_WFWG | PROT_NT_LM_0_12 )
#define ARCH_WINNT    ( PROT_PC_NETWORK_PROGRAM_1_0 | PROT_XENIX_CORE | \
			PROT_MICROSOFT_NETWORKS_1_03 | PROT_LANMAN1_0 | PROT_WFWG | \
			PROT_LM1_2X002 | PROT_LANMAN2_1 | PROT_NT_LM_0_12 )
#define ARCH_WIN2K    ( ARCH_WINNT & ~(PROT_XENIX_CORE | PROT_MICROSOFT_NETWORKS_1_03) )
#define ARCH_OS2      ( ARCH_WINNT & ~(PROT_MICROSOFT_NETWORKS_1_03 | PROT_WFWG) )
#define ARCH_VISTA    ( ARCH_WIN2K | PROT_SMB_2_001 )
#define ARCH_SAMBA    ( PROT_SAMBA )
#define ARCH_CIFSFS   ( PROT_POSIX_2 )
#define ARCH_OSX      ( PROT_NT_LM_0_12 | PROT_SMB_2_002 | PROT_SMB_2_FF )

/* List of supported protocols, most desired first */
static const struct {
	const char *proto_name;
	const char *short_name;
	NTSTATUS (*proto_reply_fn)(struct smb_request *req, uint16_t choice);
	int protocol_level;
} supported_protocols[] = {
	{"SMB 2.???",               "SMB2_FF",  reply_smb20ff,  PROTOCOL_SMB2_10},
	{"SMB 2.002",               "SMB2_02",  reply_smb2002,  PROTOCOL_SMB2_02},
	{"NT LANMAN 1.0",           "NT1",      reply_nt1,      PROTOCOL_NT1},
	{"NT LM 0.12",              "NT1",      reply_nt1,      PROTOCOL_NT1},
	{"POSIX 2",                 "NT1",      reply_nt1,      PROTOCOL_NT1},
	{"LANMAN2.1",               "LANMAN2",  reply_lanman2,  PROTOCOL_LANMAN2},
	{"LM1.2X002",               "LANMAN2",  reply_lanman2,  PROTOCOL_LANMAN2},
	{"Samba",                   "LANMAN2",  reply_lanman2,  PROTOCOL_LANMAN2},
	{"DOS LM1.2X002",           "LANMAN2",  reply_lanman2,  PROTOCOL_LANMAN2},
	{"LANMAN1.0",               "LANMAN1",  reply_lanman1,  PROTOCOL_LANMAN1},
	{"MICROSOFT NETWORKS 3.0",  "LANMAN1",  reply_lanman1,  PROTOCOL_LANMAN1},
	{NULL,NULL,NULL,0},
};

So, is it just as-simple-as setting the lowest bloody value and rebooting? I edited the Dockerfile and updated the injected smb.conf configuration:

    echo '   # Security' >>$file && \
    echo '   client ipc max protocol = SMB3' >>$file && \
    echo '   client ipc min protocol = LANMAN1' >>$file && \
    echo '   client max protocol = SMB3' >>$file && \
    echo '   client min protocol = LANMAN1' >>$file && \
    echo '   server max protocol = SMB3' >>$file && \
    echo '   server min protocol = LANMAN1' >>$file && \

And it worked! Finally! BeOS has connected to my NAS with a reasonably-recent version of linux and Samba! Sure, commenting out the zero-termination might reinstate a bug that can be exploited, but this service will never be public. Meanwhile, World 'O Networking still hated me... but that's OK, at least I can now transfer files!

Giving Docker a Hostname

As you can see above, all interactions with the new samba docker server are via IP. It turns out that the --hostname field that you configure in Docker only applies internally to the docker container. It's not exported! Googlin' around, I found a great stack overflow article describing the same issue, with many "can't do that" responses.

It's not until you scroll a few answers down that you'll see a --net-alias flag that seems to do want I want. Just a note, it's --alias if you're using docker network connect and --net-alias when using docker compose. I added the required configuration to the Dockerfile and spun up a new instance.

services:
  samba-bridge:
    networks:
      mynet:
         ipv4_address: 192.168.1.46
         aliases:old-samba-bridge
networks:
  mynet:
    external: true

mynet has been set up using the instructions over here, which were pertinent to getting PiHole running in an adjacent Docker container. The rest of the configuration was borrowed from here.

I honestly hoped this would get Samba showing up on the local LAN with a hostname, but no such luck! I wonder if the docker network is preventing promiscuous traffic or somesuch... Maybe I'll spin this up on a physical machine on the network just to rule a few things out.

But what about that CIFS Browser error?

Oh yeah, I would still love WON to actually list my computers... can I do it? It seems that you can configure Samba to be a CIFS Server with a single local master = yes in the configuration file. Unfortuantely this didn't work... neither did wins support = yes. I'll have to keep fighting to get my WORKGROUP listed.