BASIC developers/experts: I need your help!

Page 2/4
1 | | 3 | 4

Par NYYRIKKI

Enlighted (6016)

Portrait de NYYRIKKI

09-10-2011, 00:17

@Manuel: Yes, here is a bit better example of possible use:

10 _TURBO ON
20 DEFINT A-Z
30 DIM Y(5),AY(5)
40 COLOR 15,0,0:SCREEN 8
50 VDP(9)=10:R=RND(-TIME)
60 FOR I=0TO255:LINE(0,I)-STEP(255,0),I,,XOR:LINE(I,0)-STEP(0,255),I,,XOR:NEXTI
70 M=RND(1)*4+1:M2=200\(M+1):KL=RND(1)*50+40
80 FOR S=0 TO M:AY(S)=RND(1)*10-5:NEXTS
90 FOR S=0 TO M:Y(S)=Y(S)+AY(S)
100 IF S=0 THEN WAITSCREEN ELSE WAITLINE= M2*S+VDP(24)
110 VDP(24)=Y(S):NEXT S
120 IF INKEY$>"" THEN END
130 K=K+1:IF K=KL THEN K=0:GOTO 70 ELSE 90

@PingPong: Yes, sure I could have used other than existing keywords, but MSX-BASIC keywords pack better to RAM = Less wasted memory space

Par sd_snatcher

Prophet (3642)

Portrait de sd_snatcher

09-10-2011, 06:32

For dealing with screensplit wouldn't it be better to deal in interrupt syle, instead of pooling? Something like:

10 _TURBO ON
20 ON LINEINT GOSUB 200
30 ON FRAMEINT GOSUB 300
40 'BLABLABLA CODE
50 'BLABLABLA CODE
190 END
200 'Handles Line interrupts
210 SETPAGE1,1:VDP(24)=0
220 RETURN
300 'Handles frame interrupts
310 SETPAGE0,0:VDP(24)=SCL:VDP(19)=SCL+VDP(24)
320 RETURN

Par JohnHassink

Ambassador (5655)

Portrait de JohnHassink

09-10-2011, 07:35

I always thought that screensplit was impossible with MSX-BASIC, so I'm totally spacing out right now anyway. Smile

Par NYYRIKKI

Enlighted (6016)

Portrait de NYYRIKKI

09-10-2011, 08:26

@sd_snatcher: Yes, ON LINE=X GOSUB is among planned features as well as LINE ON /OFF (FRAMEINT can be handled with ON INTERVAL=1 GOSUB)

I agree that handling line interrupts with current X-BASIC versions is "a bit" complex: Example

There are plenty of things that I would like to squeeze in (like for example DO / LOOP) but where to put the code! That 16KB has only ~ 50 bytes left ATM and I'm sort of good ideas:
- If I take out commands -> I break compatibility with existing applications -> Not a good idea
- If I expand up (>#8000) I will break compatibility with major number of existing applications and I will reduce the space needed for source, variables & compiled code -> Not a good idea
- If I expand down (<#4000) I end up doing heavy page switching as XBASIC is pretty BIOS intensive -> Huge work, more slow -> Not a good idea
- If I implement mapper support, then mapper hardware is required and I will break compatibility with Nestor BASIC and possibly other software that require mapper -> Not a good idea

Par Manuel

Ascended (19273)

Portrait de Manuel

09-10-2011, 11:29

Now that you're looking at MSX Basic-kun (as the official name is), how does it work? Does it really compile? If so, how can it be that it goes so quickly? How does it handle the turbo on/off blocks?

Par wolf_

Ambassador_ (10088)

Portrait de wolf_

09-10-2011, 11:40

- If I take out commands -> I break compatibility with existing applications -> Not a good idea

I figure there could be use for such a new XBasic for people who make games in BASIC.

How about letting the user decide what commands should be supported? I can imagine there're commands no one ever uses in these days of MB replayers and loading images into VRAM. Think of PLAY and DRAW. These have parsing code inside that - when erased - is bound to give you some breathing space again.

Also, does anyone ever use CIRCLE or PAINT, or (if it's to be a disk game) CLOAD and CSAVE? Or CAS: and GRP: in open statements?

Par PingPong

Prophet (4093)

Portrait de PingPong

09-10-2011, 12:35

Now that you're looking at MSX Basic-kun (as the official name is), how does it work? Does it really compile? If so, how can it be that it goes so quickly? How does it handle the turbo on/off blocks?
i've always been curious about xbasic internals. maybe it's possible to remove the co-existence with the interpreted basic and leave only a .bin that can be loaded in memory without others? if possible, one can remap bios calls with thin layer (relatively) that does the magics or re-implement BIOS from C-BIOS " linking " the required BIOS parts statically from a 'shared' library.

Pratically i'm asking what limitations arise from making xbasic a traditional compiler, invocable from dos, and having a static .bi or .exe file free to run....

Anyone know about internals?

Par NYYRIKKI

Enlighted (6016)

Portrait de NYYRIKKI

09-10-2011, 20:04

Now that you're looking at MSX Basic-kun (as the official name is), how does it work? Does it really compile? If so, how can it be that it goes so quickly?
Yes it does compile... Actually I started learning to do more complex stuff on assembler by writing stuff on X-BASIC and then reading the compiled code. Smile

The ROM contains a runtime library that the compiled code uses. The compile process is very quick because MSX-BASIC has already packed the BASIC-data so that there is less data to process... Rest of the speed can be explained only by accepting it is just so damn good code! Smile

How does it handle the turbo on/off blocks?
_TURBO ON is MSX-BASIC command and _TURBO OFF is X-BASIC command. When _TURBO ON is executed the compiler starts to compile code until it finds _TURBO OFF or end of program. Then this compiled program is called. When turbo block has been executed MSX-BASIC continues from line after _TURBO OFF. If there are multiple turbo blocks in a program the new compiled code will overwrite previous compiled code, so if you are having problems making the program fit to memory it helps if you can split the code to smaller turbo blocks. Note how ever that because of performance it is naturally not recommended to jump in and out of turbo block constantly.

Par NYYRIKKI

Enlighted (6016)

Portrait de NYYRIKKI

09-10-2011, 20:29


i've always been curious about xbasic internals. maybe it's possible to remove the co-existence with the interpreted basic and leave only a .bin that can be loaded in memory without others? if possible, one can remap bios calls with thin layer (relatively) that does the magics or re-implement BIOS from C-BIOS " linking " the required BIOS parts statically from a 'shared' library.

Pratically i'm asking what limitations arise from making xbasic a traditional compiler, invocable from dos, and having a static .bi or .exe file free to run....

Anyone know about internals?

Yes, it is possible. I've actually tried this long time ago. Theory goes something like this: you need to POKE correct compile address to memory. Start your program with END command, execute _RUN, BSAVE the compiled code, patch the first jump to "END" with call to own init routine where you select X-BASIC to #4000-#7FFF area and call variable init routine. You also need to patch the real end of code with own code that sets the slots back.

Even if you want DOS COM-files you just need rip the runtime and order the memory correctly... Although that is not very easy there is no need re-implementing BIOS or anything like that. So far I have anyway always found space also for the source, so I have not needed to do tricks like these.

Par NYYRIKKI

Enlighted (6016)

Portrait de NYYRIKKI

09-10-2011, 20:45

I can imagine there're commands no one ever uses in these days of MB replayers and loading images into VRAM. Think of PLAY and DRAW. These have parsing code inside that - when erased - is bound to give you some breathing space again.

Also, does anyone ever use CIRCLE or PAINT, or (if it's to be a disk game) CLOAD and CSAVE? Or CAS: and GRP: in open statements?

Yeah... too bad the original X-BASIC developers thought exactly the same, so in X-BASIC there is no PLAY or DRAW or casette related routines or disk related routines. GRP etc are handled by BIOS device handler and CIRCLE & PAINT are just linked to MSX-BASIC, so practically all this has been already done.

Page 2/4
1 | | 3 | 4