Any interest in a DIY MSX hardware group

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

Par RetroTechie

Paragon (1563)

Portrait de RetroTechie

28-07-2015, 17:35

tvalenca wrote:

Either you do it right from the beginning and use PS2 and/or USB-HID protocols natively,

Not an option. Too many existing software would need patching. Read: until that's done (if ever!), too much existing software wouldn't work. MSX isn't like PC's etc where practically all software goes through the BIOS and you have much freedom to change the underlying hardware.

Either a real PPI (or equivalent), or some translation layer that's more complex that you'd want, but invisible from software point of view. No options in between.

Alexey wrote:

- ATX form factor board with ATX power supply connectors

Arghhhh, and require a PC case? Evil Try Mini ITX, nice size for implementing a mainboard, many good-looking cases exist.

Single DC input, on-board converter to +/-12V.

Quote:

- z80 with selectable modes (normal/turbo)

Yep. I doubt that true R800 compatibility would even be needed. There's very few software around that actually needs an R800. In the few Turbo-R targeting software, what's needed is a fast Z80.
Add a few of the most-used R800 instructions to T(V)80 or other Z80 FPGA clone (if speed alone won't do), patch a few softwares for which that isn't enough, done.

Quote:

- 9958 vdp

I guess what most people don't realize, is that a discrete VDP practically rules out modern video outputs.
VDP included in FPGA: VGA relatively simple, DVI or HDMI possible (given enough development work).
Discrete V9958: analog RGB, composite video optional, and you can forget about other type outputs.

For those people who want analog RGB and nothing else, fine. But technology moves on, and it may only be a matter of time before SCART-equipped TV's become hard to find (like PS/2 keyboards are starting to be these days).
Not to mention DRAM chips for the V9958, those VDP chips themselves, or (with VDP included in FPGA) the possibility of a high-speed VDP, alternative VRAM access methods, etc.

Real V9958 gets you a 100% compatible VDP, but at the cost of a loooottt of options.

Quote:

Maybe a crazy idea, but a flashable ROM BIOS would be great. Also other ROMs should be either socketed or flashable.

Low hanging fruit. A single Flash ROM could be used to include all MSX system ROMs. Having it flashable would be extremely useful for development purposes, and should be doable at 0 extra cost. So stupid not to have that. Tongue

Par Alexey

Guardian (3385)

Portrait de Alexey

28-07-2015, 18:22

ITX is a good form factor indeed. But the small size of the board will reduce DIYability a lot. With this form factor you can say good bye to microchips in DIP packages. Everything will have to be in SOP or even worse. This rules out real VDPs and original sound chips. And all other components will have to be smd too because of space considerations. I also doubt that a 2 layer board will be sufficient if we want all goodies in. Multilayer boards are way more expensive.

One flash for all is good, but will require a boot block so it can be flashed regardless of the main BIOS' functtionality. This can be similar to PC design where the boot block only supports floppy drive interface. We can make a boot manager or even a GUI based setup in the BIOS to select different BIOS images and hardware (for example enable fmpac or other optional hardware).

The problem is - who's gonna code all that? And who's gonna design the hardware? I can't do either of those. Forgive my pessimism, but I think this project will not leave this forum's thread. But I would like to be proven wrong...

Par ToriHino

Paladin (766)

Portrait de ToriHino

28-07-2015, 20:19

Quote:

I guess what most people don't realize, is that a discrete VDP practically rules out modern video outputs.
VDP included in FPGA: VGA relatively simple, DVI or HDMI possible (given enough development work).
Discrete V9958: analog RGB, composite video optional, and you can forget about other type outputs.

For those people who want analog RGB and nothing else, fine. But technology moves on, and it may only be a matter of time before SCART-equipped TV's become hard to find (like PS/2 keyboards are starting to be these days).
Not to mention DRAM chips for the V9958, those VDP chips themselves, or (with VDP included in FPGA) the possibility of a high-speed VDP, alternative VRAM access methods, etc.

Real V9958 gets you a 100% compatible VDP, but at the cost of a loooottt of options.

And why not go for the V9978 (as a combination of V9958 and V9990) to finally create what the Turbo-R should have been?

Par syn

Prophet (2096)

Portrait de syn

28-07-2015, 21:56

Coincidentally I discussed this yesterday over at #msxdev.

The v9978 was never meant to be a v9958 with added screenmodes. look here : http://www.msx.org/forum/msx-talk/hardware/yamaha-v9978-data...

A data sheet was found, it seems the v9990 is exactly what the v9978 was intended to be. No built-in v9958.

I think they intended for a Turbo R to be r800 + v9990, and adding a z80+v9958 for backwards compatibility.

Par tvalenca

Paladin (747)

Portrait de tvalenca

28-07-2015, 22:11

Well... my answer got too long Sad sorry about that!

As @PAC and @syn said, I would agree that we need a faster Z80, a V9958 and a FM chip as a starting point. But I feel a little uncomfortable with that FM chip being the YM2413. I think it would be better using a OPL4 and SD-Snatcher's MSX-AUDIO BIOS for OPL3/OPL4, as the OPL4 chip is at the same time 100% compatible with FM part of MSX-AUDIO (which is a OPL1, but is listening to a different I/O port than Moonsound) and the BIOS has a OPLL-to-OPLn conversion. As you can tell, this would be a problem as some software was written ignoring BIOS and direct accessing YM2413 I/O port. If weren't for that we'll had just the OPL4 at its full capacity.

Like @syn said, I'm also a MSX-Audio fan, and I would like to do something about the ADPCM issue, which is not playable on OPL4. And about OPL4 Sample Memory, I'm not sure if it can hold an entire 4MB SRAM bank, but we can make the ROM bank Flasheable/overridable (you write to it and its new contents are there only when the computer is on, when you turn it off it returns to its original state).

As @RetroTechie already said to @Alexey, I'd say having a flashable ROM BIOS isn't a crazy idea, but a must.

Regarding @darkschneider666 and @RetroTechie answers, I'm still reluctant about having a "PS2-to-PPI converter" instead of converting software to use BIOS calls to read keyboard, so we can use a native PS2 keyboard controller or a USB-HID controller and have the BIOS to work natively with them. @RetroTechie thinks there's too much software that does direct keyboard scanning, And I think this is something worth testing, as SD-Snatcher already provided an Acid-Test that would detect that. (http://frs.badcoffee.info/MSXAcidTests.html).

Likewise the YM2413 issue, I would like to see the software being patched over such hardware translation solutions (two FM chips and two BIOS extensions on a single MSx on the YM2413 issue). Here in Brazil, we call that way of doing things "gambiarra". You may know it as quick-fix or jerry-rig. But the worse of it is that we're doing a gambiarra and we still have the ghosting problem, which is worse on PC keyboards. That means we're going to force people to use joysticks on MSX because they can't, for example, fly diagonally and shoot at same time on Gradius/Nemesis, not to mention possible issues with Speccy ports that use QAOP keys for moving and M or spacebar for action. (even if I still think they also should be patched)

A new MSX keyboard would be the best solution, but impratical and very expensive. You may like to use any MSX keyboard you have lying around, but it wouldn't be a universal solution because the different connectors, layouts and keyboard matrixes.

About Video capabilities, answers differ a little: Disagreing with @syn, having two or more VDPs only makes sense when you superimpose them. It's easier, cooler, and also idiot-proof. The only reason to not superimpose them is to use two monitors for two different tasks. But you always can have a switch (or switchable connector) to split video signals rather than superimposing.

VGA/DVI/HDMI outputs are only possible if, like @RetroTechie said, we simulate the V9958 (and/or something else) on FPGA. First of all: We don't have perfect VDP simulations, as we don't have perfect VDP emulations either, so it won't be accurate from the beginning. But while it will put an end to our every day odyssey to hook our computers to modern tv sets, but at the same time will create another issues. I don't know about you, but I can't stand what modern tv's do with SD signals. The image gets too crappy after the stretching. Best way to do that, in my opinion, would be maintaining pixel aspect ratio on 1:1, which will generate a huge letterbox. I wouldn't care if it worked this way, but some people will want to use the extra screen, which will generate new video modes (even new text modes with more than 80 columns are possible). If we do that, I'd like to see a improved PATTERN mode. I know, you only care about bitmap modes, but think about independent multilayer scrolling planes, with less color limitations per tiles and sprites, with shape transformations (mirror, rotate), more sprites per screen and "scanlines", big pattern memory, like every other decent gaming machine from that time (except maybe for SNES mode 7), arcade hardware included. Having something comparable on bitmap modes, would only be pratical with deep modifications on MSX architecture (a fast enough bus, DMA transfers and faster math calculations, which brings us so near to PCs that I'm getting bored just thinking about it)

Just to mention what a faster Z80 can do, I once configured a Z80 clocked at 21,477MHz machine on Blue MSX and it significantly overspeeded the R800 moded (clocked at 7,16MHz) Blue MSX maybe not completely speed accurate, but I got the picture. So, as @RetroTechie said, maybe we don't need a R800 clone, just the faster Z80. But I would like to do math calculations faster. There's some things I'd like to do on my MSX, and right now I have to go to PC to have them done.

As for @syn thoughts about other things that would be nice included on this machine, I agree with @Grauw and @RetroTechie: Its better to stick with the core expansion, and leave the extensions as external devices. The SCC is the best example of it. The way it works makes more sense when it is a external device, as it also works as an external memory mapper device for konami MegaROM games. The same for Flashrom carts. You may want to have better sound mixing capabilities between internal and external devices, and better sound quality. Maybe the only extension that makes sense having internalized is Mass Storage, because it would greatly benefit of increased speed access and making possible to leave external bus only for slower devices, in a similar layout approach to Turbo R design. (internal memory is faster, the rest is slow).

As for Ethernet, MIDI, RS232c, we can just leave them as cartridge expansions, so only who need them will have installed, and they can eventually be improved.

Par tvalenca

Paladin (747)

Portrait de tvalenca

28-07-2015, 22:30

syn wrote:

Coincidentally I discussed this yesterday over at #msxdev.

The v9978 was never meant to be a v9958 with added screenmodes. look here : http://www.msx.org/forum/msx-talk/hardware/yamaha-v9978-data...

A data sheet was found, it seems the v9990 is exactly what the v9978 was intended to be. No built-in v9958.

I think they intended for a Turbo R to be r800 + v9990, and adding a z80+v9958 for backwards compatibility.

That link (to the document inside that forum thread) didn't worked for me. But a 16 bit databus between VDP and R800 would been superb.

Par AxelStone

Prophet (3108)

Portrait de AxelStone

28-07-2015, 22:38

syn wrote:

Coincidentally I discussed this yesterday over at #msxdev.

The v9978 was never meant to be a v9958 with added screenmodes. look here : http://www.msx.org/forum/msx-talk/hardware/yamaha-v9978-data...

A data sheet was found, it seems the v9990 is exactly what the v9978 was intended to be. No built-in v9958.

I think they intended for a Turbo R to be r800 + v9990, and adding a z80+v9958 for backwards compatibility.

Yes but really 9978 was cancelled so we can never know if final version of 9978 should be compatible with 9958. Since 9978 project was cancelled and they switch to 9990, the original desing was lost.

You are right, MSX3 was intended to be a powerfull 16bit machine with unlocked R800 (equivalent to z80@40mhz, not z80@28mhz as the actual R800, and SIMD instructions), an according VDP like 9978 (V9990+V9958) and OPL4 sound chip. Since it was going to be backwards compatible I supposse that finally they should use the most cheap solution: 9978 with 9958 modes built in or 9990 + 9958.

Finally everything was dropped, they launched the remains of the original project using old 9958, limited R800, standar FM-PAC and they called it MSX turbo R.

Par tvalenca

Paladin (747)

Portrait de tvalenca

28-07-2015, 22:46

AxelStone wrote:

Yes but really 9978 was cancelled so we can never know if final version of 9978 should be compatible with 9958. Since 9978 project was cancelled and they switch to 9990, the original desing was lost.

You are right, MSX3 was intended to be a powerfull 16bit machine with unlocked R800 (equivalent to z80@40mhz, not z80@28mhz as the actual R800, and SIMD instructions), an according VDP like 9978 (V9990+V9958) and OPL4 sound chip. Since it was going to be backwards compatible I supposse that finally they should use the most cheap solution: 9978 with 9958 modes built in or 9990 + 9958.

Finally everything was dropped, they launched the remains of the original project using old 9958, limited R800, standar FM-PAC and they called it MSX turbo R.

What a pity. One MSX like that would be superb.

Do you remember where you learned about those MSX3 specifications?

Par syn

Prophet (2096)

Portrait de syn

28-07-2015, 23:00

Quote:

About Video capabilities, answers differ a little: Disagreing with @syn, having two or more VDPs only makes sense when you superimpose them. It's easier, cooler, and also idiot-proof. The only reason to not superimpose them is to use two monitors for two different tasks. But you always can have a switch (or switchable connector) to split video signals rather than superimposing.

I forgot to say superimposed but what you are saying is really basically what I meant in my post. I did mention a switch right Smile Although I have to say, personally I prefer one monitor but two monitor setup does have it use, so its nice to have that option.

Quote:

And about OPL4 Sample Memory, I'm not sure if it can hold an entire 4MB SRAM bank, but we can make the ROM bank Flasheable/overridable (you write to it and its new contents are there only when the computer is on, when you turn it off it returns to its original state).

What do you mean with hold? The specs say the OPL4 can support up to 4 MB sram. if you mean whether the soundbank of the YRW-801 ROM can fit into 4MB SRAM, then yes. I checked it, the rom image is about 2MB. Bifi made a emulated demonstration https://www.youtube.com/watch?v=2EDwMVi5xIc

Par tvalenca

Paladin (747)

Portrait de tvalenca

28-07-2015, 23:28

syn wrote:

What do you mean with hold? The specs say the OPL4 can support up to 4 MB sram. if you mean whether the soundbank of the YRW-801 ROM can fit into 4MB SRAM, then yes. I checked it, the rom image is about 2MB. Bifi made a emulated demonstration https://www.youtube.com/watch?v=2EDwMVi5xIc

I mean that if someone expects to use something inside the YRW-801 ROM, you may still have a copy of it... but you can TEMPORARIALY replace the contents of the ROM the OPL4 is accessing. so you have a big 4MB bank where you upload something onto, and then switch by the original YRW-801, but when you turn off the computer, that 4MB bank loses its contents and the OPL4 switchs back to the YRW-801. Just thinking...

Anyway, I think I got confused about Sample ROM and Sample RAM. Anyway, I just got YMF278B Datasheet: There are 21 lines on memory address bus (MA0-MA20) and 8 lines on memory data bus (MD0-MD7) so, that's 2MB per memory. BUT, there are 10 Memory chip selects (/MCS0-/MCS9), so, theoretically, you can have ten 2MB memories. I don't know how this will work, but you may be correct on what you said about 4MB of SRAM.

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