Porting GW-BASIC for the MSX

صفحة 3/3
1 | 2 |

بواسطة Dolphin101546015

Champion (273)

صورة Dolphin101546015

05-06-2020, 18:26

PingPong wrote:

in Xbasic kun memory is constrained by the requirement to have both the compiled and tokenized version side by side.
If you take into account that the basic area is itself, at most about 28000 bytes, it's easy to understand that xbasic limitation is somewhat to much heavy.

Nestor Basic (XBasic+), not have this limitations.
You able using almost whole RAM for code, and even VRAM.

بواسطة PingPong

Prophet (3549)

صورة PingPong

06-06-2020, 18:51

Is the basic source code held in vram? If it is the limitation is still here

بواسطة Dolphin101546015

Champion (273)

صورة Dolphin101546015

06-06-2020, 21:50

PingPong wrote:

Is the basic source code held in vram? If it is the limitation is still here

No problems, simple - not use it. Cool

بواسطة sdsnatcher73

Paragon (1091)

صورة sdsnatcher73

06-06-2020, 23:02

Dolphin101546015 wrote:
PingPong wrote:

Is the basic source code held in vram? If it is the limitation is still here

No problems, simple - not use it. Cool

Maybe it would help to explain why the original code remains in memory (I thought maybe for editing, saving)? And whether or not it is actually a limitation. I don’t know if it is, can the compiled output be greater than the available ~28kB? If it can’t it is not really a limitation anymore (as long as the uncompiled code is stored in other RAM/VRAM).

بواسطة Dolphin101546015

Champion (273)

صورة Dolphin101546015

07-06-2020, 06:30

sdsnatcher73 wrote:

I don’t know if it is, can the compiled output be greater than the available ~28kB? If it can’t it is not really a limitation anymore (as long as the uncompiled code is stored in other RAM/VRAM).

Compiled frame can't be greater 10kb. Uncompiled code might be stored in any RAM/VRAM, with special call syntax and interslot calls (also with special calls for VRAM snippets).

صفحة 3/3
1 | 2 |