Quote:

Of course, this was and still is within well defined boundaries.

not even close to the MSX definition, but nice ideas

Quote:

Future extensions for the OCM shouldn't be necessarily compatible with previous MSX generations.

I agree. There is no reason to not use the OCM to its fullest potential. Its just sad seeing it be called MSX. I'd prefer to call the hardware 'retro platform' or something and the current VHDL implementation MSX. But I guess Trembint is right. If the box says MSX, that's what it is. Unfortunate that MSX no longer is the nice well specified hw and software platform that it once was

Just another couple of applications I'd like to have on a OCM:
- internal debugger: capable of breaking execution of cpu and dumping Z80 and peripheral registers
- machine state freeze/save/load: with all the memory available it could be possible to store many machine states and switch from a state to the other in the time of an ALT+TAB

Pressing F12 on the keyboard already activates numerous odd debug screens, actually...

i'm going to do what i did first on all other systems i programmed for, write pacman for it (in VHDL) i can't wait to pick up my old hobby and write pacman again is some weird system.

after that i might go help if some people are going to implement the ultimate retro gaming platform for the OCM. i really like to see some Z80-ish based machine combined with SNES-ish VDP Features. i think if we hope to set a new standard we should aim at the ultimate game development station for oldskool games. (i bet some oldskool MSX developers would love to be creative on such a device)

of course i agree that some people should try to extend the OCM's msx implementation to a hacked version. preferably there would be only 1 such a hacked version. features for that could be:
- msx 2+ video chip with more memory
- extra sprites on screen
- faster vram access
- maybe faster z80 (maybe only the OUT command to the VDP has to be tweaked to take less t-cycles)

i can imagine though that there is a fairly tight limit to the amount of memory reads the OCM memory controler can do, it might be that there is not so much extra memory access possible that we can actually speed up the whole thing as much as we all hope for now.

(one thing about a hacked MSX implementation would be that it does not follow the MSX specs. the whole reason to hack it is to make it go outside those specs and let the OCM specs be the limit)

next to that i think a lot of developers would like to extend the OCM's MSX implementation inside the MSX standard limits. i think for that it would be good to get the USB working as a first step, so people can go write drivers on the MSX for harddrives, mouse, PC-OCM link, network etc. Well maybe the mouse should be hard wired to the joystick port in VHDL code for backward compatability. Also a nice extra would be if you can load ROM images in the OCM without loosing memory in the MSX itself.

i am not sure about the amount of LE's that are free still, and i dunno how much this amount can be after optimizing the VHDL of the MSX, but i think we should not hope to have too much still. so in my opinion it's not good to hope for writing all possible USB drivers in vhdl. of course it would be nice to load a TCP stack in vhdl code, but i am afraid that is not a realistic wish.

hmmm, about that TCP stack, i don't understand what people want to do after getting the MSX online? if you make the MSX connect via USB to the PC then you can do all you want with it. (with the PC for downloading software and functioning as a harddrive, or maybe using a small p2p tool on the PC to connect a MSX net for multiplayer games.) who needs a real network connector on a MSX? what are you going to do? load a webpage with a few 100 something KB jpeg image?

Quote:

what are you going to do? load a webpage with a few 100 something KB jpeg image?

And why not? Wouldn't that be fun?
And wouldn't it be even more fun to run a small web server on it?

lol, of course it would be fun! i just was thinking of the usefullness for the average user set out against the effort (or something like that).

like if you want the msx to be a webserver i think you need the full memory and cpu power to host the tcp buffers and stack + server? well maybe i got sucked into the pc x ghz timezone and forgot that 3.5mhz was all you need to do whatever you liked.

time will tell i guess for i am sure someone finds it kool to go implement networking for the msx.

Well, Adriano Cunha implemented tcp-ip stack and some apps (like IRC, web server, browser) in his Uzix OS, and it worked quite fine. Unfortunately at the time we didn't have ethernet in MSX, so internet connection had to be done using RS-232 and modem (dialing to a ISP), but despite that it was really cool, with a ethernet card with a microcontroller on it and a buffer dealing with sending/receiving bytes in order to speed up the connection (z80 would be free for other tasks) it would be really awesome.

If/when I get my OCM, I plan to buy some wine and cheese, put on romantic music and make hot passionate love to it!

Take that, all you ZX Spectrum affectionados!

Quote:

If/when I get my OCM, I plan to buy some wine and cheese, put on romantic music and make hot passionate love to it!

Using the cas-port?

Quote:

Using the cas-port?

I have a custom-designed I/O device for making love to MSX! It operates at roughly 50 to 60 Hz frequency

Quote:

Quote: Using the cas-port? I have a custom-designed I/O device for making love to MSX! It operates at roughly 50 to 60 Hz frequency

Arf, an MSX operated baby doll (or sybian, for the ladies)

Me rather goes