As for the first part of your question: yes, it is possible to fall back to a 'factory default' at any time. You don't need an FPGA cable for that.

In order to answer your second question correctly I'd have to check the exact FPGA reprogramming mechanism of the OCM. I'll get back to it soon, but due to personal circumstances that might take a few days. Hang on!

You need one way or another to communicate with the device in case of failure. Since I have one of the early protoypes Tim it confirms your statement, but I am not aware of the current type-that one was programmed via a spartan fpga and indeed we needed the fpga cable for the price of 126 euro. You can make it yourself but even than it very hard so not impossible to get that device at the corner of the street and as a private person.

Oh btw Tim, a little of topic - but I get nowadays some questions about the sourcecode of FDE , do you have it somewhere still?

sunrise - your comment is - indeed - based on an early prototype of the One Chip MSX. The ASCII One Chip MSX could already be reprogrammed from MSX-DOS, but it did not have an option to recover from failure other than using the FPGA cable you mentioned. The new (D4E) One Chip MSX does have the capability of returning to the default configuration without using such a cable. Once again, I'll get back to describe the exact functionality of it all in the near future.

Quote:

The new (D4E) One Chip MSX does have the capability of returning to the default configuration without using such a cable. Once again, I'll get back to describe the exact functionality of it all in the near future.

I'm very curious how this is done. I hope in a way it makes 'hot reconfiguring' possible, we'll see.

Questions for timbr:

Since you are familiar with VHDL could you estimate/ gamble how easy or difficult is it to make some usefull features in VHDL for 1CMSX?
And what basic skills are required to learn VHDL? If I can program Pascal and C is that as basis enough or do I need to learn assembly first?

Well, I see most people here are concerned about new software... if msxa wants to spend some $$$ on it, I think a small group of brazilian developers could come up with 3-4 games in a year ^_^

I've this feeling that some of the programmers will find it more interesting to poke around in the VHDL to make their MSX-coding life somewhat more easy and add all kinda project-related features (also art-wise). This means we have to wait even longer on products.

Quote:

Questions for timbr: Since you are familiar with VHDL could you estimate/ gamble how easy or difficult is it to make some usefull features in VHDL for 1CMSX? And what basic skills are required to learn VHDL? If I can program Pascal and C is that as basis enough or do I need to learn assembly first?

I think some knowledge of C and Pascal can be usefull. VHDL (and Verilog) are high level languages, so assembly is irrelevant.
Everybody talks about VHDL but there is also Verlilog which also can be used to develop hardware. Both are supported by the Altera development environment.
VHDL looks a bit more like Pascal, Verilog looks a bit more like C.

I'm afraid that some people may think too easy about developing in VHDL. It may look like a normal programming language, it really is totally different than programming software for a CPU.
But I'm sure that everybody that is smart enough to be able to develop software in C/Pascal can learn to develop hardware with VHDL/Verilog, but it will certainly took some time and effort to learn.

VHDL cannot be compared with software programming languages. VHDL is about logic design while C and Pascal are meant for designing code (algorithms). VHDL may look like C or Pascal, but that's syntax, not semantics.

You probably do need to hit yourself in the head a few times to get that sequential thinking out of your system. But it's still a logical system, so if you can program, I think learning this should possible to learn as well.

Hit yourself on the head. Your programs are not sequential? I mean, your MSX executes all instructions in parallel?? Awesome.

In VHDL, there's no assembly, but a bitstream file which configures the FPGA. In VHDL, you have a simulater to view the values of the signals you created. If you start with simple gates, say AND, OR, XOR, NAND or NOR, for which there are Operators in VHDL, you easily get the basic syntax and semantics. You can specify inputs to your gates and see the results on the output -- and even the inner signals, if your design is more complex -- in the simulator window. Then, you can go on step by step to more complicated designs. So you test your components first, than use them to build up a more complex gate or device. This than is simulated too, and so on. It's a little more complicated than in Software, because you have interface descriptions via the ENTITY statement and one or more ARCHITECTRUEs for that entity in a CONFIGURATION section, you can select on of them for simulating or bitstream generataion. It seems to be complicated, but it is a very nice feature I like to have for software developement, too.

Actually, the gates, registers the design is built on are working in parallel. VHDL can describe this parallelism!

To get back to the real topic, here my personal wishlist:

- Hot reconfigure FPGA possible (Snout, you allready know more about this?).
- 4MB mapper instead of only 256kB (why only 256kB when there is 32MB available?).
- Possibility to map all available memory (32MB), including the VRAM area.
This feature is extremely usefull when hot reconfiguring is possible, to prepare the memory content for it. Also useable for linear VRAM addressing.
- Fast Z80 (I guess +/- 40 MHz should be possible with this FPGA).
- MegaROM loader tool to play .rom files directly, needs little hardware support.
- Disk image loader tool to play .dsk images directly (like FDE). This may need little support from hardware.
- Better FDISK/firmware then I know from the Sunrise IDE interface, supporting PC compatible partition table and FAT16 out of the box. Also 'format' from MSX-DOS2 should work properly.

tim - unfortunately I can't tell you more about the hot configurability of the FPGA at this moment. Due to personal circumstances I haven't had the time to get into it as of yet. I'll post about it in this forum thread as soon as I do know more about it.

As for the mapper, Bazix suggested to set the default to 2MB RAM. All I can tell now that a final decision about this has not been made, but the default config will have -at least- 256kB. Quite a few of the suggestions voiced by Bazix (and others) have made it to the real thing, so... there's a chance!

The disk image loader tool is already there. Being MEGA-SCSI compatible, the disk image loader 'EP' (fat16 version) works perfectly on the One Chip MSX. This also answers your FAT16 suggestion, the OCM already supports FAT16 (and a PC compatible partition table) out-of-the-box.

As for the MegaROM loader: through jumpers, the OCM can be configured to have either a 512KB Snatcher compatible RAM cartridge in Slot 2, or an ESE Flash ROM cartridge of 512kB. At least, this is the case in the prototype to be demonstrated at the Bazix stand in Bussum. It's likely, but not confirmed yet, whether or not this funtionality will be there in the final product as well, but if not the code needed to make it all work is bound to hit the web shortly after the release of the OCM.