Previous Thread
Next Thread
Print Thread
Page 60 of 120 1 2 58 59 60 61 62 119 120
Joined: May 2010
Posts: 2
R
Member
Offline
Member
R
Joined: May 2010
Posts: 2
hi mess?
sam coupe support?
does it read actual compact flash cards from an atom lite and allow me to use the software thereon?
does it support zx spectrum 48/128 mb-02+ dma support?
ula+
is there an art package for the cpc+ - does the + make any difference to the art other than 4096 colours and would the incredibly small 16x16 sprites with their own 15 colours be usable? is there no interlace mode?
have tyou seen any russian spectrum clone with 14mhz processor running spectrum 128 or 48 software using te faster processor pelase?
can you replay rzx files in mess? can we accelerate the processor to speed up replay like in zx spin please?
can you choose processor speed for playback? could the processor speed emualte the functionality of the msx turbo r800 processor?
does mess support general sound neo for russian clones? - does any software use the z84 (they told me it was 24mhz - although zilog dont even make such a chip - nor is there any info on a dma at 24mhz either - what a shame zilog didnt make a z84 24mhz with dma and r800 core compatiblity!

if you ahve made mess to be compatible with so many machines and their individual video configurations how long before you can create a hardware version of mess compatible with most home computer systems? surely a vitrual video environment could emualte most home computer video chip modes adn you then only need the device to support the z80 or 6502 instruction sets as these were pretty much the only processors in most micros - with a faster version z84 24mhz or is there a 20mhz 6502? surely support for both is possible and accelerators could replay rzx style files faster then youtuibte can replay low quality uncompressed video files! - or crash when you try to install flash player into a 64bit browser or crash when you select one of the tv tuner video inputs as a webcam in the settings

below files are for fuse emulator video screen playback with ay 8912 hopefully soon to be converted to sam - but we could do with mode 4 16 colours and maybe interlaced if atom lite+ or velesoft datagear dma or mayhem quazar or vleesoft accelerators can handle it

Last edited by R. Belmont; 05/27/10 02:44 PM. Reason: Spam links deleted, enjoy the rest!
Joined: Aug 2004
Posts: 1,455
Likes: 9
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2004
Posts: 1,455
Likes: 9
my, my... thx to RB for leaving that there.. laugh

Joined: Dec 2009
Posts: 351
ASH Offline
Senior Member
Offline
Senior Member
Joined: Dec 2009
Posts: 351
wow

How do I find what he's smoking cool

ASH #62380 06/01/10 05:47 PM
Joined: Sep 2001
Posts: 534
F
Senior Member
Offline
Senior Member
F
Joined: Sep 2001
Posts: 534
I started looking at the softlists to implement support in mame_regtest and found a problem with associating a "software" entry with a device.

This is an entry from sms.xml:

Code:
<software name="20embr">
	<description>20 em 1 (Bra)</description>
	<year>1995</year>
	<publisher>Tec Toy</publisher>
	<part name="cart" interface="sms_cart">
		<dataarea name="rom" size="40000">
			<rom name="20 em 1 (brazil).bin" size="262144" crc="f0f35c22" sha1="2012763dc08dedc68af8538698bd66618212785d" offset="0"/>
		</dataarea>
	</part>
</software>


But a device entry in -listxml output actually looks like this:

Code:
<device type="cartridge" tag="cart16">
	<instance name="cartridge16" briefname="cart16"/>
	<extension name="sms"/>
	<extension name="bin"/>
</device>


IMO the "name" attribute in the "part" node should have the same name as the device type it is supposed to be used with. So it should be "cartridge" instead of "cart". The latter is just the brief name used for command-line parameters and device tags in the code and not the actual type.

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
I do not agree. the matching should only require the image and the device to have the same interface.

the name attribute of part could be used at a later stage to handle games which comes with e.g. a tape and a cart, but I'm not 100% sure we should force the part name to match the device type...

judge?

Joined: Apr 2004
Posts: 1,556
J
Very Senior Member
Offline
Very Senior Member
J
Joined: Apr 2004
Posts: 1,556
The code matches on interface type, if no interface is set for the cartridge slot it just picks the first entry. Unless you specify the full software name: softlist:softname:partname of course.

Joined: Sep 2001
Posts: 534
F
Senior Member
Offline
Senior Member
F
Joined: Sep 2001
Posts: 534
So how do I know exactly what entry is for which device? How would somebody who is creating a front-end know what software list to show? Since I have to run the driver with

Code:
mess sms -cart 20embr


When a system has tapes and carts listed I would need to implement some kind of translation code.

And how are entries, that have multiple entries, supposed to be loaded? If it has a cart and a tape I can't really use "-cart" as parameter.

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
Originally Posted By Firewave
So how do I know exactly what entry is for which device? How would somebody who is creating a front-end know what software list to show? Since I have to run the driver with

Code:
mess sms -cart 20embr


the interface is the key.

if you look at the -lx output, you will see that cartslot device as a interface attribute. in the list xml, part has an interface attribute as well.

when you load from software lists, MESS run through the list in search of a game with the correct name and the correct interface. if you have correct name but no <part> with the correct interface, the game is not loaded.

in principle you might load games from any list, but loading is successful only if the interface matches

a frontend author might let the user specify a list for each media/device of a system and then run through the chosen list showing in the interface only the entries of that list with the proper interface.

the frontend author I'm working with to support lists, though, will use a different approach (which I haven't fully understood, given it's strictly linked to the way the frontend parses xml) and I'm pretty curious to test it... more on this when there is some working sample to share wink

Originally Posted By Firewave
When a system has tapes and carts listed I would need to implement some kind of translation code.

And how are entries, that have multiple entries, supposed to be loaded? If it has a cart and a tape I can't really use "-cart" as parameter.


first, there is no answer yet, because only carts have an interface so far and because no system with multiple entries has lists so far.

second, you are right, I took the wrong example. cart + tape should be handled only relying on the interface attribute (even if since we support no tape + cart combo, things may change)

for sure you will always need to load

mess system -cart name -cass name

the point is where the "name" checksums are defined.

possibility one: we have separate lists for tape vs. cart and the system looks in the different lists for items with tape_intf vs. cart_intf

possibility two: a single lists, and for each game with a combo cart+tape we have two parts with two different interface attributes

in both cases, the name attribute of part is not used.

what you might need the name for, is for games with multiple floppies/tapes: e.g. you could use it to introduce a sort of hierarchy where "disk1" part goes in the first floppy drive, "disk2" goes in the second drive, etc., if the user does not specify differently.

but again, there is list support only for carts at the moment, so it's a bit early to say what we might want to use name for (let's say the attribute is there to allow for extensions in the future).

Joined: Sep 2001
Posts: 534
F
Senior Member
Offline
Senior Member
F
Joined: Sep 2001
Posts: 534
Originally Posted By etabeta78

the interface is the key.

if you look at the -lx output, you will see that cartslot device as a interface attribute. in the list xml, part has an interface attribute as well.

when you load from software lists, MESS run through the list in search of a game with the correct name and the correct interface. if you have correct name but no <part> with the correct interface, the game is not loaded.

in principle you might load games from any list, but loading is successful only if the interface matches

a frontend author might let the user specify a list for each media/device of a system and then run through the chosen list showing in the interface only the entries of that list with the proper interface.

the frontend author I'm working with to support lists, though, will use a different approach (which I haven't fully understood, given it's strictly linked to the way the frontend parses xml) and I'm pretty curious to test it... more on this when there is some working sample to share wink


Oh, I see it now. Unfortunately I chose a confusing sample. The interface is just set for the first entry, but IMO it should be set for all of them. The extension information is also redundant for all and it might be possible, that there are different cart slots on a machine (not in this case, but still).

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
Originally Posted By Firewave
The interface is just set for the first entry, but IMO it should be set for all of them. The extension information is also redundant for all and it might be possible, that there are different cart slots on a machine (not in this case, but still).


that has been a mistake at my end, because when I added softlist at sms.c I hadn't tried the display multislot unit (actually, I didn't even want to add list to it...)

each cartslot is a separate device, hence it should have its own interface of course, and I'm going to amend this. similarly, different slot might support different extensions (think in 2020 the Nintendo DS driver with a DS slot and a GBA slot), so there is no redundancy

about different slots with different interfaces, snesbsx will require that (but it's currently not working, so I haven't even thought if I will split their cart from snes.xml or if I will simply change the interface where needed)

EDIT: otoh, at the moment only one single list can be added to each driver. maybe, this will change in future...

EDIT2: smssdisp is fixed in rev.8199. each cartslot can load from xml list now. smile

Page 60 of 120 1 2 58 59 60 61 62 119 120

Link Copied to Clipboard
Who's Online Now
1 members (Augusto), 24 guests, and 6 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,086
Posts119,087
Members5,014
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com