From Basic to ROM

Page 1/2
| 2

By cesco

Champion (453)

cesco's picture

09-02-2009, 10:50

I know there's already a tool made by Karoshi that allows to convert a basic file into a working ROM, but I'd like to know how exactly it works...

I guess that while you write a basic application on a MSX computer, the source code is tokenized and stored in RAM... so my question is...

* If we take a text file in ASCII with a proper Basic program inside
* And then we tokenize it
* And then we make a ROM file of that tokenized file, adding a small assembly routine that simply copies the basic program in RAM and execute it

Would it work ?
Imagine if we could also add some assembly routines that could be called from basic, to draw sprites, graphics and play music much -MUCH- faster... and graphics and sound effects could be stored into the ROM and the read from the assembly routines, so you would also save RAM space... I really think it would attract a lot of potential developers that knows nothing about Z80 assembly but are skilled enough to make small games for the MSX... it would be the end of all problems for the rest of us IMHO Wink

Think about it: The speed and power of assembly together with a user-friendly language. It would be a match made in heaven Smile

I know nothing of MSX hardware or Z80 instructions... but I could make a "tokenizer" application that creates a ROM file, and then with a simple "cut & paste" operation I could replace simple basic commands into routine calls. I already know how to read ROM files, and then I guess I could create one of them too... and for the tokenizer... well, I could "steal" something from Vincent Van Dam tools (Sorry Vincent Smile

Login or register to post comments

By Metalion

Paragon (1451)

Metalion's picture

09-02-2009, 11:09

The fact that you have a tokenized BASIC program stored in ROM won't speed up the execution.
The BASIC program will still need to be interpreted by the MSX-BASIC ROM.

The way the BASIC ROM works is this :

1. On input, it crunches the ASCII text into tokens
2. On execution, it interprets (in real time) the tokens into actions

So the ROM would be just another way to store a BASIC program, you won't gain from it.

By cesco

Champion (453)

cesco's picture

09-02-2009, 16:13

no, that's not exactly what I had in my mind...

I was thinking that... for example if in a program it could be possible to call an assembly routine instead of a basic command... it would make the application a lot faster.

For example, if we need to write a string of text in a portion of the screen, instead of writing:

LOCATE 5, 10: PRINT "HELLO EVERYBODY"

we could invoke an already-made assembly routine that could do the same thing but faster:

DEFUSR=ADDRESS: A=USR(0)

My idea is: Let's take a basic program and replace as many instructions as possible with assembly routines, and then cram it in a ROM file. Basically it's a semi-compiler...

It is quite easy to take a block of text and replace some basic instructions with calls to some routines... I was actually making (for myself) a tiny application that takes a Basic program (with labels and without line numbers) and transform it in a proper MSX Basic program. What is really difficult for me is to write these assembly routines, since I know nothing of Z80 instructions and nothing about VDP hardware Smile

By st1mpy

Paladin (838)

st1mpy's picture

09-02-2009, 16:32

A full MSX BASIC compiler would be more useful though does that already exist?

By cesco

Champion (453)

cesco's picture

09-02-2009, 17:25

For example, this is a screenshot taken from the "toy" I'm currently developing:

img522.imageshack.us/img522/6564/immagine11gf7.png

I know that the look is crappy, but take a look at the source code I wrote on the left, and then look at the MSX Basic version created by the application...

IMHO with the indentation of the code and the use of labels/functions instead of line numbers the code is more readable and easier to mantain. The application I wrote is simply replacing some sentences with the proper MSX Basic code... a really easy task, in the vast majority of the cases it's just a matter of Search&replace substrings here and there.

Now for example think if it could be possible to convert the line

LOCATE 12,16 : PRINT "This is the introduction"

into a call to a assembly routine that makes the same thing, but faster... even faster than using VPOKEs to change VRAM values
A lot of people that don't know anything about assembler but are skilled enough to make a basic game could be able to make games that could be both easier to develop and that could run faster IMHO

By Metalion

Paragon (1451)

Metalion's picture

09-02-2009, 20:26

You are explaining the basic concept of a compiler : replacing BASIC or C lines with un-optimized Z80 machine code.
Sorry to say that nothing is new there ...

By Huey

Prophet (2676)

Huey's picture

09-02-2009, 20:31

Yes. I think it can be quite trivial to build an MSX-Basic parser.
I've done several parsers during my study.

Then you'd still need to optimize the generated assembly code. The real challenge.

By PingPong

Prophet (3793)

PingPong's picture

09-02-2009, 20:53

Yes. I think it can be quite trivial to build an MSX-Basic parser.
I've done several parsers during my study.

Then you'd still need to optimize the generated assembly code. The real challenge.
@Huey:

In the past i've considered to write a msx basic compiler.
In the first step i've also considered to generate 'c' code instead of directly asm code.
Then a 'c' compiler should have done the hard work to get asm code.
Initially i've targetted the sDCC and Hitech-C.

The project did not started because when i've posted on MRC my idea to create a msx basic compiler not fully compatible with the interpreter, some people complained about the non 100% compatibility.

To be more precise my idea was to remove some bad things like this:
10 FOR T%=0 to 100
20 IF T% AND 10 THEN BEEP:NEXT T%
30 PRINT T%
40 NEXT T%

a similar source would not be compiled because of the two NEXT T% with a single FOR
should be re-written as

10 FOR T%=0 to 100
20 IF T% AND 10 THEN BEEP ELSE PRINT T%
40 NEXT T%

one FOR, one NEXT!

By cesco

Champion (453)

cesco's picture

09-02-2009, 21:14

To be more precise my idea was to remove some bad things like this:
10 FOR T%=0 to 100
20 IF T% AND 10 THEN BEEP:NEXT T%
30 PRINT T%
40 NEXT T%

OMG. oO

By cesco

Champion (453)

cesco's picture

09-02-2009, 21:18

You are explaining the basic concept of a compiler : replacing BASIC or C lines with un-optimized Z80 machine code.
Sorry to say that nothing is new there ...

This is not exactly a compiler, it's something simpler. A true Basic compiler would involve the conversion of every single line of code in its assembly equivalent.

What I'm proposing here is just to "beautify" the code, introducing some classic constructors from the Basic Language that weren't allowed in the original MSX Basic, and then "speed up" some time-critical portions of the code with the injection of assembly routines. Something that is thousand times simpler than a real compiler.

The real advantage of it? You could produce a ROM file that can be run on every MSX machine (or emulator) without having to load a support library before.

By PingPong

Prophet (3793)

PingPong's picture

09-02-2009, 21:35


This is not exactly a compiler, it's something simpler. A true Basic compiler would involve the conversion of every single line of code in its assembly equivalent.

I can assure that for a conceptual point of view, when having a syntax tree already built , there is no pratical difference in generating 'c' code or machine code. The real problem when working in asm on a CPU like z80 is to find the 'better' way to generate it.

Two considerations:

1) for example a statement like

A%= B%+C% that is a very simple expression tree could be done in several ways:

LD HL, (A%)
LD DE, (B%)
ADD HL,DE
LD (C%), HL

but may also be:

LD A,(A%) ; low byte of word ptr in accu
LD HL, B% ; point HL to of word ptr of B%
ADD A%,(HL) ; sum the low bytes,
LD (C%),A ; store the low byte
LD A,(A%+1) ; store high byte to accu
INC HL ; point to high byte
ADC A%,(HL) ; sum the high bytes with carry
LD (C%+1),A ; store the result, high byte.

but may also be: (another series of possibility)

choosing the best is the real challenge. At a quick look appear the the first is more fast and compact, but uses four registers, the latter only tree. So what's the better? Depends.

2) Using 'c' code as an intermediate step allow me to quickly verify some code-generation bugs.

The final step would be asm.

Page 1/2
| 2