Menu
▾
▴
#222 Run init scripts under the hardwareconfig.xml
This feature request is a subset of the RFE #3209252: For Acid2Test and Acid4Test
Please allow init script to be put inside the hardwareconfig.xml file. It would be used to issue openMSX shell commands on the machine (or extension) initialization.
<init>
toggle_scc_viewer
toggle_vu_meters
toggle_vdp_access_test
</init>
The use case for this would have special machines configured for programming. They would quickly trigger the desired scripts used for the debugging.
Instead of including script inside machine configs, I'd suggest to do it the other way around: start a script which simply creates a machine with the proper config and do the other stuff in the rest of the script.
So, I propose to reject this request. Do you agree?
Humm. IMHO, it would be a bit counter intuitive and make some tests different to run from others.
The idea is that each test is a machine that quickly assures the programmer if his program is doing things right. He would use the AcidxTest machine as any other openMSX machine, so he don't have to invest time on learning how to use them (which would be against the quick and assertive principle of an AcidTest).
Making some test as machines and other as scripts would break this uniformity and simplicity?
Acid1Test would be just a machine
Acid2Test would be a machine, but require some scripts to be started manually to find the unused ports and attach watchpoint for each unused port
Acid3Test would be just a machine again. But maybe some scripts to set breakpoints for the original BIOS positions would be used. This breakpoints would issue warnings.
Acid4Test would require the user to boot any machine, then start a script on the console that starts all the timing testing.
Acid5Test would be just a machine
Acid6Test would be any machine, but the user would run some scripts that would setup traps for common mistakes
It's a bit awkward scenario, if you ask me. Nothing serious, but awkward anyway. :)
But I trust the openMSX team on the decision of the best way to implement concept proposed by the tests. Please think of the tests more like use-cases of aspects to be tested/debugged than a canned solution as it may be sounding.
I think that starting all tests as a script would be a solution. This makes it easier to setup the right conditions for the test and doesn't need the change you originally suggested. That change is not something that fits in the design at all. Machine configurations are only to define hardware, they have nothing to do with scripts. (Think about what happens if a script starts a machine with a script... things you really don't want :)
So, making things uniform could be done by starting any test with a script. And with that, I think all your plans would still be implementable.
I think you're right for the machines based on scripts, like the Acid4 and Acid6 draft proposals.
Please don't get me wrong, but I think that some of the tests, like Acid1 and Acid2 wouldn't fit well as scripts. In fact, they're almost complete as-they-are now, lacking only some minor features, in order of importance:
1) Acid2Test:
a) Reconfigurable MemoryMapper I/O ports, like all other devices on openMSX.
b) Reconfigurable expanded-slot-register address
2) Acid1Test:
a) Possibility to place each frame of the same memory-mapper under a different slot.
The openMSX team don't need to include the machines by default on the emulator if they don't want to. I can made them available on my site coupled with install instructions. I'm just asking for the features needed for the machines to get complete. Mainly the 1a and 1b of the above list, if you ask me. :)
I've been following this discussion for a while, and I suggest FRS reads the MSX standard properly and stop making bombastic and false claims (in general).
(this comment rewritten 4 times to be less offensive)
Patriek,
That's a sad and improper accusation. I would like to know what are those "bombastic and false claims" you're talking about.
Why are you making personal attacks? Its it because you don't agree with the viewpoints? What are you trying to accomplish with this?
Could you please explain your point of view using well based arguments and referencing the standard where appropriate? This is the only rational way to get into a common agreement.
As 1a and 1b are in another fetaure request and we will not implement starting of scripts in a hardware configuration XML file, I will close this request.