SymbOS 3.0 is ready

Congratulations for everyone involved in this project. It keeps getting better and better!

If I would ask for something right now, it would be some documentation on how to create disk drivers for it.

Really, really impressive guys.

Also, gunzip!

Indeed it is amazing what SymbOS has achieved. I remember that some msx users said it wouldn't be possible to do what SymbOS already did in his first version. And now it does even more. Congratulations to all of you that made this possible.

The completeness of this package and the care they put into it all is amazing

Yes, this is something i would like myself as well Thing is, SymbOS does not know anything about the MSX configuration after it is started. It does not use any bios or what so ever. The question here is how can we execute MSXDOS from SymbOS without reboot. There is no BIOS call which can do that. (Only a reboot) as far i know? (Because of storage configuration?) In the past i was thinking about some kind of status dump. (memory, cpu state) before starting SymbOS, which you can execute from SymbOS. I don't have the skills to make something like this. (Not sure if this is possible as well) If someone could make something like this, a MSXDOS program, which saves the system status of the machine, which we could execute from SymbOS. Then you can make a shortcut on your desktop which execute something in MSXDOS. But of course you leave the OS then. But in such case you can use SymbOS as a HD menu kind of thing.

Trebmint (Unify) and Prodatron are the real programmers here I only have some basic program skills. But yes.. this idea is really something cool for MSX!

I know, UZIX is the very same, as it is other different OS with different kernel.

I just took a look at the sources and there is, indeed a MSX-DOS 1.0 / CP/M 2.2 emulator, with BDOS included. The file BDOSEMU.AS has following header:

;----------------------------------------------------------
;         MSXDOS 1.0 / CP/M 2.2 emulator for UZIX
;	    a port of EMU.ASZ by Harold F.Bower
;         Copyright (C) 1999,2001 by A&L Software
;----------------------------------------------------------
;
; BDOSEMU:
; It provides a minimal CP/M 2.2 functional subset to allow
; applications to execute in an UZIX process.  It must be
; compiled under Hitech-C to create a "host" UZIX program,
; that will  contain the  CP/M  application.  It  will  be
; "inserted" on the compiled code by the CPM2UZIX program.
; The BDOS code is a port of EMU.ASZ from UZI180 by Harold
; F. Bower,  with  many  parts  enhanced  and/or modified.
;
; MSXDOSEMU:
; MSX-DOS Emulator for UZIX (MSX-DOSEMU) provides a minimal
; CP/M 2.2 functional subset to allow MSX-DOS (mainly CP/M)
; applications to be executed in an UZIX process.  It  must
; be compiled under Hitech-C to be  a  true  UZIX  program.
; The core of MSX-DOSEMU is BDOSEMU,UZIX CP/M 2.2 emulator,
; a port of EMU.ASZ from UZI180 by  Harold  F.  Bower.  The
; advantage of MSX-DOSEMU is that it can  run  the  MSX-DOS
; applications without the need of converting them to  UZIX
; with BDOSEMU.
;
;----------------------------------------------------------

How feasible is to take advantage of this in SymbOS... I guess only Prodatron could say :)

This is a magnificent and excellent work!!
All Msx World thanks the authors for their brilliant software.

Um audio and video player are already in...

OK, i mean audio and video player with all extensions supported
Mods files, SCC, opll, opl4 chip.
The hope is: why have i to use so many software to play my music why symbos can do it?

Very cool! :-)

BTW: Where can I get the new 3.0 version? There is only the 2.1 version in the download section at Symbos.

http://www.symbos.de/download.htm

Many, many thanks, Edoz, for the backgrounds.
You and your team are great developers, really.

https://youtu.be/CSdhPkjon44

Any support regarding mass storage drivers is so much welcome! Source codes of the existing ones are already available, but I will add a detailed documentation now. @sd_snatcher, will inform you about this soon!

I had the same idea at the beginning, too...
"SymbOS should become a demonstration, what could be possible on the CPC since its beginning in the early 80ies."
( http://www.symbos.org/facts.htm )
But now there are much more reasons and motivations around it haha! :D

This is something which would be really cool for sure!
Currently you have NYYRIKKIs ROM starter for the MSX and my emulator SNApshot loader for the CPC for starting games.
I was already thinking about an app, which would start any kind of native CPC app/game within the SymbOS environment. You reboot the system but add some little code, which won't be deleted during reset. SymbOS could even freeze itself during such a game session, if you have enough ram. But that's a nice project for the future again (and completely app-based - no need to modify SymbOS itself).

Unify is the "next" release of SymStudio. I still have a beta version of Unify which i have on my personal share, including my basic projects. Unify beta
Trebmint stopped Unify as well, because of code loss and because of other reasons (stop support of blitz, which he used as development environment) Currently the new project is called Quigs, which is still in development.
Unify is very beta. So don't expect everything. There is less documentation as well. Maybe it would help to have a look to my projects as well. But don't look to my ugly code. Other nice feature is the auto- fill in the editor. (which shows you the commands, not all but some)

Some years ago Trebmint released some introduction movies as well: (which will be somewhat the same like in Unify)

Introduction 1
A sample project part 1
And part 2

Without Trebmint i was not able to make applications for SymbOS, so i like his work very much! And i hope he will release Quigs someday!

Yes it would really help to get the development environment up and running, especially also with the documentation. The more applications are written for SymbOS the more users it will attract. Making it more interesting again to develop for it :P

Interesting youtube movie ;) Seems that you are using a old beta version of SymbOS. Looks like a nice machine. I wonder if it also possible to start the MSX without putting in commands? Can you explain a bit what are you doing with the different displays in this presentation? I also see this border in SymbOS. Is it possible to display it fullscreen? (Like in OpenMSX with F12?)

Yes! This will be a really good idea!! Streaming radio would be possible. Let's see if that can be done in the future.
About the SE-ONE! I'm glad it works with MP3. The Radio app works as well, but have some small issues as well. Be sure you use the last SE-ONE firmware and radio app.

In the past I heard that in SymbOS applications the alternate register set (ex, exx) can not be used, since it is in use by the OS. This is quite a limitation for assembly IMO, the limited number of registers are already quite a puzzle to work with. Would be good if this restriction was lifted.

Also it would be nice to have a brief overview of the 64K application memory layout, how one does banking, what common system calls exist, what limitations there are, what handy system features exist (any memory mgmt / threading classes?), etc. At the same time, is there also low level access so that I can hook up my current routines with a slightly different implementation? Can I define a fast ISR? What are the do's and don'ts?

Currently the TPA size is one of my biggest enemies, and I’m still trying to think of a quick and fairly transparent system that’s not too hard to integrate in my codebases. I’m thinking maybe coroutines with context switches, or 16K code blocks with far calls, something like that. I wonder if you guys came up with anything fancy for SymbOS.

Basically, from an assembly programmers POV, what makes SymbOS a better programming environment than DOS2 and ROM, and how easy is it to port code written for one of those?

In the control panel there is a setting which can be set, called "auto save" If you enable that, (save it), your changes will be saved automatically if you do a proper shutdown. (start -> shutdown)

Yes, SymbOS expects the disk to be there, but it is removed from the hardware. Maybe it helps to select the option in the setup that the disk is not fixed. (Removable disk setting, see page 18 of the installation manual) Not sure if the Sunrise supports this feature, but you can give it a try. Maybe a new feature like a auto mounter will solve this issue as well

Which icon do you mean? Probably this is the same reason as above. Try to set it as a removable device.

Hi,
Symbos is impressive, incredible, awesome! I really love it!
I’m just a bit disappointed that in my turboR only the internal memory is usable (which make it not usable with only 256 k installed on my ST)...
Anyway, I was just just curious about the the techinical reason that make Symbos unable to use the external memory mapper of my MFR or C2 (while they actually work on my MSX2+). Does anybody know why?
Cheers

Actually SymbOS does not have anything to do with this "problem". SymbOS uses just the mapper that MSX-DOS has already selected as primary... And why MSX-DOS selects the internal mapper as primary? -> Because internal memory is a LOT faster to use than external memory in case of MSX tR & R800 CPU. If you switch to external memory you can really see the speed difference with plain eyes... So in the end this is a selection made by ASCII between two bads... Either less mem fast or more mem slowly...

Ok, maybe I didn't select my words carefully, but don't shoot the messenger... I was just trying to answer the "Does anybody know why?"-question... And yes it is a hassle. (Pretty much everything related to MSX slot handling is due to "must do" slot swapping on page 3. Worst MSX design error if you ask me.) Swapping slot every once in a while is not a big thing, but I can imagine it starts to pile up in an multitasking environment where the processes are swapped in/out from memory pretty much hundreds of times in a second... You can see this if you ie. compare printing text on BASIC to SCREEN 3 on MSX1 and MSX2... The MSX2 is more than 4x slower due to slot swapping.

I bet this same explains also the reservation of secondary shadow registers... I guess no one would do such a thing "just for fun". It is a painful sacrifice done for multitasking performance. No one can prevent you to disable interrupts and taking control of shadow registers, but it may have bad effect to performance if you don't do it carefully. How ever I think it is better left for program than do it on OS level that causes huge overload no matter if the registers were used or not... but this is just opinion... I know it is not always quite so straight forward, but same method has been used many times on games interrupt handlers due to same performance reasons.

I can understand your point about slot switching... and I don't see reason why this could not really be added in the future... I can also see why this has not been high in the list... This is very MSX specific code that requires identifying memory mappers etc. SymbOS also can use memory only up to 1MB. I think the main reason why things are like they are is that SymbOS does not originate from MSX. This kind of multiplatform OS like CP/M or SymbOS rarely support all features available in hardware... and even I as MSX user consider that there are more important things to put Prodatron's effort into... such as internet radio etc.

It is a bit about the view you want to take... I can see that you feel that these features have been taken away from you as developer, but in my opinion they have been used vicely by the OS to make the OS what it is... Naturally this means that porting application code1/1 to this OS is not possible, but developing for multitasking OS is quite different anyway. You just can't expect that you can mess around like you do when you have full access to everything and you don't need to share any resources. In perfect world we would have CPU that could take care all of these problems, but unfortunately what we have here is just plain old Z80. I think the user experience that SymbOS offers proves it self that the design decisions taken have not been that bad.

True... The time spent to documentation has not been great, but it is a good idea to take a look at the sources... Almost all of the applications have sources included and the include files are even very well documented and explain what they do... Sure it would be more nice if there could be some big documentation with all the information in nice ordered fashion. There is also quite little to be found from inner parts of OS, but as those parts are still subject to change even in quite radical ways and they contain platform specific code I understand also this quite a well. Giving people free access to inner parts of the OS would also pretty much work against the original idea of making multiplatform OS. We also have to remember that this is pretty much one man's vision done on free time, so we can't really expect it to have professional level support, can we?

Most easy way to start is to install Unify... The process goes something like this:
- Draw / resize a program window
- Draw a textbox inside window
- Write "Hello World" inside textbox
- Draw an "Ok"-button
- Click Ok-button & code and to the "Button click"-function write "Exit" (You can also add BASIC or assembly if you wish)
- Compile

... it has been a LONG time since I've tried last time, so my memory may not serve me well... Maybe better to look some of the apps Edoz has done. I'm also very sure that I've seen some "Hello you"-program example for command line, but I could not find it now... Maybe good idea to ask from Prodatron.... How ever if you look inside symbos_lib-SymShell.asm I don't think you can really go much wrong... Sure there are a lot more things in it that you don't need (like commandline parsing etc.) but if you don't need them, don't define them or just completely delete them.

Can someone point me to the sources of SymbOS? Or tell me how to reach Prodatron? I am checking if MSXUSB support would be great to add.