Waaaaahhh!! It works!
Can you imagine: I detected the wrong FAT type... SymbOS detected FAT16 instead of FAT12, so every file, which had a size of more than one cluster, made a crash.

The reason is the following:
- in the microsoft FAT documentation it is written, that only if there are less than 4085 available clusters, it is always FAT12
- SymbOS detected exactly 4085 clusters, so it thought, it is FAT16
- so (1): maybe the SymbOS detection is wrong by 1, and FDISK310 formatted 4084 clusters
- or (2): the SymbOS detection is correct, but the microsoft documentation is wrong and there must be less than 4086 clusters
- or (3): FDISK310 is wrong, and it formats 4085 clusters, but should only format 4084 clusters

If someone has an idea, what of these three possibilities is right, please tell me, otherwise I have to check at least (1).
In any case I will detect fat12 now also with 4085 clusters Everything runs fine with IDE on the TurboR now! Totally cool! I will upload the new version as soon as possible and will also try to write a converter for the video files.

@Dvik: Again, not your fault!
I made the mistake and didn't test it in the emulator with the biggest possible partition...

Here is the new version, which runs fine on my TurboGT with Sunrise IDE and BIG fat12 partition
http://www.symbos.de/files/symbosmsx.zip

Unfortunately I figured out, that it runs very unstable in R800 mode when doing many VDP operations (moving around windows, having a background pictures etc.). Somewhere seems to be a timing issue which I have to fix. In Z80 mode I couldn't find any problems yet, seems to run stable here.

Hi,

I just catched-up on this thread. It is a nice jewel that I have learned about today. Great job done.

@Prodatron: I can provide you with the source of the TC8566AF driver that I wrote for fastcopy a few years ago (fastcopy is a copy program for MSX that directly accesses the diskcontroller).

I noticed in one of your postings the question if the track & sector registers of the WDx controller are write-only: I can confirm this. On some MSX models they are write-only. On other MSX models they can be read and written to. The safest method to stay compatible is to keep track of a copy of the registers in the driver memory. It was one of the problems that I encountered with fastcopy. In the first version of the WDx793 driver I assumed that in all MSX models, the registers could be read. Note that I do not remember anymore which MSX models have the write-only registers.

Furthermore, I will test SymbOS on my MSX turbo R and on the ESE-MSX prototype version 3. The prototype supports MSX2 VDP, including a fully functional command engine. However, the command engine is significantly faster then on real MSX, so based on this thread I expect SymbOS to really fly on it.


Kind regards,
Alex Wulms (a.k.a. XelaSoft)

Wow! it's a large poll!

I want to comment two questions, I have a Sony F700 and a sunrise IDE
Then, when I load an app, first fails ( error 06 ), and in the second attemps, work well, I test it loading symbos on a HD and on a disc, with the same results.

Other theme, the drive letters... in msxdos, the first letter are the HD partitions, then, the CD unit and the last letters are for disk drives... then...
I think that I would be better use the same order that msxdos...

That you think?

Oh yes, another question... I try to modifique the symbos.ini for use the HD unit has the system directory... ( in msxdos as a:, and in symbos as c: ) but I have not obtained that it works

Thanks and excuse my English

Hi Alex, nice to see you here I already read about your FASTCOPY and your FDC routines in the past! I would be very glad to have your help with the Toshiba FDC routines to get the TurboR completely up and running. You can contact me directly at
jmika . a t . symbos . d o t . de
Thanx to you I also understand, why my autodetection routines didn't work on the real machine, but only on the emulator, as I read/write the sector/track registers for testing purpuse. Did you somehow solve this autodetection problem?
What the hell is an ESE-MSX??? Is it the next generation of the OCM?

@Nyyrikki: I started the VID converter in SymPlay, but there is some problem missing. Unfortunately I need to go to bed now, so I can't fix it until 8. Hope you will still be able to run SymbOS tomorrow somehow with IDE, which works now completely on my machine. If it crashes too often on the TurboR just run it in Z80 mode. But I think I already know, what the problem is (CPU->VDP logic pixel transfer mode).

Hi Prodatron,

I have put the fastcopy source on my homepage, in the section 'XelaSoft'. You can find my homepage at:
http://web.inter.nl.net/users/A.P.Wulms/index.html

There are 4 drivers:
dr-bio0.gen: for WD2793 controller
dr-bio1.gen: for WD1793 controller
dr-bio3.gen: for TC8566AF controller in MSX turbo R. It can work in both Z80 and R800 mode
dr-bio4.gen: for TC8566AF controller in MSX turbo R. It switches back to Z80 mode when accessing the floppy. I made it because the R800 mode driver is known to have problems with some external memory modules. Don't know exacly why.
dr-bio5.gen: for TC8566AF controller in a Sanyo Wavy model. The controller is at a different port in this machine. Furthermore, as it is not an MSX turbo R, the driver simply assumes the machine contains a Z80@3.5MHz

Each driver contains an initialization routine that checks if the appropriate memory-addressed controller is present in the slot of the disk-rom

Note that I do not have a driver for the Brazilian MSX models, which have a WDx793 on the I/O ports.


ESE-MSX is a hobby project to re-create MSX in FPGA technology. It was initiated several years ago by a Japanese MSX group called ESE Artists factory. The creators of amongst others the Mega SCSI interface.

The most well known member of this group is Tsujikawa-san. He wrote the PSG, SCC, PPI interface (keyboard, etc) and several other parts of the VHDL code. Another member is Ohnaka-san, who wrote the major part of the VDP rendering. My own contributation is the VDP command engine. Another member is Okazaki-san who at least wrote a low and high-pass filter for the sound processing. I do not know if he also made other contributions.

There is an informal relation between the ESE-MSX project and the OCM project.

The OCM project is an attempt to reproduce MSX in a single-chip with mass production so that the price can be kept low. The OCM project is run by MSX Association, which was founded by Nishi-san, who is the former vice-president (or president?) of ASCII corporation and who was in the 80's instrumental in getting the entire Japanese consumer industry aligned behind the MSX project.

So far, the OCM project has been based on the prototypes of the ESE-MSX boards with our VHDL code. Though, a couple of years ago, Nishi-san was also thinking about making the OCM based on ASIC technology in stead of FPGA technology. I do not know if these plans still exist for a next phase of the OCM project.


Kind regards,
Alex Wulms

Quote:

@Nyyrikki: I started the VID converter in SymPlay, but there is some problem missing. Unfortunately I need to go to bed now, so I can't fix it until 8. Hope you will still be able to run SymbOS tomorrow somehow with IDE, which works now completely on my machine. If it crashes too often on the TurboR just run it in Z80 mode. But I think I already know, what the problem is (CPU->VDP logic pixel transfer mode).

@Prodatron:

What the reason you use the CPU->VDP logical trasfer mode in video playing instead of Byte transfer mode?

In the first mode you have to do 4 times the out to fill the area. Using byte transfer only 1 byte can 'fill' 4 pixels...

Quote:

Waaaaahhh!! It works! Can you imagine: I detected the wrong FAT type... SymbOS detected FAT16 instead of FAT12, so every file, which had a size of more than one cluster, made a crash. The reason is the following: - in the microsoft FAT documentation it is written, that only if there are less than 4085 available clusters, it is always FAT12 - SymbOS detected exactly 4085 clusters, so it thought, it is FAT16 - so (1): maybe the SymbOS detection is wrong by 1, and FDISK310 formatted 4084 clusters - or (2): [...]

A possible source of confusion is that the first cluster on a disk with a FAT file system has number two. Therefore the highest cluster number is equal to the number of clusters plus one.
The drive parameter block you get with the "get allocation" bdos call ($1b) contains the number of clusters +1 at offset 14/15. The number of clusters is returned in register de.

Quote:

What the reason you use the CPU->VDP logical trasfer mode in video playing instead of Byte transfer mode? In the first mode you have to do 4 times the out to fill the area. Using byte transfer only 1 byte can 'fill' 4 pixels...

I do it only, if it is not possible to use the byte mode. So as an example, if it only plots a graphic with the visible width of 3 pixels or so. Now I figured out, that it even sometimes crashed in Z80 mode, but not as often as in R800 mode. I hope to fix this today.

Another thing: I forgot to mention, that you still have to start SymbOS with the F0 option (=deactivated FDC support), if you want to run it on a Panasonic machine with the Toshiba FDC.

@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.

Quote:

Then, when I load an app, first fails ( error 06 ), and in the second attemps, work well, I test it loading symbos on a HD and on a disc, with the same results.

06 means, that the device is not ready (as an example, when no disc is inserted). Hm, strange, especially for IDE...

Quote:

Other theme, the drive letters... in msxdos, the first letter are the HD partitions, then, the CD unit and the last letters are for disk drives... then... I think that I would be better use the same order that msxdos...

Yes, you are right! Currently you already can define all drive letters by yourself. But I should implement an autoconfiguration, if there is no existing INI file. This tool should configure the same drive letters than in MSX-DOS. Another current problem is the drive, where the INI is loaded from/saved to. Currently it's always the same, from which SymbOS has been started, but as the letters maybe different, we have a little chaos here... I will have to solve all these little issues.

Quote:

Oh yes, another question... I try to modifique the symbos.ini for use the HD unit has the system directory... ( in msxdos as a:, and in symbos as c: ) but I have not obtained that it works

The system path starts at address #00AB and can have a maximum length of 32 bytes (including the zero terminator).
The device definition starts at address #0008. The first is the letter (must be in upper case).

Do you need more information?

Quote:

A possible source of confusion is that the first cluster on a disk with a FAT file system has number two. Therefore the highest cluster number is equal to the number of clusters plus one. The drive parameter block you get with the "get allocation" bdos call ($1b) contains the number of clusters +1 at offset 14/15. The number of clusters is returned in register de.

I also start counting from cluster 2. Also WinHex (a disc examination utility for Windows) counts 4085 clusters. So maybe there is an error in the MS documentation. I will try the bdos call, too.

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?

Quote:

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?

I don't think I've ever done that. Perhaps the code in between the initial command and the actual block-outs has always been long enough in my routines for this problem not to occur. I guess the R800 was just fast enough to arrive at your blockout before the VDP was actually ready, despite the massive wait-penalties the R800 incurs. Part of the problem could also be -perhaps- that you're using sprites. I never use sprites, and tend to make a point of disabling them. The extra speed the command-engine gains by this could also be the difference between having to wait and not having to wait. Regardless tho, checking for the initial byte only should have little impact, so I suppose it's best to do this for now.

The funny thing is, that this problem occured only with one routine. I have several other routines, which never crashed. So I think you are totally right, it only happens in very few cases when the bytes maybe send to short after the initial command.
In any case I put a "ready for next byte"-wait now in front of all these routines, and it doesn't crash anymore.