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, <, &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.[snip]
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.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.zipI'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 think this is a great idea. And it would be twice as good in doubleI'm well familiar with Beagle Graphics - used to mess around with its
high-res. Pun intended. Haha. Beagle Graphics contains a similar &
"library" for DHGR in BASIC:
https://beagle.applearchives.com/Software/Beagle%20Graphics.zip
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.
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.
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 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.DHGR would be kinda weird for this.
The shapes would be used in monochrome mode and in most cases whereWhile it would certainly be slower and larger, it might be possible to get better results from the DHGR mode, using 140x192x16.
color bleeds, the shapes show better detail. Fonts, cursors and
non-color shapes are in this category.
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.
The ultimate idea was to try to reimplement Logo ...
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
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
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.
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?
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.
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).
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 916 |
Nodes: | 10 (1 / 9) |
Uptime: | 51:33:58 |
Calls: | 12,172 |
Calls today: | 2 |
Files: | 186,522 |
Messages: | 2,234,753 |