Asking for the cooperation from MSX Software developers

Page 4/9
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9

By hit9918

Prophet (2923)

hit9918's picture

07-08-2015, 00:37

@Manuel, it was about timer interrupts.

There even is a terminology problem. "PCM" means "you never know".
The MSX1 has as much PCM as the little TurboR, needs 100% cpu.
In Amiga world it is called audio DMA.

It is no problem that MSX has no DMA. An MSX device needs a PIO buffer and an interrupt about it.
The diskette lacks the PIO buffer
The moonsound cracks when uploading data

Mhm now that I think of it, always the same chip and an interrupt, maybe the moonsound is best timer cartridge, lol.
OK, so the MSX3 always had a timer interrupt, synergy, yay Smile

By Grauw

Ascended (10604)

Grauw's picture

07-08-2015, 02:33

NYYRIKKI wrote:
Grauw wrote:

but e.g. the Bit² MIDI interface is still a big question mark.

I've been always under impression that this is just MSX-MIDI combined with 256KB memory mapper... Correct me if I'm wrong. I think you just first need to activate it... Also I think MIDI-Saurus is quite similar... Just different I/O ports or so... This all is anyway based on very faint memory of discussion I had about 20 years ago. Sorry if not very helpful or you feel I'm hijacking this conversation.

No problem Smile. I was referring to the Bit² BM-012 MIDI Interface Cartridge (“MIDI Saurus”) though. The µ-Pack is fully documented and supported in Synthesix, no mysteries there.

The BM-012 “MIDI Saurus” interface is very different, check the link for some details (oh, ah, I see sd_snatcher already elaborated on it a little :)). I know (sort of) the general architecture and the I/O ports it uses, but I’ve no clue about the I/O functions and control interface. I’ve got one though so with a little disassembling and experimentation it should be possible to figure out, like I did for the SFG-05.

By sd_snatcher

Prophet (3510)

sd_snatcher's picture

07-08-2015, 04:07

Quote:

I bet OPLL has no timer interrupt. Else TurboR ST would not lack the amiga sound.

Yes, the OPLL is a OPL chip but it isn't a OPLn, as the "n" stands for a number. Smile
Being a cut down version of the OPL2, the OPLL has no timers.

Quote:

and I bet there is no bios with the functions

Yes, there's a nice BIOS for both the RS-232 and the MSX-MODEM. It even got a version 2 with more advanced functions, it's own work-ram and DMA support.

Quote:

same question about midi cartridges.

Being (AFAIK) the last official device released for the MSX, the MSX-MIDI was designed in a time where the standard was very weak and ASCII seem to have been loosing the principles and cutting down costs wherever they could. This means that it's one of the very few devices where its BIOS does almost nothing. Most of the programming interface described on the MSX-Datapack is based on accessing the I/O ports directly. The ROM is basically used for the MSX-BASIC and offers almost no asm support. It's the very same stripped down version of the MSX-Audio BIOS, without a huge part of its functionality.

Very sad, if you ask me. A clear sign that they already had lost their hope that the system would have any future.

OTOH, the fully fledged MSX-Audio BIOS has most of what's needed for MIDI-out support. It even has hooks for that. It shouldn't be that hard to add full MIDI support on it, but I'm not being able to find free time for that. And would it be even worth trying? Or would just be a waste of time coding something that nobody seems to be interested in using?

By tvalenca

Paladin (747)

tvalenca's picture

07-08-2015, 19:28

hit9918 wrote:

the VDP cartridge would have some brand new port, and nobody would code for it.
then I gave the example "9958 + rs232".
by some magic, this immedeately got a userbase above 0.
some users saying "didnt I have an old rs232 flying around in the basement".
plus a "million" openmsx users just click rs232 expansion.
so that is better than inventing new ports.

I wasn't talking about a new VDP cartridge. I was talking about a "simple cartridge", on which you plug any video output (but RF out), and it will count sync signals as they occour, and this will tell to the cartridge which line VDP is drawing. So, you could tell the cartridge to fire an interruption signal on, let's say, line 50. and this could be done at a very low cost, it's kinda simple to do implement this. Of course this is a special timer, with zero support. But if enough coders ask for them, it may be an interesting option.

Oh, and this circuit is simple enough to be implemented on a game cartridge. one or two RCA jacks, a small CPLD, and some passive components will do the job.

Last but not least, altough it won't be in sync with video output, the RS232 is a cool idea, and saves us the trouble of padronizing another thing that we don't know if will be adopted by coders.

hit9918 wrote:

maybe hardware makers are eager to add a special to give their cartridge a special touch.
for synergy I suggest "compile things from already existing expansions".
and then a little dip switch can make the difference between a happy user and frustrating conflicts.

Yes, I agree. A selfish way to see things. Of course hardware makers want to do something that everyone uses, makes sooo good to the ego! But we already know where this leads us to: tons of useless hardware that no one uses because there's no software support. That's what I had in mind when I started this thread.

The way you said on last quote box leads me to think this way: If I want to offer an "screen line based interrupt generator for MSX computers", better do it adding a second VDP to the cartridge. I don't think this is the way. Or, I got you wrong.

sd_snatcher wrote:

OTOH, the fully fledged MSX-Audio BIOS has most of what's needed for MIDI-out support. It even has hooks for that. It shouldn't be that hard to add full MIDI support on it, but I'm not being able to find free time for that. And would it be even worth trying? Or would just be a waste of time coding something that nobody seems to be interested in using?

I know your realife(tm) activites may drain most of your time for projects like this, but seing you talk this way about MSX-Audio BIOS makes me see it ported for some other devices... YM2413 and YM2151 just to name two MSX related devices. I know this is useless for the OPLL chip (because most softwares for it access directly and it won't make any difference) but I think it will be freaking awesome to have a full MSX-Audio BIOS for YM2413 and MIDI support on my A1GT. I probably would replace the internal MSX-Music BIOS from it if something like that was available. About the YM2151... well @Grauw said he wanted to see a SFG cartridge for non-Yamaha computers, and I probably would like to do something like that because I love the music from arcade games that uses this chip. (I also like the OPN2 from Sega Genesis... but I won't go offtopic on this thread)

By hit9918

Prophet (2923)

hit9918's picture

08-08-2015, 02:23

@tvalenca,

Quote:

The way you said on last quote box leads me to think this way: If I want to offer an "screen line based interrupt generator for MSX computers", better do it adding a second VDP to the cartridge. I don't think this is the way. Or, I got you wrong.

maybe one good indication is "can I click it on the emulators expansion list" Smile

By tvalenca

Paladin (747)

tvalenca's picture

10-08-2015, 18:40

hit9918 wrote:

maybe one good indication is "can I click it on the emulators expansion list" Smile

Good point. But emulators aren't immutable, untouchable... If some coders intend to use the hardware I proposed, I most likely will either code or specify requirements and test cases for the emulator's dev teams code that hardware. Most of the code was already written anyway, No one will need to -for example- rewrite V9990 or V9958 code from scratch just to add a second one on the machine when you need only another instance...

Take for example the ADVRAM from Ademir Carchano. Both BlueMSX and OpenMSX supports it, even if it never reached the market... Pity it won't work from a cartridge, you need to place the circuit between VDP and VRAMs, then take some other signals like MainROM /CS.

By hit9918

Prophet (2923)

hit9918's picture

10-08-2015, 21:58

Programmer thoughts... in the context of there being very low workforce...
The idea of a dual-9958, the sprites of a single 9990 wipe the floor with a dual-9958.
The dual-9958 asks coding a sprite workload distribution engine if gameplay shall not be a toy.
And then it is 16 sprites linecolor mono.
While the 9990 has 16 sprites per scanline in unlimited 16 colors with no coding.

All the MSX3 wet dreams... maybe the question of this era is whether MSX2 coders can imagine to upgrade to the 9958? Smile

The 9958 is not a minor upgrade on 9938 but a whole different kind of critter.
It does what you always wanted from 9938 but got it refused.
Mario could have been in YUV mode with tiles even more reminding of SNES or Nintendo64.

By hit9918

Prophet (2923)

hit9918's picture

10-08-2015, 22:33

An idea for a 9958 cartridge
VDP port dipswitch
patchable ROM to upload game or NEOS VDP cartridge ROMs
genlock and digitize

now if someone has a 9958 and puts its output to the cartridge genlock, there is the funky dual-9958 idea.
at same time it is a cartridge for those who always wanted to have the phillips with digitize.
at same time it is MSX2+ cartridge for MSX1 users.
at same time it can give real 9958 to OCM users.
Smile

By tvalenca

Paladin (747)

tvalenca's picture

10-08-2015, 23:06

hit9918 wrote:

Programmer thoughts... in the context of there being very low workforce...
The idea of a dual-9958, the sprites of a single 9990 wipe the floor with a dual-9958.
The dual-9958 asks coding a sprite workload distribution engine if gameplay shall not be a toy.
And then it is 16 sprites linecolor mono.
While the 9990 has 16 sprites per scanline in unlimited 16 colors with no coding.

All the MSX3 wet dreams... maybe the question of this era is whether MSX2 coders can imagine to upgrade to the 9958? Smile

The 9958 is not a minor upgrade on 9938 but a whole different kind of critter.
It does what you always wanted from 9938 but got it refused.
Mario could have been in YUV mode with tiles even more reminding of SNES or Nintendo64.

I think we agree that V9990 is better than two V9958, no matter how much "witchcraft" was made on hardware side. But we have V9990 cartridges around since 1994 if i'm not mistaken, still coders didn't bother coding for them! So, whenever I think on a graphic capabilities upgrade for MSX, better ask coders first IF they want something, and WHAT they want.

Oh, there's something I need to ask: I often see some people talking about SNES (and sometimes N64) graphics capabilities on the same sentence. The problem with this is SNES and N64 have some kind of 3D graphics acceleration (N64 was made with 3D on mind, and SNES mode 7 has an 1/z perspective correction, with hardware zoom and rotation). Are you talking about this, or just about SNES 2D modes (anything but mode 7)? It isn't difficult to implement an framebuffer to hold a new screen mode, but the computing power involved on replicating a mode-7 alike screen mode (with its per frame transformations) is beyond any Z80 coder can imagine.

When I think about better graphics for MSX, I always thought about SEGA Genesis/Mega-Drive alike graphics with more colors (Genesis are only capable of displaying 64 colors at once from 512 colors pallete, and we won't taking a step back giving up on YJK modes). The YM7101 even has similar architecture than our MSX VDPs, because VRAM is only accessible to the CPU through VDP (the YM7101 has DMA thou), 2 tile-based layers with hardware scroll (line & row effects) and tile flipping, 80 sprites on screen, 20 per line, 8x8 to 32x32 with 16 colors per sprite with "integer zoom" and sprite flipping. Altough this is SEGA, I thing this is A LOT like a MSX should be. All this with only 64k VRAM. Anyway, maybe it's better to stick with V9990 than look for a discontinued custom chip made only for SEGA. Think on how much Genesis units we'll need to disassemble to take it's VDPs... maybe for a second version of Franky/Playsoniq (since it is backward compatible with SMS games that don't use TMS9918 video modes)

By hit9918

Prophet (2923)

hit9918's picture

10-08-2015, 23:56

I still must finish my MSX1 game Smile a page 3 bios project intercepted.
For example a multibyte rdslt slot transfer, one could build apps that scale from MSX1 to MSX3 with dozen megs.
I much thought about synergy on the platform.

At some point, when your desire is to make something with a 9958, well just do it.
But then dont be shocked when it gets no games.
The irony is that the naked 9958 itself could need more games Smile

Page 4/9
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9