Lost somewhere inside OpenMSX, please save me.

Página 2/2
1 |

Por NYYRIKKI

Enlighted (5776)

imagem de NYYRIKKI

20-06-2014, 22:16

Quote:

Yes, that's because in the Japanese computer, that character doesn't exist and the type command uses the character mapping to type what it should. And for this character it doesn't know what to type (so which keys to press) to get this particular character, because it is impossible. How should it know which alternative to type?

Maybe not impossible, but fixing these kind of issues would be very hard and pretty much pointless effort... How ever I think this is one of the things that gives a reason for my script to exist... Although we don't always agree how certain things should be done the beauty that I love on OpenMSX is that all these solutions can live happily together and we can select the scripts and ways of doing things that we found most useful for our own purposes. I very much like the possibility that if I don't like the official solution I can go and fix it for my self without need of forking the OpenMSX project. Only thing I need to learn is how to become OpenMSX power user Smile

I hope that when I ie. design some new hardware I learn to write a script to emulate it in PC so that I can test the driver software before the hardware even exists! And all this is already possible on OpenMSX. Now how cool is that?

Quote:

The installer puts stuff in your Program Files (a.k.a. "System") directory, but you can put your own custom additions in your User directory and the installer will never touch them. See this section of the manual for examples on where the System and User dir are located for several operating systems: http://openmsx.sourceforge.net/manual/setup.html#romlocation

Yes... I know that I've just been using the program wrong way... I really can't blame anyone else for that. I hope I'll get new primary development computer soon and then I'll select different approach. I have currently many computers with many different OpenMSX versions, but only this old one that I use for development is totally messed up in all possible ways. :) Because OpenMSX is not only problem here I've been pushing the project forward for quite a long... Installing OS and setting up ALL the tools you need in a way you like is a project that need at least one case of beer and a free weekend... It is easy to find better things to do. :)

Por Manuel

Ascended (17947)

imagem de Manuel

22-06-2014, 22:03

OK, I'm glad you found out that the scripting engine makes openMSX very powerful, but indeed, you have to become a true power user to get some results.

About emulating new devices: unless they're really simple, I wouldn't recommend to try to use the scripting engine to emulate them. (It's not really meant for that.) But I'd be happy to help you write the proper C++ code to get the device emulated.

Por Manuel

Ascended (17947)

imagem de Manuel

30-06-2016, 23:25

After being reminded to this thread again, I took the liberty to add the script to openMSX... but I made loads of changes to simplify it. For your reference, check out: https://github.com/openMSX/openMSX/commit/3d0645839b2db45ff9... for the details :)

Por NYYRIKKI

Enlighted (5776)

imagem de NYYRIKKI

01-07-2016, 12:35

\o/

Por NYYRIKKI

Enlighted (5776)

imagem de NYYRIKKI

01-07-2016, 13:03

This is nice, but could you consider implementing also alternative for regular "type"-command ?

I think you remember my "hijack" script for CAS-files... I hope that similar script could be used to replace the "type"-command so that we could use Catapult's input window to input BASIC-programs and DOS-scripts fast. I tried to do that once, but with my skills I didn't manage to get it working correctly.

Por rogermm

Master (130)

imagem de rogermm

01-07-2016, 19:03

Manuel wrote:

OK, I'm glad you found out that the scripting engine makes openMSX very powerful, but indeed, you have to become a true power user to get some results.

About emulating new devices: unless they're really simple, I wouldn't recommend to try to use the scripting engine to emulate them. (It's not really meant for that.) But I'd be happy to help you write the proper C++ code to get the device emulated.

I developed a plugin engine on openmsx that loads a generic cartridge as a Windows DLL. Editing the device configuration XML file with the DLL path and optionally some parameters is possible to code a new emulated cartridge without knowing the openmsx internals(lots of high quality C++ source code). I created a directory "plugin" on openmsx data area to host all cartridge dll plugins. The openmsx data structures/objects are hided by the interface.
I coded this plugin system to build the MSX-ARM simulator & SDK suite. The MSX-ARM simulator is a plugin(DLL) from openmsx(coded by me) and the ARM Cortex M4/M7 simulator (uses a proprietary plugin interface) . The MSX-ARM uses some hardware tricks on MSX to accelerate(z80 zombie mode tecnique) the data transfer. The original openmsx cannot emulate this behavior, so I modified openmsx to handle this particular trick! The openmsx continues to work in the same way but the Z80/R800 processor emulation is slightly slower. Not a problem for my AMD at 4Ghz even running the ARM Cortex M4/M7 simulator simultaneously: https://www.youtube.com/watch?v=bEIdZhM_kcA :)

I know it's not a standard/proper and efficient way to do a emulated cartridge device on openmsx, but is more faster to code (don't need to know openmsx internals). Hardware designers without much C++11/14 coding skills can do the work. I don't need to patch all openmsx code at each new release(Currently the plugin system work on 0.12)! I only need to patche the plugin engine(less work and more bug free). It's more easy to debug the newly cartridge too, since the code is on a sand box. The emulated cartridge can be ported to other emulator/platform with the same plugin interface! Using this feature I could port the MSX-ARM board to ZX Spectrum more easily by using the ZX Spectrum emulator

Here there is a device configuration XML file from MSX-ARM cartridge on openmsx:

|?xml version="1.0" ?>
|!DOCTYPE msxconfig SYSTEM 'msxconfig2.dtd'>
|msxconfig>
  |info>
    |name>MsxArm|/name>
    |description|MSXARM cartridge simulator|/description>
  |/info>
  |devices>
    |primary slot="any">
      |secondary slot="any">
        |Plugin id="MSXARM Plugin">
          |dll>
             |filename>d:\data\msxarm\msxarm-simulator\Release\msxarm-plugin-openmsx.dll|/filename>
          |/dll>
          |mem base="0x0000" size="0x10000"/>
        |/Plugin>            
      |/secondary>
    |/primary>
  |/devices>
|/msxconfig>

Por Manuel

Ascended (17947)

imagem de Manuel

02-07-2016, 00:00

NYYRIKKI wrote:

This is nice, but could you consider implementing also alternative for regular "type"-command ?

I think you remember my "hijack" script for CAS-files... I hope that similar script could be used to replace the "type"-command so that we could use Catapult's input window to input BASIC-programs and DOS-scripts fast. I tried to do that once, but with my skills I didn't manage to get it working correctly.

Challenge accepted. I'll create a setting in which you can set which type variant you want. The slow, but robust and keyboard independent one, or the fast, but blunt one, which just puts bytes in the keyboard buffer.

To be honest: I've already done it mostly, but needs some work for the final dots on the i Smile

Por Manuel

Ascended (17947)

imagem de Manuel

07-07-2016, 23:36

Yep, done now. You can select the method to be used for the type command, e.g.
set default_type_proc type_via_keybuf

And this works also for Catapult of course.

Página 2/2
1 |