Willard Goosey | 1 Jun 2011 05:48

Re: MAKE_TK.lzh has a bad case of Y2K.

On Mon, May 30, 2011 at 10:16:28PM -0700, Stephen H. Fischer wrote:

> I have moved on and this is a busy week.
> This looks like the makefile that caused the "STACK OVERFLOW".

Hokay, I finally got make_tk to fail with a STACK OVERFLOW.

Using make's debug option "-d" requires extra memory or it'll clobber
its stack.  make #8K -d seems to be enough, at least for archive's
makefile.

And yes, the timestamp printouts could use a little doctoring, 111/5/31
isn't quite right... ;-)

The code that checks for dependency loops must use a little more space
than was planned for.

Willard
--

-- 
Willard Goosey  goosey@...
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard

--
Coco mailing list
Coco@...
http://five.pairlist.net/mailman/listinfo/coco

(Continue reading)

Stephen H. Fischer | 1 Jun 2011 07:20
Picon

Re: MAKE_TK.lzh has a bad case of Y2K.

Hi,

OK, I will accept that.

I thought that I only added the -d after I had seen the stack overflow to 
try and find out what was wrong.

I discovered a bug, the error message for example when the disk is full does 
not stay on the screen until a CR like the code says it should.

So I will have to fix that. Another NitrOS-9 change?

SHF

----- Original Message ----- 
From: "Willard Goosey" <goosey@...>
To: "CoCoList for Color Computer Enthusiasts" <coco@...>
Sent: Tuesday, May 31, 2011 8:48 PM
Subject: Re: [Coco] MAKE_TK.lzh has a bad case of Y2K.

> On Mon, May 30, 2011 at 10:16:28PM -0700, Stephen H. Fischer wrote:
>
>> I have moved on and this is a busy week.
>> This looks like the makefile that caused the "STACK OVERFLOW".
>
> Hokay, I finally got make_tk to fail with a STACK OVERFLOW.
>
> Using make's debug option "-d" requires extra memory or it'll clobber
> its stack.  make #8K -d seems to be enough, at least for archive's
> makefile.
(Continue reading)

gene heskett | 1 Jun 2011 10:43
Favicon

Re: MAKE_TK.lzh has a bad case of Y2K.

On Wednesday, June 01, 2011 04:29:40 AM Willard Goosey did opine:

> On Mon, May 30, 2011 at 10:16:28PM -0700, Stephen H. Fischer wrote:
> > I have moved on and this is a busy week.
> > This looks like the makefile that caused the "STACK OVERFLOW".
> 
> Hokay, I finally got make_tk to fail with a STACK OVERFLOW.
> 
> Using make's debug option "-d" requires extra memory or it'll clobber
> its stack.  make #8K -d seems to be enough, at least for archive's
> makefile.
> 
> And yes, the timestamp printouts could use a little doctoring, 111/5/31
> isn't quite right... ;-)
> 
> The code that checks for dependency loops must use a little more space
> than was planned for.
> 
> Willard

The stack overflow problem s/b curable using one of vfy's options.
See the -ud option when you just type 'vfy'.  Here is what I get here:

{t2|07}/DD/NITROS9/dw3install/6309L2/SCRIPTS:vfy /dd/cmds/make
Length of file: $00003D51

Module found at offset $00000000 in this file
Header for    : make
Header parity : $45 (good)
Module size   : $3D51
(Continue reading)

Stephen H. Fischer | 1 Jun 2011 20:02
Picon

"C" Compiler update project

Hi,

In compiling "Archive" I needed to add "FALSE", "TRUE" and "ERROR" to 
"stdio.h"

I am beginning to wonder if the failure to wait for a <CR> is due to another 
difference in header files or in the "clib.l" library.

It may also be another difference in C_Prep19b.

   while(getchar() != ENTER);

I think that we need to vet the header files and libraries.

In order to do so, we need a place that the potential header files and 
libraries are available so we can check our copies with them and then make 
suggestions.

SHF

--
Coco mailing list
Coco@...
http://five.pairlist.net/mailman/listinfo/coco

Stephen H. Fischer | 1 Jun 2011 20:36
Picon

NitrOS-9 Differences.

Hi, 

I have noted some differences between OS-9 that I was running and NitrOS-9 for the VCC emulator. 

I cannot find what the current parameters for "tmode" are. 

In any case, the following shell script does not pass "t' and "tmode" settings to the forked script like I
remembered from twenty years ago. 

I checked and "PATH=" has these words. "The specified paths are retained when
subshells are forked, either by directly calling the shell (shell i=/w&) or by
running a shellscript/memscript." 

Sorry about the wrapped lines and vertical spacing.

SHF

_________________________________________ 

*w.s - create new 80 Column Window 2011/05/28

t

tmode .1 pau=1

windows.s var.0=12

_________________________________________

*windows.s
(Continue reading)

Manny | 1 Jun 2011 21:03
Picon
Gravatar

Re: XLISP!!!!!

On Tuesday, May 31, 2011 09:51:46 PM Willard Goosey wrote:
> On Tue, May 31, 2011 at 08:58:21PM +0100, Manny wrote:
> > I would just use (setq) all of the time...  But for local variables, you
> > can use  (let (var val) ... )  Hold on, let me check this works for
> > Xlisp...  Ack. No, it doesn't have a (let) function.
> 
> See, that's like (set) and (setq)!  Did CL really need _another_ way to
> do variable assignment?

I believe (setq) is more global, whereas (let) is local.

> It doesn't help that xlisp's error reporting isn't very detailed.  You
> type in some complicated function, it goes wrong somewhere, and xlisp
> tells you there was an error in your function and spits the whole thing
> back at you!

Yeah, I agree here.  I was testing a quick rewrite to yesterday's code 
submission a minute ago and had to type the damned thing out 4 times due to me 
forgetting something and being unfamiliar with xlisp...

Speaking of which, were you trying to get all the numbers in to a list with 
your code?  :)

(defun second-w (num)
  (cond
    ((== num 0) (cons num (quote ())))
    (t (cons num (second-w (- num 1))))))

This should output a list of digits from 100 to 0.  I really love the 
recursion here.
(Continue reading)

Steve Bjork | 1 Jun 2011 21:04

Status update and your input on the Floppy Disk Controller emulator for the CoCo

Earlier this year, work start on a Floppy Disk Controller emulator for 
the CoCo. This device would plug into a CoCo and emulate the functions 
of the Western Digital Floppy Disk Controller and Floppy Disk Drive. In 
place of the Floppy media, the device would use a SDHC memory card to 
store the floppy disk data.

Since the device would emulate the WD1793 and the other components on 
the Tandy Floppy Disk controller, it will work with most color computer 
software without any software patches. (Even most copy protected software.)

At the last CoCoFest, I received a lot of helpful input on the device. 
Some of the ideas ranged from adding a Network interface to talk to a 
host computer to a video circuit for 256 colors. But the best suggestion 
was KIS (Keep It Simple) so the device could be designed and build in 
the shorted time possible.

With the fact that others are working on both USB and Network interfaces 
for the CoCo, there is no need for the FDC emulator to anything more 
than the FDC and SDHC memory card. There will be a PC program for 
transferring data to the SDHC card and back. You could even use 
DriveWire or CoCoNet to talk to Host PC and will using the FDC emulator. 
These options should handle any need to talk to a host PC for getting 
data to and from the device.

The current design uses two micro-controller. The first is a small, but 
very fast chip to emulate the WD1793 and Tandy logic of the FDC pak. The 
second micro-controller handles the track format and data information 
stored in the SDHC card. The total cost of both micro-controllers cost 
less than $10 in single unit quantities.

(Continue reading)

Willard Goosey | 1 Jun 2011 21:33

Re: XLISP!!!!!

On Wed, Jun 01, 2011 at 08:03:16PM +0100, Manny wrote:
> I believe (setq) is more global, whereas (let) is local.

Yeah, I read about that last night.  Scoping rules.  Dynamic scoping can
be convient, but it can cause the weirdest bugs ever to pop up!

> Yeah, I agree here.  I was testing a quick rewrite to yesterday's code
> submission a minute ago and had to type the damned thing out 4 times
>due to me forgetting something and being unfamiliar with xlisp...

Oh man, if ever there was an interpeter crying to have a way to fork off
an editor from within the interpeter, xlisp is it!  I may look into that.
> 
> Speaking of which, were you trying to get all the numbers in to a list with 
> your code?  :)
> 
> (defun second-w (num)
>   (cond
>     ((== num 0) (cons num (quote ())))
>     (t (cons num (second-w (- num 1))))))
> 
> This should output a list of digits from 100 to 0.  I really love the 
> recursion here.

Yeah, I've always admired LISP's unabashedly recursive nature.

> If anyone is the least bit interested in this, a good read is 'The
>Little Schemer, Fourth Edition' by Daniel P. Friedman and Matthias
>Felleisen.  It's a brilliant book to learn some of this stuff for
>lisp or Scheme.
(Continue reading)

Frank Pittel | 2 Jun 2011 00:05

Re: Status update and your input on the Floppy Disk Controller emulator for the CoCo


Steve,

When you first mentioned the concept I misunderstood what you were doing
and thought that it would be just a floppy controller and I wasn't interested
since I already have a bunch of them. :-) What you discribe here is very different
then what I first thought. I also like the idea of keeping it simple. Get
something out the door now and add features later as they make sense!! I would
suggest that you stick with the fat filesystem of the cards and use the .dsk
format. That way us linux users can backup the cards and existing tools would be
able use the "disks" directly without the need for additional tools.

I hope that you get something out soon and look forward to getting one!!

The Other Frank

On Wed, Jun 01, 2011 at 12:04:26PM -0700, Steve Bjork wrote:
> Earlier this year, work start on a Floppy Disk Controller emulator
> for the CoCo. This device would plug into a CoCo and emulate the
> functions of the Western Digital Floppy Disk Controller and Floppy
> Disk Drive. In place of the Floppy media, the device would use a
> SDHC memory card to store the floppy disk data.
> 
> Since the device would emulate the WD1793 and the other components
> on the Tandy Floppy Disk controller, it will work with most color
> computer software without any software patches. (Even most copy
> protected software.)
> 
> At the last CoCoFest, I received a lot of helpful input on the
> device. Some of the ideas ranged from adding a Network interface to
(Continue reading)

gene heskett | 2 Jun 2011 00:56
Favicon

Re: "C" Compiler update project

On Wednesday, June 01, 2011 06:55:10 PM Stephen H. Fischer did opine:

> Hi,
> 
> In compiling "Archive" I needed to add "FALSE", "TRUE" and "ERROR" to
> "stdio.h"
> 
> I am beginning to wonder if the failure to wait for a <CR> is due to
> another difference in header files or in the "clib.l" library.
> 
> It may also be another difference in C_Prep19b.
> 
>    while(getchar() != ENTER);
> 
Huh?  'ENTER' had better be defined someplace so that it actually aliases 
back to the os9 carriage return, aka a '\r'.

> I think that we need to vet the header files and libraries.
> 
> In order to do so, we need a place that the potential header files and
> libraries are available so we can check our copies with them and then
> make suggestions.
> 
> SHF
> 
> 
> --
> Coco mailing list
> Coco@...
> http://five.pairlist.net/mailman/listinfo/coco
(Continue reading)


Gmane