Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SE Basic support
#8
LCD Wrote: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.

Quote: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.
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 1 Guest(s)