Serial disk server

[Robb Bates]

I watched a video about a serial disk server on an Altair.

https://www.youtube.com/watch?v=Pa-DNcmbVLY

I was wondering whether RomWBW supports a serial disk server.

Robb

[Alan Cox]

There are CP/Net implementations for RC2014 style systems. 

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/3ccd9073-69eb-4b14-ad03-4141bac99449n%40googlegroups.com.

[Greg Holdren]

I'm sure the proper bits in RomWBW could be changed to work with the same SW as the Altair server. 

There is NHACP ( HCCA Application Communication Protocol ) which was developed on the Nabu system to mount and read/write disks over serial or other physical layers. I'm thinking that this would be a good candidate for something similar.

https://github.com/NHACP-IF/NHACP-specification

Several servers support NHACP protocol such as the nabud (Linux), nhacpy (Win) etc. I think there is another but cant remember the name but I use these.

https://github.com/GryBsh/NabuNetSim

https://github.com/thorpej/nabud

For the NABU there is Ishkur CP/M that uses NHACP for disk access.

https://github.com/tergav17/IshkurCPM

Soldergirl on the Retroz80! Discord forum has added NHACP for reading and writing files as well as setting and getting RTC info using CP/M 3.0 on the Retroz80! board.

https://gitlab.com/SolderGirl/CPM_NHACP_Utils

I'm using soldergirl's code as a guide and adding NHACP on a Rosco6502 board currently.

Anyways, I think this would be a flexible option for compiling on a Win/Linux PC and having the bits accessible on the target system. Not to get to far for your original post. :)

Greg

[Wayne Warthen]

Hi Robb,

On Sunday, October 5, 2025 at 8:40:01 AM UTC-7 Robb Bates wrote:

I was wondering whether RomWBW supports a serial disk server.

Not currently.  I was not able to quickly locate the FDC+ serial protocol, but I don't think it would be hard to add a RomWBW disk driver to support it.  If someone can point me to some protocol documentation, I will take a look at it as time permits.

Thanks, Wayne

[Greg Holdren]

Wayne,

It looks like it is here.

https://deramp.com/downloads/altair/hardware/fdc+/FDC%20Serial%20Server%20Protocol.txt

Greg

[Wayne Warthen]

Thanks Greg.  I took a look and the protocol is pretty straightforward.  My only concern is that the data exchange seems to be full track read/write.  This implies a 10K buffer which is a lot of space.  Under RomWBW the 10K would not impact CP/M TPA, but it would impact the space in the 32K HBIOS core.  Many of the current RomWBW platforms have less than 10K available, so that becomes a problem.

There are ways this could be addressed, but they add complication to RomWBW and would take a fair amount of my time.  Unless there is a lot of interest in this, I'm not sure it makes sense to support this.

Thanks, Wayne

[Greg Holdren]

Yes, it appears to be track by track based. File access would be of benefit over track access for sure anyways. NHACP operates on a file basis with knowledge of sub directories (sever side).  CP/M has no knowledge of sub directories but user numbers that can be translated to directories if desired. NHACP can xfer up to 8KB in one "GET" response transaction but is configurable on the fly with each "GET" request so sticking to 1KB or 2KB as a norm could make the HBIOS buffer limitation happy.

For CP/M OS like systems everything could live in CP/M's TPA and have a NHACP "ndir", "nget" and "nput" like executable that operates through secondary serial port via HBIOS or direct HW access to a second serial port. The 10KB would affect the file xfer as mentioned. CP/M utilities would be easier to develop vs a transparent method at the HBIOS<=>NHACP level. Kinda like how mTCP provides TCP/IP networking under MS-DOS via com file utilities.

For the Rosco6502 board, I'm just planning on these three basic command since there is no OS on it. The directory listing is working so far but I would like to clean code up and get the hard coded stuff organized before working on file get and put. Reusable libs. The dir * code is under 400 lines of 6502 assembly so it is not that complicated. See below for server and client transactions. 

I would like to take a stab at least some TPA based code on the SC126 after finishing the 6502 code as see where that leads on RomWBW.

Greg

WinPC server:

Microsoft Windows [Version 10.0.26100.6584]
(c) Microsoft Corporation. All rights reserved.

C:\Users\gregh>cd \nabu\nhacpy

C:\NABU\NHACPY>nhacpy
info: [2025-10-10 15:46:11.8854] Lifetime: Application started. Press Ctrl+C to shut down.
info: [2025-10-10 15:46:11.8854] Server: Defined Adapters: 2
info: [2025-10-10 15:46:11.8854] Lifetime: Hosting environment: Production
info: [2025-10-10 15:46:11.8854] Lifetime: Content root path: C:\NABU\NHACPY
info: [2025-10-10 15:46:11.8854] Server: Starting Serial:COM7
info: [2025-10-10 15:46:11.8979] SerialAdapter: Port: COM7, BaudRate: 115200, ReadTimeout: 00:00:02
info: [2025-10-10 15:46:11.8979] AdapterEventReceiver: Storage Path: C:\uP\6502\rosco6502_nhacp\nhacp_disk
info: [2025-10-10 15:46:11.9134] SerialAdapter: Started
info: [2025-10-10 15:46:11.9134] SerialAdapter: COM7: Ready
info: [2025-10-10 15:46:24.6192] NHACPV01Protocol: COM7: Session: 0, Started
info: [2025-10-10 15:46:24.6516] NHACPV01Protocol: COM7: 0 Open: 0, Flags: Directory, Uri:
info: [2025-10-10 15:46:24.6786] NHACPV01Protocol: COM7: 0 LIST: 0, Pattern: *
info: [2025-10-10 15:49:28.7603] NHACPV01Protocol: COM7: Session: 0, Started
info: [2025-10-10 15:49:28.7754] NHACPV01Protocol: COM7: 0 Open: 0, Flags: Directory, Uri:
info: [2025-10-10 15:49:28.7916] NHACPV01Protocol: COM7: 0 LIST: 0, Pattern: *

Client side:

W65C02S CPU @ 10MHz with 16KB+16x32KB RAM and 1x8KB ROM
RAM Banks 0-15 passed
ROM Bank    #0 passed (BIOS+Monitor)
Memory checks: passed

rosco_6502 EWozMon

0000: B=00 S=FF A=00 X=00 Y=00 P=32 nv1BdiZc

\L
Start Intel hex file load:
....................
Load successful. Start:0600 Bytes:0276
0600: B=00 S=FF A=36 X=FB Y=07 P=31 nv1BdizC

\600R
0600: 20

2025-10-07 23:19:06  RW    140 BigFile.txt
2025-10-07 23:17:16  RW   8456 nhacp.asm
2025-03-01 19:04:22  RW     17 test1.txt
2025-10-06 19:45:31  RW     22 testfile123.txt
2025-10-09 22:48:22  RW      0 zero.txt

0600: B=00 S=FF A=04 X=EF Y=01 P=31 nv1BdizC

\

[Wayne Warthen]

Hi Greg,

It looks like you are going for a NABU like interface.   That would be awesome.  For file level access I agree that a TPA-based solution makes the most sense.  Sort of like CP/NET works.  The serial port access could go through RomWBW HBIOS or direct.  HBIOS would allow this to work on any RomWBW platform, but there is a lot of overhead in the RomWBW serial access.  A buffer style serial interface into RomWBW would go a long way toward solving that.

Thanks, Wayne

[Tadeusz Pycio]

A network client operating in the TPA area is the only solution that does not require revolutionary changes to the RomWBW code. As mentioned earlier, this is how CP/Net works, which offers more possibilities than just disk operations (e.g. console redirection), but no one has implemented such a solution in the RomWBW environment due to the low performance of serial transfer.
There are several available solutions that can be implemented:

https://github.com/durgadas311/cpnet-z80

https://github.com/cm68/cpnet

https://github.com/hperaza/cpnet-server

Achieving higher performance than the limit of 115 kbps requires the use of DMA channels, which are rare in Z80 systems (the situation is better for Z180 and Z280, due to the built-in DMA in the chip). I think (I'm not sure) that using DMA for the serial port will require modifying RomWBW.

[Alan Cox]

CP/Net has been available for rcbus machines for some years both via serial which is quite usable and via wiznet networking 

Even over serial it is generally faster than disk serial images as only what is needed gets fetched not 10k chunks. You can also just share part of your PC filesystem and update it from both sides live unlike nhacp

If you want a serial disk though look at drive wire 3 instead. It's using 256 byte blocks indexed by LBA and can do many other useful things nhacp can't. Really nhacp is just unfortunate. Back when people were working on it I pointed out drive wire and cpnet existed but it seems every nabu person feels obliged to write their own CP/M port, own disk sharing, etc 8-)

Ideally for cp/net you would put just the packet rx/tx helpers in ROMWBW so that it's portable and can keep speed. Ditto probably drive wire.

Alan

--

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

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/6817ad1c-379b-4345-a8f2-f47494d2630an%40googlegroups.com.

[Greg Holdren]

NHACP was developed so that it would be a seamless "add on" with the existing protocol running between the NABU and Internet Adaptor (server) side. There is defiantly more overhead with NHACP vs drivewire based on comparing with a quick scan of the drivewire spec for disk access portion of it. One thing nice about NHACP is that it deals with directories and files directly so something could be cobbled together or changed quickly. Yes, looks like drivewire can do a lot more IO com stuff. I'm not a COCO user but I'll look into this more as time permits. Might be a candidate for the 6502 stuff.

I'm working on an Ethernet card for the RCBUS and I'm aware of the Wiznet stuff too.  CP/Net looks interesting and will get to it in the future.

Greg

[Tadeusz Pycio]

Modern network solutions are problematic for 8-bit computers. Only the RTL8019, which is becoming difficult to obtain, allows direct connection to the bus. Using this solution involves a huge overhead for network stack support.
The use of Wiznet is a reasonable compromise between the capabilities of an 8-bit CPU thanks to its built-in TCP/IP support, while also supporting current network technologies. This solution has one ‘drawback’: it requires an SPI interface to be built, as there are no ready-made hardware solutions for such processors.
A similar problem arises when we want to use WiFi with ESP32, because using the serial port on the Z80 side only changes the transmission medium, while the performance of this solution remains unchanged.
In my solutions, I used an Arcnet controller that worked flawlessly at 2.5Mbps without using DMA channels thanks to the memory built into the integrated circuit. However, it is now a historical curiosity and has not been supported for decades. My choice was dictated by the desire to recreate all elements of the CP/Net network (CP/M client, CP/NOS thin client and MP/M server) on its 40th anniversary.