[Coco] What would your ideal CoCo cartridge do?
iggybeans at comcast.net
iggybeans at comcast.net
Thu Oct 31 18:01:57 EDT 2013
>I believe Boisy already has done all that. He hooked up an Arduino,
>talking DriveWire over the cartridge bus (parallel). HDB-DOS includes
>support for this DriveWire interface. See Boisy's mails about it and
>his blog.
I'd love to study that, but I believe I have bugged Boisy more than enough with my current pet projects.
I have looked at building a OPN2 sound card for the Coco, but adding a CPU dedicated to feeding this device has occurred to me.
If any of you can find some direct references, they could prove useful.
----- Original Message -----
From: coco-request at maltedmedia.com
To: coco at maltedmedia.com
Sent: Thursday, October 31, 2013 2:27:31 PM
Subject: Coco Digest, Vol 129, Issue 106
Send Coco mailing list submissions to
coco at maltedmedia.com
To subscribe or unsubscribe via the World Wide Web, visit
http://five.pairlist.net/mailman/listinfo/coco
or, via email, send a message with subject or body 'help' to
coco-request at maltedmedia.com
You can reach the person managing the list at
coco-owner at maltedmedia.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Coco digest..."
Today's Topics:
1. Re: serial port problem (Bill Pierce)
2. Re: serial port problem (Bill Pierce)
3. Coco WiFi (chawks at dls.net)
4. Re: serial port problem (Robert Gault)
5. Re: Coco WiFi (billg999 at cs.uofs.edu)
6. Re: new problem with unpack (Wayne Campbell)
7. Dragon32 with factory Daughterboard SAM chip
(Luis Antoniosi (CoCoDemus))
8. Re: Dragon32 with factory Daughterboard SAM chip
(Luis Antoniosi (CoCoDemus))
9. Re: serial port problem (Mathieu Bouchard)
10. Re: Dragon32 with factory Daughterboard SAM chip
(Phill Harvey-Smith)
11. Re: serial port problem (Mathieu Bouchard)
12. Re: serial port problem (Aaron Wolfe)
13. Re: serial port problem (Luis Antoniosi (CoCoDemus))
14. Re: What would your ideal CoCo cartridge do? (Frank Swygert)
15. Re: new problem with unpack (Wayne Campbell)
----------------------------------------------------------------------
Message: 1
Date: Thu, 31 Oct 2013 06:49:06 -0400 (EDT)
From: Bill Pierce <ooogalapasooo at aol.com>
Subject: Re: [Coco] serial port problem
To: coco at maltedmedia.com
Message-ID: <8D0A43DF466BBE2-117C-1F76E at webmail-d251.sysops.aol.com>
Content-Type: text/plain; charset="utf-8"
Mathieu,
You have the cable, now you just need the software. The old baud rates no longer apply. Check these links:
http://www.cocopedia.com/wiki/index.php/Getting_Started_with_DriveWire
http://www.cocopedia.com/wiki/index.php/DW4_Installation_Guide
The drivewire4 server will run on Windows, Mac OS, and Linux. All that's needed is the serial cable and the Coco side software.
Bill Pierce
My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Webmaster of The TRS-80 Color Computer Archive
http://www.colorcomputerarchive.com/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com
-----Original Message-----
From: Mathieu Bouchard <matju at artengine.ca>
To: coco <coco at maltedmedia.com>
Sent: Thu, Oct 31, 2013 12:35 am
Subject: [Coco] serial port problem
Hi, I have built an adaptor between a DB9 serial port and a DIN4 serial
port, and I can send characters both ways at 300 baud and at 2400 baud
now, but when I try 4800, 9600 or 19200, I get either garbage or nothing.
This is between Terminate 5.0 in MSDOS 6.22 with UART 16550, and a CoCo 3
running UltimaTerm 4.1.
Any idea on how to fix this ?
______________________________________________________________________
| Mathieu BOUCHARD ----- t?l?phone : +1.514.383.3801 ----- Montr?al, QC
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco
------------------------------
Message: 2
Date: Thu, 31 Oct 2013 07:01:44 -0400 (EDT)
From: Bill Pierce <ooogalapasooo at aol.com>
Subject: Re: [Coco] serial port problem
To: coco at maltedmedia.com
Message-ID: <8D0A43FB8AA5881-117C-1F97D at webmail-d251.sysops.aol.com>
Content-Type: text/plain; charset="utf-8"
Mathieu,
Also, here are some videos of what drivewire4 can do.
http://www.youtube.com/results?search_query=drivewire+4&oq=drivewire+4&gs_l=youtube.3...2481.2481.0.3232.1.1.0.0.0.0.0.0..0.0.eytns%2Cpt%3D-27%2Cn%3D2%2Cui%3Dt..0.0...1ac.1.11.youtube.
Bill Pierce
My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Webmaster of The TRS-80 Color Computer Archive
http://www.colorcomputerarchive.com/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com
-----Original Message-----
From: Mathieu Bouchard <matju at artengine.ca>
To: coco <coco at maltedmedia.com>
Sent: Thu, Oct 31, 2013 12:35 am
Subject: [Coco] serial port problem
Hi, I have built an adaptor between a DB9 serial port and a DIN4 serial
port, and I can send characters both ways at 300 baud and at 2400 baud
now, but when I try 4800, 9600 or 19200, I get either garbage or nothing.
This is between Terminate 5.0 in MSDOS 6.22 with UART 16550, and a CoCo 3
running UltimaTerm 4.1.
Any idea on how to fix this ?
______________________________________________________________________
| Mathieu BOUCHARD ----- t?l?phone : +1.514.383.3801 ----- Montr?al, QC
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco
------------------------------
Message: 3
Date: Thu, 31 Oct 2013 08:59:34 -0500
From: chawks at dls.net
Subject: [Coco] Coco WiFi
To: <coco at maltedmedia.com>
Message-ID: <49742.1383227974 at dls.net>
Content-Type: text/plain; charset="utf-8"
One of these cards (and a CF to SD adapter in a SuperIDE) and the appropriate
hacks...
http://hackaday.com/2013/08/12/hacking-transcend-wifi-sd-cards/
Christopher R. Hawks
HAWKSoft
---------------------------
"The strongest test of any system is not how well its features conform to
anticipated needs but how well it performs when one wants to do something
the designer did not forsee."
-- Alan Kay, Xerox PARC
------------------------------
Message: 4
Date: Thu, 31 Oct 2013 10:27:24 -0400
From: Robert Gault <robert.gault at att.net>
Subject: Re: [Coco] serial port problem
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Message-ID: <527268CC.8040503 at att.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mathieu Bouchard wrote:
>
> Hi, I have built an adaptor between a DB9 serial port and a DIN4 serial port,
> and I can send characters both ways at 300 baud and at 2400 baud now, but when I
> try 4800, 9600 or 19200, I get either garbage or nothing.
>
> This is between Terminate 5.0 in MSDOS 6.22 with UART 16550, and a CoCo 3
> running UltimaTerm 4.1.
>
> Any idea on how to fix this ?
>
Well, aside from using Drivewire instead of Terminate (or some other software
combination) or getting an RS-232 PAK for the Coco, there may be a problem with
your serial cable.
The Coco port has a limited number of connections so will not send or receive
some signals needed for higher speed connections. To quote the Coco service
manual, "It is also possible that devices which use a larger set of RSW-232C
signals may be used with the Color Computer 3. This would be accomplished by
connecting unused device inputs to the correct high or low level."
You can do this by bridging cable lines inside either the PC or Coco connectors.
I'm not sure where I got this info but you could try it. I'm sure I have my
cable set this way.
PC DB9 connector - bridge lines
DB9 6 to DB9 4
DB9 7 to DB9 8
Robert
------------------------------
Message: 5
Date: Thu, 31 Oct 2013 11:14:10 -0400
From: billg999 at cs.uofs.edu
Subject: Re: [Coco] Coco WiFi
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Message-ID:
<e3a06848e937129008b67322321d5a9d.squirrel at www.cs.uofs.edu>
Content-Type: text/plain;charset=iso-8859-1
>
> One of these cards (and a CF to SD adapter in a SuperIDE) and the
> appropriate
> hacks...
>
> http://hackaday.com/2013/08/12/hacking-transcend-wifi-sd-cards/
>
>
Cute. And brings up another interesting idea. I used to have an
iPaq (anybody even remember them?). It had both a WIFI card and a
GPS card that were CF. I wonder what the chances are of making one
or both of these work in a SuperIDE if you are not using it for disk
storage? Mark.... :-)
bill
------------------------------
Message: 6
Date: Thu, 31 Oct 2013 08:35:27 -0700
From: Wayne Campbell <asa.rand at gmail.com>
Subject: Re: [Coco] new problem with unpack
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Message-ID:
<CAK_fd-Ebvw=JKjGJt0WBZBCbj7JaseLSrXgymoKL3j9eubYwWQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Oct 30, 2013 9:57 PM, "Greg Law" <glaw at live.com> wrote:
> There are a few other things you might try to split the modules into
> physically separate processes without resorting to using temporary files
for
> intermediate output.
> 1. Have the first part of the application (decode?) write all output to
> standard input and the secondary/tertiary applications read from standard
> input and write standard output. This way you can deocde ! unpack ! split
!
> prettyprint >module.bas via fast pipes without touching disk for the
> intermediate results.
First, to make sense of the program and its organization, decode is a
stand-alone version of what in unpack is now called readCode. The program
flow is as follows:
getHeader --------- unpack
|
+--------+--------+--------+--------+
| | | | |
readCode linNums defVars buildSrc instruction
| | | | | |
lSort vSort fSort dsSort hex$ DRPN
For decode, the flow is different, as each module is CHAINed from the
previous:
decode -> defVars -> buildSrc -> instruction
| | | | |
lSort vSort dsSort hex$ DRPN
fSort
Both versions are disk intensive, in that the module (decode) or
merged-module file (unpack) is read from disk, and the tables in the I-Code
are read directly from the file. There are pre-created data files stored in
the DATA directory (/DD/DATA) that decode and unpack both use to hold
various data, like the line references, the variable references, and
internal data used by the program.
Due to the problems I still have with DIMension statements (TYPE statements
and STRINGs) three "work files" are generated by both programs. Until now,
the output of source to stdout was for the user to see what the program is
doing, as a source code file is generated in decode, and until yesterday
was being generated in unpack. This file is created first in buildSrc
(PROCEDURE statement and DIM statements), then instruction adds the source
statements to the file. In unpack, this is now changed so that the utility
will work as expected, you redirect output to save it to a file, using the
format "unpack <filepath> > <sourcefile>". It turns out that it will need a
memory modifier to work, so the actual command will be "unpack <filepath>
#16k > <sourcefile>".
That brings us up to the point of this post. The issue remains in
instruction because it and DRPN cannot run at the same time. According to
what you wrote above, I can use pipes to run both in separate spaces, and
have the data communicated between them. I think this means I use a SHELL
statement to run DRPN in it's own 64K block (I believe this is the way you
fork a process from within Basic09), then have instruction send its output
to DRPN through stdin, and DRPN can either print the resulting source
statement to stdout, or I can have DRPN send it back to instruction via
pipes (stdin) and let instruction print it to stdout. If I have
misunderstood anything here, please correct me.
> 2. If you need to feed a secondary app data and get decoded data back out
in a
> loop (e.g. for DRPN), set up a named pipe. I think (someone correct me if
I'm
> wrong here) named pipes were carried over into NitrOS-9, so you could open
> something like /pipe/dprn in read+write mode in both processes and
communicate
> via a predefined protocol over the pipe. This way the two functions are
> separate processes with their own 64K process space. Communicating over a
pipe
> this way is slower than calling a function, but it is significantly faster
> than disk.
If I understand this part correctly, I can definitely have DRPN send its
result back to instruction. This is the way it is currently coded (as in
DRPN just parses the string, then returns to instruction to print it out).
I think I can modify the existing code to work with pipes, but I may need
some help with the actual syntax for forking the DRPN process and having
the pipes setup to be bi-directional.
I will post when I have tried it, and hopefully I won't have issues.
Wayne
------------------------------
Message: 7
Date: Thu, 31 Oct 2013 11:34:45 -0400
From: "Luis Antoniosi (CoCoDemus)" <retrocanada76 at gmail.com>
Subject: [Coco] Dragon32 with factory Daughterboard SAM chip
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Message-ID:
<CAFgJrh8M8GXrxGvfsLLvKS4nBaa4gWTiWp8ZjZt1uebgmwWSoA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
What would be the reason for this ?
Its a daughter board with the SAM, some jumpers and 2 TTLs.
Would this be a fix to change the clock rate ?
I have no clues. There is red jumper going to what looks to be the the
mc6847 Field Synchronization pin.
--
Long live the CoCo
------------------------------
Message: 8
Date: Thu, 31 Oct 2013 11:37:24 -0400
From: "Luis Antoniosi (CoCoDemus)" <retrocanada76 at gmail.com>
Subject: Re: [Coco] Dragon32 with factory Daughterboard SAM chip
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Message-ID:
<CAFgJrh_CR9rYbXyyQHBKG3deH1kWOYewB7yX+UJVrPTcmXptog at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
oh I forgot the link:
http://www.ebay.co.uk/itm/Dragon-32-Computer-with-Factory-SAM-CHIP-Daughterboard-VERY-RARE-/171162110825?pt=UK_VintageComputing_RL&hash=item27da0e8b69
On Thu, Oct 31, 2013 at 11:34 AM, Luis Antoniosi (CoCoDemus) <
retrocanada76 at gmail.com> wrote:
> What would be the reason for this ?
>
> Its a daughter board with the SAM, some jumpers and 2 TTLs.
>
> Would this be a fix to change the clock rate ?
>
> I have no clues. There is red jumper going to what looks to be the the
> mc6847 Field Synchronization pin.
>
>
> --
> Long live the CoCo
>
--
Long live the CoCo
------------------------------
Message: 9
Date: Thu, 31 Oct 2013 12:23:48 -0400 (EDT)
From: Mathieu Bouchard <matju at artengine.ca>
Subject: Re: [Coco] serial port problem
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Message-ID: <alpine.DEB.2.00.1310311209450.29667 at artengine.ca>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Le 2013-10-31 ? 06:49:00, Bill Pierce a ?crit?:
> You have the cable, now you just need the software. The old baud rates
> no longer apply.
I had already downloaded DW4, but I just wanted to test the connection. If
I can't get anything to be transmitted outside of DW4 above 2400, I won't
be able to get above 2400 inside of DW4. Both software are supposed to be
able to go up to 19200.
Besides, DW4 doesn't detect my serial port, and when I try to add it
manually, the window is too small for its contents and I can't find a way
to resize it (and there seems to be a non-working horizontal scrollbar
too). This is in Linux (Ubuntu 12.04) and I haven't tried my serial port
in any other way inside Linux yet (my other software was in DOS), but at
least I'd expect the ??add serial port?? dialogue-box to be of the proper
size, or otherwise usable.
______________________________________________________________________
| Mathieu BOUCHARD ----- t?l?phone?: +1.514.383.3801 ----- Montr?al, QC
------------------------------
Message: 10
Date: Thu, 31 Oct 2013 15:50:29 +0000
From: Phill Harvey-Smith <afra at ramoth.org.uk>
Subject: Re: [Coco] Dragon32 with factory Daughterboard SAM chip
To: coco at maltedmedia.com
Message-ID: <52727C45.4040301 at ramoth.org.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 31/10/2013 15:34, Luis Antoniosi (CoCoDemus) wrote:
> What would be the reason for this ?
>
> Its a daughter board with the SAM, some jumpers and 2 TTLs.
>
> Would this be a fix to change the clock rate ?
>
> I have no clues. There is red jumper going to what looks to be the the
> mc6847 Field Synchronization pin.
Yep I have a Dragon 32 like it. The daughter board is Dragon Data
PN48200, the extra circuit is a 74LS74 and a 74LS32. It appears to
ensure that the changes to /HS and DA0 happen at co incident with the E
clock (E is fed to the CLK pin of both flipflops).
I have traced the schematic in Eagle and can post if anyone wants it.
Cheers.
Phill.
------------------------------
Message: 11
Date: Thu, 31 Oct 2013 12:37:11 -0400 (EDT)
From: Mathieu Bouchard <matju at artengine.ca>
Subject: Re: [Coco] serial port problem
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Message-ID: <alpine.DEB.2.00.1310311224451.29667 at artengine.ca>
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
Le 2013-10-31 ? 10:27:00, Robert Gault a ?crit?:
> You can do this by bridging cable lines inside either the PC or Coco
> connectors. I'm not sure where I got this info but you could try it. I'm
> sure I have my cable set this way.
>
> PC DB9 connector - bridge lines
> DB9 6 to DB9 4
> DB9 7 to DB9 8
I had done this at first, and then I realised that the serial cable I have
does not connect any pins apart from RX, TX, GND (which are DB9's 2,3,5).
The cable does contain enough wires to connect everything, but I think
that this is a custom-built cable made by someone who got lazy. I had
another cable but I threw it away earlier this year because I hadn't used
a RS232 port since about 12 years (and luckily, I didn't throw away both
cables).
I could find a way to to the bridges inside the cable's plug on the PC
side, but I don't know why that would make 4800 bauds begin to work, when
currently 2400 already works. For example, it can't be a flow-control
issue yet, it doesn't look like that (otherwise, at least *some*
characters would go through correctly).
______________________________________________________________________
| Mathieu BOUCHARD ----- t?l?phone?: +1.514.383.3801 ----- Montr?al, QC
------------------------------
Message: 12
Date: Thu, 31 Oct 2013 12:46:51 -0400
From: Aaron Wolfe <aawolfe at gmail.com>
Subject: Re: [Coco] serial port problem
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Message-ID:
<CAA6uQZSwTDiXYWZMZJkuFGVhOY+uPK89E7EbJKY3oUWnA7P5-w at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Oct 31, 2013 12:24 PM, "Mathieu Bouchard" <matju at artengine.ca> wrote:
>
> Le 2013-10-31 ? 06:49:00, Bill Pierce a ?crit :
>
>
>> You have the cable, now you just need the software. The old baud rates
no longer apply.
>
>
> I had already downloaded DW4, but I just wanted to test the connection.
If I can't get anything to be transmitted outside of DW4 above 2400, I
won't be able to get above 2400 inside of DW4. Both software are supposed
to be able to go up to 19200.
>
This is inaccurate. You will be able to do transfers at up to 230,400 bps
using DriveWire because of Darren's awesome bit banger routines. These
routines are only found in the HDBDOS for DriveWire and the OS9 DriveWire
modules, so the speeds you see in other software (which uses different
serial IO code) is largely irrelevant.
Various terminal programs tried different tricks to make the bit banger go
faster than the BASIC ROM routines, which are limited to 600 bps iirc (it's
some very slow speed). Because the operation of the bit banger is largely
software defined, there is no set clock speed like you would have in a
UART. Better code can make the port work faster and/or more reliably than
poor code. This makes serial IO on the coco bit banger quite a different
beast than the typical scenario where things like port speed are fixed and
control lines are handled in specialized hardware with rigid behavior. For
instance, we use the CD pin on the coco as part of the read data operation
to achieve speeds over 115k. You couldn't typically re purpose a pin on a
serial port connected to a UART like that (of course, some exceptions do
apply, but the point is that a software defined bit banger is very
different to a uart).
Long story short, behavior in one coco serial program can be entirely
different than another. If you have 300 bps or 2400 bps or really any comm
at all between PC and coco, you are probably fine.
> Besides, DW4 doesn't detect my serial port, and when I try to add it
manually, the window is too small for its contents and I can't find a way
to resize it (and there seems to be a non-working horizontal scrollbar
too). This is in Linux (Ubuntu 12.04) and I haven't tried my serial port in
any other way inside Linux yet (my other software was in DOS), but at least
I'd expect the ? add serial port ? dialogue-box to be of the proper size,
or otherwise usable.
>
It is difficult to size some gui components to display correctly on the
huge range of platforms we try to support. Linuxes vary a lot from
distribution to distro, window manager to wm, etc. I haven't tested on an
Ubuntu machine in a while.
I can make it bigger in the next version. Can you send me a screen shot of
what it looks like?
You have find changing your display resolution makes the dialog usable in
the meantime. You can also use the configuration editor or any text editor
on config.xml to manually set the port.
>
> ______________________________________________________________________
> | Mathieu BOUCHARD ----- t?l?phone : +1.514.383.3801 ----- Montr?al, QC
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
------------------------------
Message: 13
Date: Thu, 31 Oct 2013 12:53:18 -0400
From: "Luis Antoniosi (CoCoDemus)" <retrocanada76 at gmail.com>
Subject: Re: [Coco] serial port problem
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Message-ID:
<CAFgJrh-wVfNV0s-4Z8MiYSus8gk_ENL40_Tyu4QVb52=CFMnRw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
You can try to updating the DW first (Tools -> Update)
I use it on Ubuntu, Xubuntu and Lubuntu without any GUI problem.
Also, you can use any unexpensive RS232 dongle:
http://www.ebay.com/itm/USB-to-RS232-serial-DB9-Adapter-4-XP-Vista-Win7-Female-Screw-FastShipping-USA-/230911838342?pt=US_Parallel_Serial_PS_2_Cables_Adapters&hash=item35c36b0886
I use one of this with linux and it works fine.
On Thu, Oct 31, 2013 at 12:37 PM, Mathieu Bouchard <matju at artengine.ca>wrote:
> Le 2013-10-31 ? 10:27:00, Robert Gault a ?crit :
>
> You can do this by bridging cable lines inside either the PC or Coco
>> connectors. I'm not sure where I got this info but you could try it. I'm
>> sure I have my cable set this way.
>>
>> PC DB9 connector - bridge lines
>> DB9 6 to DB9 4
>> DB9 7 to DB9 8
>>
>
> I had done this at first, and then I realised that the serial cable I have
> does not connect any pins apart from RX, TX, GND (which are DB9's 2,3,5).
> The cable does contain enough wires to connect everything, but I think that
> this is a custom-built cable made by someone who got lazy. I had another
> cable but I threw it away earlier this year because I hadn't used a RS232
> port since about 12 years (and luckily, I didn't throw away both cables).
>
> I could find a way to to the bridges inside the cable's plug on the PC
> side, but I don't know why that would make 4800 bauds begin to work, when
> currently 2400 already works. For example, it can't be a flow-control issue
> yet, it doesn't look like that (otherwise, at least *some* characters would
> go through correctly).
>
> ______________________________**______________________________**
> __________
> | Mathieu BOUCHARD ----- t?l?phone : +1.514.383.3801 ----- Montr?al, QC
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
--
Long live the CoCo
------------------------------
Message: 14
Date: Thu, 31 Oct 2013 14:11:02 -0400
From: Frank Swygert <farna at amc-mag.com>
Subject: Re: [Coco] What would your ideal CoCo cartridge do?
To: coco at maltedmedia.com
Message-ID: <52729D36.5050208 at amc-mag.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On Tue, Oct 29, 2013 at 7:29 PM,<billg999 at cs.uofs.edu> wrote:
>> Frank Swygert wrote: Someone mentioned they wouldn't want to use another computer as a
>> server. Well, build the server on a cartridge, and have the cart work
>> like a serial port. The server software could be pre-loaded, and could
>> be transparent to the CoCo. An RPi could be used, but there are other
>> small ARM based computers that would work, some smaller than the RPi
>> (but a bit more costly). Maybe build an entirely new board, stripping
>> the unnecessary functions of the RPi...
> Now that brings up even more ideas. How fast would DriveWire be
> if the interface were parallel instead of serial? RPi in a cart
> talking directly to the bus hosting DriveWire and all the bells
> and whistles that gets you.
I believe Boisy already has done all that. He hooked up an Arduino,
talking DriveWire over the cartridge bus (parallel). HDB-DOS includes
support for this DriveWire interface. See Boisy's mails about it and
his blog.
Tormod
==============================
Does someone have a link to the blog concerning this?
--
Frank Swygert
Editor - American Motors Cars Magazine
www.amc-mag.com
------------------------------
Message: 15
Date: Thu, 31 Oct 2013 11:27:25 -0700
From: Wayne Campbell <asa.rand at gmail.com>
Subject: Re: [Coco] new problem with unpack
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Message-ID:
<CAK_fd-FK2weEudD-Defse_qkxfz5LLtFmcKM_9Ub1Qp-1MO3NA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Well, the problem isn't what I was thinking it was. I removed DRPN from the
equation by packing it separately so that instruction would be small enough
to execute. That was when I realized that instruction was not executing at
all. The error is being generated by the system (or runb), not by my
program. I looked again at my code in instruction. The first instruction is:
PRINT #2,"Building Instruction Statements";
I thought, maybe that is the problem, and somehow #2 is not being
recognized by runb or the system as stderr. I replaced it with:
PRINT "buildSrc";
The same error occured. The first instruction is not being executed,
period. The error occurs as soon as an attempt to execute instruction is
made. Since instruction and hex$ both fit well under 8k and the data space
requirements for instruction are <8k, something else must be causing the
problem.
One change I made to make instruction smaller was I replaced 2 of the 3
records with only the variables needed to hold those fields, and passed the
fields from unpack. I thought, maybe runb doesn't like me trying to pass a
filepath number contained in a record. I changed unpack so it contained the
necessary variables, assigned those variables the necessary field values,
and passed just those variables. The same error occurs in the same place.
I know I can use a path number in a record field because I do it in every
procedure in unpack. The only difference here is, instead of passing the
entire record I am passing a specific field of the record. And now I am not
even doing that. I am assigning a different variable of the same type as
the field the value of the field, and passing that variable instead.
ERROR #201 (as the system displays it) is displayed by ErrorCodes as:
Error#: 201 ILLEGAL PATH NUMBER The path number is too large or you
specified a non-existent path.
since the error occurs when the first attempt to execute instruction is
made, instruction is small enough to fit in memory now, and the error
report is coming from the system (or runb) (and not through my program's
error trap system), I can only think that runb is the problem. I do not
know what to do about it.
Anyone out there have any ideas?
Wayne
------------------------------
_______________________________________________
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco
End of Coco Digest, Vol 129, Issue 106
**************************************
More information about the Coco
mailing list