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

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

PETTIL - a 6502 Forth

Started bychitselb <chitselb@gmail.com>
First post2014-06-29 12:49 -0700
Last post2014-08-06 19:57 -0700
Articles 20 on this page of 102 — 16 participants

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

Contents

  PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-06-29 12:49 -0700
    Re: PETTIL - a 6502 Forth AKK <akk@nospam.org> - 2014-06-29 22:20 +0200
      Re: PETTIL - a 6502 Forth barrym95838@yahoo.com - 2014-06-29 21:32 -0700
        Re: PETTIL - a 6502 Forth AKK <akk@nospam.org> - 2014-06-30 07:55 +0200
          Re: PETTIL - a 6502 Forth "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-30 06:40 -0400
            Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-06-30 09:39 -0700
              Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-06-30 11:43 -0700
                Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-06-30 09:24 -1000
              Re: PETTIL - a 6502 Forth hughaguilar96@yahoo.com - 2014-06-30 15:44 -0700
                Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-06-30 16:42 -0700
          Re: PETTIL - a 6502 Forth barrym95838@yahoo.com - 2014-06-30 07:49 -0700
    Re: PETTIL - a 6502 Forth BruceMcF <agila61@netscape.net> - 2014-06-29 13:51 -0700
      Re: PETTIL - a 6502 Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-30 03:21 -0500
        Re: PETTIL - a 6502 Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-30 11:55 +0000
        Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-06-30 07:29 -0700
      Re: PETTIL - a 6502 Forth Mark Wills <markwills1970@gmail.com> - 2014-06-30 01:48 -0700
      Re: PETTIL - a 6502 Forth trebor.english@gmail.com - 2014-07-01 16:46 -0700
        Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-01 20:46 -0700
          Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-01 21:38 -0700
    Re: PETTIL - a 6502 Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-30 14:02 +0000
      Re: PETTIL - a 6502 Forth BruceMcF <agila61@netscape.net> - 2014-06-30 13:53 -0700
        Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-06-30 17:18 -0700
    Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-04 08:48 -0700
      Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-04 09:23 -0700
        Re: PETTIL - a 6502 Forth Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-04 10:31 -0700
          Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-04 10:49 -0700
            Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-04 11:38 -0700
          Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-04 11:45 -0700
            Re: PETTIL - a 6502 Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-04 23:10 +0000
              Re: PETTIL - a 6502 Forth BruceMcF <agila61@netscape.net> - 2014-07-06 15:39 -0700
                Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-06 15:58 -0700
                  Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-07-06 14:10 -1000
                    Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-06 18:08 -0700
                      Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-06 19:04 -0700
                        Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-06 20:31 -0700
                          Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-07-06 18:26 -1000
                            Re: PETTIL - a 6502 Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-07 10:15 +0000
                          Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-06 21:56 -0700
                            Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-07-06 19:39 -1000
                              Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-07 06:53 -0700
                            Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-06 22:43 -0700
                              Re: PETTIL - a 6502 Forth Coos Haak <chforth@hccnet.nl> - 2014-07-07 13:25 +0200
                              Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-07 07:15 -0700
                                Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-08 19:09 -0700
                                  Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-08 20:52 -0700
                                    Re: PETTIL - a 6502 Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-09 13:56 +0000
                                  Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-08 21:13 -0700
                                    Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-09 04:48 -0700
                                      Re: PETTIL - a 6502 Forth Mark Wills <markwills1970@gmail.com> - 2014-07-09 05:51 -0700
                                        Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-09 06:05 -0700
                                      Re: PETTIL - a 6502 Forth BruceMcF <agila61@netscape.net> - 2014-07-09 20:01 -0700
                                        Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-07-09 21:13 -1000
                                          Re: PETTIL - a 6502 Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-10 08:47 +0000
                                            Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-10 07:24 -0700
                                              Re: PETTIL - a 6502 Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-10 14:34 +0000
                                                Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-10 08:22 -0700
                                              Re: PETTIL - a 6502 Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-10 14:45 +0000
                                                Re: PETTIL - a 6502 Forth BruceMcF <agila61@netscape.net> - 2014-07-10 11:13 -0700
                                                Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-07-10 08:44 -1000
                                                  Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-10 12:34 -0700
                                  Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-07-08 18:27 -1000
                                  Re: PETTIL - a 6502 Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-09 12:51 +0000
                                    Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-09 06:16 -0700
                                      Re: PETTIL - a 6502 Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-09 15:01 +0000
                                        Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-07-09 09:01 -1000
                                        Re: PETTIL - a 6502 Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-09 20:54 +0000
                                      Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-09 10:33 -0700
                      Re: PETTIL - a 6502 Forth hughaguilar96@yahoo.com - 2014-07-06 19:10 -0700
                        Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-06 20:41 -0700
                          Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-06 21:31 -0700
                            Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-06 22:58 -0700
                              Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-07 07:29 -0700
                              Re: PETTIL - a 6502 Forth Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-07 09:30 -0700
                                Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-07 10:04 -0700
                                  Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-07 20:10 -0700
                                    Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-07 21:00 -0700
                                      Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-07 22:24 -0700
                                        Re: PETTIL - a 6502 Forth mhx@iae.nl - 2014-07-07 23:53 -0700
                                        Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-08 06:58 -0700
                                  Re: PETTIL - a 6502 Forth Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-07 21:37 -0700
                          Re: PETTIL - a 6502 Forth hughaguilar96@yahoo.com - 2014-07-06 23:01 -0700
                            Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-06 23:21 -0700
                  Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-06 17:17 -0700
                  Re: PETTIL - a 6502 Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-07 08:54 +0000
          Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-07-04 09:04 -1000
        Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-04 11:42 -0700
          Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-04 12:09 -0700
            Re: PETTIL - a 6502 Forth Mark Wills <markwills1970@gmail.com> - 2014-07-04 12:44 -0700
          Re: PETTIL - a 6502 Forth "Elizabeth D. Rather" <erather@forth.com> - 2014-07-04 09:12 -1000
        Re: PETTIL - a 6502 Forth Coos Haak <chforth@hccnet.nl> - 2014-07-05 03:51 +0200
          Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-04 23:26 -0700
    Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-10 04:18 -0700
      Re: PETTIL - a 6502 Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-07-10 11:42 +0000
      Re: PETTIL - a 6502 Forth BruceMcF <agila61@netscape.net> - 2014-07-11 17:42 -0700
        Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-11 22:44 -0700
          Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-07-12 13:04 -0700
    Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-14 00:55 -0700
    Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-07-18 15:44 -0700
      Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-08-04 10:55 -0700
        Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-08-04 12:52 -0700
          Re: PETTIL - a 6502 Forth chitselb <chitselb@gmail.com> - 2014-08-04 13:06 -0700
            Re: PETTIL - a 6502 Forth bruce.mcfarling@gmail.com - 2014-08-06 19:57 -0700

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#32057 — PETTIL - a 6502 Forth

Fromchitselb <chitselb@gmail.com>
Date2014-06-29 12:49 -0700
SubjectPETTIL - a 6502 Forth
Message-ID<2afc5c79-c840-4ac0-b375-d5a75ecfb724@googlegroups.com>
A few years ago I asked the people here for some help, and I got more of it than I would have imagined.  I'd like to thank everyone who contributed for the part they played.  http://pettil.tumblr.com  http://chitselb.com/files/tiddlypettil.html It is very close to fruition.

The language core dictionary comes in at around 4K.  I am trying to make it recognizable to someone who worked on Forth in the '80s.  Below is an extract from the documentation tiddlywiki

I've had a lot of fun putting PETTIL together, and now I'm getting very close to release.  There is one thing I'm not clear on, and that's whether my virtual memory on cassette tape design is any good (or not).

self-doubt area #1)
The PET has a 1000 character screen, inadequate for editing 1024 byte blocks, at least with the native screen editor that I wanted to use.  It will eventually have the ability to load from sequential files too, but I wanted a screen editor.  My compromise was metadata, and I'm not entirely unhappy with it even though it lacks the spirit of purity that I remember from my early 
Forth days.  

self-doubt area #2)
There's PKT, SCR, and BLK.  I'm pretty sure I need BLK to tell INTERPRET if we're using the terminal or loading source from mass storage, but I might be able to get rid of either PKT or SCR

self-doubt area #3)
I'm planning to treat screen-shaped blocks in the same way as Commodore BASIC, with 40/80 line terminations as whitespace.  It would seem more natural on this machine.  The linewrap information is already carried in a screen block.

I'd appreciate any comments, positive or critical.

Virtual memory words

    BUFFER ( u - addr )
    Returns the addr of BUFFER and sets PKT=u. No packet is created in VMBUF until UPDATE occurs, and no initialization of BUFFER occurs.

    BLOCK ( u - addr )
    Unpacks the requested block from VMBUF to BUFFER, creating it and any lower-numbered blocks if necessary. BUFFER is first filled with spaces.

    RLENCODE ( source dest srcsize - finaldest flag )
    Performs a run-length encoding operation on the region of memory between source and (source+srcsize) with the output delivered to dest. The finaldest returned is the next available address following the compressed data, and flag indicates if RLENCODE was unable (flag=true) to compress the data smaller than its original size, and was simply copied. Compressed data returns flag=false.

    RLDECODE ( source dest srcsize - finaldest )
    Uncompresses srcsize bytes of data beginning at source, delivering the output at dest.

    UPDATE ( - )
    commits the current PACKET to the VMBUF

    RENEW ( - )
    RENEW is the antonym of UPDATE, and will reload the BUFFER or the VIDRAM

    VMBUF ( - addr )
    User Variable
    The bottom address of the virtual memory buffer. The buffer grows downward, and is always marked by a zero-word at the tail.

    #PKTS ( - addr )
    User Variable
    The current number of packets in VMBUF. EMPTY-BUFFERS resets this to zero.

    PKT ( - addr )
    User Variable
    The subject of UPDATE and RENEW

    SCR ( - addr )
    User Variable
    Current screen. The screen most recently edited or listed. SCR might hold the block number of a data packet, but the editor views data packets in read-only mode. Writable screen packets are commited to the VMBUF (by UPDATE) when the user navigates away from the screen in the editor or exits the editor.

    EDITING? ( - addr )
    User Variable
    True if new blocks are created as screens, false creates them as data

    VIDRAM ( - $8000 )
    Constant
    The address of the upper left corner of the screen, the start of the memory-mapped video area

    SAVE-BUFFERS ( - )
    Writes the memory between VMBUF and BUFFER out to tape via the kernel SAVE routine.

    LOAD-BUFFERS ( - )
    Searches on the DRV# device for the named file stored in FILENAME and reads it in at PAD, initially. After LOAD completes, the memory will be moved to just below BUFFER, then VMBUF and #PKTS will be set to reflect what was loaded. If FILENAME is off, or the length is zero, LOAD-BUFFERS will read the next file.

    EMPTY-BUFFERS ( - )
    Empties the virtual memory packet buffer by setting VMBUF to BUFFER-2 and storing a zero there, and resets #PKTS to zero.

    FLUSH ( - )
    performs SAVE-BUFFERS then EMPTY-BUFFERS

    FILENAME ( - addr )
    User Variable
    The address of a counted string. The first 16 characters is the filename for SAVE-BUFFERS or LOAD-BUFFERS

    DRV# ( - addr )
    User Variable
    Contains the current device number for SAVE-BUFFERS and LOAD-BUFFERS. The default value is 1 (cassette #1)

General

There is a single 1K BUFFER located directly below the symbol table (or below MEMSIZ when the Transient dictionary and symbols aren't present). During UPDATE, the original contents of BUFFER are not overwritten by their compressed counterpart. Instead, RLENCODE uses a separate 1K region directly below VMBUF.
Creating blocks

The packet (BLOCK) number is implicit by that packet's position within VMBUF. The packet header stored at BUFFER-2 is for packet 0, and packets build downward from there. BLOCK and UPDATE can't refer to a packet that doesn't exist, so when a packet is referenced by BLOCK or the BUFFER is committed to VMBUF by UPDATE, new packets may need to be created. If EDITING? is false, all newly created blocks will be data packets, otherwise they will be screen packets

[toc] | [next] | [standalone]

#32058

FromAKK <akk@nospam.org>
Date2014-06-29 22:20 +0200
Message-ID<53b0750a$0$6654$9b4e6d93@newsspool3.arcor-online.net>
In reply to#32057
Am 29.06.2014 21:49, schrieb chitselb:
> A few years ago I asked the people here for some help, and I got more of it than I would have imagined.  I'd like to thank everyone who contributed for the part they played.  http://pettil.tumblr.com  http://chitselb.com/files/tiddlypettil.html It is very close to fruition.
>
> The language core dictionary comes in at around 4K.  I am trying to make it recognizable to someone who worked on Forth in the '80s.  Below is an extract from the documentation tiddlywiki
>
> I've had a lot of fun putting PETTIL together, and now I'm getting very close to release.  There is one thing I'm not clear on, and that's whether my virtual memory on cassette tape design is any good (or not).
>
> self-doubt area #1)
> The PET has a 1000 character screen, inadequate for editing 1024 byte blocks, at least with the native screen editor that I wanted to use.  It will eventually have the ability to load from sequential files too, but I wanted a screen editor.  My compromise was metadata, and I'm not entirely unhappy with it even though it lacks the spirit of purity that I remember from my early
> Forth days.
>
> self-doubt area #2)
> There's PKT, SCR, and BLK.  I'm pretty sure I need BLK to tell INTERPRET if we're using the terminal or loading source from mass storage, but I might be able to get rid of either PKT or SCR
>
> self-doubt area #3)
> I'm planning to treat screen-shaped blocks in the same way as Commodore BASIC, with 40/80 line terminations as whitespace.  It would seem more natural on this machine.  The linewrap information is already carried in a screen block.
>
> I'd appreciate any comments, positive or critical.
>
> Virtual memory words
>
>      BUFFER ( u - addr )
>      Returns the addr of BUFFER and sets PKT=u. No packet is created in VMBUF until UPDATE occurs, and no initialization of BUFFER occurs.
>
>      BLOCK ( u - addr )
>      Unpacks the requested block from VMBUF to BUFFER, creating it and any lower-numbered blocks if necessary. BUFFER is first filled with spaces.
>
>      RLENCODE ( source dest srcsize - finaldest flag )
>      Performs a run-length encoding operation on the region of memory between source and (source+srcsize) with the output delivered to dest. The finaldest returned is the next available address following the compressed data, and flag indicates if RLENCODE was unable (flag=true) to compress the data smaller than its original size, and was simply copied. Compressed data returns flag=false.
>
>      RLDECODE ( source dest srcsize - finaldest )
>      Uncompresses srcsize bytes of data beginning at source, delivering the output at dest.
>
>      UPDATE ( - )
>      commits the current PACKET to the VMBUF
>
>      RENEW ( - )
>      RENEW is the antonym of UPDATE, and will reload the BUFFER or the VIDRAM
>
>      VMBUF ( - addr )
>      User Variable
>      The bottom address of the virtual memory buffer. The buffer grows downward, and is always marked by a zero-word at the tail.
>
>      #PKTS ( - addr )
>      User Variable
>      The current number of packets in VMBUF. EMPTY-BUFFERS resets this to zero.
>
>      PKT ( - addr )
>      User Variable
>      The subject of UPDATE and RENEW
>
>      SCR ( - addr )
>      User Variable
>      Current screen. The screen most recently edited or listed. SCR might hold the block number of a data packet, but the editor views data packets in read-only mode. Writable screen packets are commited to the VMBUF (by UPDATE) when the user navigates away from the screen in the editor or exits the editor.
>
>      EDITING? ( - addr )
>      User Variable
>      True if new blocks are created as screens, false creates them as data
>
>      VIDRAM ( - $8000 )
>      Constant
>      The address of the upper left corner of the screen, the start of the memory-mapped video area
>
>      SAVE-BUFFERS ( - )
>      Writes the memory between VMBUF and BUFFER out to tape via the kernel SAVE routine.
>
>      LOAD-BUFFERS ( - )
>      Searches on the DRV# device for the named file stored in FILENAME and reads it in at PAD, initially. After LOAD completes, the memory will be moved to just below BUFFER, then VMBUF and #PKTS will be set to reflect what was loaded. If FILENAME is off, or the length is zero, LOAD-BUFFERS will read the next file.
>
>      EMPTY-BUFFERS ( - )
>      Empties the virtual memory packet buffer by setting VMBUF to BUFFER-2 and storing a zero there, and resets #PKTS to zero.
>
>      FLUSH ( - )
>      performs SAVE-BUFFERS then EMPTY-BUFFERS
>
>      FILENAME ( - addr )
>      User Variable
>      The address of a counted string. The first 16 characters is the filename for SAVE-BUFFERS or LOAD-BUFFERS
>
>      DRV# ( - addr )
>      User Variable
>      Contains the current device number for SAVE-BUFFERS and LOAD-BUFFERS. The default value is 1 (cassette #1)
>
> General
>
> There is a single 1K BUFFER located directly below the symbol table (or below MEMSIZ when the Transient dictionary and symbols aren't present). During UPDATE, the original contents of BUFFER are not overwritten by their compressed counterpart. Instead, RLENCODE uses a separate 1K region directly below VMBUF.
> Creating blocks
>
> The packet (BLOCK) number is implicit by that packet's position within VMBUF. The packet header stored at BUFFER-2 is for packet 0, and packets build downward from there. BLOCK and UPDATE can't refer to a packet that doesn't exist, so when a packet is referenced by BLOCK or the BUFFER is committed to VMBUF by UPDATE, new packets may need to be created. If EDITING? is false, all newly created blocks will be data packets, otherwise they will be screen packets
>

Surely you know this:
http://6502.org/source/forth65.zip

BTW vintage Forths had 16x64 byte screens (1k size that fit nicely to 
the 512b blocks of BIOS file system chunks)

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

#32064

Frombarrym95838@yahoo.com
Date2014-06-29 21:32 -0700
Message-ID<f409047c-86da-4931-9788-305367944d49@googlegroups.com>
In reply to#32058
On Sunday, June 29, 2014 1:20:26 PM UTC-7, AKK wrote:
> 
> Surely you know this:
> 
> http://6502.org/source/forth65.zip
> 
> 
> 
> BTW vintage Forths had 16x64 byte screens (1k size that fit nicely to 
> 
> the 512b blocks of BIOS file system chunks)

@AKK:
 Wow.  That is brutally condescending, and makes no effort whatsoever to
 understand what CH is trying to do here.  It's clearly a labor of love,
 from someone who knows more than a little bit about vintage hardware and
 software.  If I published photos of a 50-year-old car that I customized
 and restored, would you ridicule me for not using the original style
 wheels, or neglecting to add airbags and climate controls?

@CH:
 Nice work, man!  I'd like to try out your "virtuality" game on VICE when
 it's done.

Mike

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

#32065

FromAKK <akk@nospam.org>
Date2014-06-30 07:55 +0200
Message-ID<53b0fbea$0$6621$9b4e6d93@newsspool4.arcor-online.net>
In reply to#32064
Am 30.06.2014 06:32, schrieb barrym95838@yahoo.com:
> On Sunday, June 29, 2014 1:20:26 PM UTC-7, AKK wrote:
>>
>> Surely you know this:
>>
>> http://6502.org/source/forth65.zip
>>
>>
>>
>> BTW vintage Forths had 16x64 byte screens (1k size that fit nicely to
>>
>> the 512b blocks of BIOS file system chunks)
>
> @AKK:
>   Wow.  That is brutally condescending, and makes no effort whatsoever to
>   understand what CH is trying to do here.  It's clearly a labor of love,
>   from someone who knows more than a little bit about vintage hardware and
>   software.  If I published photos of a 50-year-old car that I customized
>   and restored, would you ridicule me for not using the original style
>   wheels, or neglecting to add airbags and climate controls?
>
> @CH:
>   Nice work, man!  I'd like to try out your "virtuality" game on VICE when
>   it's done.
>
> Mike
>

Your own response is "brutally condescending". I just wanted to help 
with information. That's it, you quick shooting man.

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

#32070

From"Rod Pemberton" <dont_use_email@xnothavet.cqm>
Date2014-06-30 06:40 -0400
Message-ID<op.xh9jw4r46zenlw@localhost>
In reply to#32065
On Mon, 30 Jun 2014 01:55:55 -0400, AKK <akk@nospam.org> wrote:

> I just wanted to help with information.

Hopefully, he's aware of these sources as well:

fig-Forth 6502 pdf
www.forth.org/fig-forth/fig-forth_6502.pdf

"32-bit DO LOOP material for 65co2 ITC Forth" by Garth Wilson
http://wilsonminesco.com/Forth/32DOLOOP.FTH


No 6502, but other 8-bit versions with diagrams and source.
It should be easy to understand the diagrams and hopefully
the instructions for other processors.

"Moving Forth" by Brad Rodriguez
http://www.bradrodriguez.com/papers/index.html


Rod Pemberton

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

#32076

Fromchitselb <chitselb@gmail.com>
Date2014-06-30 09:39 -0700
Message-ID<699ba8ed-eb36-4cba-a72f-778e4a8da815@googlegroups.com>
In reply to#32070
On Monday, June 30, 2014 6:40:06 AM UTC-4, Rod Pemberton wrote:
> On Mon, 30 Jun 2014 01:55:55 -0400, AKK <akk@nospam.org> wrote:
> 
> 
> 
> > I just wanted to help with information.
> 
> 
> 
> Hopefully, he's aware of these sources as well:
> 
> 
> 
> fig-Forth 6502 pdf
> 
> www.forth.org/fig-forth/fig-forth_6502.pdf
> 
> 
> 
> "32-bit DO LOOP material for 65co2 ITC Forth" by Garth Wilson
> 
> http://wilsonminesco.com/Forth/32DOLOOP.FTH
> 
> 
> 
> 
> 
> No 6502, but other 8-bit versions with diagrams and source.
> 
> It should be easy to understand the diagrams and hopefully
> 
> the instructions for other processors.
> 
> 
> 
> "Moving Forth" by Brad Rodriguez
> 
> http://www.bradrodriguez.com/papers/index.html
> 
> 
> 
> 
> 
> Rod Pemberton

Brad R's "Moving Forth" was a huge inspiration. That's what led me to a direct-threaded code model, and possibly to waking the project up in the first place.  The inner interpreter is 15 clocks:  INC IP; INC IP; JMP (IP) and relies on the compiler inserting calls to the word PAGE (which performs INC IP+1) at $xxFD or $xxFE memory locations.  This gets around the 6502's notorious JMP ($xxFF) indirect jmp bug.

Also http://www.dwheeler.com/6502/ gave me the idea for the split stack.  The jury is still out on whether that's faster than a 16-bit wide stack.  I haven't implemented both approaches and run benchmarks on a "fair mix" of stack manipulation primitives.

The PETTIL screen editor is the native PET (or C=64) screen editor that you get when you turn on the machine.  A "screen" is a structure with 24 bits of line wrap information (whether a line is 40 or 80 columns, with the line 0 bit being always "1").  Blazin' Forth on the C=64 used the Leo Brodie "Starting Forth" editor and did 64-character lines, but I'm really okay with limiting source screens to 1000 characters and having them conform to the natural screen of the PET.  I can't imagine what wrapping at column 32 and having a screen spread across two screens, to get 64x16, would feel like, but I'm definitely not going that way.

area of self-doubt #4)
I'm only using one block buffer.  Can a case be made that two are required?  I thought about
0 BLOCK  1 BLOCK  1024  CMOVE
which could be written as 
0 BLOCK  PAD  1024  CMOVE  PAD  1 BLOCK  1024  CMOVE

The tape is less of a drawback because "packets" of RLE-compressed blocks are stored in a sort of RAMdisk structure growing down from the top of memory, and are loaded and saved to tape or disk in "batches" as PRG files.  When things get tighter (as dictionary grows north and source grows south) just use smaller batches.

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

#32077

Frombruce.mcfarling@gmail.com
Date2014-06-30 11:43 -0700
Message-ID<9551c7d3-dac7-4e77-95b9-79bd62b8accd@googlegroups.com>
In reply to#32076
On Monday, June 30, 2014 12:39:43 PM UTC-4, chitselb wrote:


> Brad R's "Moving Forth" was a huge inspiration. That's what led me to a direct-threaded code model, and possibly to waking the project up in the first place.  The inner interpreter is 15 clocks:  INC IP; INC IP; JMP (IP) and relies on the compiler inserting calls to the word PAGE (which performs INC IP+1) at $xxFD or $xxFE memory locations.  This gets around the 6502's notorious JMP ($xxFF) indirect jmp bug.

Yeah, I call that "PAGEFIX". The other way around the ($xxFF) bug is to align the compiled definitions, which also allows the PAGEFIX to be embedded in the NEXT, at the cost (normally) of a 17 cycle NEXT:
NEXT:
   INC IP ; with aligned IP will be odd
   INC IP ; this may cross a page
   BNE PAGEFIX
NEXT1:
   JMP (IP)
PAGEFIX:
   INC IP+1
   BNE NEXT1
   BRK

If you have space in zero page (eg, with a wedge), there's no need to align, though its two more cycles and a bigger zero page routine with unaligned code:

NEXT:
   INC NEXT1+1
   BNE PGFIX1
   INC NEXT1+1
   BNE PGFIX2
NEXT1
   JMP COLDD ; NB. self-writing code
PGFIX1:
   INC NEXT1+1
PGFIX2:
   INC NEXT1+2
   BNE NEXT1
   BRK

But I like the NEXT you use, its very clean.

> Also http://www.dwheeler.com/6502/ gave me the idea for the split stack.  The jury is still out on whether that's faster than a 16-bit wide stack.

Hardware stack for one and ,X or ,Y indexed split stack for the other is pretty sure to be faster, unless you have an X-indexed zero-page return stack with the IP on the top of the return stack. But that's also self-writing code, with ENTER and EXIT doing the writing so that the vector address of the JMP (IP) instruction is pointing to the top of the return stack. If the X-index is pointing to the actual zero page address (that is, 0,X and (0,X)), then that is just storing the X register after adjusting it.


> The PETTIL screen editor is the native PET (or C=64) screen editor that you get when you turn on the machine.  A "screen" is a structure with 24 bits of line wrap information (whether a line is 40 or 80 columns, with the line 0 bit being always "1").  Blazin' Forth on the C=64 used the Leo Brodie "Starting Forth" editor and did 64-character lines, but I'm really okay with limiting source screens to 1000 characters and having them conform to the natural screen of the PET.

Its only an issue with cross-platform development. If its all going to be on the PET itself, its all good.

> I can't imagine what wrapping at column 32 and having a screen spread across two screens, to get 64x16, would feel like, but I'm definitely not going that way.

It would be to get 32x32 ... for 32x32, it's a lot like working in a windowed system on something that is more than one display window's worth but less than two.

The convenience of a 32x32 display/edit screen when looking at the block on a 64x16 system is that it shows up as
   Row0   Row1
   Row2   Row3
...
   Row31  Row32

... which is a lot easier to work out what is going on than with the staggered row effect if 25x40. But if you're never going to be looking at a block on a 64x16 system, it doesn't matter.

Wrapping at column 32 for a 64x16 would be if you wanted to use the left column 32x16 for source and the right column 32x16 for comments, and you'd put a "flip between left and right" on one of the function keys. That would be like a poor man's shadow screens, and having them in the same block would work better for your system.

> area of self-doubt #4)
 
> I'm only using one block buffer.  Can a case be made that two are required?  
> I thought about 
> 0 BLOCK  1 BLOCK  1024  CMOVE
> 
> which could be written as 
> 0 BLOCK  PAD  1024  CMOVE  PAD  1 BLOCK  1024  CMOVE

Two are handier. They not only simplify block copy, but they allow a script to running in one block which operates on another block or set of blocks as data blocks.

The more block buffers, the better (the C64 fig Forth I had put the buffers between the BASIC ROM and the I/O addresses, so I had four), but from one to two is the biggest step up in convenience.


> The tape is less of a drawback because "packets" of RLE-compressed blocks are stored in a sort of RAMdisk structure growing down from the top of memory, and are loaded and saved to tape or disk in "batches" as PRG files.  When things get tighter (as dictionary grows north and source grows south) just use smaller batches.

That's really stylish. Luckily I never had to work around the limits of a tape drive.

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

#32078

From"Elizabeth D. Rather" <erather@forth.com>
Date2014-06-30 09:24 -1000
Message-ID<PMWdnVTomrjEJCzOnZ2dnUVZ_sydnZ2d@supernews.com>
In reply to#32077
On 6/30/14 8:43 AM, bruce.mcfarling@gmail.com wrote:
>> I'm only using one block buffer.  Can a case be made that two are required?
>> >I thought about
>> >0 BLOCK  1 BLOCK  1024  CMOVE
>> >
>> >which could be written as
>> >0 BLOCK  PAD  1024  CMOVE  PAD  1 BLOCK  1024  CMOVE
> Two are handier. They not only simplify block copy, but they allow a script to running in one block which operates on another block or set of blocks as data blocks.
>
> The more block buffers, the better (the C64 fig Forth I had put the buffers between the BASIC ROM and the I/O addresses, so I had four), but from one to two is the biggest step up in convenience.


Our experience "back in the day" was that one is untenable. Bruce is 
right, the more the better. And you should regard two as a minimum.

Cheers,
Elizabeth


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#32085

Fromhughaguilar96@yahoo.com
Date2014-06-30 15:44 -0700
Message-ID<4044d7de-5aef-404f-a4c8-41d1180102c0@googlegroups.com>
In reply to#32076
On Monday, June 30, 2014 9:39:43 AM UTC-7, chitselb wrote:
> Brad R's "Moving Forth" was a huge inspiration. That's what led me to a direct-threaded code model, and possibly to waking the project up in the first place.  The inner interpreter is 15 clocks:  INC IP; INC IP; JMP (IP) and relies on the compiler inserting calls to the word PAGE (which performs INC IP+1) at $xxFD or $xxFE memory locations.  This gets around the 6502's notorious JMP ($xxFF) indirect jmp bug.
> 
> Also http://www.dwheeler.com/6502/ gave me the idea for the split stack.  The jury is still out on whether that's faster than a 16-bit wide stack.  I haven't implemented both approaches and run benchmarks on a "fair mix" of stack manipulation primitives.

I wrote a Forth cross-compiler for the 65c02 that was based on ISYS Forth. This was subroutine-threaded and used a split parameter stack. I had not been aware of any other 6502 Forth that used a split parameter stack, so I was surprised to see the idea mentioned in that article that you provided the link for --- are you aware of any implementation that does this?

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

#32088

Fromchitselb <chitselb@gmail.com>
Date2014-06-30 16:42 -0700
Message-ID<9c46844d-8376-4a15-874f-ecae8da3085a@googlegroups.com>
In reply to#32085
On Monday, June 30, 2014 6:44:20 PM UTC-4, hughag...@yahoo.com wrote:
> On Monday, June 30, 2014 9:39:43 AM UTC-7, chitselb wrote:
> 
> > Brad R's "Moving Forth" was a huge inspiration. That's what led me to a direct-threaded code model, and possibly to waking the project up in the first place.  The inner interpreter is 15 clocks:  INC IP; INC IP; JMP (IP) and relies on the compiler inserting calls to the word PAGE (which performs INC IP+1) at $xxFD or $xxFE memory locations.  This gets around the 6502's notorious JMP ($xxFF) indirect jmp bug.
> 
> > 
> 
> > Also http://www.dwheeler.com/6502/ gave me the idea for the split stack.  The jury is still out on whether that's faster than a 16-bit wide stack.  I haven't implemented both approaches and run benchmarks on a "fair mix" of stack manipulation primitives.
> 
> 
> 
> I wrote a Forth cross-compiler for the 65c02 that was based on ISYS Forth. This was subroutine-threaded and used a split parameter stack. I had not been aware of any other 6502 Forth that used a split parameter stack, so I was surprised to see the idea mentioned in that article that you provided the link for --- are you aware of any implementation that does this?

My experience with different implementations is very limited:
R.G. Loeliger's hypothetical Z80 Forth (which I never saw running)
Various implementations described in early '80s books (same story)
MMSforth circa 1984 on TRS-80 Model 4
Blazin' Forth, late '80s on a C=64
something we got going on the VAX from SIG tapes in 1989
a little F83.exe
a little Palm Pilot Forth
some gforth
FigForth 1.1 on the PET found at http://www.idealine.info/CBM/forth.d82

This PETTIL project is my first attempt at an implementation, and I've got to say, I have really learned a lot and had incredible fun with it.

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

#32075

Frombarrym95838@yahoo.com
Date2014-06-30 07:49 -0700
Message-ID<eaf896f9-1e50-46bb-a5fd-72af81d9d48b@googlegroups.com>
In reply to#32065
On Sunday, June 29, 2014 10:55:55 PM UTC-7, AKK wrote:
> 
> Your own response is "brutally condescending". I just wanted to help 
> with information.

I totally mis-interpreted your tone in your original post; I apologize.
That is a nice, clean-looking fig source at your link, I have to admit.

> 
> That's it, you quick shooting man.

Dang it, my wife has been blabbing to her friends again ... ;-)

Mike

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

#32059

FromBruceMcF <agila61@netscape.net>
Date2014-06-29 13:51 -0700
Message-ID<f3117fed-5596-4090-bca3-ed19b9a66a66@googlegroups.com>
In reply to#32057
On Sunday, June 29, 2014 3:49:50 PM UTC-4, chitselb wrote:
> The PET has a 1000 character screen, inadequate for editing 1024 byte blocks, at least with the native screen editor that I wanted to use.

My first Forth back in the early 80's was a 6502 fig-Forth adapted to the 1000 character screen of the Pet's mass market cousin, the C64.

AFAIR, the adaptation was that it had 1024 character blocks, but 1000 was display in normal edit mode with the 24 (at the end, maybe?) normally left blank or used for an index comment. It was a headache porting block-oriented source from 64x16 to 40x25.

If it was me, I'd go with a standard 1024 block and instead of using a 40x25 layout on the full screen editor, use a 32x32 layout and toggle between:

  + --------------------------------+
00|
  |
01|
  |
02|
...
11|
  |

... when in the top half and then, when cursoring down from (normal) block row 11 (zero base), switch to:

00|

05|
  |
06|
  |
...
14|
  |
15|
  |
  + --------------------------------+

... and from there, flip back to the first if you cursor up from "row 5" (zero base).

I'd reckon keeping the front of the index row on screen and having the difference between top half and bottom half jump out immediately is more critical than having that extra line available in the bottom half display.

Then if you treat \ as skipping to the next *numbered* line, you have block source that could be loaded on modern PC for more rapid development cycle on things that do not need to be on a PET for testing.

If you just program in 32 by 32 rows leaving the final column blank, then when shown by a standard Forth94 system, it'll be in a double column effect, which is not perfect, but is a lot easier to work out what is going on than looking at the old C64 "40x25+24extra" blocks ever was. And except for PET system specific words, if you have \ skip to the "next even row" in the PETTIL, it at least stands a chance of loading and running.

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

#32066

FromAndrew Haley <andrew29@littlepinkcloud.invalid>
Date2014-06-30 03:21 -0500
Message-ID<T6qdnSM4U-O6gyzOnZ2dnUVZ_o6dnZ2d@supernews.com>
In reply to#32059
BruceMcF <agila61@netscape.net> wrote:

>> On Sunday, June 29, 2014 3:49:50 PM UTC-4, chitselb wrote:

>> The PET has a 1000 character screen, inadequate for editing 1024
>> byte blocks, at least with the native screen editor that I wanted
>> to use.
> 
> My first Forth back in the early 80's was a 6502 fig-Forth adapted
> to the 1000 character screen of the Pet's mass market cousin, the
> C64.
> 
> AFAIR, the adaptation was that it had 1024 character blocks, but
> 1000 was display in normal edit mode with the 24 (at the end,
> maybe?) normally left blank or used for an index comment. It was a
> headache porting block-oriented source from 64x16 to 40x25.

I had no difficulty at all; I don't even know there was aproblem.

The PET ROM has a full line editor: you just move the cursor around
the screen and press enter when done.  It copes well with lines that
are too long for 40 columns: it wraps them, and for editing purposes a
wrapped line is treated as a single line.  On my PET Forth, EXPECT
called this line editor routine.

My LIST began each line with "0:" or "12:" or whatever.  I defined 0:
through to 15: as words in the EDITOR vocabulary that entered the
edited line into the current block.  This worked fine with all of the
fig-FORTH source I came across and was simpler and easier to use than
most Forth editors of the time.

Andrew.

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

#32071

Fromalbert@spenarnc.xs4all.nl (Albert van der Horst)
Date2014-06-30 11:55 +0000
Message-ID<53b15016$0$4669$e4fe514c@dreader36.news.xs4all.nl>
In reply to#32066
In article <T6qdnSM4U-O6gyzOnZ2dnUVZ_o6dnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>BruceMcF <agila61@netscape.net> wrote:
>
>>> On Sunday, June 29, 2014 3:49:50 PM UTC-4, chitselb wrote:
>
>>> The PET has a 1000 character screen, inadequate for editing 1024
>>> byte blocks, at least with the native screen editor that I wanted
>>> to use.
>>
>> My first Forth back in the early 80's was a 6502 fig-Forth adapted
>> to the 1000 character screen of the Pet's mass market cousin, the
>> C64.
>>
>> AFAIR, the adaptation was that it had 1024 character blocks, but
>> 1000 was display in normal edit mode with the 24 (at the end,
>> maybe?) normally left blank or used for an index comment. It was a
>> headache porting block-oriented source from 64x16 to 40x25.
>
>I had no difficulty at all; I don't even know there was aproblem.
>
>The PET ROM has a full line editor: you just move the cursor around
>the screen and press enter when done.  It copes well with lines that
>are too long for 40 columns: it wraps them, and for editing purposes a
>wrapped line is treated as a single line.  On my PET Forth, EXPECT
>called this line editor routine.
>
>My LIST began each line with "0:" or "12:" or whatever.  I defined 0:
>through to 15: as words in the EDITOR vocabulary that entered the
>edited line into the current block.  This worked fine with all of the
>fig-FORTH source I came across and was simpler and easier to use than
>most Forth editors of the time.

It wasn't hard to make a full screen editor for blocks in MSDOS/DPMI.
Meaning: control characters for commands, other character for inserting or
overwriting.

Being used to wordstar (original IBM) commands I used those as the base
Most screens have more than 16 lines. So I made deleted lines stack up
at the bottom of the screen for undeletion. So handy!
I show the command set here. Is really complete and swift.

\-----------------------------------------
    A screen is copied to the video screen. When you exit, what
    you see within the blue cadre, is copied back into the screen.
    This editor has Wordstar compatible commands. No function key
    works, only control keys.
^V  Toggle insert-overwrite.
^E ^S ^D ^X <Enter> <Tab> : Cursor up left right down. Next line. Tab.
^A ^F : Cursor word left, right.
^G ^T ^Y : Delete char, word, line.
^Z ^U : Undelete word, line.
^W ^P : Undelete word and pop. Undelete line and pop.
^J ^O : Join lines, Open (split) line.
ESC Q / ESC q : quit (abondon edit and do not update.)
ESC x (or whatever, not q): exit editing, save and update.

Word and line deletes stack up at the bottom of the
    screen. ^P and ^W pop this stack. In all other case the last
    deleted item remains available for multiple undeletes.
    Editing outside of the blue cadre allows useful tricks.
Small sequences perform useful actions:
    swap lines ^Y ^E ^P.
    delete line without stacking <ret> ^E ^J ^O
    duplicate line ^Y ^U ^P
\--------------------------------------------------------

The delete-to-stack, with multiple undeletes, and the top item
always being available for undelete, is a feature borrowed from
Edwin's editor.

>
>Andrew.
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#32074

Frombruce.mcfarling@gmail.com
Date2014-06-30 07:29 -0700
Message-ID<9f6f6f8c-23e2-4923-ba86-178dae3958ec@googlegroups.com>
In reply to#32066
On Monday, June 30, 2014 4:21:59 AM UTC-4, Andrew Haley wrote:
> I had no difficulty at all; I don't even know there was a problem.
>
> The PET ROM has a full line editor: you just move the cursor around 
> the screen and press enter when done.  It copes well with lines that
> are too long for 40 columns: it wraps them, and for editing purposes a
> wrapped line is treated as a single line.  On my PET Forth, EXPECT
> called this line editor routine.

It was when people implemented full-screen block editors around the Commodore 40x25 screen that the problem arose (and for that its the same issue, as its not like whoever was selling the fig Forth I bought wrote their own screen editor, they just used an existing PET full screen editor, as up through a certain range the C64 re-used the PET Kernel calls) ~ ie, I was responding to the quotes part of the OP:

"self-doubt area #1)
The PET has a 1000 character screen, inadequate for editing 1024 byte blocks, at least with *the native screen editor* that I wanted to use."

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

#32068

FromMark Wills <markwills1970@gmail.com>
Date2014-06-30 01:48 -0700
Message-ID<2a55ec79-e938-4e07-8a22-8e2536037bb2@googlegroups.com>
In reply to#32059
If your screen can't host 64-column lines, then just 
use a window-shifting technique, like I did in TurboForth:

http://www.youtube.com/watch?v=1bSxUMa_jdw

When the video display is configured for 40 column mode, 
it uses a window shifting techique. If in 80 column mode,
the full 64 columns are (obviously) available and the editor
re-configures itself accordingly.

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

#32105

Fromtrebor.english@gmail.com
Date2014-07-01 16:46 -0700
Message-ID<bbe811e0-a3f8-4ac0-9ee1-825de61cb303@googlegroups.com>
In reply to#32059
On Sunday, June 29, 2014 4:51:53 PM UTC-4, BruceMcF wrote:
> On Sunday, June 29, 2014 3:49:50 PM UTC-4, chitselb wrote:
> 
> > The PET has a 1000 character screen, inadequate for editing 1024 byte blocks, at least with the native screen editor that I wanted to use.
> 
> My first Forth back in the early 80's was a 6502 fig-Forth adapted to the 1000 character screen of the Pet's mass market cousin, the C64.
> 
> AFAIR, the adaptation was that it had 1024 character blocks, but 1000 was display in normal edit mode with the 24 (at the end, maybe?) normally left blank or used for an index comment. It was a headache porting block-oriented source from 64x16 to 40x25.
> 

A different approach is to use a line oriented editor.  I have entered and edited quite a bit of source using an ASR33 Teletype.  Lines too long wrap to two lines on paper and you don't move a cursor around on the paper.  The 16x64 "screen" is in your mind and editing commands are applied in the memory block.  For confirmation you "type" the lines you want to see.  

I found this interactive editing better than punched cards.  I really didn't like the model 29 keypunch.  The Teletype was much better.  The VT52 terminal was better than the Teletype because it was 9600 baud rather than 110.  I still like the line editor.

When using a modem with a noisy line multiple character keys like the cursor positioning keys sometimes don't work when one character gets zapped.  A line oriented editor with single character text commands seemed more reliable to me.

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

#32110

Frombruce.mcfarling@gmail.com
Date2014-07-01 20:46 -0700
Message-ID<49d7932a-6b2a-4c93-801e-16f00c02198a@googlegroups.com>
In reply to#32105
On Tuesday, July 1, 2014 7:46:14 PM UTC-4, trebor....@gmail.com wrote:
> A different approach is to use a line oriented editor.

Certainly. I was responding to Messr chitselb, who elected to implement a screen editor.

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

#32111

Fromchitselb <chitselb@gmail.com>
Date2014-07-01 21:38 -0700
Message-ID<62f9604b-3514-4fdf-9e61-3e7d5b73ac19@googlegroups.com>
In reply to#32110
On Tuesday, July 1, 2014 11:46:14 PM UTC-4, bruce.m...@gmail.com wrote:
> On Tuesday, July 1, 2014 7:46:14 PM UTC-4, trebor....@gmail.com wrote:
> 
> > A different approach is to use a line oriented editor.
> 
> 
> 
> Certainly. I was responding to Messr chitselb, who elected to implement a screen editor.

http://pettil.tumblr.com/post/83629005389/easiest-full-screen-editor-ever

That's what I came up with.  It doesn't mimic any specific editor that I've ever used.  Cut/Copy/Paste is done with complete (40|80 column) lines only.  From the playing around I've done, it feels like "enough."

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

#32073

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2014-06-30 14:02 +0000
Message-ID<2014Jun30.160205@mips.complang.tuwien.ac.at>
In reply to#32057
chitselb <chitselb@gmail.com> writes:
>self-doubt area #1)
>The PET has a 1000 character screen, inadequate for editing 1024 byte block=
>s, at least with the native screen editor that I wanted to use.  It will ev=
>entually have the ability to load from sequential files too, but I wanted a=
> screen editor.  My compromise was metadata, and I'm not entirely unhappy w=
>ith it even though it lacks the spirit of purity that I remember from my ea=
>rly=20
>Forth days. =20

On the C64 with it's 40*25=1000char screen, I use screens in 40x25
format (and ignored the additional 24 bytes).  64-char lines on a 40
wide screen is not practical.  Concerning 64*16 source, I did not have
to deal with that; but if I had to, it still would have worked,
because the text interpreter uses the whole screen as one line and
does not care for how it is formatted (I think we did not have "\"
then, where it makes a difference).

I think blocks are the wrong technology for tape drives, though; they
are intended for disk drives.  I guess you can get ok performance for
loading files if the blocks are arranged in sequence, but once you
make use of random access, performance will be even slower than usual.

>self-doubt area #3)
>I'm planning to treat screen-shaped blocks in the same way as Commodore BAS=
>IC, with 40/80 line terminations as whitespace.  It would seem more natural=
> on this machine.  The linewrap information is already carried in a screen =
>block.

Screens in Forth are just 1024 chars without line breaks, and the text
interpreter does not know about line breaks. If the last char of one
line contains a non-whitespace char, the next line needs to start with
white space, or the stuff will be treated as one word.  It's unclear
to me what you are suggesting above wrt line breaks.

Hmm, you could use the additional 24 bytes to provide extra spaces so
that the last-char problem mentioned above does not happen.  So you
would have (40+1)*24+40 chars (which happily is just 1024 chars).

>    PKT ( - addr )
>    User Variable
>    The subject of UPDATE and RENEW

In fig-Forth UPDATE works on PREV.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web