Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #58072 > unrolled thread

microFORTH

Back to article view | Back to comp.lang.forth

Contents

  microFORTH JUERGEN <epldfpga@aol.com> - 2017-04-25 01:15 -0700
    Re: microFORTH "HAA" <someone@microsoft.com> - 2017-04-26 09:35 +1000
      Re: microFORTH "Elizabeth D. Rather" <erather@forth.com> - 2017-04-25 14:15 -1000
        Re: microFORTH lehs <skydda.barnen@gmail.com> - 2017-04-25 23:09 -0700
        Re: microFORTH "HAA" <someone@microsoft.com> - 2017-05-01 11:15 +1000
    Re: microFORTH David Schultz <abuse@127.0.0.1> - 2017-04-30 15:02 -0500
      Re: microFORTH rickman <gnuarm@gmail.com> - 2017-04-30 21:13 -0400
        Re: microFORTH David Schultz <abuse@127.0.0.1> - 2017-04-30 20:24 -0500
          Re: microFORTH rickman <gnuarm@gmail.com> - 2017-05-01 21:02 -0400
            Re: microFORTH Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-02 05:58 -0400
            Re: microFORTH Coos Haak <htrofhc@gmail.com> - 2017-05-02 15:13 +0200
              Re: microFORTH rickman <gnuarm@gmail.com> - 2017-05-02 11:44 -0400
                Re: microFORTH David Schultz <abuse@127.0.0.1> - 2017-05-04 16:54 -0500
      Re: microFORTH "HAA" <someone@microsoft.com> - 2017-05-02 10:36 +1000
        Re: microFORTH "Elizabeth D. Rather" <erather@forth.com> - 2017-05-01 15:20 -1000
          Re: microFORTH "HAA" <someone@microsoft.com> - 2017-05-02 13:01 +1000
            Re: microFORTH hughaguilar96@gmail.com - 2017-05-01 20:42 -0700
              Re: microFORTH hughaguilar96@gmail.com - 2017-05-01 21:27 -0700
                Re: microFORTH "HAA" <someone@microsoft.com> - 2017-05-02 17:05 +1000
                  Re: microFORTH "Elizabeth D. Rather" <erather@forth.com> - 2017-05-01 21:18 -1000
            Re: microFORTH "HAA" <someone@microsoft.com> - 2017-05-02 16:45 +1000
            Re: microFORTH JUERGEN <epldfpga@aol.com> - 2017-05-02 00:08 -0700
            Re: microFORTH hughaguilar96@gmail.com - 2017-05-02 11:36 -0700
              Re: microFORTH "HAA" <someone@microsoft.com> - 2017-05-03 10:43 +1000
                Re: microFORTH hughaguilar96@gmail.com - 2017-05-02 19:45 -0700
                Re: microFORTH Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:41 -0500
                Re: microFORTH David Schultz <abuse@127.0.0.1> - 2017-05-04 17:03 -0500
                  Re: microFORTH "Elizabeth D. Rather" <erather@forth.com> - 2017-05-04 12:58 -1000
                  Re: microFORTH "HAA" <someone@microsoft.com> - 2017-05-05 12:57 +1000
          Re: microFORTH David Schultz <abuse@127.0.0.1> - 2017-05-04 16:57 -0500
      Re: microFORTH Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 04:11 -0500
        Re: microFORTH Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 04:16 -0500
        Re: microFORTH Howerd <howerdo@yahoo.co.uk> - 2017-05-02 05:25 -0700
          Re: microFORTH "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 10:07 -1000
        Re: microFORTH David Schultz <abuse@127.0.0.1> - 2017-05-04 17:15 -0500

Page 2 of 2 — ← Prev page 1 [2]

#58469

HAA wrote:
> Elizabeth D. Rather wrote:
> > On 5/1/17 2:36 PM, HAA wrote:
> > > David Schultz wrote:
> > >> On 04/25/2017 03:15 AM, JUERGEN wrote:
> > >>> microFORTH documentation is available on the FORTH, INC. website. Not
> > >>> a new product - but many here will probably remember it. And might
> > >>> have a look after many years ...
> > >>>
> > >>
> > >> I don't know how useful it is, unless you want examples of bugs.
> > >>
> > >> It starts off with the definition of LOAD:
> > >>
> > >> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> > >>     BLK ! INTERPRET R> IN ! R> BLK C! ;
> > >>
> > >> The value in BLK is saved and restored using C@ and C! yet it has to
> > >> have a larger range than that and the new value is set using !.
> >
> > Actually, this is for the 1802, which had a development system using
> > 250K floppies! This is 1978, folks. And BLK is a user variable, so it
> > had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
> > failure. Obviously the "endianness" worked ok.
>
> 'blocks' were 128 bytes.  While any screen on the disk could be LOADed
> thanks to ! , the C@ C! would limit use of the word "LOAD" to screens 1-31
> by my calculation.  Not a big deal for floppy size storage.

Correction.  According to the tech manual BLK is allocated one byte but
is permitted to overlap IN which is two bytes.  Hence the confusing mix
of byte/word operators in dealing with BLK.  How WORD handles the IN
overlap would be interesting to know.

BTW BASE is also one byte (to save space).

[toc] | [prev] | [next] | [standalone]

#58472

On Tuesday, May 2, 2017 at 4:02:00 AM UTC+1, HAA wrote:
> Elizabeth D. Rather wrote:
> > On 5/1/17 2:36 PM, HAA wrote:
> > > David Schultz wrote:
> > >> On 04/25/2017 03:15 AM, JUERGEN wrote:
> > >>> microFORTH documentation is available on the FORTH, INC. website. Not
> > >>> a new product - but many here will probably remember it. And might
> > >>> have a look after many years ...
> > >>>
> > >>
> > >> I don't know how useful it is, unless you want examples of bugs.
> > >>
> > >> It starts off with the definition of LOAD:
> > >>
> > >> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> > >>     BLK ! INTERPRET R> IN ! R> BLK C! ;
> > >>
> > >> The value in BLK is saved and restored using C@ and C! yet it has to
> > >> have a larger range than that and the new value is set using !.
> >
> > Actually, this is for the 1802, which had a development system using
> > 250K floppies! This is 1978, folks. And BLK is a user variable, so it
> > had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
> > failure. Obviously the "endianness" worked ok.
> 
> 'blocks' were 128 bytes.  While any screen on the disk could be LOADed
> thanks to ! , the C@ C! would limit use of the word "LOAD" to screens 1-31
> by my calculation.  Not a big deal for floppy size storage.
> 
> >
> > >> Plus most of the code is missing.
> >
> > Um, no, actually, this is all of it, including the assembler, compiler,
> > text editor, source printing utility, metacompiler, and code for the
> > kernel. We wrote a bunch of completed applications with it.
> 
> There does appear to be some source that's missing - INTERPRET,
> WORD, BLOCK etc and parts of the run-time e.g. WHILE.
> 
> >
> > > It seems a little too obvious to be a bug - besides which it would only
> > > limit the range of screens on which the word LOAD could appear.
> > > I would reserve judgement until I saw the entire code.  I assume the
> > > distribution disk contained a boot image representing the forth kernel
> > > which then loads screen 3.
> >
> > Yes, that's correct. The bootstrap was in 0 and the precompiled kernel
> > is in 1 and 2.
> >
> > Cheers,
> > Elizabeth
> 
> Perhaps someone who still has disks can dump the image.  I notice there's
> been a revival of interest in 1802 Forths e.g. CamelForth and others.
> http://www.retrotechnology.com/memship/figforth_1802.html

There is the EMMA2 simulator, but we took it a step further. Steve Teal did me a big favour to design an 1802 IP, running on a low cost ICE40 8k board - the ony one ww that has an open source tool chain. 
FIG-Forth Manual is now part of the Forth Bookshelf at https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM  and more details at https://wiki.forth-ev.de/doku.php/projects:fig-forth-1802-fpga:start. 
You find an image to flash the FPGA there. And the github link to the 1802 IP.
 We are still looking for a complete source for microFORTH, but FORTH,INC was kind enough already to release the information on their website. And we hope to get it running on the same board at some time. Why? Retro, fun and good memories. 

[toc] | [prev] | [next] | [standalone]

#58524

On Monday, May 1, 2017 at 8:02:00 PM UTC-7, HAA wrote:
> Elizabeth D. Rather wrote:
> > On 5/1/17 2:36 PM, HAA wrote:
> > > David Schultz wrote:
> > >> On 04/25/2017 03:15 AM, JUERGEN wrote:
> > >>> microFORTH documentation is available on the FORTH, INC. website. Not
> > >>> a new product - but many here will probably remember it. And might
> > >>> have a look after many years ...
> > >>>
> > >>
> > >> I don't know how useful it is, unless you want examples of bugs.
> > >>
> > >> It starts off with the definition of LOAD:
> > >>
> > >> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> > >>     BLK ! INTERPRET R> IN ! R> BLK C! ;
> > >>
> > >> The value in BLK is saved and restored using C@ and C! yet it has to
> > >> have a larger range than that and the new value is set using !.
> >
> > Actually, this is for the 1802, which had a development system using
> > 250K floppies! This is 1978, folks. And BLK is a user variable, so it
> > had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
> > failure. Obviously the "endianness" worked ok.
> 
> 'blocks' were 128 bytes.  While any screen on the disk could be LOADed
> thanks to ! , the C@ C! would limit use of the word "LOAD" to screens 1-31
> by my calculation.  Not a big deal for floppy size storage.

C@ doesn't sign extend --- not nowadays anyway --- so the range would have been [0,255].

If the floppies were 250KB, and the processor was little-endien, the code would have worked despite the bug.

[toc] | [prev] | [next] | [standalone]

#58545

hughaguilar96@gmail.com wrote:
> On Monday, May 1, 2017 at 8:02:00 PM UTC-7, HAA wrote:
> > Elizabeth D. Rather wrote:
> > > On 5/1/17 2:36 PM, HAA wrote:
> > > > David Schultz wrote:
> > > >> On 04/25/2017 03:15 AM, JUERGEN wrote:
> > > >>> microFORTH documentation is available on the FORTH, INC. website. Not
> > > >>> a new product - but many here will probably remember it. And might
> > > >>> have a look after many years ...
> > > >>>
> > > >>
> > > >> I don't know how useful it is, unless you want examples of bugs.
> > > >>
> > > >> It starts off with the definition of LOAD:
> > > >>
> > > >> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> > > >>     BLK ! INTERPRET R> IN ! R> BLK C! ;
> > > >>
> > > >> The value in BLK is saved and restored using C@ and C! yet it has to
> > > >> have a larger range than that and the new value is set using !.
> > >
> > > Actually, this is for the 1802, which had a development system using
> > > 250K floppies! This is 1978, folks. And BLK is a user variable, so it
> > > had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
> > > failure. Obviously the "endianness" worked ok.
> >
> > 'blocks' were 128 bytes.  While any screen on the disk could be LOADed
> > thanks to ! , the C@ C! would limit use of the word "LOAD" to screens 1-31
> > by my calculation.  Not a big deal for floppy size storage.
>
> C@ doesn't sign extend --- not nowadays anyway --- so the range would have been [0,255].
>
> If the floppies were 250KB, and the processor was little-endien, the code would have
> worked despite the bug.

There's no bug.  When referencing a disk block, BLK is 16 bits.
However as BLK and IN represent 3 contiguous bytes, a mix of
C@ C! ! @ were needed to save/restore/zero both BLK and IN.

[toc] | [prev] | [next] | [standalone]

#58548

On Tuesday, May 2, 2017 at 5:44:00 PM UTC-7, HAA wrote:
> hughaguilar96@gmail.com wrote:
> > On Monday, May 1, 2017 at 8:02:00 PM UTC-7, HAA wrote:
> > > Elizabeth D. Rather wrote:
> > > > On 5/1/17 2:36 PM, HAA wrote:
> > > > > David Schultz wrote:
> > > > >> On 04/25/2017 03:15 AM, JUERGEN wrote:
> > > > >>> microFORTH documentation is available on the FORTH, INC. website. Not
> > > > >>> a new product - but many here will probably remember it. And might
> > > > >>> have a look after many years ...
> > > > >>>
> > > > >>
> > > > >> I don't know how useful it is, unless you want examples of bugs.
> > > > >>
> > > > >> It starts off with the definition of LOAD:
> > > > >>
> > > > >> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> > > > >>     BLK ! INTERPRET R> IN ! R> BLK C! ;
> > > > >>
> > > > >> The value in BLK is saved and restored using C@ and C! yet it has to
> > > > >> have a larger range than that and the new value is set using !.
> > > >
> > > > Actually, this is for the 1802, which had a development system using
> > > > 250K floppies! This is 1978, folks. And BLK is a user variable, so it
> > > > had to be 16 bits. That ! is pretty tacky, but it wouldn't cause a
> > > > failure. Obviously the "endianness" worked ok.
> > >
> > > 'blocks' were 128 bytes.  While any screen on the disk could be LOADed
> > > thanks to ! , the C@ C! would limit use of the word "LOAD" to screens 1-31
> > > by my calculation.  Not a big deal for floppy size storage.
> >
> > C@ doesn't sign extend --- not nowadays anyway --- so the range would have been [0,255].
> >
> > If the floppies were 250KB, and the processor was little-endien, the code would have
> > worked despite the bug.
> 
> There's no bug.  When referencing a disk block, BLK is 16 bits.
> However as BLK and IN represent 3 contiguous bytes, a mix of
> C@ C! ! @ were needed to save/restore/zero both BLK and IN.

You need BLK to be 16-bit because there may be more than 255 blocks.

You need >IN to be 16-bit because the block has 1024 bytes, which is more than 256.

This seems like a weird attempt to explain away a blatant bug. 

As I said before, this is why all Forth Inc. software after 1982 is bug-ridden. The Forth Inc. employees have the attitude that they are perfect, like angels, and they never make any mistakes --- they never have any bugs, gosh no! --- bugs get explained away, and they stay in the code forever without getting fixed.

They may have gotten away with this bug on early systems because the disk had less than 256 blocks, and the processor was little-endian --- it is still a bug though --- it will definitely bite you when you upgrade your system to use a disk with more than 256 blocks (which should have been easy to predict, even in the 1970s when 256KB seemed like a lot).

[toc] | [prev] | [next] | [standalone]

#58566

HAA <someone@microsoft.com> wrote:

> There's no bug.  When referencing a disk block, BLK is 16 bits.
> However as BLK and IN represent 3 contiguous bytes, a mix of
> C@ C! ! @ were needed to save/restore/zero both BLK and IN.

Oh yes, and blocks were only 128 bytes so there was no need for >IN to
be more than one byte.  How very Dean.  :-)

Andrew.

[toc] | [prev] | [next] | [standalone]

#58685

On 05/02/2017 07:43 PM, HAA wrote:

> There's no bug.  When referencing a disk block, BLK is 16 bits.
> However as BLK and IN represent 3 contiguous bytes, a mix of
> C@ C! ! @ were needed to save/restore/zero both BLK and IN.
> 

How does that work?

If BLK is zero then input is from the terminal. This implies that the
high byte of IN is also zero. Which would be fine.

But if BLK is non-zero then IN cannot be used as is to index into the
block. Something else must be done. It could be as simple as "IN 1+ C@"
but that means that the code to interpret a disk block is different from
the code to interpret a line from the terminal.

Kind of making that saving one byte of user variable storage moot.

Of course if ALL of the code were present we could see how it is done.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

[toc] | [prev] | [next] | [standalone]

#58687

On 5/4/17 12:03 PM, David Schultz wrote:
> On 05/02/2017 07:43 PM, HAA wrote:
>
>> There's no bug.  When referencing a disk block, BLK is 16 bits.
>> However as BLK and IN represent 3 contiguous bytes, a mix of
>> C@ C! ! @ were needed to save/restore/zero both BLK and IN.
>>
>
> How does that work?
>
> If BLK is zero then input is from the terminal. This implies that the
> high byte of IN is also zero. Which would be fine.
>
> But if BLK is non-zero then IN cannot be used as is to index into the
> block. Something else must be done. It could be as simple as "IN 1+ C@"
> but that means that the code to interpret a disk block is different from
> the code to interpret a line from the terminal.
>
> Kind of making that saving one byte of user variable storage moot.
>
> Of course if ALL of the code were present we could see how it is done.
>
Depending on endianness, you can define either

BLK 1+ CONSTANT IN   or    IN 1+ CONSTANT BLK

No need to do the 1+ on every fetch.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#58689

David Schultz wrote:
> On 05/02/2017 07:43 PM, HAA wrote:
>
> > There's no bug.  When referencing a disk block, BLK is 16 bits.
> > However as BLK and IN represent 3 contiguous bytes, a mix of
> > C@ C! ! @ were needed to save/restore/zero both BLK and IN.
> >
>
> How does that work?
>
> If BLK is zero then input is from the terminal. This implies that the
> high byte of IN is also zero. Which would be fine.
>
> But if BLK is non-zero then IN cannot be used as is to index into the
> block. Something else must be done. It could be as simple as "IN 1+ C@"
> but that means that the code to interpret a disk block is different from
> the code to interpret a line from the terminal.

QUIT suggests TIB is 80 chars in which case BLK= 16 bits, IN= 8 bits
would work without fuss.  There must however be an 'other' reason IN
was defined as a 16 bit entry (Appendix A Tech Manual).

>
> Kind of making that saving one byte of user variable storage moot.

microFORTH is like SwiftX in that target apps will likely never use
BLK IN WORD BLOCK etc (the code for these don't reside in the
nucleus).  You then have an incentive to keep user area to a
minimum e.g. BASE is 1 byte.

>
> Of course if ALL of the code were present we could see how it is done.

That or a disk dump.  Addresses for the nucleus routines 00-01FF are
given in screens 51/52.  Headers, interpreter and other code will be
residing elsewhere.

[toc] | [prev] | [next] | [standalone]

#58684

On 05/01/2017 08:20 PM, Elizabeth D. Rather wrote:
> Um, no, actually, this is all of it, including the assembler, compiler,
> text editor, source printing utility, metacompiler, and code for the
> kernel. We wrote a bunch of completed applications with it.

I don't see any code for the kernel, source or binary. I see a screen
with addresses for a bunch of code in the first block but nothing else.
For example, CZ is at address 0xff but what code is there?

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

[toc] | [prev] | [next] | [standalone]

#58480

David Schultz <abuse@127.0.0.1> wrote:
> On 04/25/2017 03:15 AM, JUERGEN wrote:
>> microFORTH documentation is available on the FORTH, INC. website. Not
>> a new product - but many here will probably remember it. And might
>> have a look after many years ...
>> 
> 
> I don't know how useful it is, unless you want examples of bugs.
> 
> It starts off with the definition of LOAD:
> 
> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
>    BLK ! INTERPRET R> IN ! R> BLK C! ;
> 
> The value in BLK is saved and restored using C@ and C! yet it has to
> have a larger range than that and the new value is set using !.

From what I remember COSMAC disk drives were about 80k bytes.

> Plus most of the code is missing.

MicroFORTH shipped with a precompiled nucleus of less than a kbyte and
the rest of system built on top of that.  I think Maj. Seltzer had
more than just MicroFORTH.

Andrew.

[toc] | [prev] | [next] | [standalone]

#58481

Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> David Schultz <abuse@127.0.0.1> wrote:
>> On 04/25/2017 03:15 AM, JUERGEN wrote:
>>> microFORTH documentation is available on the FORTH, INC. website. Not
>>> a new product - but many here will probably remember it. And might
>>> have a look after many years ...
>>> 
>> 
>> I don't know how useful it is, unless you want examples of bugs.
>> 
>> It starts off with the definition of LOAD:
>> 
>> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
>>    BLK ! INTERPRET R> IN ! R> BLK C! ;
>> 
>> The value in BLK is saved and restored using C@ and C! yet it has to
>> have a larger range than that and the new value is set using !.
> 
> From what I remember COSMAC disk drives were about 80k bytes.

Never mind that answer: the correct one followed later.

Andrew.

[toc] | [prev] | [next] | [standalone]

#58488

On Tuesday, May 2, 2017 at 11:11:33 AM UTC+2, Andrew Haley wrote:
> David Schultz <abuse@127.0.0.1> wrote:
> > On 04/25/2017 03:15 AM, JUERGEN wrote:
> >> microFORTH documentation is available on the FORTH, INC. website. Not
> >> a new product - but many here will probably remember it. And might
> >> have a look after many years ...
> >> 
> > 
> > I don't know how useful it is, unless you want examples of bugs.
> > 
> > It starts off with the definition of LOAD:
> > 
> > : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
> >    BLK ! INTERPRET R> IN ! R> BLK C! ;
> > 
> > The value in BLK is saved and restored using C@ and C! yet it has to
> > have a larger range than that and the new value is set using !.
> 
> From what I remember COSMAC disk drives were about 80k bytes.
> 
> > Plus most of the code is missing.
> 
> MicroFORTH shipped with a precompiled nucleus of less than a kbyte and
> the rest of system built on top of that.  I think Maj. Seltzer had
> more than just MicroFORTH.
> 
> Andrew.

Hi Andrew,

IIRC the COSMAC had two 160K 8 inch floppies.

OMG this was 39 years ago...
If I am correct this is longer retention than some FLASH chips and all CDs...
Of course I may have dropped a bit or two ;-)

Cheers,
Howerd

[toc] | [prev] | [next] | [standalone]

#58536

On 5/2/17 2:25 AM, Howerd wrote:
> On Tuesday, May 2, 2017 at 11:11:33 AM UTC+2, Andrew Haley wrote:
>> David Schultz <abuse@127.0.0.1> wrote:
>>> On 04/25/2017 03:15 AM, JUERGEN wrote:
>>>> microFORTH documentation is available on the FORTH, INC. website. Not
>>>> a new product - but many here will probably remember it. And might
>>>> have a look after many years ...
>>>>
>>>
>>> I don't know how useful it is, unless you want examples of bugs.
>>>
>>> It starts off with the definition of LOAD:
>>>
>>> : LOAD BLK C@ <R IN @ <R 0 IN ! 8* OFFSET @ + F9F DROP
>>>    BLK ! INTERPRET R> IN ! R> BLK C! ;
>>>
>>> The value in BLK is saved and restored using C@ and C! yet it has to
>>> have a larger range than that and the new value is set using !.
>>
>> From what I remember COSMAC disk drives were about 80k bytes.
>>
>>> Plus most of the code is missing.
>>
>> MicroFORTH shipped with a precompiled nucleus of less than a kbyte and
>> the rest of system built on top of that.  I think Maj. Seltzer had
>> more than just MicroFORTH.
>>
>> Andrew.
>
> Hi Andrew,
>
> IIRC the COSMAC had two 160K 8 inch floppies.
>
> OMG this was 39 years ago...
> If I am correct this is longer retention than some FLASH chips and all CDs...
> Of course I may have dropped a bit or two ;-)

Ah, the good old days. My memory of enormous 250K floppies is clearly 
from a later, happier era.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#58686

On 05/02/2017 04:11 AM, Andrew Haley wrote:
> From what I remember COSMAC disk drives were about 80k bytes.
>

The standard 8" SSSD disk at the time was 250K. Which matches precisely
the storage capacity listed in the 1982 RCA Microboards manual for the
CDOS dual disk system.

That and "F9F DROP" (DROP later replaced by MIN) establishes an upper
limit on BLK of 3,999 decimal. DR1 is defined on a later screen to store
2,000 into OFFSET.

Or two disks with 250K each.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web