Quote:
Originally Posted by SiriusHardware
Most odd- so I I've just reassembled the version of Tim's MINEFLD.ASM source that I have on my MK14 'support netbook' and run the resulting Intel Hex file OK on actual hardware (MK16 issue VI replica and Ortonview VDU). Loading that into HxD alongside Phil's version I find that the Intel Hex file and Phil's binary file are the same length and one byte different.
The single byte which is different in my working one is the setup value sent to the 8154 port A by Tim's mods. In Phil's version it sends the value BEh to the port, and on my version it sends the value FFh to the port. This should not matter because the 8154 port A pins are not 'connected' to the MAME emulator's VDU control inputs just as they are not connected to the control inputs on Ortonview on my real hardware.
In both cases Tim also wrote 00h out to the status register which set flags 0-2 low. If the VDU enable / disable control input is 'connected' to any of those flags then that action should enable it, as the VDU is active-low enable.
It should also be noted that for this software the VDU needs to be pointed at RAM blocks 0F00 and 0B00, character mode needs to be selected.
A thought: Could it be the length of the file NAME which is being complained about? try changing the extremely long filename of Phil's minefield file to just plain mine.bin and see if you can load it then.
|
yeah, i already shortened the name to 2 letters