Viewing Issue Advanced Details Jump to Notes ] coco12.cpp
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 coco12.cpp
Version 0.154 Fixed in Version 0.156 Build 64-bit
Summary MESS-specific 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.
Flags
Regression Version
Affected Sets / Systems Coco 1, 2, 3
Attached Files
? file icon mame-r31554-becker.diff (21,294 bytes)  Aug 8, 2014, 04:46 by Richard42
patch for Becker Port support [Show Content]
zip file icon hdbdw3bc3.zip (6,938 bytes)  Aug 8, 2014, 04:47 by Richard42
HDB-DOS ROM including Becker Port client support
patch file icon mame-r32810-beckerport.patch (19,650 bytes)  Oct 18, 2014, 22:51 by Richard42
updated patch for Becker Port support [Show Content]


-  Notes
User avatar
No.10911
BarnacleEd
(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.
User avatar
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.
User avatar
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
User avatar
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.
User avatar
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 :)
User avatar
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?
User avatar
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!
User avatar
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