Home Page Forums Active Threads

If memory serves, someone once made a simple MAME artwork creator tool that was WYSIWYG... Can't remember who, but third party obviously.

Definitely would be broken these days after the artwork system rewrite, but it would still work for old versions.

Pre-rewrite thoughts on creating such a user-friendly tool exists in https://github.com/mamedev/mame/issues/443

Another broken thing: https://mrdo.mameworld.info/mame_lay.php

Also broken: making MAME bezel artwork with Python: https://medium.com/@ericmulvihill/generating-mame-bezel-layouts-with-python-317f9dda2e6d / https://bitbucket.org/ericmulvihill/mame-bezel-layout-generator/src/master/

Yeah, what you describe is something that is "easy" to do, but requires a whole ton of actual work to do in a reasonable way, particularly for MAME's layout system.

It's something I have at the back of my mind every day, since making such a tool will eventually be necessary when MAME's UI system is updated to relatively modern hierarchical standards, as well as at my day job work, which is what the eventual UI system will be based on.

Hi guys,

After making a layout, it just seemed so hard to do something that was quite simple conceptually.

I'm not very good at editing XML text by hand, and I thought I'd play around with firefox a little.


So if I launch firefox and go to about:blank, I've got an empty page.

Then if I hit F12, I get the Developer Tools window.

Firefox won't let you open local files with XMLHttpRequest because of CORS blocking, so let's make a textarea and paste our xml into it:

in the console:


ta = document.createElement("textarea")
document.body.append(ta)

and you should have a textarea in your blank page now, it's a little small so go resize it.




Now locate a layout file in a text editor, select all the text and then paste it into the textarea.

so let's parse that xml:

par = new DOMParser()

>>> DOMParser { }

ser = new XMLSerializer

>>> XMLSerializer { }

xml = par.parseFromString(ta.value,"text/xml")

>>> XMLDocument { … }


and now you have magically parsed the xml into a DOM tree.

So you can access the elements with:

xml.querySelectorAll("element")

>>> NodeList(32) [ element, element, element, element, element, element, element, element, element, element, … ]


that returns a list of 32 elements, let's just focus on element 0:

xml.querySelectorAll("element")[0]

>>> <element name="devicetag_str" defstate="0">


so let's modify the name attribute:

xml.querySelectorAll("element")[0].setAttribute("name","was_devicetag_str")



ser.serializeToString(xml)

>>> <element name=\"was_devicetag_str\" defstate=\"0\">

so you can see that we have indeed modified the attribute name of the element.

and if you want to output the xml to your blank page, let's make another textarea and set the value to our serialized xml:

ta2 = document.createElement("textarea")
document.body.append(ta2)
ta2.value = ser.serializeToString(xml)





So let's try to make a new element and add it to the xml:

newelem = xml.createElement("element")
newelem.setAttribute("name","my_new_element")

newtext = xml.createElement("text")
newtext.setAttribute("string","a new string")
newelem.append(newtext)

xml.querySelector("mamelayout").prepend(newelem)


xml.querySelectorAll("element")[0]

>>> <element name="my_new_element">

ser.serializeToString(xml.querySelectorAll("element")[0])

>>> "<element name=\"my_new_element\"><text string=\"a new string\"/></element>"




So it's pretty easy to manipulate XML with javascript.


Next step is to try to make some resizable divs that would represent the various layout items like text and rect.

Another thing that's kinda cool to do is to open the xml file into firefox, then use the F12 developer tools to inspect the xml tree.

It does seem likely that it would wait for the end of the current sector, but a test on hardware would certainly be nice.

I added a delay so that the current byte would finish before the write is ended and then the crc was written correctly. I still got an error though because the verify read was interrupted before the crc was read. Seems to me that if a read or write are interrupted it should complete the current sector like the 765 does. I have no machine with a wd1790 to try it on though.

Thank you to kmg for the pointer to how to do it...

Two keystrokes... Still don't think I'm ready to be a dev yet.

Playing this with the kids will be a blast, especially with Halloween coming up!

It could (and should) be made a machine configuration switch, at which point it could be flipped from within the UI, similar to a DIP switch.

Bummer.

Was kinda hoping it was a command line switch or something I couldn't figure out.

Maybe in the far future it can be simulated with a dipswitch setup.

Thanks for the reply!

Aggreed, it's not clear from the datasheet, especially as it's using the write multiple sectors command which according to the datasheet will keep
polling for data until it gets a force interrupt. This would imply to me that any complete sectors it has up until this point should be written, before
acting on the interrupt.

cheers.

Phill.

Ok after some further studying of the RM technical manual and the schematic for the floppy controller, I found that the controller is actually operted at 2MHz, with ENMF grounded.

However implementing the changes on my local copy of the source and I still get the same result with the CRC errors.

Cheers.

Phill.

It's modifying the source.

The emulated floppy code tries to work in real time, following the simulated physical rotation of the floppy. So that part of the timing should be correct.

Not sure what you looked at, but the "write sector sequence" graph ends with "write one byte of 0xff" after the data crc.

That interrupt thing otoh, that's probably the cause right there. Annoyingly, I don't know what the wd actually does in that situation.

I wondered about that too, I did try playing with the delays but again couldn't get that to work

It could of course be that the emulated floppy code is taking slightly longer to execute than on the real hardware, and the forced interrupt is causing the problem.

Cheers.

Phill.

in pacman.cpp, it says the following:


How do you do that?

(If it's modifying the source... yeah, out of my ability!)

What might be happening is the dma is finished and then the machine does a wd_fdc interrupt command which halts the write before it's done.

I did try replacing that with a single 0x4e, but that didn't appear to fix it. Maybe the if (cur_live.byte_counter < sector_size + 16+3) needs the +3 increasing.....

Cheers.

Phill.

Writing is broken somehow. The last raw mfm value it tries to write is 0xa494.



But the file ends up with 0xa554



https://github.com/mamedev/mame/blob/master/src/devices/machine/wd_fdc.cpp#L2148 looks a bit suspicious. The datasheet says there should be a bunch of 0x4e written but it's only doing one 0xff and that doesn't appear to happen.

I tried to format a disk to repo this and got a crc error after the format so I made a mfm image instead which preserves the crcs and here's the result.

The data crc is 0xc03e when it should be 0xc026.

Hi all,

I'm experiencing strange behavior with raw disk images with the RM nimbus driver. Through a process of illimination I think I've ruled out the actual nimbus driver code.

What I'm getting is infrequent, though pridictable CRC errors reading sectors from the floppy image.

So I can replicate as follows :

insert a raw disk image into a floppy drive (I'm using B: as then the machine won't try and boot from it!), this image is 737280 bytes 80 double sided tracks of 9 x 512 byte sectors.
Having booted from the hard disk do the following :

copy c:\dos\*.* b:\

This will copy the files *UNTIL* it gets to copying print.exe where it will error out.

Tracing this error from dos, back through the Nimbus's sub-bios, back to the WD1793, it's reporting a CRC error reading the sector data.

Now this is a mystery, because if I understand correctly the image / floppy emulation code must be faking this data up because it doesn't exist in the image.
So the floppy emulation must be reading the raw 512 byte sector data from the image file and building header info / crc data for it.

The other odd thing is if I eject the image using the mame menu, and then re-insert it into the same drive and copy c:\dos\print.exe b:\ it succeeds.
This suggests maybe that something is not getting re-initialized where it should and that the eject/insert cycle rectifys this.

Does anyone have any thoughts on this or where I should go looking for the error? I've done a troll of the crc code in wd_fdc.cpp and compared it to the upd765.cpp code and
the two seem mostly consistent.

Cheers.

Phill.

Thanks to Kale, we can once again be State. Of. The. Art.

Sega Speed Basketball with an initial layout:



It's even kind of playable - you can move around the playfield and trigger goals.

You can simulate TV overscan by going to the Tab menu in MAME, then Slider Controls, and adjusting the Screen Horiz Stretch and Screen Vert Stretch settings.

You changing dip settings may break hi score file mainly changing game region.

Nvidia driver 470 has issues for Geforce 600 cards. CUDA, Nvenc and g-sync issues.
Driver 465 works fine.