REQUESTED
----------

By means of the present I request the conformation of a team of programmers
in assembler for the following projects related with the MNBIOS.


1. to create a language of BASIC for the mnbios.
The program will be called by convenience "MNBASIC.EXEC."
The code won't be able to occupy more than (32KB at least in its first version
and it should be programmed in assembler.
As speed it is looked for they will only be supported matrixs and variable, INT, LONG
and alphanumeric, in functions where they are required obligatorily variable
floating (for Ex:, SIN COS, you will translated the ranges of I/O to whole values).
The programs in BASIC resultants will be able to be as big as 128MB
(maximum longitude of each packageable file in memory RAM)
that is to say, to use pointers LONG instead of INT for the whole code.
They will be given support to entrance and exit of devices
(that is to say to support to full the communication with the driver MDOS).
Support variable COMMON, negotiating them in the structure DATAMEMO.
To support the use of LOCAL variables in subroutines being recursive.
Are understands each other for it, variables that are born among a GOSUB and
they die in the RETURN, using DIM to declare this type of variables.
Being ideal their location in the "Stack Point" of the program BASIC
to achieve recursivity.
Syntax compatibility with the MSX-BASIC.
Possibility to read and to record in format ASCII.
To support all the instances of the system multitasking.
To support the execution possibility in CPU secondary modules of the one
it programs BASIC.
That the code in memory of the program BASIC is executable
(in form compiled to achieve interpretation speed).
adding support of the functions that the MNBIOS provides like for ex:
FSTICK FSTRIG, event PAUSES, event CLOSE, WINDOWING etc.


2. module (code driver) guided to object that makes of bridge among
the support WINDOWING of the kernel and programming of high level.

OBJECTS:
form, listbox, textbox, label, picturebox, buttons, checklist, timer.
Each one with all the properties, events and well-known commands.
Being the entirety of the accesses managed through the following one
entrances to the driver.
And with the possibility of annexing more objects in external form:

InstallObject; To install external objects.
UninstallObject; For uninstall external objects.
LoadObject; To load an instance of an object.
UnloadObject; To discharge an instance of an object.
ListObject; To list all the installed objects.
SetProperty
GetProperty
LinkEvent; To subscribe a routine from an application to an event or instance of the object.
SendCommand; To send a command.

The form of calling to these functions is to the programmer's discretion
but always using the system ADR (administrator of resources),
that is to say the support will be in format (code driver).


3. a demonstrative and interactive demo of the whole audio-visual potential of the kernel.

To the artist's discretion.



Flyguille

www.mnbios.com.ar

I hope you understand that's a tall order! Making a BASIC interpreter is no joke... Actually, it borders on the impossible!!!

If you even want to stand a chance at making a new BASIC interpreser you'll need a lot of things. I'll try and sum up a few of them, I'll probably forget a million other things.

1) You need a BIG team, with lots of GOOD programmers.
2) You will somehow need to convince them this is something they want to do.
3) You will need to convince them some more, because they won't want to help you.
4) You will need to REALLY motivate these people.
5) You will need to do a lot of work yourself, you'll probably need to start alone.

Making a BASIC interpreter is not easy. Before anyone will want to help you, you will at least need to set up the basics and provide a clear picture on what you have already. First make very clear what the environment of your kernel/BIOS is. Once the MSX starts in MNBIOS mode, what situation is the computer in?

1) Where is the stack?
2) What interrupts are available? Where do they land?
3) What is the memory configuration?
4) What BIOS routines are available?
- what do they do?
- what registers go in?
- what registers go out?
5) This needs to be SHORT and CLEAR documentation.

In order to make a BASIC interpreter people will want you to at least setup the very basics of the code. You will need to:

1) Define all commands:
- which commands do you want?
- what do they do?
- what are their token-codes?
2) Define the variable format:
- what variables do you have?
- what is their format?
- what are their limits?
- what operations can be performed?
3) Define your system/state table
- what screen are we in?
- where is the cursor?
- are we using sprites?
- what is the mouse doing right now?
- is there sound playing?
- joysticks
- cassete
- diskdrive
- harddisk
- interrupts
- the million other things I am forgetting

I am not trying to get you down or anything, but before you start a HUGE project like this you'll really need to plan EVERTHING to the last bit. If you don't, it'll just hopelessly fail. This is why it will be very hard to find programmers that will want to help you. The best thing you can do is TRY and get programmers to each do one small part of the BASIC interpreter. The most difficult parts are the interpreter itself and the math-routines. You will need very skilled programmers to do these.

If you are REALLY serious about this, and make a clear picture of all the things I mentioned above, I will help you with a VERY SMALL part of this incredibly large job. I will do all the screen 0 routines if you want me to. This means SCREEN0, WIDTH, CLS, PRINT, PRINT USING, the KEY functions (maybe including CTRL?) COLOR, COLOR= and the whole bunch I am forgetting like the characters etc... I will ONLY do this using screen 0. I do not beleive in a graphical screen 0 since the MSX VDP is simply too slow to do this.

I know it's not much, but it's something. Remember you'll need to map out everything else yourself. This includes:

1) All the BIOS routines, including disk I/O
2) The complete memory map
3) The actual state in which a program is loaded
4) All the specifics of the BASIC languae

Remember it will be very hard to interest programmers in a project like this since the MSX already has a pretty good BASIC -one of the best around-. If you find it difficult to write all the information you need in English you can write it in Spanish, I should be able to understand.

Well, good luck!

Quote:

I hope you understand that's a tall order! Making a BASIC interpreter is no joke... Actually, it borders on the impossible!!! If you even want to stand a chance at making a new BASIC interpreser you'll need a lot of things. I'll try and sum up a few of them, I'll probably forget a million other things. 1) You need a BIG team, with lots of GOOD programmers. 2) You will somehow need to convince them this is something they want to do. 3) You will need to convince them some more, because they won't want to help you. 4) You will need to REALLY motivate these people. 5) You will need to do a lot of work yourself, you'll probably need to start alone. Making a BASIC interpreter is not easy. Before anyone will want to help you, you will at least need to set up the basics and provide a clear picture on what you have already. First make very clear what the environment of your kernel/BIOS is. Once the MSX starts in MNBIOS mode, what situation is the computer in? 1) Where is the stack? 2) What interrupts are available? Where do they land? 3) What is the memory configuration? 4) What BIOS routines are available? - what do they do? - what registers go in? - what registers go out? 5) This needs to be SHORT and CLEAR documentation.

That last is already done!.. .. sure you download the MNBIOS programmer manual?

Quote:

In order to make a BASIC interpreter people will want you to at least setup the very basics of the code. You will need to: 1) Define all commands: - which commands do you want? - what do they do? - what are their token-codes? 2) Define the variable format: - what variables do you have? - what is their format? - what are their limits? - what operations can be performed? 3) Define your system/state table - what screen are we in? - where is the cursor? - are we using sprites? - what is the mouse doing right now? - is there sound playing? - joysticks - cassete - diskdrive - harddisk - interrupts - the million other things I am forgetting

That too is already done.... again read the manual.

Quote:

I am not trying to get you down or anything, but before you start a HUGE project like this you'll really need to plan EVERTHING to the last bit. If you don't, it'll just hopelessly fail. This is why it will be very hard to find programmers that will want to help you. The best thing you can do is TRY and get programmers to each do one small part of the BASIC interpreter. The most difficult parts are the interpreter itself and the math-routines. You will need very skilled programmers to do these. If you are REALLY serious about this, and make a clear picture of all the things I mentioned above, I will help you with a VERY SMALL part of this incredibly large job. I will do all the screen 0 routines if you want me to. This means SCREEN0, WIDTH, CLS, PRINT, PRINT USING, the KEY functions (maybe including CTRL?) COLOR, COLOR= and the whole bunch I am forgetting like the characters etc... I will ONLY do this using screen 0. I do not beleive in a graphical screen 0 since the MSX VDP is simply too slow to do this.

Escept by PRINT USING, that too is already done...and... too slow? who say that?, maybe the scrolling, not printing chrs.

Quote:

I know it's not much, but it's something. Remember you'll need to map out everything else yourself. This includes: 1) All the BIOS routines, including disk I/O 2) The complete memory map 3) The actual state in which a program is loaded

That too is already done.... again read the manual.

Quote:

4) All the specifics of the BASIC languae Remember it will be very hard to interest programmers in a project like this since the MSX already has a pretty good BASIC -one of the best around-. If you find it difficult to write all the information you need in English you can write it in Spanish, I should be able to understand. Well, good luck!

BASIC??? whoooooaaahahahaa, who needs another darn basic interpreter.
hum.

Quote:

Hahaha, good point flyguille! Everything that Sonic_aka_T asked in his long list was already in the manual. You r00lz man

Actually, it isn't...

Quote:

BASIC??? whoooooaaahahahaa, who needs another darn basic interpreter. hum.

See what I told you other programmers would think... And Ro is the kind of guy you would have to convince. He would be a great candidate to write your math routines... Or did Savage do the math!?! I don't remember... Ofcourse he's lazier than shit, but he's a great programmer...

But, if you change the whole BIOS, and you make some hardware modifications, then the final product is not an MSX computer, but something totally different. And this is an MSX forum, isn't it?

I do not see the need of a new and uncompatible BIOS, a new OS or a new uncompatible MSX modification. And what the community needs is a freeware BIOS compatible with the original (and copyrighted) BIOS. For example, BouKuChi (o BouKiChi??) project.

If MSX programmers now hardly have enough spare time to code a game or a demo, imagine to program a new BIOS and a BASIC interpreter. And after that, they should learn how to code for the new system and expect that all MSX users will adopt it in the future. Hard to imagine. Even harder to understand the reasons. Windowed text is not enough, at least, IMHO it does not justify a new BIOS. And if you want a non-ASCII operating system, then try UZIX. It is a cool OS, UNIX implementation and multitasking for MSX. Beat that and I will consider joining MNBIOS project. And UZIX is not vaporware. It exists and runs fine.

By the way, in english the present of the verb TO BE is "I AM", not "I ARE". Please note that my english is not very good, but I cannot stand certain mistakes.

Regards,

Ed Robsy

let me reply that pitpan!!!!


The idea is made short the time of a develop.... actually when a programmer want to do something, he need start from zero (ofcourse some programmers got his libraries), and not all programmer got the skill for start from zero...

removing the DOS programming, (that not all people got), the msx-bios is a shit about memory resource, and is a extra-work for a lot of programmers.

As are write on the programmer's manual exist almost 20 thing for change the BIOS.

The idea is: a aplication under MNBIOS will reduce to a secuence of CALL with his arguments sets ofcourse.

pitpan wrote:

Quote:

But, if you change the whole BIOS, and you make some hardware modifications, then the final product is not an MSX computer, but something totally different. And this is an MSX forum, isn't it?

MNBIOS runs fine on standard MSX2.

Quote:

I do not see the need of a new and uncompatible BIOS, a new OS or a new uncompatible MSX modification.

You don't see the need for MSX2, or MSX2+ or MSX turboR. You've stated over and over again MSX1 is enough for you!
And in what way are flyguille's suggested hardware modifications 'incompatible'? Incompatible with WHAT?! They're compatible with MSX!

Quote:

And what the community needs is a freeware BIOS compatible with the original (and copyrighted) BIOS. For example, BouKuChi (o BouKiChi??) project.

As you say, there already IS such a project! Although Boukichi stopped working on C-BIOS, Reikan (from openMSX Windows porting fame) is continuing it.

Quote:

If MSX programmers now hardly have enough spare time to code a game or a demo, imagine to program a new BIOS and a BASIC interpreter.

Flyguille already made the new BIOS. He's just asking help for a BASIC compiler.

You guys (Ro included) may laugh at BASIC, but that's just dumb. Laughing at BASIC means forgetting your own roots. Everybody started programming BASIC and it's a very powerful language. In fact, I believe a new BASIC, more like QuickBASIC (as Flyguille is suggesting) is very important to the MSX scene.

Take NestorBASIC plus NestorPreter, include all BASIC commands NestorBASIC doesn't have, and voila you have a very powerful and very easy to program environment.

Even Nishi has expressed the importance of a BASIC to get people's creativity going. Just look at the amount of BASIC entries in the MRC Snowfall Challenge!

Quote:

And after that, they should learn how to code for the new system and expect that all MSX users will adopt it in the future.

MSX'ers learned to code for MSX1, then MSX2, then MSX-DOS2, then turboR. Why shouldn't they be able to code for MNBIOS?
Have you read the manual at all? All of it is very well documented.

Quote:

Windowed text is not enough, at least, IMHO it does not justify a new BIOS.

Ofcourse it doesn't. And MNBIOS isn't just 'windowed text'. Have you read the manual at all?

Quote:

And UZIX is not vaporware. It exists and runs fine.

MNBIOS isn't vaporware either. It exists and runs fine.
Also, UZIX does not have an english programmers' manual. If it had, I would be writing programs for it right now!

sonic_aka_t wrote:

Quote:

See what I told you other programmers would think... And Ro is the kind of guy you would have to convince.

Sorry? No offence, but Ro is an old-timer who still has to prove he's putting out products again. There've been several old-timers who've talked about making MSX stuff again, and none of them came through. (I really hope Ro will, coz he's a great asset to the scene)
Besides, Ro wrote an OS for himself (or at least with the help of Savage). So of all people he should understand why flyguille did it!

Quote:

He would be a great candidate to write your math routines...

Math routines are already implemented in MNBIOS. And with INSANE accuracy, if you ask me
The only thing needed is an expressions parser, but those are so easy a child could do it in a day.

I think it's a good things to make a few things clear about MNBIOS

- For a large part it has already been developed. Flyguille has been working on it for six years and has now reached a point where he can use the help of other MSX Developers.

- For newbies and novice MSX coders BASIC is an essential language to learn programming in an easy, encouraging way. If MNBIOS-BASIC adds some of the benefits QBASIC-alike BASICs have, adds speed comparable to BASIC-kun and even the option to scroll or (!!) screensplits in BASIC it will alow many, many, many people to create very impressive products with only little efforts.

- MNBIOS is not intended for everyone. What I mean is: highly experienced coders will always prefer coding their own 'OS' specifically designed for the projects they are working on. An all-purpose-(BI)OS often adds more limitations than convenience. If you want to squeeze ultimate performance from an MSX, that's probably not what you want.

According to me it would help if a beta-version was released in the near future, so people can have a look at what has already been achieved. Although I might give the impression, I'm not an experienced Z80 assembly coder. Basically, Flyguille is looking for people with enough time and experience to help him out on some tricky routines and a BASIC parser. The persons he needs to code these routines will probably not be using MNBIOS in the end, for the reason that they are skilled enough to create those routines all by themselves. So, experienced MSX coders out there: consider doing it for the newbies, for the novice coders... for the people who are eager to show their ideas on MSX, but do not have the skills yet to do so (like you probably had in the past as well).

If MNBIOS succeeds in its goals it will certainly be a very valuable addition to the MSX Community

Luckilly the MSX world doesn't evolve around a few persons thinking they are always right. If one person doesn't see the need for a new BIOS or BASIC, so be it. I won't shed a tear. Many people or MSX groups made their own OS for years. It's their way of doing things they like best and in most cases they're the only ones using it anyway. It does result in many new things for MSX. And isn't that what MSX is all about?

I too can't believe current MSX programmers didn't start out doing things with MSX-BASIC before they continued in Pascal, assembly, C or other languages... maybe apart from commercial companies.

People aren't too busy all the time. They will always have periods where they're not busy. Some people might have too many projects running or even have a whole lot of plans to work on. They just set the priorities on their project higher which prevents them of doing work on long-term development contests or something.

I think MNBIOS has great potential and once there's a beta version released for developers wanting to make things for it might result in a community within the community.

Hi guys,
I'm project manager of a non MSX project, called PlanetaMessenger.org, and when I started my project 3 years ago, a LOT of people made me some questions, good comments and a LOT of bad comments about my project , but no one gave me some help that time.
I think Flyguille a visionary developer and is trying a great strategy to break the barrier of actual static MSX world (unfortunately for the development's standard this is true).
MSX BIOS is the standard BIOS of MSX ? OK is true, but there's no organization or enterprise upgrading this standard for years (please don't talk nothing about MSX Association, that keep MSX alone for years and continue doing absolutely nothing to revive ( "really" ) the standard, only selling magazines). And community made standard is a good way to keep development active and maintained by people really compromised with MSX development.

Flyguile, unfortunately I'm not a experienced Z80 assembler developer, but if you need a C/C++ (Java?!?! Impossible for MSX for while), please contact me and I'll be a pleasure help you.

Leidson Campos (BR)
PlanetaMessenger.org

>>
1) Where is the stack?
2) What interrupts are available? Where do they land?
3) What is the memory configuration?
4) What BIOS routines are available?
- what do they do?
- what registers go in?
- what registers go out?
5) This needs to be SHORT and CLEAR documentation.
<<

Quote:

That last is already done!.. .. sure you download the MNBIOS programmer manual?

I did some time ago, I downloaded the Spanish one just now to see if it contained more info. I can't seem to find any info on points 1-3. These are possibly even more important than the BIOS info, well, equally important at least. I must say I didn't read all of the 186 pages of it, but by reading it briefly I couldn't find anything on the evironment.

>>
1) Define all commands:
- which commands do you want?
- what do they do?
- what are their token-codes?
2) Define the variable format:
- what variables do you have?
- what is their format?
- what are their limits?
- what operations can be performed?
3) Define your system/state table
- what screen are we in?
- where is the cursor?
- are we using sprites?
- what is the mouse doing right now?
- is there sound playing?
- joysticks
- cassete
- diskdrive
- harddisk
- interrupts
- the million other things I am forgetting
<<

Quote:

That too is already done.... again read the manual.

I couldn't find anything on points 1 and 2. (Remember I'm talking about BASIC tokens and variable setup) Point 3 I couldn't find either. I admit I didn't read all of the pages, but scanning over it I couldn't find it. I'm talking like a big-ass table similar to the one the existing MSX BIOS uses indicating all data on system-state.

Quote:

Escept by PRINT USING, that too is already done...and... too slow? who say that?, maybe the scrolling, not printing chrs.

I'm not talking about BIOS routines, I'm talking about the part of the BASIC interpreter that handles these commands. If you say the BIOS already supports the corresponding commands in Graphical Mode, I'll use them, I don't care... It WILL be a boat-load slower tho, trust me... Anyways, the part that I was talking about is the part that parses all the screen 0 related commands and executes them. This means that the token for example print is passed to a routine along with the data which then decodes it, and checks where the cursor is, what needs to be printed, if it's text, variable, ctrl chars etc and then does as told...

>>
1) All the BIOS routines, including disk I/O
2) The complete memory map
3) The actual state in which a program is loaded
4) All the specifics of the BASIC languae
<<

Quote:

That too is already done.... again read the manual.

Again, points 2, 3 and 4 I could not find. Anyways, if you want help, get going on the things I pointed out. If you feel the BIOS part has already matured to a point in which it can easily be used, I suggest you concentrate on the primary planning of the BASIC interpreter. This means commands, tokens and language structure. If you have that set up, I would be glad to put in my -little- part of the puzzle...

Quote:

Math routines are already implemented in MNBIOS. And with INSANE accuracy, if you ask me The only thing needed is an expressions parser, but those are so easy a child could do it in a day.

Well, that's settled then! You have just appointed yourself as the person that will do the part of the BASIC interpreter that decodes, parses and handles all the math routines!

Congratulations! You can even take more than a day, I guess.... Well fly, you now have Screen 0 support (in Graph mode if you want it to be) and all the math routines for your BASIC interpreter. As a bonus I'll also include the BEEP command on my list of things to do

As the Guru Logic project manager it's my turn to state that GuyveR's got enough work on his hands as it is already