But lotsa listings in the old MCM's (in its MSX+MSDOS) era were nearly uni-system! Only the odd IF THEN here and there to make sure lines were interpreted well.

Quote:

@wolf_ I suppose MSX is defined by a combination of hw (z80, memory model (16kB pages etc..), bus, cart slot format, ...) and sw (bios and basic). The hw is really flexible and allow extensions such as moonsound and gfx9000 although I think a computer with only gfx9000 can't be called MSX (at least 1/2/2+/TR) since it would break bios compability. Another big MSX feature is that all generations are backwards compatible. So doing a computer with only gfx9000 would in that sense not work. But in the end its all up to the ones owning and maintaining the MSX standard to decide. If they choose to break backwards compability its their choise.

Lets assume that there will be a gfx9000 vhdl implementation but that it does not fit on the current 1CM if you leave scc, v9938, etc implementation in place.
If someone makes then a gfx9000 game I don't need (theoretically) the v9938 vhdl in my 1CM, so I can choose my own config to run this game. So I don't think we can draw the backwards compatibility line that easy and therefore draw a conclusion what is backwards compatible and what's not.
Maybe there are in the future different OCM models with more gates. You can then have a situation that you can leave the v9938 vhdl on the chip.

Very interesting discusions here btw.

@wolf_: I think you'll find some things that define MSX on other systems as well (at least similarities). The most MSX specific thing on the hw side is the memory paging (slots and subslots), i.e. the MSX PPI. Then you have the cartridge specification which is actaully quite different (and imo a lot better) than similar systems from the same time. Its really not the extensions that define the MSX, its how the extensions are plugged in and how they work together as one system that is MSX specific.
I also think bios is quite important. the bios is what makes MSX software run transparently on different MSX machines. Although it seems like all manifacturers have choosen the same I/O ports for common peripherals (such as V9938) there is afaik nothing in the standard that says thay need to be at these ports. There are however bios calls you can make to get this information.

On the 'softer' side you have what makes the MSX feel like an MSX (as opposed to a C64). You have the PSG and SCC on MSX1 and the blocky gfx and bright palette. And on MSX2 you have the different generation of OPL's. This is quite different from other systems that were more PCM oriented. I guess PC had the fm synthesis in common with MSX (at least in the early 90's) but Amiga, Atari and others were more sample of players. On MSX2 you have the V9938 which is quite characteristic with its very slow RAM<->VRAM but instead a very powerful command engine.

dvik: about the PPI: is this something which defined MSX towards the outside world? e.g. Joe Average playing a game? And two: is this PPI actually 'nice' to have? 'm again not really mr.tech here, but the 64k adressing limit of the Z80, isn't just that the cause of all these pages? E.g. if you were to design something of a new or improved CPU, wouldn't it be best to get rid of those pages and just make the 'Z80' able to adress more than 64kb to get rid of pages?

*snip*

On MSX2 you have the V9938 which is quite characteristic with its very slow RAM<->VRAM but instead a very powerful command engine.

Other systems had a faster RAM<>VRAM. So, for games and everything, we rely on this command engine, so it's this command engine that more or less defined what we did with it (for games). For the outsider who's just playing games, this is more defining than pages, cartridge slot features and such.
So again, the V9938 defined the MSX2, and MSX2 is more or less 'the' MSX, historically seen, MSX1 comes second, 2+ third, tR fourth (I think )

The FM in the msx'es was also available in game consoles btw.. (or at least 'some' kinda FM) so don't just compare the FM with the PC

Quote:

So again, the V9938 defined the MSX2, and MSX2 is more or less 'the' MSX, historically seen, MSX1 comes second, 2+ third, tR fourth (I think )

I think this is true for most Dutch people. I guess it depends on what country you look at. In Sweden, MSX history is: MSX1, then SVI328, then nothing. In the US is more like: Music computer (Yamaha CX computers were probably the only ones that sold decent in the US)

Quote:

dvik: about the PPI: is this something which defined MSX towards the outside world

I guess you and me are looking for different definitions of what an MSX really is. Since I am a hw/embedded systems guy I think its defined by the details in the hw spec. and here the MSX is really outstanding (MSX2 more so than MSX1).
What makes MSX such a success is that they managed to create a standard where many manifacturers produced (almost) 100% compatible machines. They could only do so because the open MSX hardware and software specification. And they did so because the specifications are very good.

For me, an MSX is in first instance a computer on which I can run all (or at least as much as possible) of the existing MSX software (games, demos, utilities, msx-dos, xcc, zone terra, gen80 assembler, etc).

For the time being I will keep focussing on improving these compatibility aspects of the OCM. At this moment it is a boosted (with many features) MSX2 but I would like to see it first evolve into a boosted MSX turbo R. After that, it is for me time to see further.

Having said that, I'm definitely not against defining an entirely new computer into the OCM with a faster CPU and a VDP with less rendering modes but with direct vram access by the CPU and with a blazingly fast command engine. I'm eventually willing to join such a project. If we get enough people to join this project and to agree on a common standard, we may even get the blessing from MSX Association and that they declare this new design a MSX3 or something like that. After all, only MSX Association can officially declare what is an MSX and what not; they own the MSX trademark.

Keep in mind that to make such a new MSX usefull, we must not only have a bunch of people that implement the VHDL part but there must also be volunteers who want to work on the operating system and on applications. This is a huge undertaking. Obviously, we could decide to keep the CPU compatible with the Z80 so that it will be relatively easy to port SymbOS. That would already give a big jump-start with respect to the OS and applications. But it would also make life difficult on the long run as the 64k address limit would stay in place and would still require paging tricks or some kind of virtual memory approach to be able to manage the memory.

On the other hand, it is also possible to be more ambitios, define a completely new 32-bit CPU and port a minimalistic linux system (e.g. some embedded linux flavor) to it. All options are still open. For me, linux also reflects to a certain extend the MSX spirit; it is also about open standards, hobbyist who program themselves for it, and these kind of things. Though, I can imagine that for the non-developer, the comparison between linux and MSX does not make much sense. After all, what defined MSX for many people are the games and demo's that they have played, seen and used a lot. And this software collection is not available for linux (apart from running it in an MSX emulator). This is even true for myself. MSX does have another feeling then linux simply due to the different software collection available. But the community spirit is much alike.

I can not define MSX. I like dvik his hardware approach, thank you for that. Add up 'the scene', 'the games', 'the create impulse' and probably the 'Zeitgeist' as well.....That's probably the best MSX definition you can get.

I agree with Wolf. The 1chipMSX should be updated only on some issues. We can stay very close to the current MSX2 concept. Just make things a bit faster, easier memory access, do some graphical enhancements and we're ready to move on.

I actually don't believe the 1chipMSX being some kind of device on which you start browsing the WWW, checking your e-mail daily or using it as your daily agenda....There are other devices for that which can take care of those tasks much better. I expect my mobile phone to evolve in that direction actually. Not the 1chipMSX.

Anyway, nice discussions

Indeed, forgot the 'open standard'. It's essential to MSX.

Maybe even MSX (and the OCM) should move towards the mobile area. I like the idea of carrying my MSX around everywhere

Quote:

For the time being I will keep focussing on improving these compatibility aspects of the OCM. At this moment it is a boosted (with many features) MSX2 but I would like to see it first evolve into a boosted MSX turbo R. After that, it is for me time to see further.

Well, I think we all agree on that. There needs to be a firm basis first (which is what I said in my first message as well). After that I don't see an issue expanding on it.

If i need to choose between full moonsound in VHDL or better Z80 and VDP performance, Moonsound is very very very low on the list.

Quote:

Quote: MSX Basic looks quite a lot like GW-Basic iirc) Definitely not ! MSX-BASIC is the most extended form of BASIC, GW-BASIC is very poor by comparison!

Bullcrap. GW-BASIC and MSX- BASIC are very much alike and MSX-BASIC is definitely NOT the most extended BASIC around.
Just have a look at the BASIC of the BCC machines...

Quote:

But lotsa listings in the old MCM's (in its MSX+MSDOS) era were nearly uni-system! Only the odd IF THEN here and there to make sure lines were interpreted well.

ITYM 'dual system' And I do remember those listings. They had a line like MSX=PEEK(&H2D) somewhere at the beginning and then every system specific part was surrounded by IF MSX THEN... ELSE... neat stuff

IMHO one of the first steps in developing a new MSX should be designing a MMU.

Actually 64K addressing + 16K per segment is a real bottleneck.
In any application I can imagine the following areas:
a) application code
b) application source data
c) application destination data
d) system code (system calls and interrupts)
e) system data (stack and vars)
In actual MSXDOS (d) must be in page 0 (IM1 restarts to 0x0038) and (e) in page 3.
So (a), (b) and (c) only have 2 pages which prevents applications from working on data larger than (thorically) 16K.

A new MMU should permit to enable a set of address-translations from "logical" to "physical" addresses.
This could easily fit actual memory model.
Addressable space (16 bit = 64K today, 32 bit = 4G tomorrow ) could be mapped on huge memory areas.

About the "new" cpu what about a custom sort of Z380 with the possibility to (software) switch to full 32bit mode and back to "z80" mode. Bios already contain CHGCPU...

Why on earth should we ever need such large memory models???

I have no idea about how USB connector can be used and for what.

External storage ? We already have a SD slot, modern SD cards have plenty of space on them, so there is no need to implement additional storage device.

Keyboard or mouse ? There is no problem to find a ps/2 kb and mouse nowadays, so there is no immediate need to connect USB kb or mouse.

Using Game Reader as extra cartridge slot ? Most people won't need it, because they already have SCC and enough RAM in OCM, so there is no need to connect extra RAM cartdidge or SCC cartridge.

So, what to connect to USB ? MSX-controlled MP3 player ? Webcam ? Some kind of ethernet-alike networking device ?
Or maybe it can be an easy way to connect many OCMs into local network for multiplayer gaming ?
Do you have other ideas ?

I guess could connect printers (coding the necessary drivers ofcourse).

also Gamepads, external HDD, FDD,...