05660: Coco 1, 2, 3: Implement virtual "Becker Port" for DriveWire support

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05660	Misc.	Feature	Always	Aug 8, 2014, 04:46	Oct 19, 2014, 00:59

Tester	Richard42	View Status	Public	Platform	MESS (Self-compiled)
Assigned To	R. Belmont	Resolution	Fixed	OS	Linux
Status [?]	Resolved			Driver	trs/coco12.cpp
Version	0.154	Fixed in Version	0.156	Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	05660: Coco 1, 2, 3: Implement virtual "Becker Port" for DriveWire support
Description	There is a very widely used piece of software in the Coco community called DriveWire. Here is the main page: https://sites.google.com/site/drivewire4/ The user runs a DW server on a modern computer, which can then serve up floppy/hard disk images or MIDI devices to the Coco. A real Coco may be connected to the DW server via serial cable (or I think wireless hardware). An emulated Coco may also connect to a DW server on a network machine by use of a special hardware port which was first created by Gary Becker for his Coco3FPGA hardware system. There are 2 major Coco emulators (Vcc and XRoar) which support this Becker port emulation, and I have also written a MESS patch to add this capability to MESS.
Steps To Reproduce	I have attached a diff file which applies to r31554 of the MAME SVN source tree.
Additional Information	This patch adds a new MESS target called 'coco3dw1', which is a Coco3 machine but with an HDB-DOS ROM image supporting the Becker Port in place of the Disk Extended Color Basic v1.1 ROM. It's basically like having a real Coco machine with the HDB-DOS ROM instead of the DECB ROM in your FD-502 floppy controller. An extra ROM image (which I will attach to this bug report) is required in order to use the new target. This extra target may be removed if desired, since users can always mount a floppy disk containing a loadable version of HDB-DOS which will replace the DECB image in RAM. This patch also adds a couple of controls to the system configuration of the Coco targets: one for enabling/disabling the Becker port, and another for selecting the TCP/IP port number to use for connecting with the DW server. I could not figure out any way to add a free-form text field configuration option, which would be needed to support connections with any DW server on a network machine. So instead I hard-coded the hostname to "localhost" and only allow the user to configure the port number. This patch has been tested and works in both Linux and Windows.
Github Commit

Flags
Regression Version
Affected Sets / Systems	Coco 1, 2, 3

Attached Files	mame-r31554-becker.diff (21,294 bytes) Aug 8, 2014, 04:46 Uploaded by Richard42 patch for Becker Port support [Show Content]
	hdbdw3bc3.zip (6,938 bytes) Aug 8, 2014, 04:47 Uploaded by Richard42 HDB-DOS ROM including Becker Port client support
	mame-r32810-beckerport.patch (19,650 bytes) Oct 18, 2014, 22:51 Uploaded by Richard42 updated patch for Becker Port support [Show Content]

No.10911 NekoEd Senior Tester Aug 9, 2014, 01:26	I'll set this aside to be looked at by the devs to see if it's acceptable.
No.10917 Richard42 Tester Aug 13, 2014, 02:36	There's quite a bit of interest in this feature from the Coco community. Aaron Wolfe said, "Support for the Becker port is already present in VCC and XRoar, so MESS is the only modern emulator that doesn't provide it. Since today so many people are using DriveWire or similar solutions on their physical coco, it makes sense to me for emulators to be able to do the same, and the Becker port has become the standard way to do that." Bill Piece said, "it's handy to be able to do the same things in Mess that I do on my real Coco and Vcc (and Mess cannot currently do).... DW4 Midi, Internet Access, virtual printer, multiple HDs (more than 2), remote terminal etc." So DriveWire adds quite a few capabilities. Also, the patch that I attached to this report will not work properly with OSX, due to its different method of blocking SIGPIPE signals if the remote end of the socket closes early. If you guys decide to merge this feature into MESS, I will fix my patch to properly support OSX.
No.10982 Tafoid Administrator Sep 17, 2014, 10:19	If you have a submission you want to include in main source, this is not the correct place to submit it for review/addition. Visit http://www.mamedev.org/devwiki/index.php?title=Submitting_Source_Code
No.11050 Richard42 Tester Oct 12, 2014, 15:53	OK, I have submitted this source code patch to the development team according to the instructions on that web page.
No.11061 R. Belmont Developer Oct 14, 2014, 15:22	Hi Richard, I appreciate what you're trying to do and we definitely want this functionality in MESS, but as the portability guy I have to wave the red flag. MAME/MESS already allows you to open, read, write, and close TCP sockets via the osd_open()/osd_read()/osd_write()/osd_close() file I/O APIs. You simply feed it a specially formatted filename of the form "socket" dot HOST colon port. E.g. "socket.google.com:80". Pass OPEN_FLAG_CREATE for a listener (server) socket, omit it for an outgoing socket to connect to a remote server. Depending on how fancy you need to get it would be acceptable to add e.g. osd_fcntl() and osd_select() types of API calls to portably encapsulate those operations. Also, regarding stuff like "m_dwport = machine().root_device().ioport(DRIVEWIRE_PORT_TAG)->read_safe(65504);", you should use the required_ioport pattern to avoid doing an expensive tag lookup each time that statement executes. Admittedly it won't be often in that specific case, but we're trying to eliminate the older design pattern so when people copy/paste stuff in the future they have a fighting chance of getting something that isn't outdated. Good luck, and hopefully this isn't too drastic of a change :)
No.11111 Richard42 Tester Oct 18, 2014, 23:03	Hello, I have uploaded an updated patch which includes the two changes that you requested (1. using osd_* functions instead of socket(),recv(), etc, and 2. using the required_ioport pattern to avoid config tag lookups at runtime). There are some other improvements as well. The becker port implementation class (coco_dwsock.c) was moved from /mess/machine to /emu/bus/coco, to go along with some similar files recently moved in MESS. The 2 new config options ("Becker Port" and "Drivewire Server TCP Port") were split up so that the Becker Port enable option is implemented in the coco machine, while the Drivewire Server TCP Port is implemented in the becker port device itself (coco_dwsock.c). I think this is conceptually better. I also updated the base of the patch to the newest SVN revision as of today (32810). I tested this patch under both Win32 and Linux, and everything worked correctly. Please let me know if there are any other changes you need before merging. Should I also resubmit this patch to the email address, or is it sufficient to post it here?
No.11112 Tafoid Administrator Oct 18, 2014, 23:13	I was about to email you about this - please send it like you did your other one so it can be forwarded and looked at quicker. Devs don't come here as often as read discussion list emails. Thank you!
No.11113 R. Belmont Developer Oct 19, 2014, 00:58	Richard, The revised patch is exactly what I was hoping to see, I have applied it to trunk for 0.156. Thanks! -RB