HW shortage ?

Pagina 7/16
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12

Van marlon-B

Expert (88)

afbeelding van marlon-B

17-08-2010, 17:47

Am I right when I say that the range &H50 -> &h5F is still unused by any hardware ?

going once...

going twice...

Van Latok

msx guru (3875)

afbeelding van Latok

17-08-2010, 18:46

In this MAP entry there is a nice overview of all used I/O-ports.

Van marlon-B

Expert (88)

afbeelding van marlon-B

17-08-2010, 21:22

In this MAP entry there is a nice overview of all used I/O-ports.
thank you Latok.

This is very helpfull.

Van flyguille

Prophet (3028)

afbeelding van flyguille

17-08-2010, 22:48

take in account this, if you want to do a very PRO memory MAP

#F8-#FB
Memory Mapper controller (in 16-bit mappers, contains MSB)

#FC-#FF
Memory Mapper registers

The full standard is 16bit mapper, so you can by example, host a PC-card, SIMM 72pins maybe, that, old, with 32MB 64MB, or maybe there is a possibility of other more highers.

Or mappin a range of pages for accesing VRAM or video card, or something weird.

Van RetroTechie

Paragon (1563)

afbeelding van RetroTechie

18-08-2010, 02:12

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.

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.

I have a feeling you don't understand how Sharksym's design works... it's also memory mapped (and thus takes a slot, which is also used for the diskROM / built-in DOS2). You read a byte using any Z80 instruction you like, and by the time the Z80 is ready to read the next byte, enough clock cycles will have passed for the SD interface to have another byte ready. With a big enough memory-mapped 'window', a simple LDIR will do the job of reading/writing sectors. Sharksym's v2.2 uses discrete logic for controlling the process (design = online), Erikie put that into a CPLD.

Only way to bypass the Z80 would be to write/read directly to/from destination address (DMA), which is only possible for memory that you can fully control. Read: for on-board RAM. But you'd still need to use Z80 for transfers to other memory in the machine (MSX internal RAM / other mappers). Hence the dependence on Z80 clock speed: faster Z80 clock = faster LDIR's = faster transfers. Like you wrote: "So the speed will be determined by how fast the MSX can do LDIR's."

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.

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

I already have proven-firmware in my arsenal for reading/writing fat12/16/32 file-systems.
MSX users have all the space they'll ever need with a few GB's. FAT16 is enough, FAT32 would be useful not for the size, but for easier exchange of cards formatted on other systems. The same goes for partition table formats. The problem is not code for reading partitions or FAT16/FAT32, the problem is integrating that code into system software (MSX-DOS2 / diskROMs). So that code of yours would be nice to have, but it's only a minor part of overall solution.

Van DD

Expert (88)

afbeelding van DD

18-08-2010, 09:29

Great!!! LOL! Do you live in the Netherlands? I think i know a power-hungry cartridge... PlaySoniq also expands the slot and does work only in the digital KC version akaik, just because of masking the &HFFFF. Regarding timing of SLTSL it's no issue, there is a great change that it works but would be very nice to try.

Van marlon-B

Expert (88)

afbeelding van marlon-B

18-08-2010, 12:37

trying to add a picture

www1.xup.in/tn/2010_08/12901401.jpg

for those interested this the working sd-interface proto-type.

has it's own mapper circuit with 512k SRAM as a buffer.

finished it yesterday evening.

next step integrating this design into the slot-expanders.

so back to the drawing board

Van marlon-B

Expert (88)

afbeelding van marlon-B

18-08-2010, 13:07

@RetroTechie:

You're correct that I dont fully understand how Sharksym works. I dont wish to know.
It would take too much time and effort.
It's much faster for me to implement my own design.

making the hardware software-compatible to something that already exists

the problem with this is that I have no control over the development of the software and I dont know who does.
If for instance I were to make enhancements to my hardware at a later time. Meaning adding features not present in the current software. These features "might" never see the light of day.
I would be dependent on the willingness of others to include my features in their software.
Every piece of hardware should have their own bios and drivers. This is also how it works on other platforms.
Or am I mistaken?

MSX users have all the space they'll ever need
I dont believe this to be true.
The more space available to you the more space you will use. Just because it's there. People adapt.
I for example would find it much more "fun" listening to MP3's played on my MSX than on any other device.
So the extra space would come in handy.

Van marlon-B

Expert (88)

afbeelding van marlon-B

18-08-2010, 13:33

Yes I do live in the Netherlands (right now)

but want to emigrate to New-Zealand pretty soon.

Van DD

Expert (88)

afbeelding van DD

18-08-2010, 15:09

Wow, New Zealand... Well it would be nice to try, i don't mind driving for a test with some cartridges. Do you live in the east part? There is an MSX meeting in Mariënberg every 2nd saturday of the month, there are not many MSX meetings left unfortunately. This weekend Helsinki (i'll go there) but in the Netherlands it's very quiet. Anyway you can also contact me, pa4den at hotmail if you want, it should be visible in this forum i think.

Btw, you use a PIC controller, do you use that as a SPI interface or also for the FAT system? There are a number of SD interfaces already indeed and they have compatibility problems also, this is mainly a problem when you want to use 2 SD interfaces in one MSX, i am always struggling with the SD interface in the one-chip-MSX.

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

Pagina 7/16
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12