Porting GW-BASIC for the MSX

Page 3/3
1 | 2 |

By Dolphin101546015

Champion (269)

Dolphin101546015's picture

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.

By PingPong

Prophet (3521)

PingPong's picture

06-06-2020, 18:51

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

By Dolphin101546015

Champion (269)

Dolphin101546015's picture

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

By sdsnatcher73

Paladin (943)

sdsnatcher73's picture

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).

By Dolphin101546015

Champion (269)

Dolphin101546015's picture

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).

Page 3/3
1 | 2 |