HW shortage ?

Página 6/16
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11

Por legacy

Hero (570)

Imagen del legacy

16-08-2010, 21:56


So does anybody know where to find the 2x25 connector in The Netherlands or Germany or Belgium??

A bit late, but Reichelt have them.

Por marlon-B

Expert (88)

Imagen del marlon-B

17-08-2010, 10:47

any chance of adding (emulated or new-old-stock) SCC sound into the design? (would save me another slot) LOL!Running Naked in a Field of Flowers

Emulated could be possible.
Do you know if anyone has already analysed the frequency generation?
and any good documents of the inner workings are very welcome.

Otherwise it would take me too long to perfect the emulation.

Por marlon-B

Expert (88)

Imagen del marlon-B

17-08-2010, 10:54


So does anybody know where to find the 2x25 connector in The Netherlands or Germany or Belgium??

A bit late, but Reichelt have them.


thank you very much !
it's never too late.

Por Bastiaan

Champion (333)

Imagen del Bastiaan

17-08-2010, 12:47


Emulated could be possible.
Do you know if anyone has already analysed the frequency generation?
and any good documents of the inner workings are very welcome.

some of the guys mentioned in this doc should know, I guess:
http://www.msxcartridgeshop.com/bin/MegaFlashROM%20SCC+%20User%27s%20Manual.pdf

and it is implemented in most emulators and in the 1 chip msx, but don't know who can tell you all the details... :-?

Por RetroTechie

Paragon (1563)

Imagen del RetroTechie

17-08-2010, 15:52

Sorry will not be compatible with that design.
I have a complete different approach. The communication with the SD-card will be handled by a separate controller.
Which will fill a buffer with the requested data or write from this buffer. This buffer will be memory mapped(that's also why a slot had to be sacrificed). So the speed will be determined by how fast the MSX can do LDIR's.
Also this approach allows support for cards up to 16GB(or more).

Sorry to hear that... Shocked! MSX SD card interfaces are more than fast enough, IIRC the Sharksym design (v2.x) already does this, by using the many T-states of LDIR instructions to clock bits in/out of the SD card, so that MSX gets data at LDIR speed (simple block move in 256 byte chunks, or something like that).

The bigger problem is software support. The latest BIOS from Sharksym is good enough for practical use, but far from reliable/correctly written. By adding yet-another-access-method (beside Sharksym/Erikie's v2.2 and 1chipMSX implementation), you would dilute the effort of writing good drivers even further. Crying

As for high-capacity cards: isn't that purely a software issue (sector addressing <-> byte addressing) ?

Por DD

Expert (88)

Imagen del DD

17-08-2010, 16:36

Hi marlon-B, great to see more hardware developers in the MSX scene!

Indeed there are not many of them. I am also a hardware guy working on MSX hardware, at the moment PlaySoniq with slot expander and 16megabyte but in an FPGA this time. Indeed a real slot expander will be welcome in the MSX world, in fact we have plans (Supersoniqs) to make an expander as well in a very cheap way but to be honest i prefer working together in the MSX community instead of making competition. The design is almost ready, only some parts of the PCB design should be done but maybe it is better in this case that i focus on other things instead. I'm still working on PlaySoniq and maybe later support for DenYoNet again.

What design do you use? I noticed most of the expanders are not masking &HFFFF, the register meant for the slotexpander itself only. Most expanders also send this address to the cartridge which was enabled for &HC000-&HFFFF, if the cartridge contains an expander (there are a few) it won't work at all. If the main expander masks it (KC does!) then at least you have one subslot of that cartridge to use.

Por Yukio

Paragon (1540)

Imagen del Yukio

17-08-2010, 16:48

Sorry will not be compatible with that design.
I have a complete different approach. The communication with the SD-card will be handled by a separate controller.
Which will fill a buffer with the requested data or write from this buffer. This buffer will be memory mapped(that's also why a slot had to be sacrificed). So the speed will be determined by how fast the MSX can do LDIR's.
Also this approach allows support for cards up to 16GB(or more).

Sorry to hear that... Shocked! MSX SD card interfaces are more than fast enough, IIRC the Sharksym design (v2.x) already does this, by using the many T-states of LDIR instructions to clock bits in/out of the SD card, so that MSX gets data at LDIR speed (simple block move in 256 byte chunks, or something like that).

The bigger problem is software support. The latest BIOS from Sharksym is good enough for practical use, but far from reliable/correctly written. By adding yet-another-access-method (beside Sharksym/Erikie's v2.2 and 1chipMSX implementation), you would dilute the effort of writing good drivers even further. Crying

As for high-capacity cards: isn't that purely a software issue (sector addressing <-> byte addressing) ?

The velocity for saving would not be much affected, but a dedicated memory buffer with integrated controller could improve the loading time to 4/8 MB per second (4MB for one mapper, 8 MB for two Memory Mapper sub-slots).This is almost full speed transfer!

It is the base for a full 4MB SRAM (maybe dual) use.Fast RAM without the need of refresh rate!

Por marlon-B

Expert (88)

Imagen del marlon-B

17-08-2010, 17:01


Sorry to hear that... Shocked! MSX SD card interfaces are more than fast enough, IIRC the Sharksym design (v2.x) already does this, by using the many T-states of LDIR instructions to clock bits in/out of the SD card, so that MSX gets data at LDIR speed (simple block move in 256 byte chunks, or something like that).

What I understand is that the sharsym depends on the processing power of the MSX for the speed. Why else would they post different VERY speeds for different MHZ?
And because my system will be memory mapped LDIR in some cases is not even needed you can for example OTIR it right into VRAM.
So any game-/demo- or whatever- coder can for example stream data to show off some pretty animations
and dont have any glitches in the music.


The bigger problem is software support. The latest BIOS from Sharksym is good enough for practical use, but far from reliable/correctly written. By adding yet-another-access-method (besides Sharksym/Erikie's v2.2 and 1chipMSX
implementation), you would dilute the effort of writing good drivers even further. Crying

My goal is to just keep it simple and fast. And so it will be I promise.
With just a few lines of code(which I will provide ofcourse) data can be retrieved/send from/to the interface.

As for high-capacity cards: isn't that purely a software issue (sector addressing <-> byte addressing) ?
If you consider firmware as being software then yes otherwise NO.
I already have proven-firmware in my arsenal for reading/writing fat12/16/32 file-systems.
I've used it in many commercial-projects. There I even used some hardware-compression to further increase the maximum available space.
But I think on the MSX 16 or 32GB will be sufficient.

Por marlon-B

Expert (88)

Imagen del marlon-B

17-08-2010, 17:16

Hi marlon-B, great to see more hardware developers in the MSX scene!

Indeed there are not many of them. I am also a hardware guy working on MSX hardware, at the moment PlaySoniq with slot expander and 16megabyte but in an FPGA this time. Indeed a real slot expander will be welcome in the MSX world, in fact we have plans (Supersoniqs) to make an expander as well in a very cheap way but to be honest i prefer working together in the MSX community instead of making competition. The design is almost ready, only some parts of the PCB design should be done but maybe it is better in this case that i focus on other things instead. I'm still working on PlaySoniq and maybe later support for DenYoNet again.

What design do you use? I noticed most of the expanders are not masking &HFFFF, the register meant for the slotexpander itself only. Most expanders also send this address to the cartridge which was enabled for &HC000-&HFFFF, if the cartridge contains an expander (there are a few) it won't work at all. If the main expander masks it (KC does!) then at least you have one subslot of that cartridge to use.

thanks DD for welcoming me.
Indeed I'm not looking for any competition either. That's why I started this thread asking about shortage of hardware.
I'm doing this just for fun.

I've based my expander on the design MK 3.x.
This design does mask &HFFFF. And i've already built a prototype and it works properly.
I just have to field-test it by using some power-hungry cartridges which I dont have yet.

Por marlon-B

Expert (88)

Imagen del marlon-B

17-08-2010, 17:32

It is the base for a full 4MB SRAM (maybe dual) use.Fast RAM without the need of refresh rate!

DUAL SRAM is very very expensive. It would drive up the price extremely high.
And this is something I do not wish.

That's why I've chosen for a 32k(or larger with mappercircuit. Not decided yet) SRAM buffer separate from the main SRAM.
This buffer can be mapped onto the address space 4000-7FFF,8000-BFFF,4000-BFFF by the flip of bit in a certain IO register.

This is a cheap solution and it will work for certain.

Página 6/16
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11