[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AppleSoft Basic to text



>      Yes-- messed up there-- if you can print out to the IIe,
> then the stuff should appear on the IIe screen and be entered
> as though typed in. As long as the print speed does not exceed
> the ability of the IIe to enter each BASIC line, you should
> end up with the program in memory on the IIe.

Yes, as mentioned in my previous reply and the ADT documents,
this is 300 baud. At least in normal circumstances. It may be
possible to get higher speeds on an accelerated system. With
this method the text must be clean code. No erroneous
characters.

Normally, I would recommend Program Writer, but I'm not sure
if there is a Dos 3.3 version. I think the ProDOS version might
work as I use a slightly modified version of it in my Amperdos
Basic programming system. You will have to hack it though. The
changes I made were to patch into my & vector jumps which you
should not have to do. You will have to modify the startup code.
The problem here, PW uses the Basic.System's get buffer routine.
To get around this, tack a simple subroutine at the end of the
code file which lowers HIMEM by 4 (4 pages per buffers requested
from Basic.) Then modify the call that request the buffers to
branch (jsr most likely) to the new subroutine. This really is
harder to explain than to do. :-)

There is another problem with using Program Writer this way. It
wouldn't be able to save it's configuration data. It should be
possible to hack the default values, I just haven't tried this
yet. Of course, there are other, simpler Applesoft editors for
Dos 3.3 as well as text editors. Applewriter comes to mind.

There are drawbacks to editing the code directly on the robot.
One, there would be no automatic backup of the code as there
would be from transferring and editing it on the GS. Two,
programming directly on the robot may be a little awkward for
anything longer than a few lines. These too can be circumvented.
One, save to floppy and copy to the GS. Number two may be a
little harder depending on the robot's design. A keyboard with
a cable which could be used away from the robot would help.

Or... Maybe someone could write an ASCII only printer driver
which sends only the raw ascii characters through the port. of
course you have the speed limit if the code is being loaded to
Applesoft and translated into basic code.

As we all know, there are many different methods to do anything
we desire. This is one of the reason the Apple II became so
popular. It allows us to explore the variety of options and do
things the way we wanted them done. In today's GUI world, things
are not so easy. With the exception of Unix oriented systems and
X (Xwindows gui), most systems and OS's try and shield the user
from this capability. In essence, trapping the user in the
limitations of the system/OS as defined by someone else. Oh
well, the era of the computing appliance has arrived.

Many of use still love to tinker with hardware and software at
it's most basic level. We are now the minority. Contrast this
with with the early age of 'personal computers' where the
technical expertise was almost a prerequisite.

-- 

Thank you for your time and interest. I hope it was helpful
or at least interesting.

Phoenyx,

Apple2 user since March 1984

Links to Phoenyx's pages:
preferred..... http://zip.to/Phoenyx_A2
alternate..... http://www.tinyangeldesigns.com/Apple2