I've been thinking about trying to do something rather complicated, but
then I stepped back and was like, well, a problem is much more easily
surmountable if I break it down into smaller pieces. So I figured - for a
project I want to do - what would be the best place to start?

The ultimate idea was to try to reimplement Logo - but the part I think
that will give me the best feeling of achievement, and the one most useful
outside of the Logo context, is the Terrapin. So I figured...perhaps the
next step would be to implement the Terrapin as an & library for BASIC:
commands like &FD, &BK, &LT, &RT, &HOME, &ROT= (equivalent to SETHEADING
in Terrapin Logo), &HT, &ST, &PU, &PD, &PE, &X= (SETX), &Y= (SETY), &GOTO
(SETXY), &HGR (to clear the hi-res screen but also redraw the Terrapin);
and a USR() to implement something like Terrapin Logo's TOWARDS. (These
are, afaict, the full suite of graphics commands which is supported by
Terrapin Logo 1.0)

This would prove to be about a pain in the neck, although availing myself
of FPBASIC functionality to implement this would certainly be useful. For
example, the HPOSN and HGLIN functions would mean that actually drawing
lines can be left to FPBASIC (although the actual calculations of the
Terrapin's target position would need to be done in ASM, as well as
implementing the wrapping when the Terrapin goes off the edge of the
screen), and the same code that implements XDRAW could also be used to
draw and undraw the Terrapin.

After that comes the bit of trying to figure out what-all *is* Logo, since
even the manuals I've seen don't even scratch the surface of what it can
do outside of graphics.

-uso.

On Wed, 20 Dec 2023 04:43:25 -0500
Steve Nickolas <usotsuki@buric.co> wrote:

> The ultimate idea was to try to reimplement Logo - but the part I
> think that will give me the best feeling of achievement, and the one
> most useful outside of the Logo context, is the Terrapin. So I
> figured...perhaps the next step would be to implement the Terrapin as
> an & library for BASIC: commands like &FD, &BK, &LT, &RT, &HOME,
> &ROT= (equivalent to SETHEADING in Terrapin Logo), &HT, &ST, &PU,
> &PD, &PE, &X= (SETX), &Y= (SETY), &GOTO (SETXY), &HGR (to clear the
> hi-res screen but also redraw the Terrapin); and a USR() to implement
> something like Terrapin Logo's TOWARDS. (These are, afaict, the full
> suite of graphics commands which is supported by Terrapin Logo 1.0)

I think this is a great idea. And it would be twice as good in double
high-res. Pun intended. Haha. Beagle Graphics contains a similar &
"library" for DHGR in BASIC:
https://beagle.applearchives.com/Software/Beagle%20Graphics.zip

A lot of what makes Logo great is it's ability to do recursion and
unfortunately, BASIC can't do that. What would be nice is to have an
extended BASIC interpreter that has real subroutines with parameters,
recursion, line numbers optional, real libraries, etc. Most of the time
it could just call into the existing Applesoft BASIC in ROM, to do
the work, but implement a more sophisticated front-end syntax.

I'm working on a BASIC compiler that eventually would be able to do
these things, but my progress is very slow.

On Wed, 20 Dec 2023, Bill Chatfield wrote:

> I think this is a great idea. And it would be twice as good in double
> high-res. Pun intended. Haha. Beagle Graphics contains a similar &
> "library" for DHGR in BASIC:
> https://beagle.applearchives.com/Software/Beagle%20Graphics.zip

I'm well familiar with Beagle Graphics - used to mess around with its
paint program (one of the earliest to support a mouse!) when I was a kid.

Actually, the sum-total of my idea is to create a Logo for another,
non-Apple, 6502 project, but I wanted to use the Apple ][ to prove my
concepts before moving onto the other project, and I wanted to implement
just the turtle before I tried to implement Logo - start easy, then move
to harder.

-uso.

When I wrote my previous reply, I was half-awake. Bit more awake, so I'll
comment a bit further.

I was (still am) having trouble wrapping my head around how to implement
turtle graphics, esp. in a way that would be compact enough to actually be
useful. But I did determine that availing myself of FPBASIC ROM code
would make it easier, since it wouldn't be necessary to reinvent the
wheel. Drawing the lines could be done with HPOSN and HGLIN; the same
code that can be used for XDRAW could also be used to draw and undraw the
terrapin cursor.

MIT Logo (Terrapin Logo 1.0) is about 32K; I'm curious if that can be
knocked down.

-uso.

Bill Chatfield <bill_chatfield@yahoo.com> writes:

[snip]
> A lot of what makes Logo great is it's ability to do recursion and
> unfortunately, BASIC can't do that.
[snip]

BASIC can do recursion--you just have to be careful with your
variables. Here's a program which has a routine that calculates
factorials recursively:

10 N = 5
20 GOSUB 1000
30 PRINT F
40 END
1000 F = 1
1010 IF N = 1 THEN RETURN
1020 N = N - 1
1030 GOSUB 1010
1040 N = N + 1
1050 F = F * N
1060 RETURN

Scott
--
Scott Hemphill hemphill@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear

> > I think this is a great idea. And it would be twice as good in double
> > high-res. Pun intended. Haha. Beagle Graphics contains a similar &
> > "library" for DHGR in BASIC:
> > https://beagle.applearchives.com/Software/Beagle%20Graphics.zip
> I'm well familiar with Beagle Graphics - used to mess around with its
> paint program (one of the earliest to support a mouse!) when I was a kid.
>
> Actually, the sum-total of my idea is to create a Logo for another,
> non-Apple, 6502 project, but I wanted to use the Apple ][ to prove my
> concepts before moving onto the other project, and I wanted to implement
> just the turtle before I tried to implement Logo - start easy, then move
> to harder.

I don't know if you are into re-creating the wheel, but there is an excellent Turtle program for Applesoft basic that covers all the commands you just described. It uses Applesoft floating point heavily to calculate the angles and so forth.

And have you heard of DublStuff? Sorry BB, but it is quite a bit better than Beagle and DRAW and XDRAW commands can be used on hi-res shapes to display on the dbl-hi-res screen.

When I converted over to Prodos, I stripped a lot of the unnecessary turtle commands down to just 4. & MOVE, &TURN, &HPLOT TO, &COLOR. The MOVE moves to any absolute coordinate without plotting and HPLOT plots a line in the direction set by TURN and COLOR. So you can still do forward and backward plots and PENUP/PENDOWN are eliminated.

On Wed, 20 Dec 2023, I am Rob wrote:

>>> I think this is a great idea. And it would be twice as good in double
>>> high-res. Pun intended. Haha. Beagle Graphics contains a similar &
>>> "library" for DHGR in BASIC:
>>> https://beagle.applearchives.com/Software/Beagle%20Graphics.zip
>> I'm well familiar with Beagle Graphics - used to mess around with its
>> paint program (one of the earliest to support a mouse!) when I was a kid.
>>
>> Actually, the sum-total of my idea is to create a Logo for another,
>> non-Apple, 6502 project, but I wanted to use the Apple ][ to prove my
>> concepts before moving onto the other project, and I wanted to implement
>> just the turtle before I tried to implement Logo - start easy, then move
>> to harder.
>
> I don't know if you are into re-creating the wheel, but there is an
> excellent Turtle program for Applesoft basic that covers all the
> commands you just described. It uses Applesoft floating point heavily
> to calculate the angles and so forth.

Basically what I want to do, but there's the possibility of whether I can
actually _use_ it for what I need which might require me to ignore it.

I mean, I'll prolly be pinching most of the Apple ][ ROM in some form, but
there's reasons I think that won't go over as badly as the Franklin Ace.

> And have you heard of DublStuff? Sorry BB, but it is quite a bit better
> than Beagle and DRAW and XDRAW commands can be used on hi-res shapes to
> display on the dbl-hi-res screen.

DHGR would be kinda weird for this.

> When I converted over to Prodos, I stripped a lot of the unnecessary
> turtle commands down to just 4. & MOVE, &TURN, &HPLOT TO, &COLOR. The
> MOVE moves to any absolute coordinate without plotting and HPLOT plots a
> line in the direction set by TURN and COLOR. So you can still do
> forward and backward plots and PENUP/PENDOWN are eliminated.

Stripping them down would force me to reimplement them later when I switch
from "BASIC library" to "part of a Logo interpreter" (which would be
reused for another unrelated project), so doing them from the beginning
would make other stuff easier.

-uso.

> > I don't know if you are into re-creating the wheel, but there is an
> > excellent Turtle program for Applesoft basic that covers all the
> > commands you just described. It uses Applesoft floating point heavily
> > to calculate the angles and so forth.

> Basically what I want to do, but there's the possibility of whether I can
> actually _use_ it for what I need which might require me to ignore it.

Gotcha. The source is available too if it would help.

> I mean, I'll prolly be pinching most of the Apple ][ ROM in some form, but
> there's reasons I think that won't go over as badly as the Franklin Ace.
> > And have you heard of DublStuff? Sorry BB, but it is quite a bit better
> > than Beagle and DRAW and XDRAW commands can be used on hi-res shapes to
> > display on the dbl-hi-res screen.

> DHGR would be kinda weird for this.

The shapes would be used in monochrome mode and in most cases where color bleeds, the shapes show better detail. Fonts, cursors and non-color shapes are in this category.

> > When I converted over to Prodos, I stripped a lot of the unnecessary
> > turtle commands down to just 4. & MOVE, &TURN, &HPLOT TO, &COLOR. The
> > MOVE moves to any absolute coordinate without plotting and HPLOT plots a
> > line in the direction set by TURN and COLOR. So you can still do
> > forward and backward plots and PENUP/PENDOWN are eliminated.

> Stripping them down would force me to reimplement them later when I switch
> from "BASIC library" to "part of a Logo interpreter" (which would be
> reused for another unrelated project), so doing them from the beginning
> would make other stuff easier.

Understood. Most of the code is still there, mostly it is just the commands that were eliminated.

I think I'm going to need to write out the ultimate breakdown of
everything to explain basically what's going on:

1. Turtle graphics using FPBASIC
2. Small text editor for use as a Logo procedure editor
3. Logo interpreter
4. 6502 debugger (possibly derived from Woz's, though I'd like to make it
merely compatible with it if possible)
5. Fork of FPBASIC, so that the debugger, FPBASIC and Logo can be ported
to some hypothetical 65C02 system a friend is working on
6. Get everything up on Apple ][, Apple /// and the hypothetical system

-uso.

On Wed, 20 Dec 2023, I am Rob wrote:

>
>>> I don't know if you are into re-creating the wheel, but there is an
>>> excellent Turtle program for Applesoft basic that covers all the
>>> commands you just described. It uses Applesoft floating point heavily
>>> to calculate the angles and so forth.
>
>> Basically what I want to do, but there's the possibility of whether I can
>> actually _use_ it for what I need which might require me to ignore it.
>
> Gotcha. The source is available too if it would help.

Perhaps.

>> I mean, I'll prolly be pinching most of the Apple ][ ROM in some form, but
>> there's reasons I think that won't go over as badly as the Franklin Ace.
>>> And have you heard of DublStuff? Sorry BB, but it is quite a bit better
>>> than Beagle and DRAW and XDRAW commands can be used on hi-res shapes to
>>> display on the dbl-hi-res screen.
>
>> DHGR would be kinda weird for this.
>
> The shapes would be used in monochrome mode and in most cases where
> color bleeds, the shapes show better detail. Fonts, cursors and
> non-color shapes are in this category.

While it would certainly be slower and larger, it might be possible to get
better results from the DHGR mode, using 140x192x16.

Though the only thing the shape table would be needed for is to draw the
terrapin, and that's just white.

>>> When I converted over to Prodos, I stripped a lot of the unnecessary
>>> turtle commands down to just 4. & MOVE, &TURN, &HPLOT TO, &COLOR. The
>>> MOVE moves to any absolute coordinate without plotting and HPLOT plots a
>>> line in the direction set by TURN and COLOR. So you can still do
>>> forward and backward plots and PENUP/PENDOWN are eliminated.
>
>> Stripping them down would force me to reimplement them later when I switch
>> from "BASIC library" to "part of a Logo interpreter" (which would be
>> reused for another unrelated project), so doing them from the beginning
>> would make other stuff easier.
>
> Understood. Most of the code is still there, mostly it is just the
> commands that were eliminated.

-uso.

> >> DHGR would be kinda weird for this.
> >
> > The shapes would be used in monochrome mode and in most cases where
> > color bleeds, the shapes show better detail. Fonts, cursors and
> > non-color shapes are in this category.

> While it would certainly be slower and larger, it might be possible to get
> better results from the DHGR mode, using 140x192x16.

I tried that as well, but there is no color detail in a hi-res shape, so no way to convert to dbl-hi-res color. A shape would need to have 4-bits for each bit drawn. I gave up on it and went to bitmap shapes for dbl-hi-res instead. Not only faster, but the shape table I create this way can also be used for IIGS Super-hi-res graphics. There are also 2 hires to dbl-hires convertor routines by Beagle Bros and I wrote a 3rd that does a bit better at retaining the same colors as the hi-res screen.

On Wed, 20 Dec 2023, I am Rob wrote:

>>>> DHGR would be kinda weird for this.
>>>
>>> The shapes would be used in monochrome mode and in most cases where
>>> color bleeds, the shapes show better detail. Fonts, cursors and
>>> non-color shapes are in this category.
>
>> While it would certainly be slower and larger, it might be possible to get
>> better results from the DHGR mode, using 140x192x16.
>
> I tried that as well, but there is no color detail in a hi-res shape, so
> no way to convert to dbl-hi-res color. A shape would need to have
> 4-bits for each bit drawn. I gave up on it and went to bitmap shapes
> for dbl-hi-res instead. Not only faster, but the shape table I create
> this way can also be used for IIGS Super-hi-res graphics. There are
> also 2 hires to dbl-hires convertor routines by Beagle Bros and I wrote
> a 3rd that does a bit better at retaining the same colors as the hi-res
> screen.

SHGR & routines would be nice to have too, for separate reasons...

-uso.

In article <alpine.DEB.2.21.2312200425120.30331@sd-119843.dedibox.fr>,
Steve Nickolas <usotsuki@buric.co> wrote:
>The ultimate idea was to try to reimplement Logo ...

Not quite what you want, but this was fun, some ~40 years or so ago:

https://youtu.be/O6Uc0Ck-LNo

(I implemented a turtle graphics interpreter in Applesoft)

-Gordon

On Thu, 21 Dec 2023, Gordon Henderson wrote:

> In article <alpine.DEB.2.21.2312200425120.30331@sd-119843.dedibox.fr>,
> Steve Nickolas <usotsuki@buric.co> wrote:
>> The ultimate idea was to try to reimplement Logo ...
>
> Not quite what you want, but this was fun, some ~40 years or so ago:
>
> https://youtu.be/O6Uc0Ck-LNo
>
> (I implemented a turtle graphics interpreter in Applesoft)
>
> -Gordon
>

Well, FPBASIC is always a start... especially since it'll still be running
in the FPBASIC environment... ;)

-uso.

On Wed, 20 Dec 2023 18:14:53 -0500
Scott Hemphill <hemphill@hemphills.net> wrote:

> BASIC can do recursion--you just have to be careful with your
> variables. Here's a program which has a routine that calculates
> factorials recursively:
>
> 10 N = 5
> 20 GOSUB 1000
> 30 PRINT F
> 40 END
> 1000 F = 1
> 1010 IF N = 1 THEN RETURN
> 1020 N = N - 1
> 1030 GOSUB 1010
> 1040 N = N + 1
> 1050 F = F * N
> 1060 RETURN

That is very clever. I really like it. And yet, I'm not sure you've
convinced me. Haha. Because, while you're technically correct, I'm not
sure it would be good to use in a Logo-like, teaching scenario. It
would be more suited to a weed circle. Haha. I'm just kidding. I love
it. I was thinking more to the effect that BASIC doesn't have local
variables, but you solved the variables problem. I wonder if this is
how it is done in Assembly Language?

Copying into AppleWin now...

Bill Chatfield <bill_chatfield@yahoo.com> writes:

> On Wed, 20 Dec 2023 18:14:53 -0500
> Scott Hemphill <hemphill@hemphills.net> wrote:
>
>> BASIC can do recursion--you just have to be careful with your
>> variables. Here's a program which has a routine that calculates
>> factorials recursively:
>>
>> 10 N = 5
>> 20 GOSUB 1000
>> 30 PRINT F
>> 40 END
>> 1000 F = 1
>> 1010 IF N = 1 THEN RETURN
>> 1020 N = N - 1
>> 1030 GOSUB 1010
>> 1040 N = N + 1
>> 1050 F = F * N
>> 1060 RETURN
>
> That is very clever. I really like it. And yet, I'm not sure you've
> convinced me. Haha. Because, while you're technically correct, I'm not
> sure it would be good to use in a Logo-like, teaching scenario. It
> would be more suited to a weed circle. Haha. I'm just kidding. I love
> it. I was thinking more to the effect that BASIC doesn't have local
> variables, but you solved the variables problem. I wonder if this is
> how it is done in Assembly Language?

If you need to save local variables, you can make your own stack with
DIM.

Scott
--
Scott Hemphill hemphill@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear

On Fri, 22 Dec 2023 11:18:00 -0500
Scott Hemphill <hemphill@hemphills.net> wrote:

> If you need to save local variables, you can make your own stack with
> DIM.

Good point

> That is very clever. I really like it. And yet, I'm not sure you've
> convinced me. Haha. Because, while you're technically correct, I'm not
> sure it would be good to use in a Logo-like, teaching scenario. It
> would be more suited to a weed circle. Haha. I'm just kidding. I love
> it. I was thinking more to the effect that BASIC doesn't have local
> variables, but you solved the variables problem. I wonder if this is
> how it is done in Assembly Language?

Just be aware that the stack is limited for both LOGO, Applesoft and ML. It only has a 256 byte range. Meaning each recursion puts 2-bytes on the stack for ML whereas each GOSUB will put 5 bytes on the stack. Unsure what LOGO pushes on the stack.

For assembly, instead of using the GOSUB 1010 in line 1030, it would be "JSR address" of where in memory line 1010 started.

I am Rob wrote:
>> That is very clever. I really like it. And yet, I'm not sure you've
>> convinced me. Haha. Because, while you're technically correct, I'm not
>> sure it would be good to use in a Logo-like, teaching scenario. It
>> would be more suited to a weed circle. Haha. I'm just kidding. I love
>> it. I was thinking more to the effect that BASIC doesn't have local
>> variables, but you solved the variables problem. I wonder if this is
>> how it is done in Assembly Language?
>
> Just be aware that the stack is limited for both LOGO, Applesoft and ML.
> It only has a 256 byte range. Meaning each recursion puts 2-bytes on the
> stack for ML whereas each GOSUB will put 5 bytes on the stack. Unsure
> what
> LOGO pushes on the stack.

But in this scenario, maybe you would just redesign your program logic to
use loops instead of recursion.

On Sat, 23 Dec 2023, D Finnigan wrote:

> I am Rob wrote:
>>
>> Just be aware that the stack is limited for both LOGO, Applesoft and ML.
>> It only has a 256 byte range. Meaning each recursion puts 2-bytes on the
>> stack for ML whereas each GOSUB will put 5 bytes on the stack. Unsure
>> what
>> LOGO pushes on the stack.
>
> But in this scenario, maybe you would just redesign your program logic to
> use loops instead of recursion.

There's also the option in some languages of implementing them with an
emulated stack instead of using the CPU stack (iirc, this is what CC65
does).

Honestly, I think I'd do this for Logo - because it's highly likely with
the design of functions in Logo that programs would eat stack very
quickly, it might be better to set aside a second stack, possibly larger
than the system stack, to handle functions.

-uso.

Hi Steve,

> There's also the option in some languages of implementing them with an
> emulated stack instead of using the CPU stack (iirc, this is what CC65
> does).

While it's true that cc65 uses what you call an emulated stack, it still
uses the 6502 stack for the return addresses of function calls. So the
theoretical limit for recursion is still 128 levels.

Regards,
Oliver

So because I couldn't wrap my head around the necessaries of writing the
turtle graphics implementation in 6502 ASM, I decided to take a step back,
and implement it in a language that would allow me to quickly prototype
it...QuickBasic. This implementation is obviously not for an Apple (it's
for a PC) and there's no way to draw/undraw the cursor, but it's a start.

If porting to an Apple and writing in ASM I'd want to repurpose the
floating-point stuff already in FPBASIC, as well as leveraging XDRAW to
implement the Terrapin (you can draw at any angle and position, then do it
again to undraw).

This is one of the three major components, alongside a text editor and a
parser, that would probably be necessary in order to do that Logo
implementation I wanted to do (for purposes _other_ than Apple ][ stuff,
ultimately, but...let's start simple first, eh?)

I chose QuickBasic for multiple reasons: (1) it's similar to FPBASIC but
the procedural extensions make it better suited for what I'm trying to do;
(2) it's not that hard to figure out the code logic; (3) all the
functionality I need to do what I've done is built in. Note that it's
rough around the edges.

Ultimately I plan to get this all written into 65C02 ASM, add the
necessaries for Logo, and create a minimalist Logo interpreter that builds
off the FPBASIC code - but first things first.

-uso.

---8X------

DECLARE SUB terrapin.right (degrees!)
DECLARE SUB terrapin.up ()
DECLARE SUB terrapin.forward (steps!)
DECLARE SUB terrapin.init ()
DECLARE SUB terrapin.down ()
DECLARE SUB terrapin.rotate (degrees!)
DECLARE SUB terrapin.clearscreen ()
DECLARE SUB terrapin.home ()
DECLARE SUB terrapin.lineto (newx!, newy!)
DIM SHARED terrapin.x, terrapin.y, terrapin.r, terrapin.p
terrapin.init

terrapin.up
terrapin.forward 50
terrapin.right 90
terrapin.down
FOR i = 1 TO 36
terrapin.forward 5
terrapin.right 10
x = TIMER: WHILE TIMER = x: WEND
NEXT i
terrapin.right 90

SUB terrapin.backward (steps)
terrapin.forward -steps
END SUB

SUB terrapin.clearscreen
LINE (0, 0)-(159, 199), 0, BF
END SUB

SUB terrapin.down
terrapin.p = 3
END SUB

SUB terrapin.erase
terrapin.p = 0
END SUB

SUB terrapin.forward (steps)
theta = (90 - terrapin.r) * (1.745329E-02)
d% = SGN(steps)
FOR i = 1 TO steps
m% = 1
nx = terrapin.x + ABS(d%) * COS(theta)
ny = terrapin.y - ABS(d%) * SIN(theta)
WHILE nx > 320
nx = nx - 320
m% = 0
WEND
WHILE ny > 160
ny = ny - 160
m% = 0
WEND
WHILE nx < 0
nx = nx + 320
m% = 0
WEND
WHILE ny < 0
ny = ny + 160
m% = 0
WEND
IF m% = 1 THEN
terrapin.lineto nx, ny
ELSE
terrapin.x = nx
terrapin.y = ny
END IF
NEXT i
END SUB

SUB terrapin.home
terrapin.x = 160
terrapin.y = 80
terrapin.r = 0
END SUB

SUB terrapin.init
SCREEN 1
WINDOW
VIEW
COLOR 0, 1
CLS
LOCATE , 24
VIEW PRINT 21 TO 25
terrapin.down
terrapin.clearscreen
terrapin.home
PRINT "Initialized Terrapin"
END SUB

SUB terrapin.left (degrees)
terrapin.rotate terrapin.r - degrees
END SUB

SUB terrapin.lineto (newx, newy)
IF (terrapin.p >= 0) THEN
LINE (terrapin.x, terrapin.y)-(newx, newy), terrapin.p
END IF
terrapin.x = newx
terrapin.y = newy
END SUB

SUB terrapin.right (degrees)
terrapin.rotate terrapin.r + degrees
END SUB

SUB terrapin.rotate (degrees)
terrapin.r = degrees
WHILE terrapin.r > 360
terrapin.r = terrapin.r - 360
WEND
WHILE terrapin.r < 0
terrapin.r = terrapin.r + 360
WEND
END SUB

SUB terrapin.up
terrapin.p = -1
END SUB