Bill Pierce via Coco | 5 Feb 06:58 2016

MShell Update

I have updated my MShell project and from the reports I have received, it will work with Linux DW4 server
systems allowing the user to copy files to & from the Linux DW4 server to and from you NitrOS9 drives. I still
have not heard anything from those who said they would test it on Mac servers for me, but it "should" work
correctly on Mac as well.

I have fixed several bugs I found over the past few days while moving files to and from my PC...
Bug in the "Move File" functions (both single and batch modes) where the file would not be copied. Fixed
Bug an the "Set File Attributes" function where the attributes were not being set correctly. Fixed.
A bug in the "Directory Favorites" where when you change to a new directory, then call up the drive menu, the
"Current Drive" would not be right. Fixed.
A bug in the "Internet Updater" where after an update, the screen did not refresh properly. Fixed.

 
Anyone new to MShell...
MShell is a Graphics oriented File Manger for NitrOS9 L2. It features dual 2 column directory listing in
which you point&click to copy, move, delete, and manipulate files on your OS9, RSDOS, and DW4 PC server's
files systems. This has to be seen to believe!
MShell has many more features (and many more coming), but you'll have to read the included text file to see
the complete list as well as instuctions on using the features.
MShell requires a 512k Coco 3 (or emulator) and NitrOS9 3.3.0. DriveWire4 adds many functions like PC file
copy and internet updater, but it is not required for MShell. See the included text file for the full
requirement list.
The MShell website is here (though a little out of date now)

https://sites.google.com/site/dabarnstudio/mshell---the-ultimate-os-9-gui

And the installation disk can be downloaded here:

https://dl.dropboxusercontent.com/u/23059963/MShell/MShell%201.0.3q.zip

(Continue reading)

Bill Pierce via Coco | 5 Feb 06:16 2016

LWTool Question

I was told by someone over on the Coco Facebook page that there was version of LWTools that would run & work
under MS Visual Studio 2015. Is this true and if so, where can I find it?
Is it the standard Windows build or a special build?

Thanks :-)

Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
Global Moderator for TRS-80/Tandy Color Computer Forums
http://www.tandycoco.com/forum/

E-Mail: ooogalapasooo <at> aol.com

--

-- 
Coco mailing list
Coco <at> maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
Brian Goers | 4 Feb 17:28 2016
Picon
Picon

CGP-115 pens

I am looking for a couple of dry pens for the CGP-115 plotter.
If any one has a couple to send me I would appreciate the help.
Contact me off list.

Thank You

-- 

  Brian Goers

--

-- 
Coco mailing list
Coco <at> maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
Barry Nelson | 4 Feb 01:16 2016

Re: Computer Assisted translation of programs form 6502 to 6809

Actually, it did add some comments, mostly for known hardware port address and BASIC subroutine addresses
like this:
       STA   $FF7F  Multi-pak slot select
Stuff like that. It only disassembled 6809 code though, not 6502, and it assumed the code was running on CoCo hardware.

> Dave Philipsen dave at davebiz.com 
> Wed Feb 3 18:45:17 EST 2016
> 
> That would be very cool, Barry. I hope you find it sometime. Maybe if
> you get a chance you can improve upon it and create a disassembler that 
> creates comments! :-)
> 
> Dave

--

-- 
Coco mailing list
Coco <at> maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
Barry Nelson | 3 Feb 22:12 2016

Re: Computer Assisted translation of programs form 6502 to 6809

I once wrote something I called a tracing disassembler. Unfortunately I do not know what became of it, but
what it did was trace the program execution path though every possibility at each branch instruction.
Sections or code that were never branched to were assumed to be data although you could force the
disassembler to read sections as instructions or data overriding the automatic logic. It also analyzed
the data sections to see if they were ASCII text or binary, and then inserted fcb or fcc statements as needed.

> Neal Crook foofoobedoo at gmail.com 
> Wed Feb 3 15:09:57 EST 2016
> 
> there is a limit to what you can do from simple disassembly. To do a good
> job you need to exercise the program in a test rig until it reveals all of
> its secrets. When Digital was trying to push Alpha into the x86-dominated
> world they did a lot of work on binary translation. Here's an interesting
> paper about the tool they developed:
> 
> www.hpl.hp.com/hpjournal/dtj/vol9num1/vol9num1art1.pdf
> 
> Neal. (Ex-DECcie)

--

-- 
Coco mailing list
Coco <at> maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
Barry Nelson | 3 Feb 21:55 2016

Re: Utility of large MPI

230kbps  would be nice, but not essential. Compatibility with the RS232 would also be nice, but again, not essential.

How many RS232 paks can OS/9 handle? How much wood could a wood chuck chuck if a wood chuck could chuck wood?

> RETRO Innovations go4retro at go4retro.com 
> Wed Feb 3 14:30:20 EST 2016
> 
> On 2/3/2016 9:13 AM, Barry Nelson wrote:
> >   My thoughts/ramblings.
> >
> >   It is fairly easy to implement a SD/MMC interface using SPI if emulating a floppy controller is not
required. If floppy emulation is desired then it becomes more complex, however floppy emulation is
necessary to run many pieces of software since they access the floppy controller directly. A real time
clock is one thing I miss on my CoCo SDC that I had on my original Burke & Burke HD controller. An ethernet
interface could be implemented fairly easily in a limited fashion using a serial to wifi chip to allow
telnet, or implement the DriveWire protocol on an Arduino and use that to interface to wifi or ethernet. I
think that cramming to much functionality into one device could make it too expensive though. The
ethernet interface could be a separate device. I wish the CoCo SDC included a realtime clock however. I
think a parallel port would be of limited use at best, a second serial interface would be much more useful,
though still of limited value.
> >
> What about a serial interface that can do 230kbps?
> 
> And, is compatible with the RS232Pak?
> 
> How many rs232 paks can OS/9 handle? 2?
> 
> Jim
> 
> 
(Continue reading)

Barry Nelson | 3 Feb 16:13 2016

Re: Utility of large MPI (was: Re: ROM Cart registers)

 My thoughts/ramblings.

 It is fairly easy to implement a SD/MMC interface using SPI if emulating a floppy controller is not
required. If floppy emulation is desired then it becomes more complex, however floppy emulation is
necessary to run many pieces of software since they access the floppy controller directly. A real time
clock is one thing I miss on my CoCo SDC that I had on my original Burke & Burke HD controller. An ethernet
interface could be implemented fairly easily in a limited fashion using a serial to wifi chip to allow
telnet, or implement the DriveWire protocol on an Arduino and use that to interface to wifi or ethernet. I
think that cramming to much functionality into one device could make it too expensive though. The
ethernet interface could be a separate device. I wish the CoCo SDC included a realtime clock however. I
think a parallel port would be of limited use at best, a second serial interface would be much more useful,
though still of limited value.

--

-- 
Coco mailing list
Coco <at> maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
Francis Swygert | 3 Feb 14:15 2016
Picon
Picon

Re: Utility of large MPI (was: Re: ROM Cart registers)

Date: Tue, 2 Feb 2016 18:59:43 -0500
From: S Klammer <sklammer <at> gmail.com>

Jim, to add to your "thinking out loud"...

- a parallel port might be useful only if it merely is able to take the
bit-banger or, at worst, the RS232 data to minimize software changes.
- definitely sound, Orch90 and/or Speech&Sound emulation would be nice, but
including a MOD or MP3 player with multiple selectable banks and mixer,
that can play independently, but through the Coco.
- USB.  Programmable drivers on the same SD card if the CocoSDC is also
there.  Keyboards, mice, serial converters, wifi, bluetooth, etc. could
potentially all be available.  The cart would manage the "dirty" work.
- Using the "menu" program idea could permit many options to the user, such
as storing default RGB/Composite, 32/40/80, boot to NitrOS9, Drivewire,
ECB, SECB, etc
- oh, there is so much more... maybe later if there is still interest :)

Are you sure you couldn't use some CF cards for the Glenside? :)
==================================
Adding my own thoughts to this...
- With a CF or SD card, there is no need for a hard drive, except to transfer data from an old HD to the CF or SD. Cf
seems to be easier to implement, but it's also an older technology that's getting harder to find, so I'd
ditch it now! We already have an obsolete machine, why cripple it with waning tech now? Of course the IDE has
already been implemented, and there are cheap IDE to SD and IDE to CF adapters that let the system read the
memory cards as if they were HDs... so the IDE interface is probably the way to go. That would make one
interface work for three different types of drives (physical IDE HD, SD card, CF card). 

- No real need for a parallel port, unless you want to use implement it fully, as a bi directional port, so it
can be used for other I/O projects and not just a printer. There are few modern printers with a parallel port
(Continue reading)

Ed Orbea | 3 Feb 04:04 2016
Picon

HDBDOS Virtual Drives

Running VCC I know I can capture the bit-banger port. Is there a RS-DOS
utility to scan all the virtual drive and print a listing to the bit-banger
port?

Thanks
+----------------+
*Ed Orbea*
Poulsbo, WA

--

-- 
Coco mailing list
Coco <at> maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
Josh Harper via Coco | 3 Feb 00:38 2016

26-3024 multi pak

  finally got a pdf made of my original service manual for the 26-3024 multi pak who wants it id like to share it

--

-- 
Coco mailing list
Coco <at> maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
Barry Nelson | 2 Feb 22:59 2016

Re: Coco emulator for Mac

The path on my system is:
~/Library/Application Support/com.amobiledevice.vcc.201_144376677122231/drive_c/Program
Files/Vcc 2.0.1/
Where ~ is your home folder.

> Barry Nelson Barry.Nelson at amobiledevice.com 
> Tue Feb 2 14:07:44 EST 2016
> 
> When the VCC wine app is first run it creates a folder under your home folder/Library/Application
Support, and it creates a virtual C: drive there however you should be able to place any rom images or disk
images any where you wish and browse to them on the Wine Z: drive which is your entire Mac hard disk.
> 
>  
> 
> >        Bill cwgordon at carolina.rr.com 
<mailto:coco%40maltedmedia.com?Subject=Re%3A%20%5BCoco%5D%20Coco%20emulator%20for%20Mac&In-Reply-To=%3C005401d15dce%248a12d070%249e387150%24%40rr.com%3E> 
> Tue Feb 2 10:29:42 EST 2016 
> 
>  
> 
> >        It seems to be working, but I'd love to have my "stuff" from my PC on my Mac. What directory is it looking in?
Where is everything located? Or is it just hard-coded into the app, and no directory?
> 
>  
> >         Thanks
>  
> >         -----Original Message-----
> >         From: Coco [mailto:coco-bounces at maltedmedia.com
<https://pairlist5.pair.net/mailman/listinfo/coco> ] On Behalf Of Barry Nelson
> >         Sent: Tuesday, February 02, 2016 9:39 AM
(Continue reading)


Gmane