Author Topic: CPC Basic 3 (Read 19508 times)

ervin · « **Reply #25 on:** 09:30, 26 March 12 »

Hmmm... Mongui looks interesting.
Seems to do some pretty cool stuff for a type-in.

Looking at the listing, I can see a few things that won't work as a direct conversion.
For example, use of RND and VAL.

If I get time, I'll try to do a conversion, and take notes of what I had to change.
(I don't know if it'll work though, especially the RSX commands in the listing!)

MiguelSky · « **Reply #26 on:** 12:52, 26 March 12 »

Yes, I tried changing the RND*n to RND MOD n+1 as is said at CPCbasic page. Too I tried to relocate the RSX code to &3000 as the program compiles from &4000, but no results at the moment ...

SyX · « **Reply #27 on:** 16:31, 26 March 12 »

Quote from: ervin on 12:18, 24 March 12

Which issue of the magazine is Mongui in?

Mongui appeared in "Amstrad Sinclair Ocio" issue 6
"Amstrad Sinclair Ocio" issue 6, pages 36-40

ervin · « **Reply #28 on:** 01:31, 27 March 12 »

Quote from: SyX on 16:31, 26 March 12

Mongui appeared in "Amstrad Sinclair Ocio" issue 6
"Amstrad Sinclair Ocio" issue 6, pages 36-40

Thanks SyX. It's always interesting to see listings from their original printings.

ervin · « **Reply #29 on:** 01:35, 27 March 12 »

Quote from: MiguelSky on 12:52, 26 March 12

Yes, I tried changing the RND*n to RND MOD n+1 as is said at CPCbasic page. Too I tried to relocate the RSX code to &3000 as the program compiles from &4000, but no results at the moment ...

As I've been trying to figure this out, I've come to the realisation that I just don't understand custom RSX commands!

To make this program work, the RSX code (which I presume is in the DATA statements from lines 250 to 650) would need to be made available to the compiler somehow. i.e. the compiler would need to understand what |ON, |OFF and |PUTSPRITE mean. I have no idea how to do that.

Might be time to ask Dinoneno...

MiguelSky · « **Reply #30 on:** 01:40, 27 March 12 »

Perhaps changing the RSX to CALL...

ervin · « **Reply #31 on:** 07:12, 27 March 12 »

Yeah that'd be worth a try.
How do I go about figuring out the address of each RSX routine?

Axelay · « **Reply #32 on:** 09:42, 27 March 12 »

Quote from: ervin on 07:12, 27 March 12

Yeah that'd be worth a try.
How do I go about figuring out the address of each RSX routine?

If you get the BASIC program in an emu with a disassembler, have it poke the data into memory, but rather than call it, disassemble it from the point it calls. According to the example in 'my book', the RSX firmware setup call is &BCD1 (KL LOG EXT) and BC should be pointing to a command table that starts with 2 bytes pointing to the keyword table, and is followed by a series of JP commands that should give you the direct entries for calling. Or maybe you can just check the data statements in the BASIC listing and look for a series of the byte &c3 separated by two other bytes and try your luck using the addresses following those &c3 bytes?

ervin · « **Reply #33 on:** 09:45, 27 March 12 »

Excellent - thanks man.
I'll give it a go.

AMSDOS · « **Reply #34 on:** 23:37, 22 December 12 »

Has anyone looked at the STARS.BAS example which is included here?

The funny thing with this one is it's BASIC 1.1, one of the lines has a PLOT in it with the 4th parameter enabled for it to draw in XOR mode which is a BASIC 1.1 thing. Funny cause I had the program in 464 mode running BASIC 1.0 and it had no troubles running the program.

But the main thing I wanted to mention is the program itself. If you run that BASIC program, you get this one or two pixel moving up the screen, though I compiled it into Assembly format and compiled it (after making the code readable for the Winape Assembler), and I get this whole starfield with different layers so it looks like some stars are passing faster than other stars.

I don't understand it.

the KING · « **Reply #35 on:** 22:05, 10 March 15 »

Sorry for reopening a very old topic......

Does anyone know where to find the download and documentation for CPC Basic 3?
The website seems long gone.

Tom

TFM · « **Reply #36 on:** 22:26, 10 March 15 »

Try this (from link from 1st post):
http://cpcbasic.webcindario.com/download/CPCBasic.zip

Would be really neat to have the for FutureOS too.

the KING · « **Reply #37 on:** 22:38, 10 March 15 »

Quote from: TFM on 22:26, 10 March 15

Try this (from link from 1st post):
http://cpcbasic.webcindario.com/download/CPCBasic.zip

Thanks!
....from the first post....? did I really miss that?

Tom

TFM · « **Reply #38 on:** 22:49, 10 March 15 »

Haha! Had to search for the link too.

kilon · « **Reply #39 on:** 13:30, 11 March 15 »

wow this is an awesome project . I am shocked how you guys push so much forward such an old hardware . It also makes me sad because it seems that I underestimated CPC . I always saw home computer nothing more than game machines. I was not aware of all the cool software available for them like 3d apps, trackers, midi apps etc

I see now that CPC packs so much more potential.

AMSDOS · « **Reply #40 on:** 10:12, 12 March 15 »

Quote from: TFM on 22:26, 10 March 15

Would be really neat to have the for FutureOS too.

It relies very heavily on the Firmware, but I guess FutureOS can handle a lot of the stuff found in the Firmware, or take a similar approach with how Small-C can be written to FutureOS?

Devilmarkus · « **Reply #41 on:** 16:37, 12 March 15 »

Great project so far!
I'd like to see examples for RSX usage...
Especially about SIN, COS, etc...

Also I don't know, if it's a bug, but am I right that you have to replace multiplications with MOD?

e.g. 1 * 2 becomes 1 MOD 2... ?!?

Sykobee (Briggsy) · « **Reply #42 on:** 23:18, 12 March 15 »

Very neat - I'll be interested to see the speed up on my current BASIC program, once I find a Windows machine to try it on.

Anyone else done some speed up benchmarks, especially for non-firmware stuff?

ervin · « **Reply #43 on:** 00:56, 13 March 15 »

The speed-ups achievable with CPC Basic 3 are HUGE.
However, that performance increase comes at a cost.

You can't translate locomotive BASIC programs to CPC BASIC 3 on a line-by-line basis.
Decimal numbers are tricky to work with, and you may have to take care with negative numbers as well.

Once you figure that out though, it is absolutely awesome.

AMSDOS · « **Reply #44 on:** 09:49, 13 March 15 »

The Stars Example that comes with CPC BASIC 3 does something totally different when you run it through Locomotive BASIC, and I couldn't even get a Star Travel program to work using this compiler and got a better result when I translated it to Pascal.

AMSDOS · « **Reply #45 on:** 00:08, 15 March 15 »

Quote from: ervin on 00:56, 13 March 15

The speed-ups achievable with CPC Basic 3 are HUGE.
However, that performance increase comes at a cost.

You can't translate locomotive BASIC programs to CPC BASIC 3 on a line-by-line basis.
Decimal numbers are tricky to work with, and you may have to take care with negative numbers as well.

Once you figure that out though, it is absolutely awesome.

I think the trap with regard to negative numbers is not being able to assign a variable a negative number, so something like "dir%=-1" is illegal under CPC BASIC 3, which would prevent you from doing something like x%=x%+dir% if dir% was negative. Fortunately there is more than one way to do something in BASIC and I guess that would be another example where it can be substituted with something like "x%=x%-1".

TFM · « **Reply #46 on:** 00:00, 16 March 15 »

Quote from: AMSDOS on 10:12, 12 March 15

It relies very heavily on the Firmware, but I guess FutureOS can handle a lot of the stuff found in the Firmware, or take a similar approach with how Small-C can be written to FutureOS?

In case of SmallC it was only needed to change some libraries. Here I don't know, have to get a closer look. But FutureOS can not do everything firmware. However it probably could work around and maybe do things a bit more quick.

AMSDOS · « **Reply #47 on:** 10:04, 17 March 15 »

Quote from: TFM on 00:00, 16 March 15

In case of SmallC it was only needed to change some libraries. Here I don't know, have to get a closer look. But FutureOS can not do everything firmware. However it probably could work around and maybe do things a bit more quick.

Well in the case of CPC BASIC 3, Assembly code generated includes a long list of Firmware "EQU" Addresses, the complete list by the looks of it (or maybe just the Firmware Instructions used by BASIC), would have been nice if it only included the ones used by the program, but I guess you can't have everything.

Trebmint · « **Reply #48 on:** 11:38, 17 March 15 »

Not spotted CPCBasic 3 before. Looks pretty amazing. The Assembly output looks very good too, actually as good as any C compiler I've looked at. Hmmm seems I have to up my game with the Unify compiler

TFM · « **Reply #49 on:** 21:01, 17 March 15 »

Quote from: AMSDOS on 10:04, 17 March 15

Well in the case of CPC BASIC 3, Assembly code generated includes a long list of Firmware "EQU" Addresses...

That's a general huge problem of BASIC compilers. They still use all the firmware and so the gain of speed is not so much. The real gain of speed could be IMHO archieved by replacing some of the slowest firmware calls by own routines (f.e. print char etc.).

Could you please post such an assembly listing here as an example? Maybe one of your space and stars program. I'm really curious how it would look like in the assembler output.

News:

Author Topic: CPC Basic 3 (Read 19508 times)