HW shortage ?

페이지 8/16
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13

By marlon-B

Expert (88)

marlon-B의 아바타

18-08-2010, 15:39

This PIC-controller is not the one I'll use in the final design ofcourse.
Its programming size is too small to fit all FAT implementations.

but for a proto-type it will do fine with only FAT16 support.

And Yes I used SPI for the low-level diskio.

But I do not understand why there would be any problems with using multiple (different) SD-card interfaces.

By marlon-B

Expert (88)

marlon-B의 아바타

18-08-2010, 15:41

An MP3 Player does exist in a small cartridge (VS1011) at Sunrise, in that case using a AtMega controller as a SPI interface.

good to know MP3 players exist already for the MSX.

By Yukio

Paragon (1540)

Yukio의 아바타

19-08-2010, 03:53

Integrated disc controller.

A 52X CD-ROM XA would need a memory buffer with two sets of 4MB RAM.
8MB RAM is enought for a second of data from the disc.
1x = 150 KB
52x = 7800 KB

8MB = 8192 KB

It would refill almost two *FULL* Mappers per second ...

By DD

Expert (88)

DD의 아바타

19-08-2010, 11:19

The problem of multiple different interfaces is only on the software side. I think (but i'm not a software guy) most of the time the interface is integrated into DOS2, so two interfaces, two times DOS2... At least in the one-chip it does not work but there the SD card interface it is even more integrated, well anyway that's one-chip MSX.

I am using the CF interface of Sunrise and it works fine together with the SD card reader of Sinfox. The only disadvantage from designer point of view is that you'll have to modify existing software or ask a good programmer who likes to make software for it. If the controller handles parts of the FAT system (FAT16 is enough imho) it will probably give much more performance.

By sd_snatcher

Prophet (3501)

sd_snatcher의 아바타

19-08-2010, 15:47

The issue is not the amount of low-level code needed to access the device, but whether you need different code for different interfaces. If yes, then Sharksym's BIOS won't work with your interface. And your BIOS won't work with Sharksym's interface. And there's the 1chipMSX. Which would mean: 3x BIOS, 3x diskROM, 3x low-level driver code. That's a wasteful duplication of effort for something that has essentially same features as existing implementations. MSX land already has very few people that (can) do this kind of thing. If you want to keep things simple, minimize the amount of software work (by making the hardware software-compatible to something that already exists).

You're forgetting the Padial's LPE-MMC interface, with it's Kralizek's BIOS+tools. This would mean then 4x BIOS, 4x diskROM, 4x low-level driver code and 4x tools. Not to mention some very special MSX software would need specific versions/drivers: EVA Player and SymbOS.

By RetroTechie

Paragon (1563)

RetroTechie의 아바타

19-08-2010, 17:02

But I do not understand why there would be any problems with using multiple (different) SD-card interfaces.
In theory there shouldn't be, in practice there are... Part of the problem is that (AFAIK) there's no official documentation for how-to-write-your-own-diskROM. Another problem is that each hdd interface brings its own version of DOS2 kernel, and different versions of MSX-DOS2 system files are used on top of that. For the most part that works, but there are some incompatibilities.

Documentation exists, but you can't be 100% sure what things are (un)safe to do. And thus chances are something won't work somewhere. So you need to test with a lot of different systems and configurations, but of course developers don't always have the time/equipment to do this. So problems are found after release of a disk BIOS, and at that point a buggy BIOS will keep floating around 'forever' even when bugs are found/fixed. Which means workarounds / dirty hacks are used, which may complicate things even further.

In an ideal world, drivers would just do the low-level I/O, and be separate from hardware-independent disk/file code (MSX-DOS 1/2). But because these things are integrated into ROM, that's not the case...

By Yukio

Paragon (1540)

Yukio의 아바타

20-08-2010, 02:56

It would be good if someone take just basic CP/M 2.2 and MSX-DOS 2.20 support ... Well, I think that in most cases someone only would need two drivers. Maybe one for byte I/O transfer and another for Buffered transfer, into somecases it would be just a case of a bigger buffer. Since most languages can support Disk Buffers, this is not a hard work. The problem is if someone wanted to break the 150/300 KB transfer rate!

By marlon-B

Expert (88)

marlon-B의 아바타

20-08-2010, 09:26

In theory there shouldn't be, in practice there are... Part of the problem is that (AFAIK) there's no official documentation for how-to-write-your-own-diskROM. Another problem is that each hdd interface brings its own version of DOS2 kernel, and different versions of MSX-DOS2 system files are used on top of that. For the most part that works, but there are some incompatibilities.

Documentation exists, but you can't be 100% sure what things are (un)safe to do. And thus chances are something won't work somewhere. So you need to test with a lot of different systems and configurations, but of course developers don't always have the time/equipment to do this. So problems are found after release of a disk BIOS, and at that point a buggy BIOS will keep floating around 'forever' even when bugs are found/fixed. Which means workarounds / dirty hacks are used, which may complicate things even further.

In an ideal world, drivers would just do the low-level I/O, and be separate from hardware-independent disk/file code (MSX-DOS 1/2). But because these things are integrated into ROM, that's not the case...

Yes indeed I expected to find some centralized standard shared solutions.

I did find a file called msxdiskroms.zip which contains various diskroms for certain hardware.
But the documentation is minimal. So I dont know if they're complete or not. Or that they are just demo versions. And dos support is probably not up-to-date.
But it does help you get started a bit.

Does anyone know which dos version the latest and proven to be stable?
I will then try to reverse-engineer this version for the additional (missing) information.

By Bastiaan

Champion (333)

Bastiaan의 아바타

20-08-2010, 10:29

By marlon-B

Expert (88)

marlon-B의 아바타

20-08-2010, 12:11

페이지 8/16
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13