Windows-Applesoft Programmer Software
Charlie
It is a Windows based Applesoft BASIC programmer (editor, IDE, whatever you
want to call it) that works in conjunction with AppleWin. It is not
bug-free but it is generally usable (at least on my machine with Windows
XP).
With WASP you can write programs from scratch or load them from disk images.
You can then run them in AppleWin with one click of a button.
If you decide to use it please read the documentation and Read Me.txt file
(included) as there are some 'features' that need some explanation.
More information and download at:
http://mysite.verizon.net/charlie.d/wasp.htm
If (when) you find bugs please report them to:
And put the words WASP & bug in the title.
Happy New Year,
Charlie
Charlie
"Charlie" <charl...@verEYEzon.net> wrote in message
news:MqY6l.2372$BC4....@nwrddc02.gnilink.net...
It has been reported (and I can confirm) that WASP doesn't work properly in
Windows 95.
I have also found that the WASP help files need Internet Explorer 5.0 or
higher to display properly.
Although this has nothing to do with WASP's problems, I have also found that
some later versions of AppleWin do not work in Windows 95.
AppleWin 1.14.2 does not run at all in Windows 95.
AppleWin 1.12.7.2 seems to run okay in Windows 95.
Charlie
Bill Buckels
"Charlie" <charl...@verEYEzon.net> wrote:
>I've written a program (WASP) that you can download if you are interested.
Who wouldn't be:) This is too cool! I love the color coding.
>It is not bug-free but it is generally usable (at least on my machine with
>Windows XP).
I'll give it a try on Vista at work tomorrow. My XP SP2 is the same as yourn
no naturally it works:)
>With WASP you can write programs from scratch or load them from disk
>images.You can then run them in AppleWin with one click of a button.
Christmas came late, but just in time for New Years!
>If you decide to use it please read the documentation and Read Me.txt file
>(included) as there are some 'features' that need some explanation.
I'm happy you didn't try to make this perfect and hold it back. No point
really. Too well done.
>If (when) you find bugs please report them to:
OK. But you must mean "stingers" though:) I should write you a CGI...
here's the basic idea:)
http://www.teacherschoice.ca/bugs/
I'll let you know how Vista likes this, and Willi should try this in WIN98SE
which should likely Work.
Really neat!
Bill
Charlie
"Bill Buckels" <bbuc...@mts.net> wrote in message
news:KRA8l.93096$X05....@newsfe03.iad...
>
> "Charlie" <charl...@verEYEzon.net> wrote:
>
>>I've written a program (WASP) that you can download if you are interested.
>
> Who wouldn't be:) This is too cool! I love the color coding.
I'm glad you like it.
>
>>It is not bug-free but it is generally usable (at least on my machine
>>with
>>Windows XP).
>
> I'll give it a try on Vista at work tomorrow.
That would be great.
> My XP SP2 is the same as yourn
> no naturally it works:)
>
>>With WASP you can write programs from scratch or load them from disk
>>images.You can then run them in AppleWin with one click of a button.
>
> Christmas came late, but just in time for New Years!
>
>>If you decide to use it please read the documentation and Read Me.txt file
>>(included) as there are some 'features' that need some explanation.
>
> I'm happy you didn't try to make this perfect and hold it back. No point
> really. Too well done.
>
>>If (when) you find bugs please report them to:
>
> WASPr...@verizon.net
>
> OK. But you must mean "stingers" though:)
You know, I never thought of that ;-)
> I should write you a CGI...
> here's the basic idea:)
>
> http://www.teacherschoice.ca/bugs/
>
Wow, nice. The thing is though, I don't have my own domain and no control
over the simple web page that verizon gives me. So I'll have to be satisfied
with a dedicated email address for WASP.
> I'll let you know how Vista likes this, and Willi should try this in
> WIN98SE
> which should likely Work.
>
> Really neat!
>
> Bill
Thanks Bill. The feedback is appreciated.
Charlie
Moose
> I've written a program (WASP) that you can download if you are interested.
> It is a Windows based Applesoft BASIC programmer (editor, IDE, whatever you
> want to call it) that works in conjunction with AppleWin.
WOW !!! What a great idea !!!!!!!! :)
I'm going to test this out tonight. I'm not sure if this is possible
or included, but it would be great to link WASP with a BASIC compiler
so you can compile your BASIC and save this to DSK.
Moose
If this could be done, then maybe WASP could also toggle AppleWin's
speed to "fastest possible" before the compile and back to normal
after the compile.
xorxif
(using an Apple compiler as a guide) to compile it into a binary, then
use Ciderpress to save it to a disk image?
I always wondered what my old basic programs would run like if compiled.
- xorxif
BluPhoenyx
Sounds like the Beagle compiler would work well for both cases. It's
fast, reasonably transparent to the user, eliminates most compatibility
issues other BASIC compilers have with Applesoft and the later version
supports several memory architectures. Plus, it's freely usable! One
possible problem, it's only for ProDOS 8 but there are other compilers
for DOS.
Cheers,
Mike T.
BluPhoenyx
Sounds like the Beagle compiler would work well for both cases. It's
johnsonlam
> With WASP you can write programs from scratch or load them from disk images.
> You can then run them in AppleWin with one click of a button.
That's exactly what I wanted.
Thanks Charlie!
Rgds,
Johnson.
BLuRry
The Microsoft basic compiler seemed to work reasonably well in Dos 3.3
from what I remember. Ah, the good ol' days of non-bloated WORKING
Microsoft programs!
-B
BLuRry
How does the hook into AppleWin work, exactly? Is it possible to
expand on?
-B
Charlie
"johnsonlam" <johnso...@gmail.com> wrote in message
news:b2c40d5f-a625-4eb6...@x16g2000prn.googlegroups.com...
You're welcome.
By the way I'm pretty sure that it was a request you made some time ago that
got me started thinking about writing WASP.
So, thank you.
Charlie
Charlie
"BLuRry" <brendan...@gmail.com> wrote in message
news:edb27671-1045-408c...@k9g2000vbl.googlegroups.com...
> How does the hook into AppleWin work, exactly? Is it possible to
> expand on?
> -B
There really isn't any hook. AppleWin (at least the later versions) is
already set up to receive whatever is in the clipboard when you press the
Shift and Insert keys. AppleWin does all the real work.
Here's the code for injecting text ( running a program works the same way
except WASP does some fiddling with the text and adding the NEW and RUN
commands, etc. )
case IDM_INJECT: // send text to the emulator
{
CHARRANGE chrrange;
CHARRANGE chrrangehold;
if(!TestEmu()) return 0; // is emulator running? If not send an
error message
ClearClipboard();
SendMessage (GetActiveEdit(hwndClient), EM_EXGETSEL, 0,
(LPARAM)&chrrangehold) ; // save original selection
SetForegroundWindow(hwndEmu); // bring emulator to front
SetFocus(hwndEmu); // give emulator focus
chrrange.cpMin = 0;
chrrange.cpMax = -1;
SendMessage (GetActiveEdit(hwndClient), EM_EXSETSEL, 0,
(LPARAM)&chrrange) ; // select all
SendMessage (GetActiveEdit(hwndClient), WM_COPY, 0, 0) ; // copy
to clipboard
EmuPaste(); // send it to emulator
SendMessage (GetActiveEdit(hwndClient), EM_EXSETSEL, 0,
(LPARAM)&chrrangehold); // put back original selection
return 0;
}
/* simulates the pressing of the left shift and insert keys for pasting into
emulator */
VOID EmuPaste(VOID)
{
DWORD t1, t2;
t1 = t2 = GetTickCount();
while (t2 < (t1 + 300)) t2 = GetTickCount(); // delay
keybd_event(VK_SHIFT,0,0,0); // Shift down
keybd_event(VK_INSERT,0,KEYEVENTF_EXTENDEDKEY,0); // Insert down
t1 = t2 = GetTickCount();
while (t2 < (t1 + 100)) t2 = GetTickCount(); // delay
keybd_event(VK_INSERT,0,KEYEVENTF_KEYUP | KEYEVENTF_EXTENDEDKEY,0); //
Insert up
keybd_event(VK_SHIFT,0,KEYEVENTF_KEYUP,0); // Shift up */
return;
}
The delay stuff may not be needed. I need to do some more experimenting
with that.
By the way, WASP should work with any emulator that implements a
Shift+Insert mechanism. I don't know if there are any. The only necessary
change in WASP would be to add the emulator's name to the WASP.ini file.
Charlie
BLuRry
> Shift+Insert mechanism. I don't know if there are any. The only necessary
> change in WASP would be to add the emulator's name to the WASP.ini file.
Ok. :-) Thanks for the heads up. Sounds easy enough to do.
johnsonlam
> You're welcome.
> By the way I'm pretty sure that it was a request you made some time ago that
> got me started thinking about writing WASP.
> So, thank you.
Really appreciate making WASP, thank you.
I still coding Applesoft for fun and leisure, since Applesoft don't
have an editor, modifying the code is really a pain.
With syntax highlighting, coding become much easier.
If possible, maybe someone can help to add a "preview" output
(Applesoft simulation).
Haapy New Year!
Rgds,
Johnson.
Shawn B.
> I'll give it a try on Vista at work tomorrow. My XP SP2 is the same as
> yourn
> no naturally it works:)
>
I confirm this works just fine on Windows Server 2008 Datacenter 64-bit SP1
without any problems. (Haven't tried to run load the program into an
emulator).
screenshot:
http://www.lookwrite.com/images/Wasp027_WDSx64.png (200k) (watch out for
image resizing in IE)
Thanks,
Shawn
Charlie
"Shawn B." <lea...@html.com> wrote in message
news:I5V8l.10330$as4....@nlpi069.nbdc.sbc.com...
Looks neat. Thanks Shawn.
Charlie
Charlie
Hmmm, that's what AppleWin does (as long as its running concurrently with
WASP).
1. write your Applesoft program.
2. click the 'running man' button in the toolbar.
3. program runs in AppleWin.
Or am I misunderstanding what you mean?
Charlie
Charlie
"Moose" <the_ma...@yahoo.com.au> wrote in message
news:4b3d2ee7-1699-46ab...@a12g2000pro.googlegroups.com...
On Jan 6, 4:21 pm, Moose <the_masta2...@yahoo.com.au> wrote:
> On Jan 1, 3:22 pm, "Charlie" <charlieD...@verEYEzon.net> wrote:
>
> > I've written a program (WASP) that you can download if you are
> > interested.
> > It is a Windows based Applesoft BASIC programmer (editor, IDE, whatever
> > you
> > want to call it) that works in conjunction with AppleWin.
>
> WOW !!! What a great idea !!!!!!!! :)
>
> I'm going to test this out tonight. I'm not sure if this is possible
> or included, but it would be great to link WASP with a BASIC compiler
> so you can compile your BASIC and save this to DSK.
Well, anything is possible but the idea behind WASP is to let the emulator
do as much of the work as possible. For instance, all the saving to DSK by
the WASP save dialog is actually done by sending commands to the emulator
the same way you would if you were using the emulator by itself. The whole
idea is kind of clunky but it works.
> If this could be done, then maybe WASP could also toggle AppleWin's
> speed to "fastest possible" before the compile and back to normal
> after the compile.
Toggling AppleWin's speed *may* be possible. I'll have to look into that.
Charlie
Michael J. Mahon
> Hi,
>
>> You're welcome.
>> By the way I'm pretty sure that it was a request you made some time ago that
>> got me started thinking about writing WASP.
>> So, thank you.
>
> Really appreciate making WASP, thank you.
>
> I still coding Applesoft for fun and leisure, since Applesoft don't
> have an editor, modifying the code is really a pain.
> With syntax highlighting, coding become much easier.
WASP is a fine Applesoft editor for Windows, but Program Writer is also
a fine Applesoft editor for ProDOS. You might want to give it a try
sometime. ;-)
-michael
******** Note new website URL ********
NadaNet and AppleCrate II for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Bill Buckels
It is neat. The idea is so simple and clean. I love automatons. I have
automated production programs that I wrote in C++ running right now at the
client site and even back in my WinRobot days in the mid-90's in Win 3.1 my
C programs did the automated thingy too.
Runs on Vista too. I'll get a screenshot today if I can.
Bill
Bill Buckels
http://www.aztecmuseum.ca/tests/wasp.htm
My Vista test evidence is at the link above. Charlie D. apparently did a
great job with a great idea.
Thank-you.
Bill
Charlie
Well thank-you for the testing and the great pictures. I'm certainly happy
Vista likes WASP. Unfortunately, WASP in Windows 98se has a problem. The
version of the Riched32.dll that comes with Windows 98se handles carriage
returns differently than the one on XP and presumably VISTA. Installing a
newer DLL fixes the problem but could break other programs so...
I'm trying to come up with a solution that will work in both.
There is at least one other bug that appears in Windows 98se that doesn't in
XP and when running in Windows 95, WASP is pretty much unusable so I've got
my work cut out for me.
Charlie
Bill Buckels
"Charlie" <charl...@verEYEzon.net> wrote:
>Well thank-you for the testing and the great pictures. I'm certainly happy
>Vista likes WASP. Unfortunately, WASP in Windows 98se has a problem.
I would hate to see such a good product broken because it needs to work on
an old version of Windows. THAT unfortunately sort-of sounds like "the great
eraser".
Thanks for the heads-up. I'll hang-on to this version.
>The version of the Riched32.dll that comes with Windows 98se handles
>carriage returns differently than the one on XP and presumably VISTA.
>Installing a newer DLL fixes the problem but could break other programs
>so...
What other programs?
The majority of the World is running Windows XP. Maybe it will fix other
programs so they run in Windows 98se.
>I'm trying to come up with a solution that will work in both.
Just suggest the patch at their own risk.
>There is at least one other bug that appears in Windows 98se that doesn't
>in XP
I wouldn't call that a bug. The program is written for Windows XP and
probably works in other Windows like Server 2003 and so forth which are in
the vast majority.
>and when running in Windows 95, WASP is pretty much unusable so I've got my
>work cut out for me.
The fact that this runs on the vast majority of computers world wide but
does not run on an OS that was released 11 - 14 years ago is particularly
not worth risking the product for.
Having said that, I'm glad you did the tests. Now we know.
Bill
BLuRry
> does not run on an OS that was released 11 - 14 years ago is particularly
> not worth risking the product for.
I thought we liked coding for old micros here. ;-)
-B
Charlie
>
> "Charlie" <charl...@verEYEzon.net> wrote:
>
>>Well thank-you for the testing and the great pictures. I'm certainly
>>happy
>>Vista likes WASP. Unfortunately, WASP in Windows 98se has a problem.
>
> I would hate to see such a good product broken because it needs to work on
> an old version of Windows. THAT unfortunately sort-of sounds like "the
> great
> eraser".
I agree with you. I have no intention of breaking any part of WASP so that
it will run in older versions of Windows. If worse comes to worse I *may*
write a separate WASP 'lite' that will work in older versions of Windows but
will sacrifice a feature or two.
>
> Thanks for the heads-up. I'll hang-on to this version.
>
>>The version of the Riched32.dll that comes with Windows 98se handles
>>carriage returns differently than the one on XP and presumably VISTA.
>>Installing a newer DLL fixes the problem but could break other programs
>>so...
>
> What other programs?
Essentially any Windows program that uses 'rich text'. There are many such
as, WordPad and MSPaint.
> The majority of the World is running Windows XP. Maybe it will fix other
> programs so they run in Windows 98se.
You may be right :-)
>>I'm trying to come up with a solution that will work in both.
>
> Just suggest the patch at their own risk.
>
Well, for the time being that's exactly what I'm going to do. But I'm still
going to make an attempt to fix things. As BLuRy mentioned jokingly in a
subsequent post "we liked coding for old micros here".
>>There is at least one other bug that appears in Windows 98se that doesn't
>>in XP
>
> I wouldn't call that a bug. The program is written for Windows XP and
> probably works in other Windows like Server 2003 and so forth which are in
> the vast majority.
I have remote access to a server that is running Windows Server 2003 so I
intend to sneak in and test it there ;-)
>
>>and when running in Windows 95, WASP is pretty much unusable so I've got
>>my
>>work cut out for me.
>
> The fact that this runs on the vast majority of computers world wide but
> does not run on an OS that was released 11 - 14 years ago is particularly
> not worth risking the product for.
>
> Having said that, I'm glad you did the tests. Now we know.
The main reason I released WASP for download was that although I like to
code, I hate to test. So I figured I'd let you guys do the testing ;-)
I should mention that I've only received a bug report from one person and
that had to do with a cosmetic problem with the documentation (in Windows
95). So either, as you say, no one is using Windows95/98 or more likely no
one is using WASP :-(
Charlie
Andy McFadden
> Well thank-you for the testing and the great pictures. I'm certainly happy
> Vista likes WASP. Unfortunately, WASP in Windows 98se has a problem. The
> version of the Riched32.dll that comes with Windows 98se handles carriage
> returns differently than the one on XP and presumably VISTA. Installing a
> newer DLL fixes the problem but could break other programs so...
The Rich Edit dialog saved me a lot of time and caused me a lot of grief
with CiderPress. There's a lot of workarounds and "the following exact
order of operations works, don't mess with it" comments in
app/ViewFilesDialog.cpp.
If you put a copy of Riched32.dll in the application installation directory,
will Windows prefer to use that over the system copy? I vaguely recall doing
something like this once upon a time. If that works, the updated DLL will
only affect your application.
--
Send mail to fad...@fadden.com (Andy McFadden) - http://www.fadden.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/
Bill Buckels
Old Apple Micros... I thought. This is such a cool idea that I am hoping it
won't get drowned in the batchwater of legacy DLL HELL! It's bad enough
already I think.
When I did ClipShop I limited the installation to Windows versions that were
minimum 5.0 and Windows NT Versions that were a Minimum 4.0 because I wanted
the behaviour to be predictable to some degree. Not that ClipShop is a
brilliant piece but it like resources and processes.
I did my previous version for WIN16 which people using older versions can
continue to use on old machines with less resources and I did not want to
downgrade my features:
Windows versions:
4.0.950 Windows 95
4.0.1111 Windows 95 OSR 2 & OSR 2.1
4.0.1212 Windows 95 OSR 2.5
4.1.1998 Windows 98
4.1.2222 Windows 98 Second Edition
4.9.3000 Windows Me
Windows NT versions:
4.0.1381 Windows NT 4.0
5.0.2195 Windows 2000
5.01.2600 Windows XP
or Windows XP 64-Bit Edition Version 2002 (Itanium)
5.02.3790 Windows Server 2003
or Windows XP x64 Edition (AMD64/EM64T)
or Windows XP 64-Bit Edition Version 2003 (Itanium)
Bill
Bill Buckels
"Charlie" <charl...@verEYEzon.net> wrote:
>If worse comes to worse I *may* write a separate WASP 'lite' that will
work in older versions of Windows but will sacrifice a feature or two.
There's a thought. How many years are you going to spend on this:)
>>The version of the Riched32.dll that comes with Windows 98se
Can you perhaps do a side-by-side installation and load the new DLL from the
current directory. If you don't register it I think you may get away with
it. Provided the user is not running-up another APP that uses the DLL.
>Essentially any Windows program that uses 'rich text'. There are many such
>as, WordPad and MSPaint.
Yikes.
>> The majority of the World is running Windows XP. Maybe it will fix other
>> programs so they run in Windows 98se.
>You may be right :-)
I'm probably not. It was a weak joke:( Can you rename the DLL and the LIB
and fudge it in some way that it can redistributed safely?
>>I'm trying to come up with a solution that will work in both.
>As BLuRy mentioned jokingly in a subsequent post "we liked coding for old
>micros here".
I know, I know...
>I have remote access to a server that is running Windows Server 2003 so I
>intend to sneak in and test it there ;-)
If you can't I have one handy too. I'll se what my time is tomorrow.
>The main reason I released WASP for download was that although I like to
>code, I hate to test. So I figured I'd let you guys do the testing ;-)
I hate to test which is why I decided to help. It is a pain in butt to get
something uploaded to your site and find some annoying bugs over and over.
>I should mention that I've only received a bug report from one person and
>that had to do with a cosmetic problem with the documentation (in Windows
>95).
WIN16 HLP files using rtf would be somewhat more appropriate and a WIN16
version for something that old.
>no one is using WASP :-(
They will.
Bill
Charlie
"Andy McFadden" <fad...@fadden.com> wrote in message
news:4966786a$0$1656$742e...@news.sonic.net...
> In comp.emulators.apple2 Charlie <charl...@vereyezon.net> wrote:
>> Well thank-you for the testing and the great pictures. I'm certainly
>> happy
>> Vista likes WASP. Unfortunately, WASP in Windows 98se has a problem.
>> The
>> version of the Riched32.dll that comes with Windows 98se handles carriage
>> returns differently than the one on XP and presumably VISTA. Installing
>> a
>> newer DLL fixes the problem but could break other programs so...
>
> The Rich Edit dialog saved me a lot of time and caused me a lot of grief
> with CiderPress. There's a lot of workarounds and "the following exact
> order of operations works, don't mess with it" comments in
> app/ViewFilesDialog.cpp.
Thanks for the information. I couldn't find the "the following exact
order of operations works, don't mess with it" comment in
ViewFilesDialog.cpp but I have been looking at that file to see what you
mean. I am hampered somewhat since I don't know very much about C++ and MFC
(WASP is written in plain old C). However, your code is so well commented
that it is pretty easy to follow. I wish I had read your following comment
a while ago:
-----------------------
* Anything related to RichEdit controls is extremely fragile, and must
* be tested with a variety of inputs, preference settings, and under
* at least Win98 and Win2K (which are *very* different).
-----------------------
Basically, all riched dlls expect a newline character ( \n ) to end a line
but the older ones don't handle a carriage return by itself. The newer ones
do. I had found that when loading in a Applesoft file and converting it to
a rich text output that a ( \r ) at the end of each line worked better
(although for the life of me I don't remember what it was that worked
better).
So the obvious answer would be to go back to the \n. I tried that and it
worked but broke my syntax highlighting code. That's where I was until I
read you next statement below:
> If you put a copy of Riched32.dll in the application installation
> directory,
> will Windows prefer to use that over the system copy? I vaguely recall
> doing
> something like this once upon a time. If that works, the updated DLL will
> only affect your application.
I too vaguely remembered something about putting a copy of a dll in the
application directory and that was the first thing I tried. It didn't work,
but....
When you said the same thing I decided to do a little research and guess
what Microsoft provides a mechanism to do exactly what I want.
It's called 'Dynamic-Link Library Redirection' and here's a link to an
explanation:
http://msdn.microsoft.com/en-us/library/ms682600(VS.85).aspx
I tried it and it works.
Thanks Andy for pointing me in the right direction.
Now if anybody is having problems with WASP's edit windows not recognizing
carriage returns (one long string) when loading an Applesoft file from a
disk image, here is a temporary fix:
1. download riched32.dll (v5.1.2600.0) and riched20.dll (v5.30.23.1221).
2. copy them to the directory where WASP.exe is located.
3. start WASP and open a NEW Edit window.
4. type "Andy McFadden is a genius!" or "Apple ][ forever!" in the window
:-)
5. from the file menu select "Save to Windows Drive As..." and in the
resulting dialog box navigate to the directory where WASP.exe is located.
6. Save the file under the name WASP.exe.local
The next time you run WASP the line formatting should be correct with no
code changes to WASP. No other program will be using these DLLs.
In future versions of WASP I will pay Bill Gates huge amounts of money to
include the needed DLLs in the distribution :-)
Charlie
Charlie
>
> "Charlie" <charl...@verEYEzon.net> wrote:
>
> >If worse comes to worse I *may* write a separate WASP 'lite' that will
> work in older versions of Windows but will sacrifice a feature or two.
>
> There's a thought. How many years are you going to spend on this:)
I don't know. The older I get the shorter the years get. I'm inside some
kind of time warp :-)
>
>>>The version of the Riched32.dll that comes with Windows 98se
>
> Can you perhaps do a side-by-side installation and load the new DLL from
> the
> current directory. If you don't register it I think you may get away with
> it. Provided the user is not running-up another APP that uses the DLL.
You're on the right track. See my answer below.
> Can you rename the DLL and the LIB
> and fudge it in some way that it can redistributed safely?
Andy McFadden pointed me in the right direction. See my answer to him in
this thread. Basically what you do is put the DLLs in the same directory as
WASP.exe and then put a dummy file named 'WASP.exe.local' in that same
directory. I tried it in Windows 98se and it worked.
>>>I'm trying to come up with a solution that will work in both.
>
>>As BLuRy mentioned jokingly in a subsequent post "we liked coding for old
>>micros here".
>
> I know, I know...
>
>>I have remote access to a server that is running Windows Server 2003 so I
>>intend to sneak in and test it there ;-)
>
> If you can't I have one handy too. I'll se what my time is tomorrow.
I'm going to try to find time later tonight.
>>The main reason I released WASP for download was that although I like to
>>code, I hate to test. So I figured I'd let you guys do the testing ;-)
>
> I hate to test which is why I decided to help.
And I appreciate your help.
> It is a pain in butt to get
> something uploaded to your site and find some annoying bugs over and over.
I hear you. It does put the pressure on me, but sometimes I need that.
Yeah, right!
>
>>I should mention that I've only received a bug report from one person and
>>that had to do with a cosmetic problem with the documentation (in Windows
>>95).
>
> WIN16 HLP files using rtf would be somewhat more appropriate and a WIN16
> version for something that old.
The help file cosmetic bug is trivial and in no way effects its use. I
forgot to mention that the person reporting the bug couldn't get the help
files to display when clicking on the Help-Contents menu item but could view
them by clicking on the file itself. I couldn't reproduce this on one
Windows 95 machine but it showed up on another. Both these bugs disappear
if you upgrade Internet Explorer to version 5 or higher.
Charlie
Charlie
and all the major functions worked.
Charlie
Bill Buckels
> "Andy McFadden" <fad...@fadden.com> wrote in message
>
> news:4966786a$0$1656$742e...@news.sonic.net...
> >> version of the Riched32.dll that comes with Windows 98se handles carriage
> >> returns differently than the one on XP and presumably VISTA. Installing
> >> a
> >> newer DLL fixes the problem but could break other programs so...
Well isn't this interesting.
Here, read this you guys before you start suggesting popping-in
DLL's:)
INFO: Distribution Issues with Riched32.dll
http://support.microsoft.com/kb/197580
> > The Rich Edit dialog saved me a lot of time and caused me a lot of grief
> > with CiderPress. There's a lot of workarounds and "the following exact
> > order of operations works, don't mess with it" comments in
> > app/ViewFilesDialog.cpp.
>
Exactly Andy! Or more precisely "Why mess with it?" or "DANGER WILL
ROBINSON!"
> -----------------------
> * Anything related to RichEdit controls is extremely fragile, and must
> * be tested with a variety of inputs, preference settings, and under
> * at least Win98 and Win2K (which are *very* different).
> -----------------------
>
Win98 is too different even between SE Versions. Back in those days,
we dropped in DLL's until things worked it's true. We all have our
share of horror stories and I am currently accumulating a number of
new ones on Windows Vista which now has the complexity of .NET
assemblies and legacy pipelines and digest authentication timing
issues and inegrated Windows authentication issues and the abuse is
endless.
The sole reason for our interest in Microsoft is to feed ourselves. We
would never otherwise trust our livelihoods and computers to a bunch
of pimply faced pizza eating teenagers who work independently from
every other team and ignore compatibility issues until release time.
For example, getting a Visual Studio 20003 WEB Application to step
trace in IIS under Vista on a real network is an interesting exercise,
and one that you would die to bill for:)
Regardless... WIN98 ain't worth it.
> Basically, all riched dlls expect a newline character ( \n ) to end a line
> but the older ones don't handle a carriage return by itself. The newer ones
> do. I had found that when loading in a Applesoft file and converting it to
> a rich text output that a ( \r ) at the end of each line worked better
> (although for the life of me I don't remember what it was that worked
> better).
Did you also try an ascii 11 which is considered a soft return by some
text saving M$oft programs:) Maybe that would work until the next
release of this DLL...
It's even harder to remember the older you get. Patch a program today
to run in WIN98 and your patch may prevent your applications from
running on Vista the next time we get a security update. And so-on ad
nauseum.
Leave well enough alone and you won't need to remember what nuances
you have addressed to circumvent versioning issues. The MSDN article
that you referenced in the first place may even have been rewritten to
accomodate some new pimply faced programmer's concept of what we
should need to know.
> > If you put a copy of Riched32.dll in the application installation
> > directory,
> > will Windows prefer to use that over the system copy? I vaguely recall
> > doing
> > something like this once upon a time. If that works, the updated DLL will
> > only affect your application.
>
For Now...
> I too vaguely remembered something about putting a copy of a dll in the
> application directory and that was the first thing I tried. It didn't work,
> but....
> When you said the same thing I decided to do a little research and guess
> what Microsoft provides a mechanism to do exactly what I want.
>
> It's called 'Dynamic-Link Library Redirection' and here's a link to an
> explanation:
>
> http://msdn.microsoft.com/en-us/library/ms682600(VS.85).aspx
>
> I tried it and it works.
> Thanks Andy for pointing me in the right direction.
>
With all due respect to both Andy and yourself Charlie, be wary of
strangers bearing gifts. Nothing is stranger than a M$oft program:)
> Now if anybody is having problems with WASP's edit windows not recognizing
> carriage returns (one long string) when loading an Applesoft file from a
> disk image, here is a temporary fix:
>
This should be a permanent fix. It would be if it were me. A readme
for legacy Windows users. This DLL is redistributable I believe so you
could zip the fix into a WIN98FIX.zip and just include it and walk
away a free man.
> 1. download riched32.dll (v5.1.2600.0) and riched20.dll (v5.30.23.1221).
> 2. copy them to the directory where WASP.exe is located.
> 3. start WASP and open a NEW Edit window.
> 4. type "Andy McFadden is a genius!" or "Apple ][ forever!" in the window
> :-)
You should type both for good luck. "When in danger or in doubt, run
in circles, scream and shout!"
> 5. from the file menu select "Save to Windows Drive As..." and in the
> resulting dialog box navigate to the directory where WASP.exe is located.
> 6. Save the file under the name WASP.exe.local
>
TMI
> The next time you run WASP the line formatting should be correct with no
> code changes to WASP. No other program will be using these DLLs.
>
> In future versions of WASP I will pay Bill Gates huge amounts of money to
> include the needed DLLs in the distribution :-)
>
You may need to ship this with a Vista emulator if Gates keeps this
up:)
Hey there's a thought. Run Virtual PC on Windows 98SE and put Vista on
it, then you won't need to worry. That will cost you huge amounts of
money I am sure.
There was never any question in my mind that Andy was good. Anyone
that could make something like Ciderpress in *THAT* version of C++
must be.
Charlie, all kidding aside, WASP is cool, simple to understand and
easy to use and probably works without problem on systems going back
at least 9 years. Nothing for today's Apple computers will likely run
the same version on an 11 year old Mac. Hell, those computers don't
even talk to their predecessors.
Windows 98 users and Windows 95 users and MS-DOS users should be
thankful that their floppies can still be read by machines up to 20
years newer or spend afew hundred dollars for a new box. It is this
very backward compatibility that they are so hung-up on that has
allowed them to avoid upgrading. So what? Should the rest of us run
everything in DOSBOX or write our applications in WIN16? That's what
museums are for:)
Getting off soapbox.
Bill
BLuRry
> > but the older ones don't handle a carriage return by itself. The newer ones
> > do. I had found that when loading in a Applesoft file and converting it to
> > a rich text output that a ( \r ) at the end of each line worked better
> > (although for the life of me I don't remember what it was that worked
> > better).
>
> Did you also try an ascii 11 which is considered a soft return by some
> text saving M$oft programs:) Maybe that would work until the next
> release of this DLL...
To me, the odd man out is Applewin. The goal of copy/paste is that
you can paste text from anywhere. It would make more sense for
AppleWin to translate CR+LF (\n on windows) and LF (\n on *nix) into
CR. Before taking in the paste buffer, a very simple replace
operation can be performed on the text and then you can paste text
that was copied from notepad or a webpage.
-B
Bill Buckels
>To me, the odd man out is Applewin. The goal of copy/paste is that you can
>paste text from anywhere. It would make more sense for AppleWin to
>translate CR+LF (\n on windows) and LF (\n on *nix) into CR.
AppleWin on linux? That would be AppleCore(dump:)... is it available in
linux now?
Ok, then what about when I run a CP/M disk in AppleWin? Then what should
happen there?
To me AppleWin works beautifully.
>Before taking in the paste buffer, a very simple replace operation can be
>performed on the text and then you can paste text that was copied from
>notepad or a webpage.
Can you tell me where on the AppleWin screen I can paste?
Maybe I don't understand what Charlie did. I thought he was pasting from the
clipboard to AppleWin in his application.
I guess I should read the code in its entirety. Time for work now tho. Don't
even know if what I said here made sense. Everything is blurry now:)
But you are right. Before handing text to an edit control even in someone
else's window a person can massage the buffer.
Bill
lyricalnanoha
On Fri, 9 Jan 2009, Bill Buckels wrote:
> AppleWin on linux? That would be AppleCore(dump:)... is it available in
> linux now?
LinApple is a port of AppleWin, works pretty well.
(I still use ApplePC for most stuff though)
-uso.
Charlie
"BLuRry" <brendan...@gmail.com> wrote in message
news:a291f788-564c-417c...@v13g2000vbb.googlegroups.com...
No the culprit isn't AppleWin. AppleWin accepts text from the clipboard not
directly from the WASP edit window. The text in the clipboard should be the
same as something you would type into an apple keyboard. When WASP sends
the applesoft file to AppleWin through the RUN or SAVE commands it does
massage the linefeeds out but that is only for cosmetic reasons. AppleWin
will happily accepts CR+LF just as a real Apple ][ would but of course you
get a blank line on the screen between each applesoft line and I think you
get a syntax error. The entire program still moves into AppleWin and runs or
saves properly.
When you use the "Inject Text" function in WASP no massaging is done and
everything is sent 'as is'.
Charlie
Charlie
"Bill Buckels" <bbuc...@escape.ca> wrote in message
news:0dc95ef1-d0b3-4328...@s24g2000vbp.googlegroups.com...
On Jan 8, 10:05 pm, "Charlie" <charlieD...@verEYEzon.net> wrote:
> "Andy McFadden" <fad...@fadden.com> wrote in message
>
> news:4966786a$0$1656$742e...@news.sonic.net...
> >> version of the Riched32.dll that comes with Windows 98se handles
> >> carriage
> >> returns differently than the one on XP and presumably VISTA. Installing
> >> a
> >> newer DLL fixes the problem but could break other programs so...
>-------
Well isn't this interesting.
Here, read this you guys before you start suggesting popping-in
DLL's:)
INFO: Distribution Issues with Riched32.dll
http://support.microsoft.com/kb/197580
-------<
Yeah, leave it to Microsoft to have three different versions of the
Riched32.dll files with the same 8 digit version number!
To further confuse the whole mess I have a different version (5.1.2600.0)on
my XP machine and it is only 3,584 bytes long. It says it's a wrapper for
richedit 1.0.
> Basically, all riched dlls expect a newline character ( \n ) to end a line
> but the older ones don't handle a carriage return by itself. The newer
> ones
> do. I had found that when loading in a Applesoft file and converting it to
> a rich text output that a ( \r ) at the end of each line worked better
> (although for the life of me I don't remember what it was that worked
> better).
>---------
Did you also try an ascii 11 which is considered a soft return by some
text saving M$oft programs:) Maybe that would work until the next
release of this DLL...
---------<
I'll look into that.
> I too vaguely remembered something about putting a copy of a dll in the
> application directory and that was the first thing I tried. It didn't
> work,
> but....
> When you said the same thing I decided to do a little research and guess
> what Microsoft provides a mechanism to do exactly what I want.
>
> It's called 'Dynamic-Link Library Redirection' and here's a link to an
> explanation:
>
> http://msdn.microsoft.com/en-us/library/ms682600(VS.85).aspx
>
> I tried it and it works.
> Thanks Andy for pointing me in the right direction.
>
>-----
With all due respect to both Andy and yourself Charlie, be wary of
strangers bearing gifts. Nothing is stranger than a M$oft program:)
-----<
Hey, you play the cards you're dealt.
> Now if anybody is having problems with WASP's edit windows not recognizing
> carriage returns (one long string) when loading an Applesoft file from a
> disk image, here is a temporary fix:
>
>------
This should be a permanent fix.
------<
It will be.
> 1. download riched32.dll (v5.1.2600.0) and riched20.dll (v5.30.23.1221).
> 2. copy them to the directory where WASP.exe is located.
> 3. start WASP and open a NEW Edit window.
> 4. type "Andy McFadden is a genius!" or "Apple ][ forever!" in the window
> :-)
You should type both for good luck. "When in danger or in doubt, run
in circles, scream and shout!"
> 5. from the file menu select "Save to Windows Drive As..." and in the
> resulting dialog box navigate to the directory where WASP.exe is located.
> 6. Save the file under the name WASP.exe.local
>
>-----
TMI
-----<
Three Mile Island?
The Monroe Institute?
Thinking Machines INC?
Ah, Too Much Information :-)
Charlie
BLuRry
> directly from the WASP edit window. The text in the clipboard should be the
> same as something you would type into an apple keyboard.
I disagree with that last part. When content is copied into the
clipboard, the source application should make as much information as
possible available wherever it makes the most sense. When you paste
into another application, that target application is responsible for
handling the contents of the clipboard and making sense out of how to
use them. For example, when you copy data from a table on a webpage
and paste into a spreadsheet, the table contents get translated into
multiple spreadsheet cells. The browser didn't convert the data, the
spreadsheet program did.
Likewise, if you paste rich text into something that can't support
rich-text, then the program tries to make sense out of the stripped-
down text version. If that text is usually formatted in a way that
does not make sense to the program, then the program should be
responsible for converting it if possible.
This is consistent with how other applications already work. If you
copy an image from a word document, it goes to the cipboard as a full-
color bitmap. If you are working on an indexed-color image in
photoshop and paste the full-color image, photoshop has to make that
image fit in the more limited colorspace or tell you that it is not
possible because the image type is different. One of these is more
user friendly than the other.
You said previously that Wasp essentially activates the applewin
window and send it a shit+insert signal to tell it to paste the
clipboard. IMHO, Applewin should be smart enough to deal with CR+LF
and LF in the event someone is pasting data from, say, notepad (which
does not perform any conversion on its data ever), or example source
listing from a newsgroup. I say LF as well as CR+LF, just to cover
all bases (suppose the text is copied from another app that only puts
LF's in the data like a telnet app or another editor with a unix file
open only containing LF's). Applewin should do this, at least
optionally, especially since it's not possible to enter arbitrary
binary data through the keyboard on an Apple ][ -- the hi-order bit is
lost in the translation since it's used as the keyboard strobe bit.
-B
Charlie
> No the culprit isn't AppleWin. AppleWin accepts text from the clipboard
> not
> directly from the WASP edit window. The text in the clipboard should be
> the
> same as something you would type into an apple keyboard.
>---------------
I disagree with that last part. When content is copied into the
clipboard, the source application should make as much information as
>possible available wherever it makes the most sense. When you paste
into another application, that target application is responsible for
handling the contents of the clipboard and making sense out of how to
use them. For example, when you copy data from a table on a webpage
and paste into a spreadsheet, the table contents get translated into
multiple spreadsheet cells. The browser didn't convert the data, the
spreadsheet program did.
---------------<
Yes you are correct and I mistated how AppleWin works. I was going by
memory of why I massaged the text and my memory was wrong. AppleWin does
handle the CR+LF the way you say it should.
>--------------
Likewise, if you paste rich text into something that can't support
rich-text, then the program tries to make sense out of the stripped-
down text version. If that text is usually formatted in a way that
does not make sense to the program, then the program should be
responsible for converting it if possible.
---------------<
WASP doesn't send rich text to the clipboard. It sends plain text. WASP only
uses rich text for displaying the text. Your point, however, is correct.
>--------------
This is consistent with how other applications already work. If you
copy an image from a word document, it goes to the cipboard as a full-
color bitmap. If you are working on an indexed-color image in
photoshop and paste the full-color image, photoshop has to make that
image fit in the more limited colorspace or tell you that it is not
possible because the image type is different. One of these is more
user friendly than the other.
--------------<
I agree.
>-------------
You said previously that Wasp essentially activates the applewin
window and send it a shit+insert signal to tell it to paste the
clipboard. IMHO, Applewin should be smart enough to deal with CR+LF
and LF in the event someone is pasting data from, say, notepad (which
does not perform any conversion on its data ever),
-------------<
Yes and a simple test with notepad and even wordpad shows it is smart enough
to handle the CR+LF.
>-------------
or example source listing from a newsgroup. I say LF as well as CR+LF, just
to cover all bases (suppose the text is copied from another app that only
puts
LF's in the data like a telnet app or another editor with a unix file
open only containing LF's).
-------------<
Now you've jogged my memory. When I was writting WASP I tested it on
listings posted on web sites, newsgroups, etc. Often I found that people
would type 'returns' in places where they didn't belong. Probably to better
format the look of the listing.
>-------------
Applewin should do this, at least
optionally, especially since it's not possible to enter arbitrary
binary data through the keyboard on an Apple ][ -- the hi-order bit is
lost in the translation since it's used as the keyboard strobe bit.
-------------<
In the case of a single LF, which can be typed into the Apple keyboard,
AppleWin would have to somehow figure out that the file was using LF as a CR
(Apple style) and not as LF. That would be asking a lot of the program.
Off hand I don't see any way to do that.
All of this really has nothing to do with the richedit bug in WASP on
Windows98se. It was my 'very poor' attempt to show that it wasn't
AppleWin's fault. What I should have said was that all the rich edit code
is *in* WASP and the riched dlls. AppleWin never sees richedit (at least
not from WASP).
Charlie
TomCh
> To me, the odd man out is Applewin. The goal of copy/paste is that
> you can paste text from anywhere. It would make more sense for
> CR.
This is what it does do:
From keyboard.cpp, ClipboardCurrChar():
if((lptstr[0] == 0x0D) && (lptstr[1] == 0x0A))
{
nKey = 0x0D;
nInc = 2;
}
Tom
Michael J. Mahon
> AppleWin
> will happily accepts CR+LF just as a real Apple ][ would but of course you
> get a blank line on the screen between each applesoft line and I think you
> get a syntax error. The entire program still moves into AppleWin and runs or
> saves properly.
By chance, a few hours ago I EXECed a CR+LF text file into Applesoft on
a real Enhanced Apple //e, and each line was a syntax error and only the
first line was entered into the program.
In other words, the CR ends the preceding line normally, and the LF in
front of the next statement number causes a syntax error and the line
to be ignored.
Charlie
"Michael J. Mahon" <mjm...@aol.com> wrote in message
news:COmdnVboKq1J5PXU...@giganews.com...
> Charlie wrote:
>
>> AppleWin
>> will happily accepts CR+LF just as a real Apple ][ would but of course
>> you get a blank line on the screen between each applesoft line and I
>> think you get a syntax error. The entire program still moves into
>> AppleWin and runs or saves properly.
>
> By chance, a few hours ago I EXECed a CR+LF text file into Applesoft on
> a real Enhanced Apple //e, and each line was a syntax error and only the
> first line was entered into the program.
>
> In other words, the CR ends the preceding line normally, and the LF in
> front of the next statement number causes a syntax error and the line
> to be ignored.
>
> -michael
I should have tested before I opened my mouth (er, typed) instead of relying
on my faulty memory. After testing I found AppleWin accepted CR+LF and does
*not* emit a syntax error. Tom Charlesworth pointed out the related code in
AppleWin that shows conversion of CR+LF to CR. What I had remembered was
probably pasting code to Applewin that had CR+LF in places other than the
end of the line (I've seen this occasionally on listings found on the
internet). In most cases this would cause the lines to be truncated and the
part that was cut off would be placed on the next line usually causing a
syntax error.
But the resulting program certainly would *not* run properly. So my
statement above is wrong in two places.
>>> Hangs head in shame <<<
Charlie
BLuRry
> AppleWin would have to somehow figure out that the file was using LF as a CR
> (Apple style) and not as LF. That would be asking a lot of the program.
> Off hand I don't see any way to do that.
Well, not too hard assuming you never encounter LF+CR, only CR+LF.
Here's how I do it in Jace:
contents = contents.replaceAll("\\n(\\r)?", (char)
0x0d + "");
That is assuming your implementation can handle regex. If not, the
following algorithm works fine:
int lastChar = -1;
while (chars) {
int char = nextChar();
if (char is \n)
keyIn \r
if (char is \r and last char != \n)
keyIn \r
else
keyIn char
lastChar = char
}
Charlie
> In the case of a single LF, which can be typed into the Apple keyboard,
> AppleWin would have to somehow figure out that the file was using LF as a
> CR
> (Apple style) and not as LF. That would be asking a lot of the program.
> Off hand I don't see any way to do that.
>-------------
Well, not too hard assuming you never encounter LF+CR, only CR+LF.
-------------<
Try typing this into an apple followed by the return key ( ^J means
ctrl+J ):
10 REM TEST^J
Ctrl+J is a LF and this is a legal line to key in. Of course the CR doesn't
survive in memory or when saved to a file but that is irrelevant when we're
talking about input.
Actually though, I was referring to your statement:
>--------------
I say LF as well as CR+LF, just
to cover all bases (suppose the text is copied from another app that only
puts
LF's in the data like a telnet app or another editor with a unix file
open only containing LF's).
--------------<
I'm not familiar with telnet or any file containing only LFs (except
possibly an Applesoft tokenized file ;-) but what I meant was that if you
pasted one of those to AppleWin how would AppleWin determine it wasn't a LF
embedded somewhere other than the end of the applesoft line. You can embed
LFs into a program and it is done quite often for formatting purposes.
The algorithm would have to decide if the linefeed was at the end of the
line of code. With applesoft it could look to see if the linefeed was
followed by a linenumber but then you would need code to differentiate
between linenumbers, numbers in text, etc. And that's just for applesoft.
What if you were pasting text to be accepted by a program running in
Applewin?
Charlie
johnsonlam
Hi Charlie,
> > If possible, maybe someone can help to add a "preview" output
> > (Applesoft simulation).
>
> Hmmm, that's what AppleWin does (as long as its running concurrently with
> WASP).
>
> 1. write your Applesoft program.
> 2. click the 'running man' button in the toolbar.
> 3. program runs in AppleWin.
>
> Or am I misunderstanding what you mean?
Sorry for my English, I'm not clear enough.
What I mean is a "simulation" of the Applesoft Interpreter inside
WASP, so I can trial several times and got my desire result in WASP
before really "paste" into AppleWin.
Just a "brainstorm" suggestion.
Thanks.
Rgds,
Johnson.
Charlie
"johnsonlam" <johnso...@gmail.com> wrote in message
news:997afe09-f974-4de1...@p23g2000prp.googlegroups.com...
On Jan 7, 11:52 am, "Charlie" <charlieD...@verEYEzon.net> wrote:
Hi Charlie,
> > If possible, maybe someone can help to add a "preview" output
> > (Applesoft simulation).
>
> Hmmm, that's what AppleWin does (as long as its running concurrently with
> WASP).
>
> 1. write your Applesoft program.
> 2. click the 'running man' button in the toolbar.
> 3. program runs in AppleWin.
>
> Or am I misunderstanding what you mean?
>-----------
Sorry for my English, I'm not clear enough.
What I mean is a "simulation" of the Applesoft Interpreter inside
WASP, so I can trial several times and got my desire result in WASP
before really "paste" into AppleWin.
Just a "brainstorm" suggestion.
-----------<
While that could be done. It would be a major project. *Far* greater than
WASP itself.
For instance all the Apple ][ video modes would have to be supported as well
as all the input/output quirks, peeks, pokes and calls. And it would have
to be able to interact with DOS 3.3 and ProDOS. In other words, it would be
the same as adding an Apple ][ emulator to WASP.
And what would be the gain?
1. With WASP + built in emulator you click a button and your program runs in
WASP.
2. With WASP + AppleWin you click a button and your program runs in
AppleWin.
Not much difference.
On my machine it takes only seconds from the time you click the 'running
man' button until the program is running in Applewin (depending on the
length of the program and the speed setting in AppleWin). If you want to
try for a different result you edit your program in WASP and click the
button again (WASP sends the NEW command every time you run your program to
ensure no remnants of the old program are left behind). When you are
satisfied with the result you save the program from WASP. The only
disadvantage I can see here is that you have to end the running program in
Applewin before running your revised program (and even that you could set up
a command in WASP that would send a Ctrl+C or whatever it takes to exit the
running program).
Charlie
johnsonlam
Hi,
> While that could be done. It would be a major project. *Far* greater than
> WASP itself.
>
> For instance all the Apple ][ video modes would have to be supported as well
> as all the input/output quirks, peeks, pokes and calls. And it would have
> to be able to interact with DOS 3.3 and ProDOS. In other words, it would be
> the same as adding an Apple ][ emulator to WASP.
> And what would be the gain?
The reason for asking this because I found that the original Apple
BAISC interpreter only send out rough error message, if WASP have the
"BAISC simulation", that means I "may" execute the Applesoft line by
line inside WASP, maybe one window for debug, other for acutal output,
debug will be lot easier.
You are right, this is big project. I have no idea how big is it ....
how about using existing code of AppleWin or Apple emulator's code?
(such as ApplePC)?
Just a suggestion, I know hobby project should not become so
"sophisticated".
Anyway, I love WASP, is it possible to force all content using BLOCK
letter?
Thanks.
Rgds,
Johnson.
Charlie
On Jan 13, 12:41 am, "Charlie" <charlieD...@verEYEzon.net> wrote:
Hi,
> While that could be done. It would be a major project. *Far* greater than
> WASP itself.
>
> For instance all the Apple ][ video modes would have to be supported as
> well
> as all the input/output quirks, peeks, pokes and calls. And it would have
> to be able to interact with DOS 3.3 and ProDOS. In other words, it would
> be
> the same as adding an Apple ][ emulator to WASP.
> And what would be the gain?
>------------
The reason for asking this because I found that the original Apple
BAISC interpreter only send out rough error message, if WASP have the
"BAISC simulation", that means I "may" execute the Applesoft line by
line inside WASP, maybe one window for debug, other for acutal output,
debug will be lot easier.
------------<
Well, putting some type of code analysis into WASP would be possible (where
errors messages would pop up in WASP) but I don't know if I'm capable of
that. I'll give it some thought.
>------------
You are right, this is big project. I have no idea how big is it ....
how about using existing code of AppleWin or Apple emulator's code?
(such as ApplePC)?
------------<
Using existing code is of course an option (if it is freely available) but
you would end up with the same error messages as you get with a regular
Apple.
>------------
Just a suggestion, I know hobby project should not become so
"sophisticated".
Anyway, I love WASP, is it possible to force all content using BLOCK
letter?
------------<
I assume you mean all upper case. I'll put that on a list of new features
in an upcoming version.
Charlie
johnsonlam
Hi Charlie,
> Well, putting some type of code analysis into WASP would be possible (where
> errors messages would pop up in WASP) but I don't know if I'm capable of
> that. I'll give it some thought.
Thanks for your consideration.
> Using existing code is of course an option (if it is freely available) but
> you would end up with the same error messages as you get with a regular
> Apple.
I've been torture by the debug output of the original Applesoft
interpreter for many years, the lack of line to line execution and the
dirty output of "trace" stop me from programming Applesoft, though
it's more than 20 years I still feel programming in Apple is easier
and faster than PC.
> I assume you mean all upper case. I'll put that on a list of new features
> in an upcoming version.
Really appreciated, thank you very much.
Rgds,
Johnson.
lyricalnanoha
> On Jan 14, 12:06Â am, "Charlie" <charlieD...@verEYEzon.net> wrote:
>
> I've been torture by the debug output of the original Applesoft
> interpreter for many years, the lack of line to line execution and the
> dirty output of "trace" stop me from programming Applesoft, though
> it's more than 20 years I still feel programming in Apple is easier
> and faster than PC.
D.Code's a little better.
BTW - Ever tried GW-BASIC on the (DOS) PC? You might find it a real
familiar environment, being used to FPBASIC. I know I did.
-uso.
johnsonlam
<lyricalnan...@usotsuki.hoshinet.org> wrote:
Hi Uso,
Long time no see, how's your emulator?
> D.Code's a little better.
Beagles Brothers'?
> BTW - Ever tried GW-BASIC on the (DOS) PC? You might find it a real
> familiar environment, being used to FPBASIC. I know I did.
Not powerful as Apple, can't even control the display output properly
(maybe I don't know the exact way).
Get used to Applesoft, thousand of tricks and good for children.
Other's new BASIC (Dark, Free) have no line number, didn't like BASIC
at all.
Michael J. Mahon
> On Jan 14, 12:06 am, "Charlie" <charlieD...@verEYEzon.net> wrote:
>
> Hi Charlie,
>
>> Well, putting some type of code analysis into WASP would be possible (where
>> errors messages would pop up in WASP) but I don't know if I'm capable of
>> that. I'll give it some thought.
>
> Thanks for your consideration.
>
>> Using existing code is of course an option (if it is freely available) but
>> you would end up with the same error messages as you get with a regular
>> Apple.
>
> I've been torture by the debug output of the original Applesoft
> interpreter for many years, the lack of line to line execution and the
> dirty output of "trace" stop me from programming Applesoft, though
> it's more than 20 years I still feel programming in Apple is easier
> and faster than PC.
Interesting how people have such different styles...
I never use TRACE, and do all my debugging by observing behavior, by
printing variable values after an error, and sometimes by inserting
PRINT statements (which PROGRAM.WRITER makes very easy).
I find the error statements good enough that printing the values of
a couple of variables or expressions in the statement make the problem
quite clear.
For that matter, I use the same approach in debugging assembler
programs, where examination of memory is sufficient nine times out
of ten, and inserting a break or a call to output a value handles
most of the rest of the cases. The befuddling remainder usually
become clear after a night's sleep. ;-)
lyricalnanoha
On Tue, 13 Jan 2009, johnsonlam wrote:
> On Jan 14, 10:22Â am, lyricalnanoha
> <lyricalnan...@usotsuki.hoshinet.org> wrote:
>
> Hi Uso,
>
> Long time no see, how's your emulator?
>
>> D.Code's a little better.
>
> Beagles Brothers'?
Yeah.
>
>> BTW - Ever tried GW-BASIC on the (DOS) PC? You might find it a real
>> familiar environment, being used to FPBASIC. Â I know I did.
>
> Not powerful as Apple, can't even control the display output properly
> (maybe I don't know the exact way).
> Get used to Applesoft, thousand of tricks and good for children.
A lot of the same tricks prolly work in GW too. It's in fact quite a bit
more powerful than FPBASIC, and can do some stuff natively that FPBASIC
needs assistance for.
LOCATE [y][,x] is the equivalent of vtab and htab.
-uso.
johnsonlam
Hi Michael,
> I find the error statements good enough that printing the values of
> a couple of variables or expressions in the statement make the problem
> quite clear.
Display out with GET and INPUT sometimes make me crazy.
> For that matter, I use the same approach in debugging assembler
> programs, where examination of memory is sufficient nine times out
> of ten, and inserting a break or a call to output a value handles
> most of the rest of the cases. The befuddling remainder usually
> become clear after a night's sleep. ;-)
I know a little bit 6502 assembly, tried LISA but I'm too stupid to
use it.
Add break is good for debugging, but still need to change the content,
before WASP editing a Applesoft is a pain.
WASP is good but if the Applesoft is large, need to wait for a few
seconds, that why I want to have "a single pass" inside WASP before
really paste into AppleWin.
Johnson.
Michael J. Mahon
> On Jan 14, 11:26 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> Hi Michael,
>
>> I find the error statements good enough that printing the values of
>> a couple of variables or expressions in the statement make the problem
>> quite clear.
>
> Display out with GET and INPUT sometimes make me crazy.
With GET, things can get tricky (you have to think about how debug
output will affect the screen), but INPUT is pretty vanilla. Besides,
who cares what the screen looks like when you're getting debug output?
(I usually arrange for there to be only one or at most two lines of
debug output prior to a STOP in any case.)
>> For that matter, I use the same approach in debugging assembler
>> programs, where examination of memory is sufficient nine times out
>> of ten, and inserting a break or a call to output a value handles
>> most of the rest of the cases. The befuddling remainder usually
>> become clear after a night's sleep. ;-)
>
> I know a little bit 6502 assembly, tried LISA but I'm too stupid to
> use it.
>
> Add break is good for debugging, but still need to change the content,
> before WASP editing a Applesoft is a pain.
>
> WASP is good but if the Applesoft is large, need to wait for a few
> seconds, that why I want to have "a single pass" inside WASP before
> really paste into AppleWin.
PROGRAM.WRITER is an excellent resident editor for Applesoft. You
enter it simply by typing "&&" and can quickly go anywhere in the
program and edit using Appleworks conventions. After making a change,
just OA-Q and RUN.
All of this takes no more time than pressing the keys.
BLuRry
> enter it simply by typing "&&" and can quickly go anywhere in the
> program and edit using Appleworks conventions. After making a change,
> just OA-Q and RUN.
>
> All of this takes no more time than pressing the keys.
>
> -michael
>
My favorite was edit.pro by Ken Kashmarek/Living Legends Software. I
used that quite happily for many years, even great for editing typing
mistakes in nibble one-liners!
BluPhoenyx
is this available anywhere? any info on possible reclassification or
contact that you know of?
Cheers,
Mike T.
BluPhoenyx
is this available anywhere? any info on possible reclassification or
Bill Buckels
"BluPhoenyx" <bluph...@a2central.com.remove-go1-this> wrote in 4 messages
all exactly the same:
>Cheers,
>Mike T.
OT
Hi Mike, I have been receiving duplicate and quadruplicate copies of your
posts. I have no clue why. I generally only get 1 copy of everyone elses. I
wonder why you are special:)
Bill
BluPhoenyx
Bill,
When did this start and did this post do the same? I just switched to
Linux on a new system and the Thunderbird email/news was a newer
version. That's the only change I've made so I don't know anything else
which would cause this. I will check my news provider, A2Central via
login and see if there are duplicates there as well.
Anyone else see this from my posts?
Cheers,
Mike T.
BluPhoenyx
Bill Buckels wrote:
Bill,
lyricalnanoha
I'm seeing two on csa2p, and they're both crossposted to cea2...
-uso.
BluPhoenyx
Really odd as I checked a2central and only see the one post. The cross
post is probably due to Bill's message being cross posted originally. I
simply didn't change that.
Cheers,
Mike T
BluPhoenyx
Checked Google groups and it has double posts. I have no idea what
causes this or if it's my problem, a2central or perhaps Google. Any ideas?
Cheers,
Mike T
BluPhoenyx
Really odd as I checked a2central and only see the one post. The cross
BluPhoenyx
Checked Google groups and it has double posts. I have no idea what
David Wilson
this> wrote:
> Checked Google groups and it has double posts. I have no idea what
> causes this or if it's my problem, a2central or perhaps Google. Any ideas?
Looking at the headers it appears to be something to do with the cross
post:
Path: g2news1.google.com!news2.google.com!newsfeed.stanford.edu!
newshub.sdsu.edu!flph200.ffdc.sbc.com!prodigy.net!flph199.ffdc.sbc.com!
prodigy.com!flpi107.ffdc.sbc.com!nlpi068.nbdc.sbc.com.POSTED!8ab87810!
not-for-mail
From: "BluPhoenyx" <bluphoe...@a2central.com.remove-45a-this>
Subject: Re: Windows-Applesoft Programmer Software
Message-ID: <497523E3.567....@a2central.com>
X-Comment-To: lyricalnanoha
Organization: A2Central.com
Newsgroups: comp.sys.apple2.programmer,comp.emulators.apple2
In-Reply-To: <alpine.DEB.
0.99.0901191...@andisteele.dosius.ath.cx>
Path: g2news1.google.com!news2.google.com!newshub.sdsu.edu!
flph200.ffdc.sbc.com!prodigy.net!flph199.ffdc.sbc.com!prodigy.com!
flpi107.ffdc.sbc.com!nlpi068.nbdc.sbc.com.POSTED!8ab87810!not-for-mail
From: "BluPhoenyx" <bluphoe...@a2central.com.remove-45a-this>
Subject: Re: Windows-Applesoft Programmer Software
Message-ID: <497523E3.1522....@a2central.com>
X-Comment-To: lyricalnanoha
Organization: A2Central.com
Newsgroups: comp.sys.apple2.programmer,comp.emulators.apple2
In-Reply-To: <alpine.DEB.
0.99.0901191...@andisteele.dosius.ath.cx>
All that changes is the message ID and the Path (and I suspect it is
because of the Message-IDs containing the two different group names).
johnsonlam
Thanks Michael and BLuRry.
I'll try to find PROGRAM.WRITER and edit.pro.
BluPhoenyx
I'll try and remove those when I see I'm replying to a cross posted
message. Personally I dislike that anyhow.
Cheers,
Mike T
Bill Buckels
> Personally I dislike that anyhow.
Personally I am glad to see you are still alive and kicking!
Cheers yerself. Go vist the Aztec C Website and let me know what you think I
need to do next.
I'm almost finished the CP/M 80 Apple Graphics in Aztec C (shh!! don't tell
anyone)
Bill
BluPhoenyx
Bill Buckels wrote:
>> Personally I dislike that anyhow.
>
> Personally I am glad to see you are still alive and kicking!
Yeah, been rather quite lately. Medical issues got me down.
>
> Cheers yerself. Go vist the Aztec C Website and let me know what you think I
> need to do next.
On the way there now.
> I'm almost finished the CP/M 80 Apple Graphics in Aztec C (shh!! don't tell
> anyone)
Cheers,
Mike T