SE Basic support

[cheveron]

Hi!

Thanks for the kind words on WoSF about SE Basic. It would be really cool if the compiler could:

* support the extra commands present in SE Basic

and also

* create code that runs with the SE Basic ROM used.

Happy to give whatever support you require to achieve one or both of these if you're interested.

Cheers!

-Andrew

[boriel]

Well, that would be nice, and a bit hard at first!
The major lack of the compiler, at this moment is sound.

This aims to be a multiarchitecture compiler (e.g. Amstrad and MSX also use Z80). In fact it's so focused in 48K Spectrum, that 128K is not always compatible. :oops:

To address all of the above, the compiler will, in the near future, become a multiplatform one. So ZX Spectrum 48K, ZX Spectrum 128K, MSX and Amstrad will be different plataforms. Even the "Sinclair Basic dialect" might vary (e.g. BEEP, PLOT, etc... are commands in ZX, but don't even exist in the other). Since this is an extended dialect based on FreeBasic (which is somewhat based in VBasic, BTW), this will be the common languaje for every platform. That is:

DO LOOP UNTIL WHILE etc... will be available on every platform.
BEEP, PLOT, DRAW or SCREEN$ might not.

The (incomplete) wiki will flag every command telling which architectures are they available.

[cheveron]

I see.

On the sound front, the SE Basic way of dealing with the AY is pretty trivial to compile (and thus cross-compile to the CPC and MSX) as it's basically just a string of register values. SE Basic itself supports two different address systems for the AY (the 128 and the Timex machines).

SE Basic is also focussed on the 48K machine and doesn't know about extra RAM. It will use the AY if it is present, and the ULAplus features. The ULAplus palette is derived from the MSX so again there's a good chance for overlap.

The SE Basic commands that I think it would make sense to add to the compiler are:
CALL (to call a machine code routine)
CHRSET (to set the character set size in bits (7 or 8) - determines if tokens are printed)
ATTRP (to set the permanent attribute)
LDIR (the m/c block copy command)
ON ERR (errror trapping ... mainly for INPUT and file I/O)
PALETTE (set the ULAplus palette, but could support CPC and MSX too)
SOUND (based on the T/S2000 BASIC command)

I'm guessing some of those might be in there already along with the ability to enter numbers as hexadecimal. If you add ULAplus support then adding hexadecimal would be helpful.

The other side is being able to run the compiled code on SE Basic. I haven't looked closely at the compiler so I don't know if you're calling any ROM routines or not. SE Basic is pretty stable at 2.21 so if it works on that it should work on future versions.

Regards

-Andrew

[boriel]

The compiler calls the ROM when doing floating point ops (+, -, *, /, SIN, COS... etc). For integer / fixed values it does not.
It also calls the ROM for plotting (DRAW and CIRCLE are implemented, but they call PLOT in the end).

You can get the entire program asm code of your program with --asm option. So could try creating a .bas program file, and compile it with --asm and see the generated assembler code. You can use it to check if there's something you can take profit from.

Also, the code in the library/asm is free if you want to include it in your projects in anyway. Everything is GPLv2 licensed.

[LCD]

Hi Andrew!

On the sound front, the SE Basic way of dealing with the AY is pretty trivial to compile (and thus cross-compile to the CPC and MSX) as it's basically just a string of register values. SE Basic itself supports two different address systems for the AY (the 128 and the Timex machines).

Even if the CPC has the same sound chip (I have a CPC 464 since last week) as Spectrum 128 or MSX, the clock speed is different, so compiling just a string is not that good.

SE Basic is also focussed on the 48K machine and doesn't know about extra RAM. It will use the AY if it is present, and the ULAplus features. The ULAplus palette is derived from the MSX so again there's a good chance for overlap.

MSX or MSX2 ? I have the MSX and it has 15 colours only, with not very good choosen Palette.

The SE Basic commands that I think it would make sense to add to the compiler are:
LDIR (the m/c block copy command)

Boriels ZX BASIC has MEMCOPY already included, and LDIR can be easy done as SUB.

ON ERR (errror trapping ... mainly for INPUT and file I/O)

There is a Library INPUT routine which is errortrapped I think.

PALETTE (set the ULAplus palette, but could support CPC and MSX too)

Again MSX2 but not MSX, but I agree. Also SAM Coupé has a Palette.

I'm guessing some of those might be in there already along with the ability to enter numbers as hexadecimal. If you add ULAplus support then adding hexadecimal would be helpful.

Hexadecimals and binary are already included, but a little bit different (better) prefix than in SE BASIC. $FF=255. I hope, this will be not changed to 0xFF or something worser.

The other side is being able to run the compiled code on SE Basic.

As own compiling target...

[cheveron]

Hi Daniel,

Even if the CPC has the same sound chip (I have a CPC 464 since last week) as Spectrum 128 or MSX, the clock speed is different, so compiling just a string is not that good.

Well the preferred way of using the SOUND command in SE Basic is with an array of register values, so you can drop in the correct table for the frequency of the chip in use and it will be in perfect pitch. The manual includes tables for the TS2068, the Spectrum 128, and the Pentagon. I have a spreadsheet somewhere that can be used to generate note tables for any frequency of AY chip. In the Spectrum the AY is normally clocked at half the CPU clock. In the Amstrad it's clocked at 1Mhz.

The ULAplus palette is derived from the MSX so again there's a good chance for overlap.

MSX or MSX2 ? I have the MSX and it has 15 colours only, with not very good choosen Palette.

MSX2. It uses the same 9-bit RGB system storing it in 8-bits only to give a palette of 256 colours. It also stores them in the same format as the MSX2 (GGGRRRBB). Of course you're still limited by the Spectrum or Timex attribute system, but on the up side you can get 64 colours on screen at once without using up any extra RAM and existing games can use new palettes without the need for reprogramming.

Again MSX2 but not MSX, but I agree. Also SAM Coupé has a Palette.

SE Basic is quite close to SAM BASIC in many respects (and actually includes some SAM BASIC code). A general purpose PALETTE command would be useful. I'd base it on the MSX2 spec (which is what SE Basic uses) and adapt it to support other machines.

Hexadecimals and binary are already included, but a little bit different (better) prefix than in SE BASIC. $FF=255. I hope, this will be not changed to 0xFF or something worser.

Well you can't use $ in SE Basic because that implies a string and would screw up the parser. BBC Basic and SAM Basic also use & for hex.

The other side is being able to run the compiled code on SE Basic.

As own compiling target...

Well you could make it a separate target, but since all the BASIC functionality of the original ROM is present in SE Basic it would make more sense to have a single target and just make sure the generated code is clean enough to run on both. All well written Spectrum programs run on SE Basic already, so if a compiled program doesn't run that tells me it's doing something quick and dirty somewhere.

Cheers!

-Andrew

[LCD]

Hi Andy

SE Basic is quite close to SAM BASIC in many respects (and actually includes some SAM BASIC code). A general purpose PALETTE command would be useful. I'd base it on the MSX2 spec (which is what SE Basic uses) and adapt it to support other machines.

I have a MSX2 now too, but still no instruction. Maybe I will get one from the seller with next time (I already got two full car loads of computers from this guy, and there will be the third soon). I hope, the palette definition on MSX is more like on SAM as I love it. On the other hand I hate the way how it was done in Amiga BASIC. This was the most stupid way to define palettes.

Well you can't use $ in SE Basic because that implies a string and would screw up the parser. BBC Basic and SAM Basic also use & for hex.

No idea why this would be changed in ZXBC as a compiled program does not interact with the interpreter. It is inly a different way to enter the numbers. I would prefer too in ZXBC to have ENDIF instead of END IF for example. I think, the $ prefix is better as it is standartized, and it follows FreeBASIC compatibility rules. & is usualy used for binary AND, so changing this will break the rules of FreeBASIC compatibility.

Well you could make it a separate target, but since all the BASIC functionality of the original ROM is present in SE Basic it would make more sense to have a single target and just make sure the generated code is clean enough to run on both. All well written Spectrum programs run on SE Basic already, so if a compiled program doesn't run that tells me it's doing something quick and dirty somewhere.

I think you misunderstood me. I don't think the problem is the compatibility of ZXBC programs on Spectrum with SE BASIC ROM. They will run normally, I think. If ZXBC will use the optimised code of SE BASIC RROM, it can break the compatibility with the Spectrum which still has a standard Sinclair ROM. This is why I think, a special case compiling target will be better, to not make the output incompatible with normal Spectrum.

Cheers!

-Andrew

Cheers too
LCD

[cheveron]

I have a MSX2 now too, but still no instruction. Maybe I will get one from the seller with next time (I already got two full car loads of computers from this guy, and there will be the third soon). I hope, the palette definition on MSX is more like on SAM as I love it. On the other hand I hate the way how it was done in Amiga BASIC. This was the most stupid way to define palettes.

Well the MSX uses MS Basic. I'm not sure if it supports the full palette or not. The chip used is the Yamaha V9938. It does 9-bit RGB, but the MSX stores each palette entry in a single byte in GGGRRRBB order. You have to multiplex one of the blue bits to get the 3-bit value. This was chosen because the human eye is less sensitive to blue. I also went with GRB order for ULAplus because that's what the original Speccy palette uses (one bit for each). The result is that with a mono display you get an increasing brightness from 000 to 111.

I think you misunderstood me. I don't think the problem is the compatibility of ZXBC programs on Spectrum with SE BASIC ROM. They will run normally, I think. If ZXBC will use the optimised code of SE BASIC RROM, it can break the compatibility with the Spectrum which still has a standard Sinclair ROM. This is why I think, a special case compiling target will be better, to not make the output incompatible with normal Spectrum.

I see what you're getting at. However, the optimized code takes the same inputs and gives the same outputs, so as long as the entry point is the same there should be no problems. Things will just run a little faster under SE Basic. I would have ZXBC handle all the special case stuff that isn't in the original ROM as there's not all that much of it anyway.

Octal support would be nice ... it's really handy for dealing with palette stuff.