@Flyguille: Unfortunately I only have ICQ. Regarding the amount of memory SymbOS currently is limited to 576KB because of its CPC origin (it's the maximum for the Amstrad). It would be possible to increase it to 2MB, but that's the absolute maximum for the "main" memory in SymbOS. Additional memory could only be accessed like a mass storage device.
I think speed is important for a 8bit Z80 based system with only 3,5MHz, so I won't support multiple mappers at the same time, otherwise task switching will be slowed down a lot. Of course it would be nice to support as much as possible, but one of the goals of SymbOS is, that it runs also quite ok on a standard MSX2 or a standard CPC6128 without extensions.
So, ok, I am not thinking BIG in this case Regarding 16bit memory mappers, I wonder with which CPU you want to work with a memory of more than 64MB? Even the R800 should start to run into problems.

Prodatron: Thanks for the update. Now I can start in R800 mode, and the mouse doesn't have button 1 pressed. (Still weird that Edwin could start in R800 mode).
On my 1mb 32MHz A1GT : When I click Browse it hangs.
Same CF - interface and card in 512kb A1ST : Now I can browse, but none of the apps will start. Not even clicking the clock.
Starting to get a feel for it though, and it seems nice and quick on a TurboR.

I am glad to hear, that some problems are removed now.
Regarding the IDE, is the Sunrise IDE in slot 1 in both machines? On the A1ST you see the list of files, but when you choose an EXE, press "Open" in the browse window and "Ok" in the run window, nothing happens? That's a little bit strange, as when the directory display is working, the other things should work, too... Hm...

Quote:

@Flyguille: Unfortunately I only have ICQ. Regarding the amount of memory SymbOS currently is limited to 576KB because of its CPC origin (it's the maximum for the Amstrad). It would be possible to increase it to 2MB, but that's the absolute maximum for the "main" memory in SymbOS. Additional memory could only be accessed like a mass storage device. I think speed is important for a 8bit Z80 based system with only 3,5MHz, so I won't support multiple mappers at the same time, otherwise task switching will be slowed down a lot. Of course it would be nice to support as much as possible, but one of the goals of SymbOS is, that it runs also quite ok on a standard MSX2 or a standard CPC6128 without extensions. So, ok, I am not thinking BIG in this case Regarding 16bit memory mappers, I wonder with which CPU you want to work with a memory of more than 64MB? Even the R800 should start to run into problems.

Well, I am thinking in BIG, because I hope that msx is not going to be stucked in just msx2.

Anyway GREAT JOB.

Prod: Yes, slot 1 on both. Maybe correct ram detection will help some.
Yes, I do as you say, and nothing opens. I also tried using the keys instead of mouse.

I have tested SymbOS in my real turboR GT (512 KB RAM) + Sunrise CF IDE. I have to say that I'm really amazed with the speed of the OS, I have never seen something similar on MSX. Running it in R800 mode is even faster, although Z80 is already really speedy. I was able to move the cursor, but most of the apps didn't run. I only managed to run SymMinesweeper, AppInfo and the task manager. The border of the screen looks screewed and there seems to be a little screen corruption on the desktop. This is how SymbOS looks on my MSX turboR:



You are doing an excellent work Prodatron. Keep going, as far as I know, you are the first one on the MSX scene that manages to create such a FAST graphical environement for MSX2. Not to mention the multi-tasking, cross-plattaform and hardware abstraction capabilities...

Keep up!

I'm also running this on MSX tR A1GT with internal 512KB memory. In Z80 mode everything works like charm! I think, that the stripes are caused by wrong backround color. In SCREEN 6 the backround color is %xxyy where xx and yy are both colors. One for odd pixels and other for even pixels. Seems that there is now white and black mixed.

On R800 mode at least the sound of SymAMP seems to go wrong and draging of windows tend to hang the machine. (Does not happen always) As Karloch gets graphic corruption I think that the reason for both of these "effects" is, that you don't check, if VDP is ready for another command. You should wait before VDP executed first command before sending another. For PSG corrupted sound I don't have a good reason... I think, that it kind of fast forwards the song, but actual playing (sending data to PSG) does not get time.

So, when you send a new VDP command, first check if the VDP is ready, if not, wait. Probably everyoen thought of this by now, but you never know

It still doesn't seem to work in openMSX though. (That error 02.)
Could you possibly pass us the sources of your IDE controller programming? We could then check what's going on exactly and more easily.

Quote:

I have tested SymbOS in my real turboR GT (512 KB RAM) + Sunrise CF IDE. I have to say that I'm really amazed with the speed of the OS, I have never seen something similar on MSX. Running it in R800 mode is even faster, although Z80 is already really speedy. I was able to move the cursor, but most of the apps didn't run. I only managed to run SymMinesweeper, AppInfo and the task manager. The border of the screen looks screewed and there seems to be a little screen corruption on the desktop. This is how SymbOS looks on my MSX turboR: You are doing an excellent work Prodatron. Keep going, as far as I know, you are the first one on the MSX scene that manages to create such a FAST graphical environement for MSX2. Not to mention the multi-tasking, cross-plattaform and hardware abstraction capabilities... Keep up!

Does screen corruption also happen in z80 mode?

prodatron> if you only want to support one mapper, then you don't have to search for one as the system will select the largest one (or main in case of tR) at boot. You can just search for the number of mapper pages and be done with it. Checking can be really trivial, loop out $FE,1[255, write zero to $8000, then loop 1-255 again and in the loop check if $8000 is zero, if it is, write the number there, if it is not, you have the highest segment number.

Do you indeed skip the CE bit check? If so, you're guaranteed to run into graphical glitches. You can probably get away with it on small stuff like drawing characters, but for larger stuff the VDP can take quite a bit of time. There are also issues with writing to VRAM while a command is being processed. It results in corruption of the written data.

I've been playing with SymbOS now few hours and I'm totally amazed! Everything works so well! During this time I managed to hang SymAMP few times and SymSEE once. I went to taskmanager, killed the apps and... business as usual, application restart and everything is Ok. Damn you, only this took 15 years in Windows environment!

This whole system works so well, that it feels unreal! Even SymCommander it self is a toolset, that beats most of the GUIs that has been seen on MSX before! I find my self comparing SymbOS to Windows all the time rather than MSX-DOS that I should, but still I can't find anything bad to say!

It just feels so weird, that it is faster to browse directorys on full GUI than using DIR command in DOS! For a moment I thougt, that I found a bug because SymCommander did not show all my files from my directory, but when I went to Configuration/Options and increased List buffer size to 4KB this problem dissappeared as well. What can I say anymore... at the moment it is very hard for me to stay still... this is just so ultimate super mega turbo extra 10+ cool!

Quote:

prodatron> if you only want to support one mapper, then you don't have to search for one as the system will select the largest one (or main in case of tR) at boot. You can just search for the number of mapper pages and be done with it. Checking can be really trivial, loop out $FE,1[255, write zero to $8000, then loop 1-255 again and in the loop check if $8000 is zero, if it is, write the number there, if it is not, you have the highest segment number. Do you indeed skip the CE bit check? If so, you're guaranteed to run into graphical glitches. You can probably get away with it on small stuff like drawing characters, but for larger stuff the VDP can take quite a bit of time. There are also issues with writing to VRAM while a command is being processed. It results in corruption of the written data.

No, no that is wrong... the procedure will be a bit different if you plans to run it as a BIOS ROM or not.

But just for symb... do it (Because it loads from an already selected RAM slot/sslot)


1. checks for slot-sslot already selected at page 3.... and use it on all pages.. it is safer. For custom config you can pre-read and store on ram a user system config that set manually in which RAM mapper to work... but in that case you needs to copy all your kernel or to the slot/sslot setted.


Anyway to determine the amount of PAGES is in this way..

ok for 8 bits (CODE NOT TESTED done on the fly)


this code will use page 2 for our convenience but can be anyother

        xor a

bl1:    dec a
        out ($FD),a
        ld ($8000), a
        jrnz, bl1


bl2:  out ($FD),a
        ld hl,($8000)
        cp l
        jr nz, ENDing
        inc a
        jrnz, bl2

        <------- 4MB ram !!!!!

        ....


ENDing:

         dec a

        <----------- OUT [A] = LAST VALID PAGE.
      

but as that page writes a data in every page, you needs to thinks about which addrs at page 2 to use, and to reserve one byte in every module loadeD BEFORE to this test.


And this test is based in that in every MSX system the same RAM's pages is repeated one and other time again and again, simply because there is lines of mapper addr bus, that are ignored. Any way if there is a HOLE of RAM (that i not knows a system that has just a hole), you will get a correct output anyway in a 99% of cases.


That is basic, simple, and works.... but it starts from the point that you knows where the RAM is...

if you runs it in a slot/slot without mapper... it will get $00 as output, meaning that there is no mapper.

this consider that the RAM is in only one range , without holes...as the MSX2 standard is... so this will be ok perfectly for yours goals.

finally got to posting about SymbOS. BIG THUMBS UP Prodatron (and the SymbOS lot!)... amazing achievement!

*NYYRIKKI has done Hello World program for SymbOS and feels happy*

I just tried it in Z80 mode. The border has still the same look and most apps won't work yet, but it looks like there is not screen corruption anymore.