Quote:

@Alex: Thanx a lot for publishing your FDC routines. I would like to use (and credit) some of your code for autodetecting the different FDCs and for the Toshiba support, if this is ok for you.

Yes. This is OK with me.

Quote:

A questions about the VDP: Seems, that I fixed the crash, which sometimes occured mostly in R800 mode, when sending pixel data from the CPU to the VDP. In the past, I sent the command after writing the first pixel in the data register and then I continued sending data to the data register without checking the "VDP is ready for the next byte" status. If I would check the status before every byte, the routines would become terrible slow. And Toby also told me, that it is not needed. Now it seems, that you have to wait for this status at least between the first (which is sent before the command) and the second byte/pixel. Does anyone made the same experience?

When using the CPU to VDP commands you should check the 'VDP is ready for next byte' status before every byte./pixel. Reason is that the VDP rendering has priority in accessing video ram above the VDP command engine. Consequently, the command engine must regularly wait for memory access and can at those moments not process your data. The VDP manual does not specify the amount of time-slots that the VDP has reserved during rendering for command engine access. So you can not know how long to wait between two writes.

Kind regards,
Alex

@Prodatron

The MSX Info Update 2006 party is now over, but I must say that SymbOS was working really great on the big screen. First I showed all the stuff in Z80 but when people yelled, that they want to see this running on R800 I did that as well... I must say that I think I was lucky but this time I managed to show it so, that it did not hang at all.

For this event I had made a stupid wellcome screen with little logo, text and Ok button and even this made people quite interested about application development. After the show there were few people that really wanted to know all about the API and documentation, but unfortunately I was not able to answer all the questions. I hope that these people will catch up this thread quickly.

I must thank you for all the good work you have done already and I'm really waiting to see all the new stuff that is coming. Keep up the good work!

@Nyyrikki: Wow, that sounds very cool, I am glad, that it worked When will you put some party pictures online? I liked to watch the old ones together with the comments a lot
Currently I am concentrating on some small things like the logo of the appinfo.exe application and the MSX specific keyboard definition in the control panel. Then I hope to be able to implement Alex Toshiba FDC routines. My goal is to have something like a "nearly" release ready for the Retro-Euskal-Party in Bilbao/Spain at the 21.07.

Quote:

My goal is to have something like a "nearly" release ready for the Retro-Euskal-Party in Bilbao/Spain at the 21.07.

Konamiman, the Dumas BIOS developer, as well as the one of InterNestor Lite (the TCP/IP stack for MSX-DOS and RS232/ObsoNET), will be also at Retro-Euskal. He has lots of questions about SymbOS, so it would be interesting if you both have a talk there.

Hi again. Nice to see you're making progress. But still I cannot use symbos on my setup.
Can it still be because of incompatible ibm/msx partition tables? When I try different partitions with the Px syntax in the Symbos command I get different results. My PC cannot read my CF card(!). Even though I now placed Symbos on ALL my seven partitions. On some I get a "File not found", on some I get "Error loading file 0140000000" or something. And even though I use "f0" it still tries to read the floppy when I click "browse", and so it hangs. I really do not wanna reformat my CF, but maybe I'll try if I can take some backup soon.

@Karloch: Yes, I already heard it, I am also very interested in talking about Dums with him.

@Algorythms: Maybe the problem is because of extended partitions. You say, that you have 7 partitions, that means, at least 4 must be extended ones. Can you check this? Currently SymbOS only supports primary partitions.
Your PC can't even ready one of the partitions? On my PC I can only read the first one of the four FAT12 partitions - strange... Now I am using a second FAT32 CF card as IDE slave device for transfering data between the PC and MSX.
When you use the F0 option, the system shouldn't crash when accessing drive A or B. You should get an error message, as the drive doesn't exist, but then you should be able to continue. Just select drive C in the drop down of the browse dialogue.

I have a question about sprites in Screen 6. The mouse pointer doesn't look correct on real machines, so it seems, that every second pixel of the sprites is always in colour 0. Is this normal in Screen 6? It does not happen in the emulator.

In screen 6 a single sprite can indeed have two colours per line, the value you need to put in the sprite-colour table is 4*Cl + Cr + msn, where Cl is the colour for the left (even) pixels, Cr is the colour for the right (odd) pixels, and msn, the most significant nibble, influences collision detection and contains the early clock bit.
My guess is that you forgot the 4*Cl part and that you have just found a bug in your emulator.
The simple solution is to multiply the least significant nibble by 5. For bonus points you use extra sprites to make the pointer move in steps of one rather than two pixels.

Prodatron: I use my printer as a CF interface on the PC, and it can for some reason only access my fat16 msx partition. I do not know how to tell which is primary partition since it's formatted on my msx. I will try to take some backup and format it on a pc.

@Arnold: That's it! This wasn't mentioned in the portar document, and BlueMSX seems to have a wrong behaviour here (@dvik: could this be?). Thank you!
@Algorythms: Maybe you can have a look with fdisk310, but I don't remember, if it shows, if a partition is an extended one or not.

Quote:

@Arnold: That's it! This wasn't mentioned in the portar document, and BlueMSX seems to have a wrong behaviour here (@dvik: could this be?). Thank you!

Maybe you should download the V9938 application manual, it has lots of -relatively clear- info in it, including stuff like this. IIRC the manual suggests alternating patterns to fake a higher resolution. Sprites will still move on the 256x212 layer tho, so you would probably have to keep the lowest/highest bit of the X coordinate seperately. Having said that, the best thing for SymbOS would probably not to use sprites at all. It's a little more work, since it would involve saving the background and erasing the cursor if the area of the cursor is drawn to, but commands should prolly execute roughly 20% faster. Of course tweaks like those are better left for later times tho, once more essential things are working correctly.

Quote:

Quote: @Arnold: That's it! This wasn't mentioned in the portar document, and BlueMSX seems to have a wrong behaviour here (@dvik: could this be?). Thank you! Maybe you should download the V9938 application manual, it has lots of -relatively clear- info in it, including stuff like this. IIRC the manual suggests alternating patterns to fake a higher resolution. Sprites will still move on the 256x212 layer tho, so you would probably have to keep the lowest/highest bit of the X coordinate seperately. Having said that, the best thing for SymbOS would probably not to use sprites at all. It's a little more work, since it would involve saving the background and erasing the cursor if the area of the cursor is drawn to, but commands should prolly execute roughly 20% faster. Of course tweaks like those are better left for later times tho, once more essential things are working correctly.

I agree, later would be a good idea to not use sprites at all. They are better suited for games, and also are limited in game like applications. Under interrupt i can safely erase / save background / redraw a sw cursor without flickering at all using a size of 16x16 pixels.

Cool, I am an MSX addict now
I already tested disableing the mouse pointer sprite during screen operations, but I couldn't SEE a big difference regarding the speed. On the other side the flickering of the cursor looked terrible.
In any case I should stay with the hardware sprite. The reason is: When I am using a software sprite, I need to hide it during screen operations in any case. So why not using a hardware sprite, which I even could deactivate a lot faster. What do you think?

Quote:

Cool, I am an MSX addict now I already tested disableing the mouse pointer sprite during screen operations, but I couldn't SEE a big difference regarding the speed. On the other side the flickering of the cursor looked terrible. In any case I should stay with the hardware sprite. The reason is: When I am using a software sprite, I need to hide it during screen operations in any case. So why not using a hardware sprite, which I even could deactivate a lot faster. What do you think?

The only real reason not to use sprites is the increase in command speed. If you saw no increase in speed with sprites disabled, it means that the VDP is waiting for the Z80, and not the other way around. Since many commands involve sending data from RAM -> VRAM this may well be true. There should be an increase in 'scrolling' and stuff like that though. Just decide later on wether you think it's worth the hassle or not, since it's not all that important for now. Flickering can be easily fixed by rendering the cursor on a back page, or in the 'sprite area' (below line 212). It's probably also a good idea to render the cursor only during VBLANK (faster anyhow), and by doing small moves with one 'big' copy, erasing both the old cursor and plotting the new one in one go. Erasing the cursor would only be required if the area will actually be drawn to, which would of course involve a few extra checks. Like I said tho, not terribly important for now...