Looking to do a new hardware project

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

By PingPong

Prophet (3460)

PingPong's picture

07-06-2019, 18:38

buddha_da_great wrote:

- PSG ( I will leave it to the community if 3 or 6 chn is wanted... for me its easy peasy to implement it)

one limit of psg is that envelope pattern & frequency is one. there is a improved PSG where you can choose different frequency and patterns for each channel.
https://www.datasheets360.com/pdf/7756348957606408083
do you think can implement this instead of the normal PSG ?

By RetroTechie

Paragon (1563)

RetroTechie's picture

07-06-2019, 20:34

buddha_da_great wrote:

I do not have any implementations for:
1) MSX AUDIO (Y8950)

If you're good with FPGA's, you might want to have a look at this: Yamaha OPL3 (YMF262) reverse engineered into a SystemVerilog implementation.

Perhaps it would be doable to translate/re-route MSX-Audio music to this? Beside a native interface, of course. Not that MSX needs yet-another-audio-chip imho. But it might be a way to have something useable as MSX-Audio in FPGA implementations. Or develop actual MSX-Audio implementation, using the above to aid in understanding how it all works.

By alexito

Hero (555)

alexito's picture

07-06-2019, 20:53

I would love to see a simple Y8950 ADPCM Engines x 2 or maybe more ADPCM CHANNELS in just a simple MSX Cartridge.

Crying

By Ivan

Ascended (9122)

Ivan's picture

07-06-2019, 23:31

My proposal is a video digitizer cartridge.

As far as I know only two have been made: the Sony HBI-V1 and the Sunrise Video9000.

It is the only expansion that I miss, everything else has been made (again): RAM expansions, slot expanders, music cartridges, flash ROM cartridges, networking,...

We need a video digitizer cartridge! They are no longer available!!!

By Roland007

Expert (85)

Roland007's picture

08-06-2019, 09:53

There already is a storage cartridge, that does SCC(+), PSG and MSX-Music. Why add a co-processor and insane amounts of memory. Unless the coprocessor is used automatically, you would need developers to write routines for detection and use. A special processor for I/O? Sound great, but is the MSX databus capable of transferring data without the Z80 or should it be put on hold?

The question what is MSX for you is the most relevant and not answered. Statistically its relevant if you want to develop hardware.

I think MSX is finished as it is. How does the majority of all MSX fans use their system? My MSX usage:
- My daughter asks if she can play a game. I connect my MSX and TV. I insert my CV2 and scroll to the game she wants.
- Sometimes I use my Philips module and listen to demo disks
- Sometimes I play some vintage games
- If someone posts a patch for software I use, I start my system, patch and try it
- sometimes, I give C or Pascal a spin but 64 KB is way to limited and even compiling code at 7 MHZ takes long.
- when I don't want to connect the real hardware, I simply start openMSX. Results I copy to the CF card.

I think, working with the limitations is a part of the MSX experience. Need good Music: FM-PAC+MSX Audio + floppy, play a game, just insert the cartridge, want to do some file manipulation: start MSX-DOS etc. Adding 1000's of developers would generate a lot of software, but I would still use my PC's/Mac's as main systems and MSX remains a hobby (a pleasurable way to waste time)

By gdx

Prophet (3088)

gdx's picture

08-06-2019, 10:37

Roland007 wrote:

I would still use my PC's/Mac's as main systems and MSX remains a hobby (a pleasurable way to waste time)

These are the unpleasant moments that are a waste of time!

By wolf_

Ambassador_ (9776)

wolf_'s picture

08-06-2019, 10:47

Roland007 wrote:

Why add a co-processor and insane amounts of memory.

Because the MSX dates back from a time it had three PSG channels, and later on up to nine FM channels. That's quite doable for most productions. Now enter a Moonsound; if ever you're going to use every channel of it, you're talking 24+18=42 channels. Then your replayer will be taxing the MSX' own CPU quite a lot. Say up to 40%, that's where your game coder will tell you: "look, dude, I need the Z80 for my sprites and for this and for that and for blah and for blah. You get twelve channels, or we'll go for the PSG, you decide!" If that proposed chip in this thread has a similar amount of channels, then a co-processor really would unload the main CPU, which will be 100% available for the game engine.

Do you remember how the V9990 was first marketed as an expansion for turbo R? Naturally this chip works on all MSX generations, but the logic behind this thought does make sense. Just think about managing all those sprites and their collisions. This all was a bit of a problem that wasn't spoken about much at the time, but the V9990 and OPL4 can be used in such a way that the tax on the humble Z80 can be huge. Yet this Z80 didn't grow (other than 7MHz or using an R800). Now, replacing the CPU/Engine from an MSX for a faster one can be a tricky thing, so an easier solution can be to introduce a co-CPU.

As for memory, I think it'd be practical to load all game songs in memory, and all of the game's samples as well. That you'll do once at the beginning of the game, and preferably from a fast mass storage medium. After that, your whole game will run like a breeze; music while you load games, maps etc. No more music pauses like when loading portraits in Xak/Gazzel. So yeah, up to 32 MB of memory certainly isn't wrong here.

Quote:

A special processor for I/O? Sound great, but is the MSX databus capable of transferring data without the Z80 or should it be put on hold?

I would think that a co-CPU on a sound cartridge should operate the audio-chip on that cartridge directly, without travelling through the MSX first. This co-CPU (and the software uploaded to it) should send out events to the MSX so that your game can be synced to music, but it should also receive events from the MSX for play, stop, fade-in, pause, fade-out, songselect etc.

The only turd in the pool for this whole concept will be support and tools. As has always been the case. Tongue

By zPasi

Champion (474)

zPasi's picture

08-06-2019, 11:35

wolf_ wrote:

Looking at the Graphics9000, I wonder why the hell that didn't work out.

I don't. Why would developers make software for a device that is rare? And without software, the device doesn't sell much.

Quote:

So, allow me to be somewhat sceptic when I read suggestions for even bigger videocards.

Me too. With todays technology we could implement a GPU with 16M colors and OpenGL for MSX, but what's the point? Then the CPU and the bus were the bottleneck. No problem, just include a four-core processor and fast memory in the "graphics" cartridge. Then throw away the MSX and just use the cartridge. Smile

Quote:

Is it the retro system from your younger days?

Yes.

Quote:

Or should it be as potent as any modern day PC?

No.

Quote:

or is it also a machine you use for word processing, e-mail, internet, spreadsheets and what not?

No, why would I want to do that?

The only exception for me is sometimes I wish I could code with MSX. Of course you can code with MSX, but I mean with proper tools that just aren't there. There is BASIC of course (very limited), then there are clumsy editors and assemblers, and C-compilers decades old.

Quote:

3) A dedicated CPU for disk access. This, to ensure that a game (most notably the music) can continue while other stuff is being loaded.

Well, a dedicated CPU could load that game in a second or so, if installed in same cartridge with the card reader and a game mapper. I wonder why no-one has implemented that?

I actually made such a device some years ago with an STM32-board, but it got a little burnt and I didn't bother to diagnose it.

By PingPong

Prophet (3460)

PingPong's picture

08-06-2019, 11:44

wolf_ wrote:
Roland007 wrote:

Why add a co-processor and insane amounts of memory.

Because the MSX dates back from a time it had three PSG channels, and later on up to nine FM channels. That's quite doable for most productions. Now enter a Moonsound; if ever you're going to use every channel of it, you're talking 24+18=42 channels. Then your replayer will be taxing the MSX' own CPU quite a lot. Say up to 40%, that's where your game coder will tell you: "look, dude, I need the Z80 for my sprites and for this and for that and for blah and for blah. You get twelve channels, or we'll go for the PSG, you decide!" If that proposed chip in this thread has a similar amount of channels, then a co-processor really would unload the main CPU, which will be 100% available for the game engine.

I Agree. it was also done on some arcade machines. 68000 as the main CPU, z80 sound processor to manage sound.

Quote:

Do you remember how the V9990 was first marketed as an expansion for turbo R? Naturally this chip works on all MSX generations, but the logic behind this thought does make sense. Just think about managing all those sprites and their collisions.

Here things are not so simple. the v9990 also add capabilities that help a lot to unload cpu. say:
- better VRAM access with a simpler protocol, and no brake
- fast blitter
- no need to sat rotation (pratically)
- better sprites no need of tricks
- scroll registers
- pattern mode. (even if 16 bit)

By zPasi

Champion (474)

zPasi's picture

08-06-2019, 11:48

buddha_da_great wrote:

It includes a Spartan-6 with built-in dedicated DSP and 32MB DDR3

Wow, that should be enough I think!

Quote:

- Z80 CoProcessor running at a Multiple of 3,58. or the same. I will let you decide.

If there would be an option to shut up the main Z80 and use the MSX with that coprocessor overclocked, that would be cool.

But whatever you do, please make it open source!

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