 Previous Messages |
Posted By
MMS
on 2011-09-02
09:07:27
 |  Re: @JimH re. Austrospeed
Yeah, yesterday I wrote the core of "mouse simulator" routine in BASIC, it is a very simple one (there were several much better realizations in games) but OK for testing the speed.
Next week I will test it, but based on the last comment it wil not have too much benefits (in fact it was the answer I supposed I will receive).
Anyhow thanks for the info, I will doublecheck it. I suppose the task to integrate them into the PRG code would be too big, complicated, and would significantly increase the size of the final PRG too.
|
|
Posted By
SVS
on 2011-09-02
03:17:12
 | Re: @JimH re. Austrospeed
All graphic commands of BASIC 3.5 work with Austrospeed, but at the same speed. I suspect that Austro author simply did link the original routines for these non-C64 keywords.
|
|
Posted By
Gaia
on 2011-09-01
15:44:04
| Re: @JimH re. Austrospeed
Have a look at Balloon Shoot, a BASIC game that uses G/SSHAPE with mediocre success. I recall I compiled it with Austrospeed once and it worked just fine. It even got faster!
|
|
Posted By
MMS
on 2011-09-01
13:03:48
| Re: @JimH re. Austrospeed
Hello,
I am a little short on time now, but plan to do some BASIC programming soon (haha, sound serious  ), but in fact I really want to do some serious structured programming to generate some surprises.
Question: does Austrospeed compliler support GSHAPE and SSHAPE function of Basic? As i knwo, it is converted thing from C64, and probably able to manage most of those commands, but still my keyboard it not fully OK.
In fact these function doing very intensive memory copy, so Autrospeed may speed them up to 5x (?) faster. Then they become lightning fast, imagine XOR-ing a small picture accross the screen.
(in reality I think noone uses GSHAPE and SSHAPE in BASIC as they are just too slow in normal conditions)
|
|
Posted By
SVS
on 2009-04-23
03:16:53
| Re: @JimH re. Austrospeed
What are you trying to compile?
eheh... it's a surprise for the scene, anyhow if you want I can send you a beta
Also, I remember some kind of memory size usage with arrays or something like that..
This is very interesting, but do you mean a secret function of Austrospeed, or what?
|
|
Posted By
BushRat
on 2009-04-21
18:50:19
| Re: @JimH re. Austrospeed
Interesting...
Of all the programs that I've compiled, I can't recall running into that problem. Either they ran fine, or had errors during compilation... that I would correct and re-compile.
I don't recall ever using your wedge, of course, I didn't know it existed until Peter started sending stuff from your side of the pond.
What are you trying to compile? Also, I remember some kind of memory size usage with arrays or something like that..
|
|
Posted By
SVS
on 2009-04-21
14:42:46
| Re: @JimH re. Austrospeed
I've used your '91 version to compile a large source file. The resulting compiled file cannot work without the patch: it jumps to $0355 and halts.
Maybe the needness of the patch is only for some statements, if you do not use them in the source then it does not need the wedge.
|
|
Posted By
BushRat
on 2009-04-20
07:54:59
| Re: @JimH re. Austrospeed
They are for the C64. Thought you might try them with the De-Blitz program.
|
|
Posted By
SVS
on 2009-04-20
07:18:17
| Re: @JimH re. Austrospeed
I've received the file, thx (and tnx to MikeZ too).
The Austrospeed version is surely different than mine. First it shows a release number 91... that could mean it was coded in 1991 (mine is 87...). Then it is in English and here at Plus4world we was thinking that it was released only in German language (so that I made the texts-translated version in 2005).
A question: what are the 2 compiled files 63 blocks long, in the same d64 image? (Titled: "Austro-speed 91" and "austro(one driv)"?
|
|
Posted By
BushRat
on 2009-04-20
05:37:56
| Re: @JimH re. Austrospeed
Okay, I see that Mike already forwarded the docs to you (Thanks Mike). I just sent the program to you box.
Be interesting to see if it is diferent.
|
|
Posted By
SVS
on 2009-04-20
03:09:00
| Re: @JimH re. Austrospeed
Thank you for interesting replies.
It seems to me that there are more versions of Austrospeed for Plus4. The version I own has these features/bugs:
1) It needs to load a patch in order to run *long* compiled files (if not present in memory, like just after compilation ends);
2) I did many tests and the "::" feature works if only a sngle ":" is written (for example 120 :STOP);
3) DeBlitz (or Decompiler) says it is not a Blitz program.
For these reasons, I would appreciate if you can send me your docs (or MikeZ kindly forward them to me). The email address is that one in memberlist.
Much interesting should be to have developper notes!!! Here in the forum there was a discussion about who was the (genius) author of that masterpiece. This could clarify some other matters (like dec() statement).
P.S. Austrospeed is smarter than BASIC, in fact BASIC does accept A<>=B, Austro outputs an error
|
|
Posted By
BushRat
on 2009-04-19
19:10:49
| Re: @JimH re. Austrospeed
Is your Email, listed here, the right one? I will email the Docs to you. My ftp client is giving me fits, today and I don't have a storage link. I was going to sent it, but thought I'd check first, while doing so I sent it to MikeZ.. sorry MikeZ... wrong Mike, but he might find it of interest, too.
|
|
Posted By
BushRat
on 2009-04-19
18:01:54
| Re: @JimH re. Austrospeed
Did you try FORCING the Trap command by preceeding it with a double colon (::TRAP)?
Austrospeed recognizes most of the Basic extensions, but some others you have to "force" that way. The compiler run-time routines would then pass the entire statement to the Basic interpreter.
Have a question for you... my version of Austrospeed didn't require a dongle or wedge to be present when you'd run the resulting compiled program.. did yours? I remember you made some kind of patch for that. I never needed it.
Supposedly, Austro was compatable with most of the De-Blitz programs, to de-compile it for later rework.
|
|
Posted By
BushRat
on 2009-04-19
17:36:37
| Re: @JimH re. Austrospeed
Past tense... I've forgotten a lot
I do know that the first three menu choices will find and report an error, during compiling, then continue to compile.
The second menu choices will find the error, stop and ask if you want to contine or abort the compiling job.
That was nice if you were compiling a BIG program (which took some time) and wanted to find and fix the errors quickly. Some non-critical program hick-ups would still run, for a quick check, if you weren't in a hurry and wanted it to finish the compile job.
As far as the TRAP statement (which I almost never used), I'd have to go over some of the disk notes I'm trying to pull together from some disk images. Will put it on my LOOK list.
Didn't you ever get the documentation for this program? The developer covered quite a bit. There were some quirks to look out for, like using : (colons) as place holders and REMs.
I had a copy of Austrospeed64, way back, and the head of TPUG got in touch with the developer, back when we were doing a skintchy disk magazine. I was sent a copy of the program for use with two drives and one for a single drive and instructions.
|
|
Posted By
SVS
on 2009-04-19
14:17:04
| @JimH re. Austrospeed
Hi Jim,
I'm glad you came back to the scene
Could I ask you for some info on Austrospeed? (I know you are an expert on this jewel):
1) How can I use TRAP statement without it causes a gosub-stack mess?
2) What is the real use of menu choices 4, 5, 6 (so called: resume complet). The compiled code is longer with them, but it seems useless (someone thinks they allow some kind of RESUME function)
Many thanks
|
|
