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