Dan's suggestion worked: typing an exclamation inside the monitor brought me into the mini-assembler. I need a book * specifically * for the enhanced/Platinum model. Otherwise I won't know which mistakes are mine vs which are differences in the computer. Some of you will advise me to just get an older Apple II instead :) but I don't have space for another system. Evan Koblentz, director Vintage Computer Federation A 501(c)3 educational non-profit http://www.vcfed.org
Dan's suggestion worked: typing an exclamation inside the monitor brought me into the mini-assembler.
I need a book * specifically * for the enhanced/Platinum model. Otherwise I won't know which mistakes are mine vs which are differences in the computer.
Some of you will advise me to just get an older Apple II instead :) but I don't have space for another system.
Evan Koblentz, director Vintage Computer Federation A 501(c)3 educational non-profit http://www.vcfed.org
Or if you can't locate a book that pertains to the platinum (perhaps no one wrote one) you may find documentation of a definitive list of the differences between a II and a platinum explained so you can spot the things the book you have talks about that won't work or work differently on the platinum. I doubt there are too many more things you will run across that will trip you up.
Are you not going to use an Apple II emulator to start with?
Turns out LinApple emulates the enhanced version, same as what's on my //.
I figure it's smart to stick with the mini-assembler until I learn a few things before moving to a full-fledged assembler like Merlin. VCFed owns a few Laser 128s. Ian explained to me that the 128 is basically a //c with an expansion card slot. That may be good for me, ** if it has the older version of the mini-assembler **, because I have limited desk space and the small system is easier to bring to events. I will test our 128s this weekend -- step one, do any of them work, and step two, which version of the mini assembler. (Or can someone who has a Laser 128 test this for me sooner? Just see if it takes the F666G or ! to enter the mini assembler, then report back.)
On 1/17/2017 7:10 PM, Evan Koblentz via vcf-midatlantic wrote:
I figure it's smart to stick with the mini-assembler until I learn a few things before moving to a full-fledged assembler like Merlin.
VCFed owns a few Laser 128s. Ian explained to me that the 128 is basically a //c with an expansion card slot. That may be good for me, ** if it has the older version of the mini-assembler **, because I have limited desk space and the small system is easier to bring to events. I will test our 128s this weekend -- step one, do any of them work, and step two, which version of the mini assembler. (Or can someone who has a Laser 128 test this for me sooner? Just see if it takes the F666G or ! to enter the mini assembler, then report back.)
The mini-assembler requires much more advanced knowledge than a macro assembler. The macro assembler will do a lot of the low level work for you without having to understand things like 2s complement notation, relative branches versus absolute jumps, and a bunch of other stuff. Take a look at: http://ceos.io/dev/hello.s This "HELLO, WORLD" program is much harder to code with the mini-assembler. Mini refers to small and barebones (thus requiring some serious advanced knowledge about how things works). Macro refers to something entirely different: https://en.wikipedia.org/wiki/Assembly_language#Macros Good luck! -Adam
Mini refers to small and barebones (thus requiring some serious advanced knowledge about how things works). Macro refers to something entirely different
Indeed. The mini assembler isn't much more than an opcode table anyway. Why not skip the fuss and learn to do it the old fashioned way, with paper and an opcode table? The ref card eBay item I linked earlier includes an opcode table, forward/reverse relative tables, et c. Bonus: it's completely machine independent. You don't have to figure out if some other computer is working or not, just assemble the little sample routines yourself (you won't be doing anything complicated enough to need a real assembler at first anyway) and key them into the monitor. You could use anything from an emulator to a KIM-1. Thanks, Jonathan
On Tue, Jan 17, 2017 at 8:18 PM, Adam Michlin via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On 1/17/2017 7:10 PM, Evan Koblentz via vcf-midatlantic wrote:
I figure it's smart to stick with the mini-assembler until I learn a few things before moving to a full-fledged assembler like Merlin.
VCFed owns a few Laser 128s. Ian explained to me that the 128 is basically a //c with an expansion card slot. That may be good for me, ** if it has the older version of the mini-assembler **, because I have limited desk space and the small system is easier to bring to events. I will test our 128s this weekend -- step one, do any of them work, and step two, which version of the mini assembler. (Or can someone who has a Laser 128 test this for me sooner? Just see if it takes the F666G or ! to enter the mini assembler, then report back.)
The mini-assembler requires much more advanced knowledge than a macro assembler. The macro assembler will do a lot of the low level work for you without having to understand things like 2s complement notation, relative branches versus absolute jumps, and a bunch of other stuff.
Take a look at:
This "HELLO, WORLD" program is much harder to code with the mini-assembler.
Mini refers to small and barebones (thus requiring some serious advanced knowledge about how things works). Macro refers to something entirely different:
https://en.wikipedia.org/wiki/Assembly_language#Macros
Good luck!
-Adam
yes but that's the orignal method of learning assembly, before progressing into macro assemblers, it's old-school and I think it's worth knowing the fundamentals , it makes you have a deeper understanding of the machine language , Now they had cross-assemblers too for a very long time, look at how MITs Altair Basic was written, an 8080 "cross" assembler on a pdp-10 The cross is in quotes because they didn't really write code to convert 8080 opcodes, But rather made use of unused opcodes from the PDP-10, Then wrote Trap code for each unused opcode, so that code would then emulate the 8080 opcodes, I though it was really neat in the manner they took. Dan
The mini-assembler requires much more advanced knowledge than a macro assembler. The macro assembler will do a lot of the low level work for you without having to understand things like 2s complement notation, relative branches versus absolute jumps, and a bunch of other stuff.
yes but that's the orignal method of learning assembly, before progressing into macro assemblers, it's old-school and I think it's worth knowing the fundamentals, it makes you have a deeper understanding of the machine language
That's what I was thinking. Still thinking aloud: if I go directly from BASIC to a macro assembler, will I truly learn it? Will I miss important stuff? If I'm trying a sample problem from a book, then how will I know which parts of the example are the programming language and which parts are the macro system? That is one reason why I'm caught up on the mini assembler. The other is because everyone (for some value of "every") recommended the Assembly Lines book, and it says to start with the mini assembler, so I did.
everyone (for some value of "every") recommended the Assembly Lines book, and it says to start with the mini assembler, so I did.
Upon reading some more of that book: I don't see what is so great about it. It goes from zero to over my head in a few pages. In addition to the book Jon recommended, does anyone else have a suggestion for a book that's truly "Apple/6502 assembler for dummies"...? I need a book that reeeeeeeeeeally simplifies the concepts.
On Tue, Jan 17, 2017 at 9:23 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
everyone (for some value of "every") recommended the Assembly
Lines book, and it says to start with the mini assembler, so I did.
Upon reading some more of that book: I don't see what is so great about it. It goes from zero to over my head in a few pages.
In addition to the book Jon recommended, does anyone else have a suggestion for a book that's truly "Apple/6502 assembler for dummies"...? I need a book that reeeeeeeeeeally simplifies the concepts.
oh there's several beginners books out there here's some for starters Machine Language for Beginners - Richard Mansfield https://archive.org/details/Apple_Machine_Language_for_Beginners_Richard_Man... Using 6502 assembly language : how anyone can program the Apple II https://archive.org/details/Using_6502_Assembly_Language_1982_Datamost Assembly Cookbook for the Apple II_part_1 https://archive.org/details/Assembly_Cookbook_for_the_Apple_II_part_1 Assembly Cookbook for the Apple II_part_2 https://archive.org/details/Assembly_Cookbook_for_the_Apple_II_part_2
I need a book that reeeeeeeeeeally simplifies the concepts.
Do remember you're trying to make a CPU do your bidding at the machine language level :) Take a look through the book I recommended ("Programming and Interfacing the 6502, with Experiments," Marvin L. DeJong). You can find PDF copies of questionable legal standing all over the Internet. I wouldn't be surprised if we have a print copy somewhere in the museum, but it's usually a very cheap book anyway. Don't gloss over the parts about hardware organization. It's important. If you don't understand something, ask questions. Thanks, Jonathan
I decided to try to cookbook series. Getting it now...
Page 19: "So many assembler books and courses omit this essential first step! An assembler is simply too powerful a tool to start off with. You must first know what op codes are and how they are used. You must thoroughly understand addressing modes and the different ways you show which addressing mode is in use." So... what Glitch said. Or: Don L. was trying to sell more books. Very next sentence on that page: "There is a series of nine discovery modules in Volume II of Don Lancaster's Micro Cookbook..." ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
Agreed. These look the most promising of the several I've looked at. On Tue, Jan 17, 2017 at 11:17 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I decided to try to cookbook series. Getting it now...
Page 19: "So many assembler books and courses omit this essential first step! An assembler is simply too powerful a tool to start off with. You must first know what op codes are and how they are used. You must thoroughly understand addressing modes and the different ways you show which addressing mode is in use."
So... what Glitch said.
Or: Don L. was trying to sell more books. Very next sentence on that page: "There is a series of nine discovery modules in Volume II of Don Lancaster's Micro Cookbook..."
________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit
evan@vcfed.org (646) 546-9999
www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
On Tue, Jan 17, 2017 at 11:17 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I decided to try to cookbook series. Getting it now...
Page 19: "So many assembler books and courses omit this essential first step! An assembler is simply too powerful a tool to start off with. You must first know what op codes are and how they are used. You must thoroughly understand addressing modes and the different ways you show which addressing mode is in use."
So... what Glitch said.
Or: Don L. was trying to sell more books. Very next sentence on that page: "There is a series of nine discovery modules in Volume II of Don Lancaster's Micro Cookbook..."
just use the other two beginner books I posted along with those to learn about Opcodes You can jump back n forth betwee those beginner books to grasp a better understanding Dan
just use the other two beginner books I posted along with those to learn about Opcodes You can jump back n forth betwee those beginner books to grasp a better understanding Dan
Okay, I downloaded this one: Using 6502 assembly language : how anyone can program the Apple II https://archive.org/details/Using_6502_Assembly_Language_1982_Datamost
On 1/17/2017 11:41 PM, Evan Koblentz via vcf-midatlantic wrote:
just use the other two beginner books I posted along with those to learn about Opcodes You can jump back n forth betwee those beginner books to grasp a better understanding Dan
Okay, I downloaded this one:
Using 6502 assembly language : how anyone can program the Apple II https://archive.org/details/Using_6502_Assembly_Language_1982_Datamost how anyone can program the Apple II
Well that sounds like a winner!
just use the other two beginner books I posted along with those to learn about Opcodes You can jump back n forth betwee those beginner books to grasp a better understanding Dan
Okay, I downloaded this one:
Using 6502 assembly language : how anyone can program the Apple II https://archive.org/details/Using_6502_Assembly_Language_1982_Datamost how anyone can program the Apple II
Well that sounds like a winner!
Eh. I skimmed the first chapter (skipping the binary math lesson which I already understand). There's something about all these books so far which just makes my eyes glaze over (could it be that low-level languages require .... patience and hard work? Ack!) Maybe I ought to stick with BASIC and just extend my knowledge beyond what I learned in 7th grade. Argument for that perspective: I'm probably not ready to learn assembly if I haven't even learned PEEK and POKE yet.
Yes, all those concepts are foundational for an understanding on how to effectively code in assembly. It just takes time, you'll get there. On Wed, Jan 18, 2017 at 12:09 AM Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
just use the other two beginner books I posted along with those to
learn
about Opcodes
You can jump back n forth betwee those beginner books to grasp a better
understanding
Dan
Okay, I downloaded this one:
Using 6502 assembly language : how anyone can program the Apple II
https://archive.org/details/Using_6502_Assembly_Language_1982_Datamost
how anyone can program the Apple II
Well that sounds like a winner!
Eh. I skimmed the first chapter (skipping the binary math lesson which I
already understand). There's something about all these books so far
which just makes my eyes glaze over (could it be that low-level
languages require .... patience and hard work? Ack!)
Maybe I ought to stick with BASIC and just extend my knowledge beyond
what I learned in 7th grade. Argument for that perspective: I'm probably
not ready to learn assembly if I haven't even learned PEEK and POKE yet.
On Wed, Jan 18, 2017 at 12:37 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Evan, having seen the shadow of low-level programming,
>
crawls back into the L iberal A rts CAVE from whence he emerged. >
>GET LAMP ;)
On 1/18/2017 12:08 AM, Evan Koblentz via vcf-midatlantic wrote:
just use the other two beginner books I posted along with those to learn about Opcodes You can jump back n forth betwee those beginner books to grasp a better understanding Dan
Okay, I downloaded this one:
Using 6502 assembly language : how anyone can program the Apple II https://archive.org/details/Using_6502_Assembly_Language_1982_Datamost how anyone can program the Apple II
Well that sounds like a winner!
Eh. I skimmed the first chapter (skipping the binary math lesson which I already understand). There's something about all these books so far which just makes my eyes glaze over (could it be that low-level languages require .... patience and hard work? Ack!)
Maybe I ought to stick with BASIC and just extend my knowledge beyond what I learned in 7th grade. Argument for that perspective: I'm probably not ready to learn assembly if I haven't even learned PEEK and POKE yet.
If you are satisfied with BASIC as a solution, peek and poke should be sufficient for control if the motor control hardware is memory mapped on the Apple. If machine language routines are actually needed, its likely that folks here can write them for you easily since Integrating them with BASIC is a known quantity.
Doug wrote:
If you are satisfied with BASIC as a solution, peek and poke should be sufficient for control if the motor control hardware is memory mapped on the Apple. If machine language routines are actually needed, its likely that folks here can write them for you easily since integrating them with BASIC is a known quantity.
Which brings us back to my original problem. For the program I wrote in Lego LOGO, there are places where I need to check the status of a motor -- is it on or off -- before proceeding. Motors are mapped (by you the programmer) to ports 0-5 on the interface box. You can turn a port on/off, but there's no way to read its status! Crazy yet true. That is why I had the idea of adding such a command, and why Dean in turn figured it could be done by disassembling the code, before realizing that Lego used some not-easily-disassemblable method. Ergo we (collectively the people in this thread) considered using BASIC instead or a custom LOGO instead of Lego LOGO. We apparently settled on BASIC. That's fine with me. I would like it better on the Apple II platform :) but the path of least resistance is on an IBM PC because Lego already provides that option. Ben G. loaned us the IBM PC card with his Lego robotics kit. Glitch is currently working on building a replica card for VCFed to own, and then I'll mail the original back to Ben. Hopefully the replica will be ready in time for our February workshop. Then me, Dean, and anyone else who's interested can see about making it listen to (not just talk to) the hardware (but it won't work if the card only toggles, as stated earlier). Doh!!!
On Wed, Jan 18, 2017 at 1:17 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Doug wrote:
If you are satisfied with BASIC as a solution, peek and poke should be
sufficient for control if the motor control hardware is memory mapped on the Apple. If machine language routines are actually needed, its likely that folks here can write them for you easily since integrating them with BASIC is a known quantity.
Which brings us back to my original problem. For the program I wrote in Lego LOGO, there are places where I need to check the status of a motor -- is it on or off -- before proceeding. Motors are mapped (by you the programmer) to ports 0-5 on the interface box. You can turn a port on/off, but there's no way to read its status! Crazy yet true.
You the programmer are responsible for keeping track if you left the motor on or off in the case of a Motor, which is a Output signal from that Lego interface., this is done merely by having variable defined to keep track of different States within your project. That is contained in your code, this is a basic principle for any project, which involves a motor interface, such as in a robot. Your code is _not_ supposed to change the State of the motor unless it meets your defined conditions, via the code that you write. Your code is supposed to set the conditions, then when those conditions are satisfied, by the change in the value of your variable, only then you change the State of the Motor output. SO, it is redundant to ask to check the hardware, eg. the motor, if it is currently on or off. If the State of the motor is changing for some mysterious reason, eg,opposite of what you defined, then you have a Bug. For example, And this is a basic principle for a control system operating in any project. There should be only one subroutine[eg.function] to decide on the state of the motor. And this subroutine will accept parameters[eg,variables] containing values from the other parts of your code. And this Motor subroutine will use those parameters to make a decision on the state of the motor, either to change it to On or Off. There should _not_ be any other subroutines which decide on changing the state of the motor, because then you create bigger problems, such as Bugs. The only other time there may be something wrong is when there's a component failure and it doesn't respond to any commands. The same idea applies for the other output ports such as the Lamps. In any control system, there are times when you need additional sensors to provide some feedback to your processor. This can be checked by your code, and decide on a new course of action. But this involves some more complexity. One such example is if the motor experiences a stall condition, there are sensors for this. And this hardware will provide feedback to your code which can be read and decoded to let the processor know that it experienced a fault condition in it's environment, such as the wheel is stuck on a rock and can't spin any more. But your'e not approaching that level of sophistication yet, this is just fyi.
That is why I had the idea of adding such a command, and why Dean in turn figured it could be done by disassembling the code, before realizing that Lego used some not-easily-disassemblable method. Ergo we (collectively the people in this thread) considered using BASIC instead or a custom LOGO instead of Lego LOGO. We apparently settled on BASIC. That's fine with me. I would like it better on the Apple II platform :) but the path of least resistance is on an IBM PC because Lego already provides that option.
Ben G. loaned us the IBM PC card with his Lego robotics kit. Glitch is currently working on building a replica card for VCFed to own, and then I'll mail the original back to Ben.
Hopefully the replica will be ready in time for our February workshop. Then me, Dean, and anyone else who's interested can see about making it listen to (not just talk to) the hardware (but it won't work if the card only toggles, as stated earlier). Doh!!!
In general, as you may know, you can always access the hardware via Poke/Peeks or Assembly embedded into your Basic code, whenever there aren't any commands specific for that purpose. Because all of the hardware is memory-mapped in the memory of the PC, which means software can access it anytime About the Apple version, you could always translate the IBM Basic to Apple Basic. Becasue its the same 9750 interface box, just a different interface card in the slot. So just the memory-mapped address for that interface card changes. The ports which are accessed by software pointing to the input and out ports on the 9750 will be the same, Becasue your not changing the wiring inside that 9750. That hardware on the interface card will have a specific Memory Address, in case of the PC it will be I/O Port address, maybe a couple.It should be documented somewhere, If not, it can be reverse engineered from the schematics of that interface card. Don't hesitate to ask for any help when you get it running Dan
On Wed, Jan 18, 2017 at 2:34 AM, Dan Roganti <ragooman@gmail.com> wrote:
On Wed, Jan 18, 2017 at 1:17 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Doug wrote:
If you are satisfied with BASIC as a solution, peek and poke should be
sufficient for control if the motor control hardware is memory mapped on the Apple. If machine language routines are actually needed, its likely that folks here can write them for you easily since integrating them with BASIC is a known quantity.
Which brings us back to my original problem. For the program I wrote in Lego LOGO, there are places where I need to check the status of a motor -- is it on or off -- before proceeding. Motors are mapped (by you the programmer) to ports 0-5 on the interface box. You can turn a port on/off, but there's no way to read its status! Crazy yet true.
You the programmer are responsible for keeping track if you left the motor on or off in the case of a Motor, which is a Output signal from that Lego interface., this is done merely by having variable defined to keep track of different States within your project. That is contained in your code, this is a basic principle for any project, which involves a motor interface, such as in a robot.
[snip]
in other words, assign a variable to track the current state of the motor output, via that motor subroutine And just check that >variable< anytime you want, anywhere in your code Dan
Dan, You are spot on. TC Logo only lets you check the status of one joystick button, not both. So we were limited to using one button as a toggle. Easy enough to track the status of the last command sent to the motor with a variable, but the check for a button press only worked sporadically due to timing issues and Logo's limited program flow features. I strongly suspect that the IBM, especially with qbasic, will allows us to write a much tighter polling loop and/or allow the checking of more than one joystick button (one for off, one for on). D On Wed, Jan 18, 2017 at 2:58 AM Dan Roganti via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Wed, Jan 18, 2017 at 2:34 AM, Dan Roganti <ragooman@gmail.com> wrote:
On Wed, Jan 18, 2017 at 1:17 AM, Evan Koblentz via vcf-midatlantic <
vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Doug wrote:
If you are satisfied with BASIC as a solution, peek and poke should be
sufficient for control if the motor control hardware is memory mapped
on the Apple. If machine language routines are actually needed, its
likely that folks here can write them for you easily since integrating
them with BASIC is a known quantity.
Which brings us back to my original problem. For the program I wrote in
Lego LOGO, there are places where I need to check the status of a motor --
is it on or off -- before proceeding. Motors are mapped (by you the
programmer) to ports 0-5 on the interface box. You can turn a port on/off,
but there's no way to read its status! Crazy yet true.
You the programmer are responsible for keeping track if you left the motor
on or off
in the case of a Motor, which is a Output signal from that Lego interface.,
this is done merely by having variable defined to keep track of different
States within your project.
That is contained in your code, this is a basic principle for any project,
which involves a motor interface, such as in a robot.
[snip]
in other words,
assign a variable to track the current state of the motor output, via that
motor subroutine
And just check that >variable< anytime you want, anywhere in your code
Dan
On Wed, Jan 18, 2017 at 6:32 AM, Dean Notarnicola <dnotarnicola@gmail.com> wrote:
Dan, You are spot on. TC Logo only lets you check the status of one joystick button, not both. So we were limited to using one button as a toggle. Easy enough to track the status of the last command sent to the motor with a variable, but the check for a button press only worked sporadically due to timing issues and Logo's limited program flow features. I strongly suspect that the IBM, especially with qbasic, will allows us to write a much tighter polling loop and/or allow the checking of more than one joystick button (one for off, one for on).
yea, I kinda think you are "pushing the envelope" with the Logo Language I noticed all along that has been a very rudimentary programming language When you start progressing beyond the simple "turn motor on" of "push switch on" type examples Because that issue about checking multiple joystick buttons is trivial when done in Assembly, Basic or any other code Now I just noticed something while typing this email You know the 1st disk image, the Lego Lines disk image from that webpage I mentioned That disk is the BASIC code version of the Lego TC Logo disk The Lego TC Logo software is just the "flashy" version for the kids You already >have< what you @need@ I didn't look closely last night cause we were so busy about the *.do file from the Lego TC Logo disk image That Lego Lines disk image has a **complete** software toolkit suite,eg. SDK, with Basic code to do that same exact thing Plus, there's a pdf on there, the Teacher's manual, which **also** shows how to program everything in Basic >AND< Machine code I suppose none of you looked on there yet Otherwise you wouldn't have been trying to **reinvent** the wheel all this time So now you will be able to replicate any of the commands in Lego Logo and then some, like check multiple Joystick Buttons, or any other conditions you come across. I have to admit, that was the last place I looked cause I didn't expect to find any "bare metal" programming info. I was trying to find some kind of tech manual, and it just do happened to be at the end of the Teachers manual. I apologize to my teacher friends out there, for expecting less, I won't 2nd guess this again in the future Everything starts on pdf page 138 in that Teachers manual, How to use that Lego Lines software starts on pdf page 161 The Basic code info starts on pdf page 170 And the Machine code info starts on pdf page 173 as they say, RTFM !! Dan
Now I just noticed something while typing this email You know the 1st disk image, the Lego Lines disk image from that webpage I mentioned That disk is the BASIC code version of the Lego TC Logo disk
!!!!!!!!! Well that a nice thing.
Plus, there's a pdf on there, the Teacher's manual, which **also** shows how to program everything in Basic >AND< Machine code
Going to look RIGHT NOW.
On Wed, Jan 18, 2017 at 11:31 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Now I just noticed something while typing this email
You know the 1st disk image, the Lego Lines disk image from that webpage I mentioned That disk is the BASIC code version of the Lego TC Logo disk
!!!!!!!!!
Well that a nice thing.
Plus, there's a pdf on there, the Teacher's manual,
which **also** shows how to program everything in Basic >AND< Machine code
Going to look RIGHT NOW.
OK, I see you caught up on your emails :)
Now I just noticed something while typing this email You know the 1st disk image, the Lego Lines disk image from that webpage I mentioned That disk is the BASIC code version of the Lego TC Logo disk
!!!!!!!!!
Well that's a nice thing.
Plus, there's a pdf on there, the Teacher's manual, which **also** shows how to program everything in Basic >AND< Machine code
Going to look RIGHT NOW.
OK, I see you caught up on your emails :)
Okay, I downloaded the .dsk files and used ADTPro to make disks. I now have LEGO Lines (and it feels so good). Next, have to RTFM. This may take a while...
We already tried using a variable. In that example, I built a Lego V-8 style motor. Pressing joystick button 0 one time starts it. I wanted the next button 0 press to stop it. As Dean said, it didn't work using the variable method because of (we think) timing issues. It works fine in walkie-talkie style mode (Dan that's just like the code you and I made ahead of Maker Faire) where "IF NOT BUTTON? 0 [TTO "(port number) OFF] and it also works fine if I have button 1 turn it off. But our attempts to have button 0 turn it on, change a variable to represent that, then check the variable again upon the next button press and turn it off it the variable = 1 just didn't work reliably. The motor stuttered and * sometimes * turned off. Sometimes it worked reliably for a few minutes and then wouldn't work at all. Another place where I need to check motor status (port on/off status) is for the steering rack. As in a real car, the steering has a mechanical limit. Imagine if you had superhero strength: you could keep turning the steering wheel at its limit and you'd break some component. In the Lego model, if a kid holds the joystick to one side after that limit is reached, then either the Lego pieces start coming apart or the motor could burn out. So I put the optical sensor there. When the sensor is blocked, it turns off the steering rack port. Kind of ingenious right? :) But it doesn't work because the program does not know which master to obey -- the joystick telling it to spin the steering motor or the sensor telling it to stop! I tried some code saying if the sensor is true and the motor is true then turn off the port, but couldn't get that to work. There is chance it was my code at that point, not the logic. All these problems could be avoided if I had a simple way to check a port status. "Hey I see a button was pressed? Is the port on? Okay, turn it off. Oh was it off? Okay, turn it on." Evan Koblentz, director Vintage Computer Federation A 501(c)3 educational non-profit http://www.vcfed.org
On Wed, Jan 18, 2017 at 10:07 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
We already tried using a variable. In that example, I built a Lego V-8 style motor. Pressing joystick button 0 one time starts it. I wanted the next button 0 press to stop it. As Dean said, it didn't work using the variable method because of (we think) timing issues. It works fine in walkie-talkie style mode (Dan that's just like the code you and I made ahead of Maker Faire) where "IF NOT BUTTON? 0 [TTO "(port number) OFF] and it also works fine if I have button 1 turn it off. But our attempts to have button 0 turn it on, change a variable to represent that, then check the variable again upon the next button press and turn it off it the variable = 1 just didn't work reliably. The motor stuttered and * sometimes * turned off. Sometimes it worked reliably for a few minutes and then wouldn't work at all.
Another place where I need to check motor status (port on/off status) is for the steering rack. As in a real car, the steering has a mechanical limit. Imagine if you had superhero strength: you could keep turning the steering wheel at its limit and you'd break some component. In the Lego model, if a kid holds the joystick to one side after that limit is reached, then either the Lego pieces start coming apart or the motor could burn out. So I put the optical sensor there. When the sensor is blocked, it turns off the steering rack port. Kind of ingenious right? :) But it doesn't work because the program does not know which master to obey -- the joystick telling it to spin the steering motor or the sensor telling it to stop! I tried some code saying if the sensor is true and the motor is true then turn off the port, but couldn't get that to work. There is chance it was my code at that point, not the logic.
All these problems could be avoided if I had a simple way to check a port status. "Hey I see a button was pressed? Is the port on? Okay, turn it off. Oh was it off? Okay, turn it on."
oh yea I remember that work we did, didn't you see my email this morning at 8:17am, Dean replied that he read it I explained where to look in the manual and it shows you how you can do everything in Basic and Assembly So you can forget using Logo, it just way too limited, for what you are doing and so you can follow the normal programming practices with control system theory, just as the problem you described just now, and as I described in my email this morning, eg, Fault condition when motor stalls by using a better programming language than Logo Dan
On Wed, Jan 18, 2017 at 10:43 AM, Dan Roganti <ragooman@gmail.com> wrote:
On Wed, Jan 18, 2017 at 10:07 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
We already tried using a variable. In that example, I built a Lego V-8 style motor. Pressing joystick button 0 one time starts it. I wanted the next button 0 press to stop it. As Dean said, it didn't work using the variable method because of (we think) timing issues. It works fine in walkie-talkie style mode (Dan that's just like the code you and I made ahead of Maker Faire) where "IF NOT BUTTON? 0 [TTO "(port number) OFF] and it also works fine if I have button 1 turn it off. But our attempts to have button 0 turn it on, change a variable to represent that, then check the variable again upon the next button press and turn it off it the variable = 1 just didn't work reliably. The motor stuttered and * sometimes * turned off. Sometimes it worked reliably for a few minutes and then wouldn't work at all.
Another place where I need to check motor status (port on/off status) is for the steering rack. As in a real car, the steering has a mechanical limit. Imagine if you had superhero strength: you could keep turning the steering wheel at its limit and you'd break some component. In the Lego model, if a kid holds the joystick to one side after that limit is reached, then either the Lego pieces start coming apart or the motor could burn out. So I put the optical sensor there. When the sensor is blocked, it turns off the steering rack port. Kind of ingenious right? :) But it doesn't work because the program does not know which master to obey -- the joystick telling it to spin the steering motor or the sensor telling it to stop! I tried some code saying if the sensor is true and the motor is true then turn off the port, but couldn't get that to work. There is chance it was my code at that point, not the logic.
All these problems could be avoided if I had a simple way to check a port status. "Hey I see a button was pressed? Is the port on? Okay, turn it off. Oh was it off? Okay, turn it on."
oh yea I remember that work we did, didn't you see my email this morning at 8:17am, Dean replied that he read it I explained where to look in the manual and it shows you how you can do everything in Basic and Assembly So you can forget using Logo, it just way too limited, for what you are doing and so you can follow the normal programming practices with control system theory, just as the problem you described just now, and as I described in my email this morning, eg, Fault condition when motor stalls by using a better programming language than Logo Dan
oh and since this is really your first foray into robotics, however minuscule it might be, also your attempt to implement and formulate some sort of a control system scheme into your code, when you revisit programming this in Basic and/or Assembly, **highly recommended** You should really consider making a concise Flow Chart. Because it will help you and others that come after you, when you make a museum exhibit from this to explain what is going inside the brain of your robot, however small it might be, it's still a good form of documentation for any project. And these days you can make flowcharts on your desktop instead of pen and paper While including the little details that happen in each step, not just a simple " is the switch On ?" that any dope can write but other pertinent details such as the memory address where that switch is accessed It keeps you from going insane, you don't have enough hair to pull out anymore :) Dan
didn't you see my email this morning at 8:17am, Dean replied that he read it I explained where to look in the manual and it shows you how you can do everything in Basic and Assembly
??? Didn't get that message nor do I see it here: https://lists.vintagecomputerfederation.org/pipermail/vcf-midatlantic/2017-J... There's nothing further I can do until I get access to an IBM PC and get Jon's replica IBM Lego card. ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
On Wed, Jan 18, 2017 at 11:05 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
didn't you see my email this morning at 8:17am, Dean replied that he read
it I explained where to look in the manual and it shows you how you can do everything in Basic and Assembly
??? Didn't get that message nor do I see it here: https://lists.vintagecomputerfederation.org/pipermail/vcf- midatlantic/2017-January/date.html
There's nothing further I can do until I get access to an IBM PC and get Jon's replica IBM Lego card.
_
I see what happened I resent it just now For some reason, on this email list, sometimes i have to click "reply-all" to make sure it goes to the email list because at times depending on your replies to the post, the "TO" field gets munged, and the actual reply address for the email list winds up in the "CC" box insted while the person who replied to the post winds up in the "TO" box So my reply went directly to Dean instead This doesn't happen on every post, just certain ones Dan
On Wed, Jan 18, 2017 at 11:12 AM, Dan Roganti <ragooman@gmail.com> wrote:
On Wed, Jan 18, 2017 at 11:05 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
didn't you see my email this morning at 8:17am, Dean replied that he read
it I explained where to look in the manual and it shows you how you can do everything in Basic and Assembly
??? Didn't get that message nor do I see it here: https://lists.vintagecomputerfederation.org/pipermail/vcf-mi datlantic/2017-January/date.html
There's nothing further I can do until I get access to an IBM PC and get Jon's replica IBM Lego card.
_
I see what happened I resent it just now For some reason, on this email list, sometimes i have to click "reply-all" to make sure it goes to the email list because at times depending on your replies to the post, the "TO" field gets munged, and the actual reply address for the email list winds up in the "CC" box insted while the person who replied to the post winds up in the "TO" box So my reply went directly to Dean instead This doesn't happen on every post, just certain ones Dan
oh and I forgot to mention, in that email I just resent, posted now at 11:09am that you don't have to wait for the IBM card you can still continue programming with the Apple interface card the one you said that Jon made before already on your Apple Platinum or whichever Apple you want to use Dan
On Wed, Jan 18, 2017 at 10:07:31AM -0500, Evan Koblentz via vcf-midatlantic wrote:
But our attempts to have button 0 turn it on, change a variable to represent that, then check the variable again upon the next button press and turn it off it the variable = 1 just didn't work reliably. The motor stuttered and * sometimes * turned off. Sometimes it worked reliably for a few minutes and then wouldn't work at all.
Insufficent information so this could all be known/offbase. If it was coded as something like this motor_on = false loop till end of time if not motor_on and button pressed turn on motor motor_on = true else if motor_on and button pressed turn off motor motor_on = false end if end loop Then you would get behavior like you said. The stuttering would be First loop Motor is off and button pressed so turn it on Next loop Motor is on and button is still pressed so turn it off Next loop Motor is off and button is still pressed so turn it on ... If the loop is fast enough that you don't hear the stuttering it would randomly be on or off when you let up the button based on how many times it went through the loop while the button was pressed. The fix would be instead of button pressed check if button pressed and was not pressed last time through the loop. If the loop is fast enough you may then get another problem caused by switch bounch. Switches don't cleanly transition from on to off or the opposite. Instead they will generate a sequence of on's and off's if you sample them fast enough. Random web page showed someone measuring a switch bounce of 157 milliseconds. To cure this you need to ignore additional transitions for some time after the first. Switch bounce gets worse with age which is why you get extra characters on old buttons. The put in debounce for the new switch bounce time but it now bounces longer.
yes, switch noise is always a problem but you have to balance the solution with the problem While the switch noise can be relatively long, The processing time for the Basic interpreter on a vintage computer is also very slow So there 2 kinds of switch debounce methods, hardware or software But the hardware method can involve several degrees of effectiveness depending on the size of modifications you want to add to the circuit
From a simple RC network on the switch input port, to a combo RC & Schmitt Trigger buffer, to a RS Flip-Flop or even a 74LS76 JK Flip-Flop Adding any of these options is very possible. But then again the Basic interpreter is very slow
The alternative with the software method involves adding a delay or timer loop in the switch scanning code. But this only adds more latency in the Basic code,which is already slow, this technique is mostly relegated to Machine code or compiled code where it runs faster than Basic code. For the time being, Evan has stated he will confine the programming to Basic code for now. Also now that he has direct control now over the interfaces by using Basic [or machine code], essentially having 'bare metal' programming at his fingertips when using that Lego 9750 box When I worked with Evan last summer on this project, I noticed severe limitations with Logo. I haven't spent enough time debugging the problems in Logo, nor do I really want to, But I think some of these switch problems present a race condition inherent within the Logo language. The Logo platform runs constantly in the background, and his Logo code is running in a Loop, so that same port is accessed by 2 different sources. Logo is really only meant for the simple projects The ports are only checked once by Basic code at a specific point within the Loop. And the loop in the Basic is nothing more complicated than 1. Init Hardware, Motors Off, Lamps Off 2. Read Input = Joystick Control switche 3. Read Input = Limit switche 4 Update State of Motors --> based on inputs 5. goto #2 BTW, Evan you only have 2 sensor input ports on that Lego 9750 box I lost track what you have connected, you should make a diagram to further your documentation I remember one button is connected for the Drive Motor So the other button is connected for the Steering Motor ? Because then you don't have any Sensor Input ports left over, in order to connect a Limit switch on the Steering Motor to prevent damage So I wondered what you had in mind, Dan
Evan you only have 2 sensor input ports on that Lego 9750 box I lost track what you have connected, you should make a diagram to further your documentation I remember one button is connected for the Drive Motor So the other button is connected for the Steering Motor ? Because then you don't have any Sensor Input ports left over, in order to connect a Limit switch on the Steering Motor to prevent damage So I wondered what you had in mind, Dan
Ports 0-5 are for motors and lights. Ports 6-7 are for sensors. I am using one port from the first bank to control the drive motor, another to control the V-8 motor (just for fun; it's not actually connected to the drivetrain, kids don't need to know that!), and a third port to control the steering motor. I used a sensor in the second bank to know when the steering rack (Lego rack-and-pinion steering!) is at its maximum mechanical limit. Joystick buttons and the associated paddle 0/1 have nothing to do with the interface box, that's plugged into the standard Apple game port.
On Wed, Jan 18, 2017 at 3:04 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Evan you only have 2 sensor input ports on that Lego 9750 box
I lost track what you have connected, you should make a diagram to further your documentation I remember one button is connected for the Drive Motor So the other button is connected for the Steering Motor ? Because then you don't have any Sensor Input ports left over, in order to connect a Limit switch on the Steering Motor to prevent damage So I wondered what you had in mind, Dan
Ports 0-5 are for motors and lights. Ports 6-7 are for sensors. I am using one port from the first bank to control the drive motor, another to control the V-8 motor (just for fun; it's not actually connected to the drivetrain, kids don't need to know that!), and a third port to control the steering motor. I used a sensor in the second bank to know when the steering rack (Lego rack-and-pinion steering!) is at its maximum mechanical limit. Joystick buttons and the associated paddle 0/1 have nothing to do with the interface box, that's plugged into the standard Apple game port.
ah ok, I remember now its been a long summer :) also, I wouldn't really say there are multiple banks Those are all connected to the same 8 bit I/O port on the 6522 on that interface card which is essentially only one bank and then you have the individual ports on that one bank Some are input ports, and some are outputs ports and then their associate port# Just like the Game Port Dan
On Wed, Jan 18, 2017 at 3:26 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
also, I wouldn't really say there are multiple banks
Those are all connected to the same 8 bit I/O port on the 6522 on that interface card
Yeah but you know what I meant. English not technobabble.
don't you mean, using the correct terminology versus English-babble you might have to buy a Babel Fish ;)
On 1/18/2017 10:07 AM, Evan Koblentz via vcf-midatlantic wrote:
We already tried using a variable. In that example, I built a Lego V-8 style motor. Pressing joystick button 0 one time starts it. I wanted the next button 0 press to stop it. As Dean said, it didn't work using the variable method because of (we think) timing issues. It works fine in walkie-talkie style mode (Dan that's just like the code you and I made ahead of Maker Faire) where "IF NOT BUTTON? 0 [TTO "(port number) OFF] and it also works fine if I have button 1 turn it off. But our attempts to have button 0 turn it on, change a variable to represent that, then check the variable again upon the next button press and turn it off it the variable = 1 just didn't work reliably. The motor stuttered and * sometimes * turned off. Sometimes it worked reliably for a few minutes and then wouldn't work at all.
Another place where I need to check motor status (port on/off status) is for the steering rack. As in a real car, the steering has a mechanical limit. Imagine if you had superhero strength: you could keep turning the steering wheel at its limit and you'd break some component. In the Lego model, if a kid holds the joystick to one side after that limit is reached, then either the Lego pieces start coming apart or the motor could burn out. So I put the optical sensor there. When the sensor is blocked, it turns off the steering rack port. Kind of ingenious right? :) But it doesn't work because the program does not know which master to obey -- the joystick telling it to spin the steering motor or the sensor telling it to stop! I tried some code saying if the sensor is true and the motor is true then turn off the port, but couldn't get that to work. There is chance it was my code at that point, not the logic.
All these problems could be avoided if I had a simple way to check a port status. "Hey I see a button was pressed? Is the port on? Okay, turn it off. Oh was it off? Okay, turn it on." Evan Koblentz, director Vintage Computer Federation A 501(c)3 educational non-profit http://www.vcfed.org
All these problems could be avoided if I had a simple way to check a port status. "Hey I see a button was pressed? Is the port on? >Okay, turn it off. Oh was it off? Okay, turn it on."
Maybe. Perhaps there is another explanation: Consider whether when you press button 0- does LOGO give you ONE indication or is it as LONG as you hold it it gives you continuous "button pressed" indications? This is a typical problem with button processing. IF LOGO gives you BUTTON PRESSED continuously (as I suspect) then what is happening is you are toggling your motor on and off continuously and when you release it you have a pretty much 50-50 chance of it being on or off. IF this is the case you have to put in specific logic to only process the first indication of the press and ignore the rest until you see a release of the button. Make sure this is not the case, because if is is, the port status in fact will not help at all. They very likely give continuous indication that a button is pressed because that has its purposes too and tends to be a norm in my experience... let the user catch the first one of that is what he(she) is interested in. As for the sensor:
But it doesn't work because the program does not know which master to obey -- the joystick telling it to spin the steering motor or >the sensor telling it to stop! I tried some code saying if the sensor is true and the motor is true then turn off the port
You were on the right track for that, the joystick cannot command the motor if the sensor has triggered. sensor routine shuts off the mother and sets an varaible. Joystick, on press, only starts the motor if the sensor for that direction has not hit. If that logic is not achievable in LOGO then it is a total failure, something must be fixable here. It is normally perfectly reasonable to represent the motor's status in a variable.
Maybe. Perhaps there is another explanation: Consider whether when you press button 0- does LOGO give you ONE indication or is it as LONG as you hold it it gives you continuous "button pressed" indications?
I think just one (unrelated to programming a button press in push-to-talk mode, which is very easy and works great, but I wanted button 0 to work like turning the key in a car, not like a gas pedal.)
As for the sensor:
But it doesn't work because the program does not know which master to obey -- the joystick telling it to spin the steering motor or >the sensor telling it to stop! I tried some code saying if the sensor is true and the motor is true then turn off the port
You were on the right track for that, the joystick cannot command the motor if the sensor has triggered.
But it does. LOGO programs are iterative. It's constantly scanning to see if any input is happening. So you have the optical sensor being activated and telling the steering motor's port to turn off, while you also have the joystick pushed to one side telling the steering motor's port to turn on. That is why I figured some code that says "if both the joystick and the sensor are true, then turn the motor off" would help. But I couldn't get it to work. Dean and I tried a zillion syntax combinations with no luck.
On 1/18/2017 1:26 PM, Evan Koblentz via vcf-midatlantic wrote:
Maybe. Perhaps there is another explanation: Consider whether when you press button 0- does LOGO give you ONE indication or is it as LONG as you hold it it gives you continuous "button pressed" indications?
I think just one (unrelated to programming a button press in push-to-talk mode, which is very easy and works great, but I wanted button 0 to work like turning the key in a car, not like a gas pedal.)
As for the sensor:
But it doesn't work because the program does not know which master to obey -- the joystick telling it to spin the steering motor or >the sensor telling it to stop! I tried some code saying if the sensor is true and the motor is true then turn off the port
You were on the right track for that, the joystick cannot command the motor if the sensor has triggered.
But it does. LOGO programs are iterative. It's constantly scanning to see if any input is happening. So you have the optical sensor being activated and telling the steering motor's port to turn off, while you also have the joystick pushed to one side telling the steering motor's port to turn on. That is why I figured some code that says "if both the joystick and the sensor are true, then turn the motor off" would help. But I couldn't get it to work. Dean and I tried a zillion syntax combinations with no luck. I'll look that up, seems you are saying logo lets you configure the response of the buttons as one-shot or continuous reporting of button pressed = true.
I'll look that up, seems you are saying logo lets you configure the response of the buttons as one-shot or continuous reporting of button pressed = true.
Sort of. What I'm saying is, AFAIK, if you press the button * and let go * then it records one press, which is what I thought you were asking. However if that were true then my PTT code wouldn't work, yet it does :) so you guys are probably right about it reading the button as long as it's pressed. ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
On Wed, Jan 18, 2017 at 01:26:52PM -0500, Evan Koblentz via vcf-midatlantic wrote:
Maybe. Perhaps there is another explanation: Consider whether when you press button 0- does LOGO give you ONE indication or is it as LONG as you hold it it gives you continuous "button pressed" indications?
I think just one
"I think" is where I have wasted more hours looking in the wrong place than I want to admit. Warning: Since you say you aren't a experienced programmer preachy exposition follows. Programming is a house of cards of mental models. When one doesn't match reality you end up with a pile on the table instead of your pretty design. The common models are how does the hardware/language work, what you are trying to accomplish, and the steps the computer needs to do to accomplish it. When you get to the spot where you're saying this should be working you need to see which model/assumption is wrong. In your case you are assuming the behavior of the Lego call and that something is wrong/insufficent with Lego so it can't be accomplished. Switching to Basic will help in that case. If it's really your algorithm/button behavior that is wrong you will end up with the same behavior in Basic. Switching to Basic may have other advantages such as more powerful language and being able to get all the help you can stand from others who know it. The best thing to do when reality doesn't match what you think it should be doing is to try to understand what the underlying difference is. Your assumption is you should get one motor state change per button push. One generally available debugging method is to add a print statement to verify. Add one to the turn motor on and turn motor off path. Then see what you get with the button push. Possible things you could see are not always getting a print, lots of prints, or it prints what you expect but the motor isn't doing what the prints say you commanded it to do. Each leads you down a next step. The multiple prints would question the assumption of one button press event per press. You can do a separate test of just the button press to verify its behavior. I have run into many occasions where the documentation is unclear or flat out wrong on how something operates.
On 1/18/2017 7:58 PM, David Gesswein via vcf-midatlantic wrote:
On Wed, Jan 18, 2017 at 01:26:52PM -0500, Evan Koblentz via vcf-midatlantic wrote:
Maybe. Perhaps there is another explanation: Consider whether when you press button 0- does LOGO give you ONE indication or is it as LONG as you hold it it gives you continuous "button pressed" indications? I think just one "I think" is where I have wasted more hours looking in the wrong place than I want to admit.
Warning: Since you say you aren't a experienced programmer preachy exposition follows.
Programming is a house of cards of mental models. When one doesn't match reality you end up with a pile on the table instead of your pretty design.
The common models are how does the hardware/language work, what you are trying to accomplish, and the steps the computer needs to do to accomplish it.
When you get to the spot where you're saying this should be working you need to see which model/assumption is wrong. In your case you are assuming the behavior of the Lego call and that something is wrong/insufficent with Lego so it can't be accomplished.
Switching to Basic will help in that case. If it's really your algorithm/button behavior that is wrong you will end up with the same behavior in Basic. Switching to Basic may have other advantages such as more powerful language and being able to get all the help you can stand from others who know it.
The best thing to do when reality doesn't match what you think it should be doing is to try to understand what the underlying difference is.
Your assumption is you should get one motor state change per button push. One generally available debugging method is to add a print statement to verify. Add one to the turn motor on and turn motor off path. Then see what you get with the button push. Possible things you could see are not always getting a print, lots of prints, or it prints what you expect but the motor isn't doing what the prints say you commanded it to do. Each leads you down a next step. The multiple prints would question the assumption of one button press event per press. You can do a separate test of just the button press to verify its behavior. I have run into many occasions where the documentation is unclear or flat out wrong on how something operates.
Very beautifully put, Dave!
Very beautifully put, Dave!
Agreed! Educational and authoritative without making me feel stupid. Evan Koblentz, director Vintage Computer Federation A 501(c)3 educational non-profit http://www.vcfed.org
Very beautifully put, Dave!
Agreed! Educational and authoritative without making me feel stupid. Evan Koblentz, director Vintage Computer Federation A 501(c)3 educational non-profit http://www.vcfed.org
^^^ Butchered my .sig there. Sorry... The full one if anyone gives a hoot :) is this: ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
Your assumption is you should get one motor state change per button push. One generally available debugging method is to add a print statement to verify. Add one to the turn motor on and turn motor off path. Then see what you get with the button push. Possible things you could see are not always getting a print, lots of prints, or it prints what you expect but the motor isn't doing what the prints say you commanded it to do. Each leads you down a next step. The multiple prints would question the assumption of one button press event per press. You can do a separate test of just the button press to verify its behavior. I have run into many occasions where the documentation is unclear or flat out wrong on how something operates.
I made a test program in LOGO: when button 0 is pressed, it prints "pressed" on the screen. Ran the program. Each button press results in exactly one printed statement. Holding the button down results in a continuous flow of statements. I'll try testing the real program another time. I considered the version Doug suggested but I'm not sure how to adjust its syntax for Lego LOGO. For now, Dan/Dean are helping me privately with the BASIC approach. I'll report back in a day or two... ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
On 1/19/2017 3:26 AM, Evan Koblentz via vcf-midatlantic wrote:
Your assumption is you should get one motor state change per button push. One generally available debugging method is to add a print statement to verify. Add one to the turn motor on and turn motor off path. Then see what you get with the button push. Possible things you could see are not always getting a print, lots of prints, or it prints what you expect but the motor isn't doing what the prints say you commanded it to do. Each leads you down a next step. The multiple prints would question the assumption of one button press event per press. You can do a separate test of just the button press to verify its behavior. I have run into many occasions where the documentation is unclear or flat out wrong on how something operates.
I made a test program in LOGO: when button 0 is pressed, it prints "pressed" on the screen. Ran the program. Each button press results in exactly one printed statement. Holding the button down results in a continuous flow of statements.
I'll try testing the real program another time.
I considered the version Doug suggested but I'm not sure how to adjust its syntax for Lego LOGO.
For now, Dan/Dean are helping me privately with the BASIC approach.
I'll report back in a day or two... Sounds like they implement a delay / repeat like a PC keyboard. If the delay is long enough to be practical for your toggle use, then what we've been saying may not explain your difficulties with LOGO logic. Can you post the code? Just curious, maybe I can spot something.
On Thu, Jan 19, 2017 at 3:26 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Your assumption is you should get one motor state change per
button push. One generally available debugging method is to add a print statement to verify. Add one to the turn motor on and turn motor off path. Then see what you get with the button push. Possible things you could see are not always getting a print, lots of prints, or it prints what you expect but the motor isn't doing what the prints say you commanded it to do. Each leads you down a next step. The multiple prints would question the assumption of one button press event per press. You can do a separate test of just the button press to verify its behavior. I have run into many occasions where the documentation is unclear or flat out wrong on how something operates.
I made a test program in LOGO: when button 0 is pressed, it prints "pressed" on the screen. Ran the program. Each button press results in exactly one printed statement. Holding the button down results in a continuous flow of statements.
I'll try testing the real program another time.
I considered the version Doug suggested but I'm not sure how to adjust its syntax for Lego LOGO.
For now, Dan/Dean are helping me privately with the BASIC approach.
I'll report back in a day or two...
yea, we're making progress. But I just might have to borrow that plastic noodle from Jeff the he used over the VCFed Calendar incident :) you know, to give you some additional motivation Maybe this time I should fill up the plastic noodle with cement to increase the effectiveness But I wouldn't want to create an incident over this, it wouldn't be appropriate Luckily my stitches are out now from surgery, otherwise I might bust one from the exertion, while chuckling of course :) I can see it now, reprinted in the comics Police: sir, why is this geek lying on the floor unconscious ? Me: I kept trying to teach him the Art of Programming for his new project Police: but why is he unconscious me: I kept trying to show him how to program the interface on his computer for his robot Police: sir, how did he wind up unconcious on your floor Me: he wouldn't listen that you don't need to Read an Output port on a 6522 VIA Police: OK.......... Me: I kept telling him to use a variable Police: Alright......... Me: so I wacked him with my plastic noodle Police: sir, there's cement in this plastic noodle
ROTFLMAO! 😂😂 :-) :-D X-D On Thu, Jan 19, 2017 at 9:38 AM Dan Roganti via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Thu, Jan 19, 2017 at 3:26 AM, Evan Koblentz via vcf-midatlantic <
vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Your assumption is you should get one motor state change per
button push. One generally available debugging method is to add
a print statement to verify. Add one to the turn motor on
and turn motor off path. Then see what you get with the button
push. Possible things you could see are not always getting a print, lots
of prints, or it prints what you expect but the motor isn't doing
what the prints say you commanded it to do. Each leads you down
a next step. The multiple prints would question the assumption
of one button press event per press. You can do a separate test
of just the button press to verify its behavior. I have run into
many occasions where the documentation is unclear or flat out wrong
on how something operates.
I made a test program in LOGO: when button 0 is pressed, it prints
"pressed" on the screen. Ran the program. Each button press results in
exactly one printed statement. Holding the button down results in a
continuous flow of statements.
I'll try testing the real program another time.
I considered the version Doug suggested but I'm not sure how to adjust its
syntax for Lego LOGO.
For now, Dan/Dean are helping me privately with the BASIC approach.
I'll report back in a day or two...
yea, we're making progress.
But I just might have to borrow that plastic noodle from Jeff the he used
over the VCFed Calendar incident :)
you know, to give you some additional motivation
Maybe this time I should fill up the plastic noodle with cement to increase
the effectiveness
But I wouldn't want to create an incident over this, it wouldn't be
appropriate
Luckily my stitches are out now from surgery, otherwise I might bust one
from the exertion,
while chuckling of course :)
I can see it now, reprinted in the comics
Police: sir, why is this geek lying on the floor unconscious ?
Me: I kept trying to teach him the Art of Programming for his new project
Police: but why is he unconscious
me: I kept trying to show him how to program the interface on his computer
for his robot
Police: sir, how did he wind up unconcious on your floor
Me: he wouldn't listen that you don't need to Read an Output port on a 6522
VIA
Police: OK..........
Me: I kept telling him to use a variable
Police: Alright.........
Me: so I wacked him with my plastic noodle
Police: sir, there's cement in this plastic noodle
On 01/19/2017 09:38 AM, Dan Roganti via vcf-midatlantic wrote:
Police: sir, why is this geek lying on the floor unconscious ? Me: I kept trying to teach him the Art of Programming for his new project Police: but why is he unconscious me: I kept trying to show him how to program the interface on his computer for his robot Police: sir, how did he wind up unconcious on your floor Me: he wouldn't listen that you don't need to Read an Output port on a 6522 VIA Police: OK.......... Me: I kept telling him to use a variable Police: Alright......... Me: so I wacked him with my plastic noodle Police: sir, there's cement in this plastic noodle
It's technical name is a concrete clue bat. I need to replace mine ... ;-) -- Linux Home Automation Neil Cherry ncherry@linuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies
About the Apple version, you could always translate the IBM Basic to Apple Basic. Becasue its the same 9750 interface box, just a different interface card in the slot. So just the memory-mapped address for that interface card changes. The ports which are accessed by software pointing to the input and out ports on the 9750 will be the same, Becasue your not changing the wiring inside that 9750.
That hardware on the interface card will have a specific Memory Address, in case of the PC it will be I/O Port address, maybe a couple.It should be documented somewhere, If not, it can be reverse engineered from the schematics of that interface card.
Keeping this super-clear: there exist two Lego cards, one is IBM/BASIC and the other is Apple/LOGO. Are you saying we would need to construct a new card to use Apple/BASIC, or are you saying the existing Apple/LOGO card can be used with BASIC if we make some software changes? This is the initialization code which is required at the beginning of every Lego BASIC program: http://vcfed.org/evan/basic_init.txt. This is the Apple card schematic: http://lukazi.blogspot.com/2014/07/lego-legos-first-programmable-product.htm.... ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation
On Wed, Jan 18, 2017 at 11:28 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
About the Apple version, you could always translate the IBM Basic to Apple
Basic. Becasue its the same 9750 interface box, just a different interface card in the slot. So just the memory-mapped address for that interface card changes. The ports which are accessed by software pointing to the input and out ports on the 9750 will be the same, Becasue your not changing the wiring inside that 9750.
That hardware on the interface card will have a specific Memory Address, in case of the PC it will be I/O Port address, maybe a couple.It should be documented somewhere, If not, it can be reverse engineered from the schematics of that interface card.
Keeping this super-clear: there exist two Lego cards, one is IBM/BASIC and the other is Apple/LOGO. Are you saying we would need to construct a new card to use Apple/BASIC, or are you saying the existing Apple/LOGO card can be used with BASIC if we make some software changes?
This is the initialization code which is required at the beginning of every Lego BASIC program: http://vcfed.org/evan/basic_init.txt.
This is the Apple card schematic: http://lukazi.blogspot.com/201 4/07/lego-legos-first-programmable-product.html.
dude that was from 2:30am a lot has changed since then, catch up on your emails :) and no you don't have to redesign anything, the same cards apply, in this case the Apple interface card, so you can continue programming BUT disregard all of that now did you read the one I just resent at 11:09am that what you should be looking at and the reading the manual I mentioned in that email Dan
On 01/17/2017 11:17 PM, Evan Koblentz via vcf-midatlantic wrote:
I decided to try to cookbook series. Getting it now...
Or: Don L. was trying to sell more books. Very next sentence on that page: "There is a series of nine discovery modules in Volume II of Don Lancaster's Micro Cookbook..."
I love Don Lancaster's stuff! I've not read all of it but I do recall learning how to do reverse engineering with Don Lancaster's Cookbook (? not sure if it was part of the series). Remember that I had an Atari 800xl and he was referencing the Apple ][ series. If anyone has seen my little red notebook with the Apple sticker on it, that's my notes from when I was reading the series (when Don first printed these books). I used the Omnimon XL instead of the Apple Monitor. As far as assembly language books go, I love the books of Lance Levanthal. Having said all of that, computer languages come pretty easy to me. I have had trouble with Intel's memory access (far, near, argh!) and the PIC chips memory layout (banked memory). -- Linux Home Automation Neil Cherry ncherry@linuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies
IMHO, the difficult bit with assembly language is that you have to keep track of all the "book keeping" needed by your algorithm. If you need 10 variables, and array of 100 integers, and pointers to subroutines, then you have to keep track of all this stuff yourself. This means that you have to start planning on paper long before you write your first opcode. Of course, it also means that you have to be familiar with the machine architecture, how many registers it has, how much stack, etc, so that you can figure out WHERE you are going to store all the stuff you need. In comparison, with a high level language, one can just declare a bunch of variables and an array, and the compiler does all the book keeping for you. It's still advisable to make a plan before you start coding, but you don't have to know the addressing modes of the CPU, etc. So, my suggestion for learning assembler would be: run through some tutorials to learn the machine architecture and what operations the CPU is capable of. (Can it do indirect jumps? relative jumps? indexed addressing of storage?) Once you sort of have a grasp of machine architecture and the instruction set, set yourself a problem to solve, and try to plan out how you'd attack it ON PAPER (or virtual paper, in a text file.) I would write my plan down as comment lines in a text file, and then when it was time to code, code up each section between the comment lines. I was an embedded developer for many years. Initially, I wrote everything in Z80 assembler. Later, when compilers (and cross compilers) became readily available, I would code in C, and then hand optimize the assembler output of the C compiler for the nasty bits that had to run extra fast. I never got particularly good at X86 assembler, but I learned enough to be able to hack the compiler output so my application would run faster. Just for the hell of it: here are two articles I had published "back in the day": This first one is about hacking the CPM command processor so that it has Emacs-style command history. This work was all in Z80 assembler, running on an 64180 with banked memory available for the history storage: http://www.dudley.nu/MicroSystemsJournal_article_198609.pdf This second article was the cover story in the August 1990 Dr Dobb's Journal, about converting a "real mode" X86 application to run in "protected mode". The application was a electronics CAD package, written in C, and the protected mode code was a fair amount of 386 assembler: http://www.casano.com/ddj_0890.html Bill Dudley This email is free of malware because I run Linux. On Wed, Jan 18, 2017 at 8:24 AM, Neil Cherry via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On 01/17/2017 11:17 PM, Evan Koblentz via vcf-midatlantic wrote:
I decided to try to cookbook series. Getting it now...
Or: Don L. was trying to sell more books. Very next sentence on that page:
"There is a series of nine discovery modules in Volume II of Don Lancaster's Micro Cookbook..."
I love Don Lancaster's stuff! I've not read all of it but I do recall learning how to do reverse engineering with Don Lancaster's Cookbook (? not sure if it was part of the series). Remember that I had an Atari 800xl and he was referencing the Apple ][ series. If anyone has seen my little red notebook with the Apple sticker on it, that's my notes from when I was reading the series (when Don first printed these books). I used the Omnimon XL instead of the Apple Monitor. As far as assembly language books go, I love the books of Lance Levanthal.
Having said all of that, computer languages come pretty easy to me. I have had trouble with Intel's memory access (far, near, argh!) and the PIC chips memory layout (banked memory).
-- Linux Home Automation Neil Cherry ncherry@linuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/ My HA Blog Author of: Linux Smart Homes For Dummies
On Jan 17, 2017, at 21:56, Systems Glitch via vcf-midatlantic <vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I need a book that reeeeeeeeeeally simplifies the concepts.
Do remember you're trying to make a CPU do your bidding at the machine language level :)
Take a look through the book I recommended ("Programming and Interfacing the 6502, with Experiments," Marvin L. DeJong). You can find PDF copies of questionable legal standing all over the Internet. I wouldn't be surprised if we have a print copy somewhere in the museum, but it's usually a very cheap book anyway.
Don't gloss over the parts about hardware organization. It's important. If you don't understand something, ask questions.
Seconded. The thing to remember is that, at its core, a CPU (especially one as simple as the 6502) is a pretty dumb machine. All it does is fetch an instruction from memory, perform that instruction (which is usually along the lines of "add this", "load this from here", "store that to there", "jump to this instruction", etc.), then load the next one. The CPU can't do too much; it's just a fancy calculator. I'll be happy to give you a little tutorial tomorrow evening if you want. Assembly and machine language have a reputation for being difficult, but really it's probably the simplest part. The difficult part is working out how the low-level concepts (add/subtract, load/store, jump, etc.) map to higher level concepts (loops, text output, functions, etc.). That just takes practice. - Dave
On Tue, Jan 17, 2017 at 7:10 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I figure it's smart to stick with the mini-assembler until I learn a few things before moving to a full-fledged assembler like Merlin.
VCFed owns a few Laser 128s. Ian explained to me that the 128 is basically a //c with an expansion card slot. That may be good for me, ** if it has the older version of the mini-assembler **, because I have limited desk space and the small system is easier to bring to events. I will test our 128s this weekend -- step one, do any of them work, and step two, which version of the mini assembler. (Or can someone who has a Laser 128 test this for me sooner? Just see if it takes the F666G or ! to enter the mini assembler, then report back.)
hmm, this is interesting, about the Laser 128, I couldn't find an emulator for that yet, But then after digging up some more info I see that even though it was compatible with a ][c externally Internally, the Roms were compatible with the Enhanced ][e, so it has both the Applesoft Roms and the Mini-Assembler then you just use the "!" at the Monitor prompt, just as when running the emulator in Enhanced ][e mode maybe you still want someone to confirm this Dan
On 1/17/2017 7:04 PM, Evan Koblentz via vcf-midatlantic wrote:
Dan's suggestion worked: typing an exclamation inside the monitor brought me into the mini-assembler.
I need a book * specifically * for the enhanced/Platinum model. Otherwise I won't know which mistakes are mine vs which are differences in the computer.
Some of you will advise me to just get an older Apple II instead :) but I don't have space for another system.
Evan Koblentz, director Vintage Computer Federation A 501(c)3 educational non-profit http://www.vcfed.org
Or if you can't locate a book that pertains to the platinum (perhaps no one wrote one) you may find documentation of a definitive list of the differences between a II and a platinum explained so you can spot the things the book you have talks about that won't work or work differently on the platinum. I doubt there are too many more things you will run across that will trip you up.
Are you not going to use an Apple II emulator to start with?
Turns out LinApple emulates the enhanced version, same as what's on my //. Its not configurable? http://linapple.sourceforge.net/ says LINux emulator of APPLE][, Apple][+, Apple//e, and Enhanced Apple//e computer.
On Tue, Jan 17, 2017 at 4:44 PM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Dan's suggestion worked: typing an exclamation inside the monitor brought me into the mini-assembler.
I need a book * specifically * for the enhanced/Platinum model. Otherwise I won't know which mistakes are mine vs which are differences in the computer.
Some of you will advise me to just get an older Apple II instead :) but I don't have space for another system.
Evan Koblentz, director Vintage Computer Federation A 501(c)3 educational non-profit http://www.vcfed.org
oh, that was John Linville who uncovered that tidbit I just verified it here I don't recall what specific features are in the ][e platinum, I have one too so I better look, that would inhibit you from coding assembly for the Apple ][ in general. or require a specific assembly book for that platform Didn't the Apple Logo run on any Apple ][ platform, maybe except the ][c So any Assembly coding shouldn't matter either I'm going to look around some more too, so I'm just thinking out loud for now Dan
Some of you will advise me to just get an older Apple II instead :) but I don't have space for another system.
Get an older Apple :P Seriously though, it shouldn't matter which Apple you have, as long as you can get to the ROM monitor. I wouldn't think too hard about the built-in assembler -- it's not a big step over paper and an opcode table, and if/when you start doing more complex programs you'll want a real assembler that takes edit-able source files. IIRC the Apple II does have a *disassembler* which can be incredibly useful. As to modern stuff, I *really* like this in-browser JavaScript 6502 simulator: http://www.masswerk.at/6502/ He's got an assembler, disassembler, and instruction set summary linked below, too. Of course, its biggest advantage was being able to run it on my work computer when I was waiting on something to finish (test run, client to return a call, whatever). Thanks, Jonathan
On 1/17/2017 4:44 PM, Evan Koblentz via vcf-midatlantic wrote:
Dan's suggestion worked: typing an exclamation inside the monitor brought me into the mini-assembler.
I need a book * specifically * for the enhanced/Platinum model. Otherwise I won't know which mistakes are mine vs which are differences in the computer.
Some of you will advise me to just get an older Apple II instead :) but I don't have space for another system.
Well, you really don't want to use the mini-assembler for more than the introductory exercises, anyway, which is the source of all your computer specific problems. Here are couple of options: Consider Merlin 8bit: http://mirrors.apple2.org.za/ftp.apple.asimov.net/images/programming/assembl... Merlin is an IDE (and macro assembler.. just trust me, that's a really good thing) that will make life much easier programming 6502 directly on your IIe. The text editor is, well, different, though. My preference is Merlin 16bit on the IIgs, but I know you don't want to bring a IIgs into the equation. Consider, however, Merlin 32bit for Windows/Linux/MacOSX etc.: http://www.brutaldeluxe.fr/products/crossdevtools/merlin/ Then you have to find a way to get the files onto a disk for your IIe (a bit a of a problem, unless you are lucky enough to have a CFFA card... in which case life is easy). "Assembly Lines" use Merlin syntax and all three of these are directly compatible with the book. Best wishes, -Adam
participants (11)
-
Adam Michlin -
Dan Roganti -
David Gesswein -
David Riley -
Dean Notarnicola -
Douglas Crawford -
Evan Koblentz -
Jeffrey Brace -
Neil Cherry -
Systems Glitch -
William Dudley