What have you in mind to do with OCM ?

Page 11/19
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13 | 14 | 15 | 16

By Latok

msx guru (3841)

Latok's picture

12-12-2006, 15:23

Big smileBig smileBig smile My 1chipMSX (JP model) arrived today Big smileBig smileBig smile

By cax

Prophet (3736)

cax's picture

12-12-2006, 15:58

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 !

By Latok

msx guru (3841)

Latok's picture

13-12-2006, 10:20

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 Smile

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 Smile

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 Tongue......But sooooooo cool Big smile 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 Smile

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 Smile

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 SmileSmile

By Huey

Prophet (2676)

Huey's picture

13-12-2006, 11:39

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]

By Tanni

Hero (556)

Tanni's picture

13-12-2006, 12:57

dvik, December 11 2006, 18:59:

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.

Dvik, read again what you've quoted from my text. I wrote about a special purpose processor with special instruction set for a special purpose. This was intented for implementing additional functionality, not for replacing the Z80, of course. The OCM is a system on a chip, the MSX system, consisting of the Z80 processor and the special purpose processors VDP, PPI, and PSG. So, if there are USB ports on the OCM, and I we don't want to extend e.g. the PPI (this means the VHDL code of the PPI), we need to add some VHDL code to access these ports. But that isn't enough: We also need to implement the USB protocoll, which might be too performance consuming to the Z80.

To add e.g. a special purpose processor for USB management, we would like to restrict the affect on the system necessary to the smallest amount, using techniques already used in the MSX standard. Such a special purpose processor also hides implementation details and allows improvement without affecting the software support needed. We only have to define a new device, saying that from now on some already reserved port adresses are for USB device access and add some new BIOS calls dedicated to USB support. Thats the way MSX can be extended in a totally standard manner.

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

Maybe only a few people will be interested in development. As I understood what Kay Nishi said, we are invited to develop on the OCM by our own. He wants to promote developing on OCM done by the users. There must be dicussions on what kind of development will be appropriate for future MSX versions, of course.

The ''cool improvementns'' you mention also change dramatically the core characteristics of non tR MSX, as these are extensions to the Instruction Set Architecture (ISA) of the Z80 and the special purpose processors building up the MSX system.

TR is only one way for extending the MSX standard, others also will be possible, so the MSX standard could spread out like the twigs of a tree. The core would be MSX1, MSX2, MSX2+ respectively. Why shouldn't these different twigs have its own kind of MSX ''soul''?

By Tanni

Hero (556)

Tanni's picture

13-12-2006, 13:28

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 Smile

If there are only few developers, at least now and in the near future, some kind of structure (organisation?) will not be necessary. It sounds good but leads to administrative overhead. Kay Nishi intented to raise interest for developing on the OCM and for hardware design on FPGA in general, so we should start as we did in the early 80th with software development. We should differentiate between professional development for updating the OCM and hobbyist development for learning hardware design as intented by Kay Nishi. Sooner or later, the latter may also lead to professional updates to the OCM. With the PC goes on in becoming faster and more complex, it'll be a gap between some small and low power applications and PCs. Development based on MSX or other retro systems may fill in the gap. Compare it with the upcoming of the gameboy.

The quality of the code also depends on the synthesis tool used and the amount of ''effort'' it made. What makes an MSX is quite clear as far as the classical MSX is concerned. What should be a future MSX based on the OCM could have been discussed in deep in the last few years. There were such discussions, yes, but they didn't lead to a reasonable result, as far as I see. That's maybe why we still think of ONE standard (actually, there are four, at least), defending the ''soul'' of MSX, longing for the old days of early computing and gaming etc. Doing so is ok, but should not lead to be not interested in new developments or new opportunities as FPGA or VHDL. The ''soul'' of MSX is what we put there by our own. With the OCM we have the chance to do so more than ever.

By wolf_

Ambassador_ (9903)

wolf_'s picture

13-12-2006, 13:42

Is there a reason things should stay backwards compatible? MSX has always been forwards compatible! Somehow people seem to be hesitating to work with different configurations. What about two configs:

[MSX1 MSX2 MSX2+ tR <additions>] (these additions include G9k, Moonsound, USB etc. etc.)

and

[MSX3 ? ? ? ?] (the most ideal MSX designed today, no gates wasted on chip artifacts etc.)

Best of both worlds I'd say, the first config allows you to play any of the games 'n demos we already have. The second config is simply the nextgen MSX, that doesn't have to be compatible with the first config. The issue ofcourse is how to design this new MSX3 in line with the MSX philosophy. But then again, I already posted the question 'what defines MSX', and that's still a bit unclear.

MSX1 more or less is like a spectrum, Z80, TMS etc. not entirely, but comparible.
What made MSX2? The V9938 I'd say, and that makes it hard to compare with other systems. The rest? Comparible with other systems.
What made the MSX2+? The V9958, which is more like a photochip than a gamechip (apart from the scroll registers). And most MSX2+'s had the MSX-Music built-in, for the rest, nothing notable.
What made the tR? All the MSX2+ things + the R800 + the PCM, the rest -afaik- was already available as option for 2 and 2+ (MIDI, RAM, DOS2)

So, the way I see it: only the videochips made MSX, perhaps a bit o' sound, since other vintage computers had 3-chn chips (SID, PSG), or 4-chn PCM (Amiga). Tho, a PC with a Soundblaster would be comparible with an MSX and MSX-Audio again. (and perhaps MSX-Music, but I don't know whether Soundblasters had more than only a sine for their waveforms)

So, if the real difference between MSX and non-MSX are the videochips (38 and 58) used, then it means the rest could easily be souped-up already, nothing uniquely MSX to loose here. What's left is that videochip which mainly caused quite some pain due its slowness.

2ct. Tongue

By wolf_

Ambassador_ (9903)

wolf_'s picture

13-12-2006, 13:45

note: I'm not entirely sure whether I mixed up backwards and forwards compatibility here Big smile Ohwell, you get the point: MSX1 software runs on MSX2, but not the other way around.. Tongue

By Tanni

Hero (556)

Tanni's picture

13-12-2006, 14:21

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

We should not ''act'' that fast, we still have time until that kind of decisions should be made, if at all. Time will show!

By Tanni

Hero (556)

Tanni's picture

13-12-2006, 14:33

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.

So it is not runtime reconfigurable? What does it mean that ''Obviously, this new hardware configuration should still support loading another configuration (like the original one) from the SD-Card.'' Does it mean that the original configuration can only reconfigurated at power up, but the newly loaded hardware configuration still supports loading another configuration at any time?

Page 11/19
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13 | 14 | 15 | 16