Bazix reveal further One Chip MSX details and newsletter

Great news indeed!VGA monitor output (which can be used as an RGB-SCART compatible output as well)This part I do not understand -- VGA and SCART are two completely different signals, aight? 31kHz vs. 15kHz and that kind of stuff? How's that possible then?

What kind of cable(s) will be delivered with the OCM since I assume that little ones are capable of making such a cable

I agree, too bad that the extra config won't be available. If MSXA's reply to msx users that complain about missing features is "add yourself everything you wanted in OCM in the first place", how can they release OCM without the restore option? How can they expect someone to develop vhdl code or even try someone else's code knowing that if they screw up, they won't have an easy way to restore the default config? Or will they package with OCM the cable needed to allow people restore the default config just in case something goes wrong?

Sonic: I'm aware of the fact that some of our demands found their way to the OCM. But there are still issues, like code licensing, and now the restore option. The way I see it, both have a big (negative) impact on the sucess of OCM. In order to have a new improved MSX, OCM users need to make their own extensions to VHDL code, and those extensions should be spread among the users. I don't see this happening with these two problems to overcome. I wouldn't try to use new OCM softwares that changes the VHDL without the restore option, after all, if something goes wrong and the OCM doesn't boot anymore, I would need this cable, that doesn't seem to be included in the package. Unless, of course, the cable is included in the package...

@iamweasel,
I don't think the impact will be very huge on the succes. Most people interested in a OCM will only want to have it as a gadget. Most people simply don't program VHDL at all, and thus also won't be very much interested in the licensing.

It is S-Video, not S-VHS. S-VHS is a type of VHS recorder that is always equipped with S-Video in- and outputs. S-Video describes signal - separated Y intensity and C encoded color signal - and connector type, 4 pin mini DIN.
Whether the S-video output of the OCM shows color outside of US, Japan and the rest of the NTSC world, depends on how sophisticated the tv/monitor is. The OCM has NTSC output (mediocre, NTSC is Never The Same Color) and most tv sets in Europe accept PAL color encoding and some, more recent types, also NTSC. turboR owners outside Japan know all about this!
S-Video cables are cheap and widely available.
RGB/Scart beats S-video in all quality aspects and is free of the NTSC/PAL encoding complications.

@snout,
How do you make +12V or -12V out of +5V power supply?

>How do you make +12V or -12V out of +5V power supply?
Ever heard of Switched Mode Power Supplies (SMPS), with this you can create +12V easily from +5V. Just google for step-up or buck convertor and have fun...

Well it's really a pity that the fallback-config couldn't find it's way to the OCM...
But at least there should be another way to do it. Edwin already made a good suggestion IMO.

As the OCM's really a great platform to learn/play VHDL with. I have to learn VHDL atm, it would really come in handy.

Most people simply don't program VHDL at allJust think of some demos/games/... using newly introduced features. Then you are forced to reprogram the OCM.
(perhaps MRC could start a new poll soon, asking how many ppl would *actively* make modifications or develop for OCM)

The VHDL development environment does come with a simulator though which should indicate problems before you even actually put the OCM into the VHDL. People who are serious about developing upgrades for the OCM are also likely to be willing to create, buy or already have the cable needed to restore their OCM if they mock up.Experts will (more likely) avoid "hazardous" code, and/or already have a cable, I agree - but as a beginner I honestly wouldn't dare to rewrite the OCM w/o the restore function.

As long as the upgrades they distribute are properly tested, end-users are not likely to run into problems.And as long as the power supply doesn't get cut

Will there be a OCM-modding database provided (by Bazix?)? So the developers & freaks among us can send their upgrades to and where it gets verified then.

And uhmm snout... when can I order it? *drool*

@vampier: The wii wil just be an emulator. No different than openMSX or blueMSX. That also doesn't stop the ocm.

About the restore/fall-back function: You have to know that during configuring an FPGA, the FPGA will not 'execute' its configuration.

A "load default configuration by pressing [DEL]" could download a new BIOS image on the fly, as this is not part of the FPGA configuration. Re-configuring the configuration device would only be possible if the design is stable enough. (which can be bad due to timing, bus-conflicts, etc. only because of adding this nice small feature like a blinking LED)

But having more configurations would be possible, because an FPGA normally has a few configuration methods:

* Configure using JTAG (For that you can use the 'byteblaster' cable)
* Download using serial configuration (like EPC4)
* Parallel download (Flash-ROM, EPROM, SRAM)

A device like an EPC4 is rather expensive, but easy for layout and configuring. This is the configuration method mentioned at the Bazix site.

Using a parallel configuration device would give the posibility to select a configuration by pulling up/down an address line which is not used by the configuration pins. (most I/O pins will tri-state during configuration, a few I/O pins will act like address, data and control lines during configuration)
Flash memory and SRAM would be suitable for that, but I did not see SRAM, nor do I remember seing flash-memory. SDRAM is not suitable for configuration... So, that leaves out any methods suitable for re-configuration. (Given that it would be possible to re-trigger the FPGA configuration with parallel configuration)

Maybe someone (snout?) can answer the following questions:
* Is there is any flash-memory available?
* Is the MSX-BIOS etc. loaded from the EPC4? (transfer from left over space of the EPC4 to SDRAM)
* Is it possible to pre-release the schematics of the one chip MSX, so all our technical questions can be answered before actually buying/receiving one?

Another question:
* Is the one chip MSX RoHS compliant? That means: is the soldering done without lead?

Because of european environment regulations any new electronic equipment since the 1st of july 2006 must have been produced without lead.
I do not know if the japanese have the same regulations at this time.

Maybe someone (snout?) can answer the following questions:
* Is there is any flash-memory available?
* Is the MSX-BIOS etc. loaded from the EPC4? (transfer from left over space of the EPC4 to SDRAM)
* Is it possible to pre-release the schematics of the one chip MSX, so all our technical questions can be answered before actually buying/receiving one?

Good questions. Especially the schematics would be nice to see.

My proposal regarding the configuration issue:

- On power on a minimal configuration is loaded (no MSX) with only a Z80, Flash, SRAM, SD-Card IF.
- This thing looks in the root of the SD-Card if there is a configuration file (system.hex).
- If it finds this configuration file, it loads it into the SRAM.
- If not, it copies the default configuration from Flash to SRAM.
- It signals a CPLD to reconfigure the FPGA out of SRAM.
- When the MSX is running it can also signal the CPLD to reconfigure out of SRAM making it possible to reload the gateware from MSX-DOS without having to reprogram any Flash.

In this way it is possible to develop new gateware by just putting a file on an SD-Card. The default configuration can safely be updated by reprogramming the flash because if anything goes wrong, you just have to put an SD-Card with a valid 'system.hex' on it into the OCM and it starts again.

Because all of this needs some support from hardware (CPLD, Flash, SRAM connected in the right way),
I have very little hope this is possible with the hardware as it is going to be selled now.
I hope at least it will be possible to make an add-on board that makes this possible (without having to modify the OCM). I'm planning to develop such a board and hopefully can produce and sell the thing with the help of some people (Sunrise, Bazix, ...)

I'll do that. But indeed I'm affraid it's too late now. I assumed the designers of this board made some usable update mechanism because they always stated that it is also meant to 'play with vhdl'. But apparently this was a bad assumtion.

In my (possibly realistic) dreams the following happens:
- The OCM is selled at least 5000 pieces.
- Someone releases the extension board (I am willing to help) and sell it for about 100 pieces, we call it OCM+ or something.
- Because a reasonable amount of people (100) have this OCM+, some nice things will be developed (like a NES game loarder, C64 'emulator' that can be started from MSX-DOS)
- Because of this, a lot more people gets interested and buy the extension board (1000+).
- There are 1000+ potential developers for cool things with this thing.

Or better, but not realistic I'm afraid, the designers add some components making all of this possible from start.

This would be a great idea, mars!

Concerning the restore funtionality: I assumed that these functionality will be present in the new OCM, because it was said that it shall be for learnig VHDL and play around with reconfigurable devices, too. This is the great idea behind the OCM, this is why it could be more than a retrocomputer. If it will lack, it would be very disappointing. It was a mistake right form the start of MSX -- and maybe other homecomputers as well -- not to start with a convenient minimal system configuration. For the first MSX computers this would have been e. g. 64KB of memory as minimal configuration right form the beginning. Maybe this was one of the reasons for the success of the C64. Without restore-function, the OCM is like the ZX81 which also lacks a reset button. But here, the Z80 inside was permanent, so you just need to tear off the power supply and after reconnecting it, the system rebooted.

If you want people to buy, use, learn something, nowerdays, you must make it convenient to apply. We aren't back in the eighties these days!

I don't have personal connections with those people, but there allready are complete vhdl sources available on the net of the C64 (c-one project) and the Amstrad CPC (Turbo CPC). I think it will be relatively easy to port them to the OCM.
I also know that some guy called Kevin is making a FPGA implementation of the NES, but the sources are not on the net. I don't know if he will be interested in porting it to the OCM, or releasing the sources to let someone else do it.

I fail to see why would such option would be so expensive. But if it is, they could have said the price and asked if the customers are willing to pay the extra price. I know I would, maybe others would prefer to have this option as well. For the same reason I would prefer spend some more euros if there was an option to buy an OCM with a bigger FPGA. Some market research could only benefit MSXA and their customers...

Well, some people have MSX1, others MSX2, MSX2+, Turbo-R... I think we already know how to live with the problem you are worried about. But let's forget about a bigger FPGA, since it's not gonna happen. The problem is the restore option, it would be nice to know why we can't have it... I don't remember seeing an answer to this question.

The problem is that everyone needs such a cable once ppl are releasing special software for the OCM. Software that comes with its own VHDL code. It's not unthinkable that some ppl would make an MSX game, and pump-up the sprite-on-a-row limit. In this case the software auto-installs this VHDL code and could restore the old state upon the game's exit.

Sofar so good. But this custom VHDL does most probably not come with an MSXA seal. What if anything goes wrong suddenly? The end-user could be stuck with a dead OCM all of a sudden.

So therefor I think that, if an OCM user will be an active close follower of the OCM 'scene', that a cable or restore function is top-priority. Just dividing between normal users and VHDL freaks, as MSXA might have done, is actually.. uh.. like uhm.. forgetting something essential.

You hit a very good point here, Wolf: I don't think it's realistic to expect that users will buy a cable and learn how to work with the software that programs the FPGA, just because they wanted to play a game that modified the VHDL... And there you lose a huge advantage of the OCM...

The latter is a possible solution, but the other things you said do not apply to the situation I described: the real force of the OCM is that you can provide a piece of hardware with your software. E.g. a game provides a piece of VHDL-hardware to play MP3 files. So, when you run the game of them, it will enhance your OCM with a MP3 replaying hardware.
On a normal MSX, you are used to press the RESET button when you want to exit the game (or start over). So, for OCM, this means that suddenly your MSX is still hardware-modified after the RESET. You can't expect ordinary users to buy a cable to fix this, or to run a program to reset the hardware modification.

However, with some kind of boot menu, in which you can restore the stuff from SD, it might be workable to have the above scenario become reality.

Yeah, but it won't be called if someone just presses the RESET button...

Interesting idea: snout suggests to have some kind of auto-restore at startup, and you suggest one at reset. Maybe it can just be the same, though. As long as the reprogramming doesn't take too long...