Quote:

Quote: I will buy 1chip to have an accurate implementation of an MSX2, not to have an FPGA. I have to disappoint you ARTRAG. The OCM is _not_ (and probably never will be) accurate enough to use as an MSX2 reference system. Its good for playing most existing games but not as a development platform.

Maybe it can be improved to reach accuracy.

Quote:

Not nescessary plain logical, but useful, at least. Yes, you've got it: You can e.g. design a processor for a special purpose with only the insturction set needed for that special task, leaving space for further extensions

Youre on really thin ice Tanni. It is very easy that you loose the MSX soul in the OCM if you start tweaking and improving the core characteristics of the MSX, such as the V99x8 or z80 instruction set. I promise you that only a handful of people will be interested in developing, testing and playing with cool FPGA features (I am actually one of those that is interested so I'm not opposed to the idea). Problem is that noone in the MSX community will be intereseted in a pseudoMSX3 based on some sceners wet dreams.

So that said, I can think of many cool improvments. Here are some, many more to follow:

* Wider address bus (e.g. 20 bit) with extended registers, e.g. xhl
* multiple plane support in the VDP, so you can do semi transparent overlays
* Memory mapped VRAM
* An extra accumulator register in the Z80
* div instructions
* floating point unit
* overclock the VDP command engine (like current OCM)

All these suggestions are 100% backwards compatible with the TR, so all (99%) of existing MSX games can be played

Quote:

Maybe it can be improved to reach accuracy.

Most likely not, unfortunately. But it _can_ be improved and hopefully be much better than existing PC emus.

Tanni, indeed, with structure I mean 'coordinated development'. The scene IS small, there should not be various groups developing the same updates. And I also agree with Wolf as well: the war will not be based on the quality of ones code, but more on 'what makes an MSX'.

And again, I see NO structure in all this. WE SHOULD ACT NOW

And cax, INDEED! What the f*ck is happening in Japan at D4E HQ? Are they developing? And if so, WHAT are they developing?

I keep shouting ^_^

Hmmm, I think it's a little premature to be this negative about the future of the OCM already. First of all, the OCM is already a lot more than a 'basic' MSX2 computer with SD/MMC, 10MHz mode and various sound extensions. This did not fall out of the sky, but was the result of a very small team of developers. These developers intend to continue development for the very same reason why they started it in the first place: they love MSX.

The main difference in the future will be

a] Further development of the OCM will be more open, and will hopefully involve quite a larger group of developers. This does indeed need structure, just as the developments of the past needed structure. Just because you can't see that structure at this moment doesn't mean it was never there. D4E and Bazix have already announced they will release future upgrades for the OCM, which will both involve accuracy and feature updates.

b] Different, independant VHDL upgrades will occur. Donkey Kong mentioned here is already an example. Different systems, weird system upgrades, software-specific VHDL... it could all happen. And that's a good thing. You have got to see hardware in a more software-kind of way here. Just because there's SymbOS, doesn't mean there should be no MNBIOS, Uzix or EdiOS.

tho, practically speaking: Windows kicked OS/2 out of the game.. and since SymbOS apes Windows ...

Quote:

Alex, can I ask you: do you have serious motivation to start OCM VHDL development? And are you doing this in some kind of structured way with other people or all by yourself? You're operating from the side line for quite some time now, yet you seem to be very well informed. Please, enlighten me

At this moment, I have two things in mind that I want to work on:

• Improving the VDP command speed (to be as close as possible to the real one)
  
• Implementing MSX Audio processor (by deriving it from the MSX MUSIC processor)
  

The OCM development has happened from two different tracks that eventually were merged:

Track 1: The people from ESE Artists factory in Japan wanted to implement an MSX-clone in VHDL, so that it can be put in an FPGA. They asked me if I wanted to help with the project. Especially due to my experience with the VDP command engine that I wrote for fMSX and which later also got used in all other MSX emulators. In the early days, we did not yet have a clear idea on what type of hardware board to use to bring the ESE-MSX eventually to the people

Track 2: Mr. Nishi wanted to start the MSX revival. First with an MSX emulator and in a next step with a One Chip MSX. In those days, there was already contact between Mr. Nishi, ESE Artists factory and also myself. I have for example granted Mr. Nishi the permision to use my command engine in the MSX Player. Mr. Nishi founded MSX Association and negotiated with ASCII corporation that he could take over most of the intellectual property rights related to the MSX and he negotiated with Microsoft that the MSX Basic could be used in MSX Player and later also in OCM (as far as I know, MSX Basic is still copyright Microsoft). I do not know the further terms of the agreement between MSX Association, ASCII Corporation and Microsoft.

Eventually, the VHDL code of ESE Artists factory was good enough to be MSX1 compatible. The MSX2 extensions where already well under way but not yet finished. Around that time, agreement had been reached that MSX Association may use the VHDL code of ESE Artists factory people. Furthermore, a few people of ESE Artists factory designed the PCB. MSX Association and ASCII corporation had found a manufacturer who could produce the OCM at a reasonable cost, provided that at least 5000 units would be produced and sold. Otherwise, the unit price was simply too high. As you all know, the order count only reached 3000 units at that moment.

However, meanwhile there were also business ties between MSX Association and D4E. Reason is that D4E is the company behind Project EGG, which sells retro-games that are bundled in emulators. MSX Association negotiated with D4E and several Japanese game companies that the classical MSX games could be sold on Project EGG bundled in MSX Player.

Approximately 2 years later, the VHDL code had further evolved. It is mainly the people from ESE Artists factory in Japan who have spent a lot of time on the project the last 2 years. My own involvement was rather low during that period due to many other things eating my time. Anyway, ESE Artists factory designed a new PCB, taking into account lessons learned from the previous PCB (e.g. the 12 volt on the cartridge port). Meanwhile, ASCII corporation had stepped out of the OCM project (at least, as far as I know, though, I do not know all details of the commercial aspects) but D4E was willing to take care of the mass production and the distribution and retail aspects in Japan. This is how the current OCM came into existence.

So to wrap it up shortly, the PCB design and VHDL design has not been done at the HQ of D4E but in the houses of various MSX hobbyists. Most of them are hardware specialist, who for their profession work at chip design companies. I think that at the moment, I'm the only person who has mainly a software background. So far, I have mainly been in contact with Mr. Tsujikawa of ESE Artists factory. He took care of the coordination between me and the other people of ESE Artists factory. He also designed many parts of the VHDL code. For further info of who designed which parts, you should look into the copyright statements of the VHDL sources.

I guess that if more people in Europe join the project, I could act as liasion between Europe and Japan. We could also for example meet face 2 face at MSX fairs (how about next Nijmegen?) to discuss next steps/contributions by European developers. I hope that MSX-ers from other parts of the world (Brazil?) will join as well.

I suppose that if the number of people contributing remains small, we can keep using direct email contact for discussions and to exchange updates to the code.
If the number of designers/developers however grows, we might want to set-up a mailing list and put the sources somewhere on a server on the internet. Perhaps in sourceforge or perhaps on some other site. There are a few sites dedicated to VHDL projects.

Though, at this moment it is still early days. I like the discussions here about next steps. Some ideas feel like dreams (there are still limitations in what can be fitted in the FPGA). Some sound more realistic. Nevertheless, I have seen often enough that something that sounded like a dream eventually did become a reality. So please keep having the lively debates here.

Ps: One note about dynamic configuration (I have seen some ideas around dynamic configuration in several messages):
It is possible to load a new configuration into the configuration device contained in the OCM. However, the FPGA only reads the configuration device on power-up. Not on a software reset, not on a hardware reset. Only on power-up. So if a game needs special hardware support in the FPGA then the user must first load the hardware configuration into the configuration device. Then power-off and power-on the OCM and only after that, he can load the game. Obviously, this new hardware configuration should still support loading another configuration (like the original one) from the SD-Card.

What I miss in your story is your p.o.v. on 'MSX3' 'n stuff. Like what new stuff is "allowed" in order to still be called "MSX", Latok's concern, so to say. How do you see the differences between MSX and non-MSX, etc.

Another thing to keep in mind: do we wish to spend gates to emulate MSX hardware up to the smallest detail, or do we wish to spend it on raw power, no gates lost just to make sure it 100% mimics an MSX with all its artifacts.

Emulating those artifacts are the trade-off for sticking to old chips..

( * hides for Latok and his spikey club )

Quote:

Emulating those artifacts are the trade-off for sticking to old chips..

It is a choise indeed. If I thought it would be possible to to an accurate MSX2 emulation I'd pick that and fight hard for it. But since I really don't believe that it is possible I think its better to have a decent but not necessarily100% accurate MSX2 emulation and go for new features and aim for something MSX3ish.

PFEW, comforting words from both snout and Alex. THANK YOU very much, guys.

Alex, special thanks to you and your story. I think the need for some kind of liasion between Europe and Japan is huge. Therefore I think it's fantastic you're willing to act exactly like that. I also like the ideas of a mailing list, sourceforge project and IRL meetings. If I can contribute to those things in some kind of way, I am very willing to do so. I'm no programmer, though......

Anyway, the latest reactions are definitely more promising

My 1chipMSX (JP model) arrived today

Too bad there is no SRAM in OCM. Every new feature that changes the default behaviour (for example, LED mod that shows SD/MMC access instead of knightrider mode) could then be configured just like BIOS on PC.

Of course, we have DIP switches, but they are less convenient for this purpose and we have a small number of them.

IMHO this should become a rule for modders: any new feature that changes default behaviour should not cancel the old behaviour and should provide a way to switch back without re-flashing to the older firmware.

BTW, are "firmware" and "flashing" good terms to be used when we are talking about replacing OCM's VHDL code ?

And, yup, congratulations to Latok ! Tell us more about the toy !

Yesterday evening, I just sat down and looked at the 1chipMSX. It's a freaky thing!! I mean.....Old school joystick ports....Next to USB Ports.......MSX cartridge slots......Next to an SD/MMC slot.......Old meets new, in a GREAT way

The casing is very very nice, the MSX logo rocks!! The paper box is nice as well. From the outside it indeed looks amateurish with that pedo sticker, but from the inside, it is nicely customized (folded) for the 1chipMSX. And the manual with its front and back full color is printed on professional paper and has a great lay out. I like such details

Then I just laughed....It's surreal receiving some piece of old<>new hybride device with an MSX logo on it. Then I concluded: it in fact IS a new MSX computer, how bizarre ......But sooooooo cool And it simply looks professional/commercial. Which I like.

Only late yesterday evening I found the time to actually plug in all the necessary cables (not included) and to boot the device. There are 10 dip switches on the back. Out of the box, it boots in MSX Basic 2.0 without disk access. If you switch dip switch 5 it boots with Disk Basic 2.01. And the SD/MMC becomes available. Built-in FAT16 support, awesome

Then I tried some Konami cartridges like Usas and MetalGear2.....They all work just fine. I also tried the Moonsound. MBWAVE116 booted without any problems and it played tunes like a charm

Next to the terribly annoying 'knight rider leds'-feature, I encountered 2 problems which should be fixed:

• The RTC is emulated but settings are not stored. There is no SRAM or battery or something. I like working in screen 0/width80/color15,1,1/keyoff and have to input those settings manually everytime I boot (I wonder now if I should just add 'baskom' to the autoexec.bat file)
• Perhaps more important, the screen 0 blink mode doesn't function! Which makes it practically impossible to use MBWAVE for instance

More to come, it is really really great, all this

Last night I made a small list of what would be a reason for me to make a new game for the OCM specific if ARTRAG and me finish our current project.

My personal interest would be a screen4+ mode which has:
- the 2 colors on one line limit (I love it and it really is very MSX-ish)
- one patternbank of minimal 512 patterns (instead of the 3 independend 256 patterns)
- XOR-ing sprites (or was it OR?) same as the current screen4
- more sprites on one line (let's say 16)
- direct VRAM access

I came up with these requirements with game development in mind that still has some challenges and typical MSX-limitations. So no multicolor, multilayer, large memory and (unfair) numbers of posibble sprites. If I want that then I just go and code some BlitzBasic.

Another reason for my list is that current source code can be easily ported/converted. And the direct VRAM will give us a whole new spectrum of new possible tricks for demos and games.

[edit]
A screen2+ would be okay too (just add the custom palette to the list)
[/edit]