Previous Thread
Next Thread
Print Thread
Page 2 of 3 1 2 3
Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114252
11/11/18 05:59 PM
11/11/18 05:59 PM
Joined: Aug 2002
Posts: 350
Melbourne, Australia
H
Heihachi_73 Offline
Senior Member
Heihachi_73  Offline
Senior Member
H
Joined: Aug 2002
Posts: 350
Melbourne, Australia
No such thing as more trouble than it's worth when it comes to MAME.

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114253
11/11/18 06:01 PM
11/11/18 06:01 PM
Joined: May 2009
Posts: 1,747
J
Just Desserts Offline
Very Senior Member
Just Desserts  Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,747
Just to pimp out fenugrec's excellent work so far, it seems they agreed!

[Linked Image]

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114262
11/12/18 05:07 AM
11/12/18 05:07 AM
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
Vas Crabb Online content
Very Senior Member
Vas Crabb  Online Content
Very Senior Member
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
Originally Posted by fenugrec
Granted, the artwork system would be the highest quality solution, but more trouble than I think is worth for this particular project...

Anyway, I have some medium-quality photos of the front panel and LCD segments ( [Linked Image] ), but it doesn't seem like there's an official Artwork repo ?

I still think I'm just going to try the simplest text rendering I can find...


The trouble is, all this talk about patching out major pieces of functionality and not doing things the "MAME way" is how we end up with drivers like ti85.cpp - a mess of stuff done the wrong way, not properly representing the hardware, that no-one wants to clean up, so they end up rotting. It's all very well to say "I'm not interested in doing this the MAME way", but if you want to go that way you can't expect a great deal of support/assistance, and you shouldn't expect to have it accepted in mainline.

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114263
11/12/18 05:19 AM
11/12/18 05:19 AM
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
Vas Crabb Online content
Very Senior Member
Vas Crabb  Online Content
Very Senior Member
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
But to answer the question about official artwork, we do have built-in artwork in the mainline repository, and it works quite well for test equipment, etc. with front panel buttons, switches and displays. See e.g. the layouts for et3400 (see #2682 for a screenshot - buttons are all clickable), whousetc, or intlc440 (see illustration on our wiki page here for what an older version of it looked like - all switches and lights are fully functional). Those are more complex than they need to be as I've tried to make them attractive as well as functional. You can get a working layout less effort.

Re: Adding new system - HP 3478A multimeter [Re: Vas Crabb] #114266
11/12/18 02:19 PM
11/12/18 02:19 PM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
Originally Posted by Vas Crabb
we do have built-in artwork in the mainline repository,


Thanks, I was thinking more of bezel and LCD mask scans, but for this unit plain layouts as you showed would be fine.


Quote
not doing things the "MAME way"

I see your point, but emulating this machine is a bit of a stretch anyway : it's a test instrument measuring analog signals, so the realism eventually reaches a limit somewhere in the model.

Is it not possible to add a driver in a WIP state without it becoming a rotting mess ?

I did end up implementing the LCD interface to avoid patching the ROM, but there are some things I have insufficient time and sanity to add (e.g. the analog processing CPU). So the (unpatched) emulated machine still runs but hits an error when trying to communicate with the analog CPU.


Quote
ti85.cpp

OK, I failed the test. What's horribly messy about that driver ? The only thing I noticed was the use of MCFG_ macros which I only recently learned were "on their way out", but there's still a good number of drivers with those, so ti85 doesn't stand out in that sense...

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114267
11/12/18 03:11 PM
11/12/18 03:11 PM
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
Vas Crabb Online content
Very Senior Member
Vas Crabb  Online Content
Very Senior Member
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
Originally Posted by fenugrec
Originally Posted by Vas Crabb
we do have built-in artwork in the mainline repository,


Thanks, I was thinking more of bezel and LCD mask scans, but for this unit plain layouts as you showed would be fine.


Yeah, you're right that there's no official source for that kind of scanned/photographed artwork. The trouble with trying to maintain/distribute that material is you often end up with copyrighted artwork and/or trademarked logos in it, so you can expose yourself to litigation. That said, there are unofficial but de facto standard sources for scanned/traced external arcade cabinet artwork layouts and handheld/tabletop game artwork layouts. There isn't one for test equipment, industrial automation, or embedded development hardware, but it would be awesome if there was. The trouble is, someone needs the time/skills to maintain it, and the willingness to expose themselves to potential legal issues.

Originally Posted by fenugrec
Quote
not doing things the "MAME way"

I see your point, but emulating this machine is a bit of a stretch anyway : it's a test instrument measuring analog signals, so the realism eventually reaches a limit somewhere in the model.

Is it not possible to add a driver in a WIP state without it becoming a rotting mess ?

I did end up implementing the LCD interface to avoid patching the ROM, but there are some things I have insufficient time and sanity to add (e.g. the analog processing CPU). So the (unpatched) emulated machine still runs but hits an error when trying to communicate with the analog CPU.


Well, in this case the "MAME way" to avoid emulating the analog processing CPU and still progress past ROM patches would be to just simulate whatever responses the main CPU expects from it. Either use hooks in the driver class, or create a device class to represent it. This can later be replaced with emulation of the other CPU when someone else has the time/motivation to have a crack at it. It has the added bonus of documenting what the communication is supposed to look like so the next person to take a look knows what's supposed to happen when it's working. Documentation is what MAME's supposed to be about in the first place. We aim to emulate enough of the machine to allow the original code to run, not patch the code so it can run without the system being emulated around it.

The analog input can be simulated in various ways. You could model whatever's connected to the test leads as a Norton or Thévenin source and map the parameters to analog axis inputs. That would allow someone to use a joystick to control it and watch the numbers dance.

Yes, a driver can be accepted when it's incomplete, but I'd rather it were incomplete but heading in the right direction.

Originally Posted by fenugrec
Quote
ti85.cpp

OK, I failed the test. What's horribly messy about that driver ? The only thing I noticed was the use of MCFG_ macros which I only recently learned were "on their way out", but there's still a good number of drivers with those, so ti85 doesn't stand out in that sense...


OK, I guess it's not immediately obvious and it's not in as bad state as it was to begin with. One of the key issues is that it makes no attempt to emulate the bootstrap on the Flash-based calculators. It assumes a valid OS is present in the main Flash and it can be booted directly. It's impossible to load an OS or get the calculators into OS recovery mode. The person who contributed the driver was adamant that it's not important because you can use the systems without emulating that aspect.

Another issue with it was that it assumed that a speaker was connected across the link port and provided no other options. You could only get data in and out of the systems by hacking the NVRAM files. I ended up addressing this myself for the TI-82 and TI-85, so you can now connect various other things to the link port and transfer data in/out over a TCP socket, or link two instances of MAME together and transfer data between them.

Anyway, my main gripe is that it's a driver where a significant aspect of the systems is completely ignored as "unimportant", there seems to be little prospect of it ever being emulated properly, and the driver tends to rot and sit in a non-working state for significant periods before someone finally notices it and hacks it enough to get it usable again.

Re: Adding new system - HP 3478A multimeter [Re: Vas Crabb] #114270
11/12/18 05:29 PM
11/12/18 05:29 PM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
Originally Posted by Vas Crabb
just simulate whatever responses the main CPU expects from it
.
Unfortunately I can't simply map a few IO locations or trap some opcodes with a dummy driver. It's yet another undocumented, bit-banged serial protocol I would need to RE and implement.

Sadly that's where I need to draw the line. Of course I want to make that part of the emulation as clean and as simple as possible to eventually implement, but the for the work I want to do, patching 4 bytes is as simple as it gets. Otherwise the original ROM will just run up to the "AD LINK ERROR". That might not be so bad; everything up to that point is properly emulated. And since my patch allows me to get past that, other parts of the emulation will be tested for correctness.

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114277
11/13/18 05:05 AM
11/13/18 05:05 AM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
Ok, I wasted most of a day on this next problem. Here's what I have to accomplish (trimmed code just to illustrate what I have in mind)

Code
//callback for MCS48 "write P2 pins"
WRITE8_MEMBER( hp3478a_state::p2write )
{
	if (data & PIN_CS_NVRAM)
		m_iobank->set_entry(0);
	else if (data & PIN_CS_GPIB)
		m_iobank->set_entry(1);
	} else if (data & PIN_CS_DIPSW) {
		m_iobank->set_entry(2);
	}
}

void hp3478a_state::i8039_io(address_map &map)
{
	map.global_mask(0xff);
	map(0x00, 0xff).bankrw("iobank");
}

void hp3478a_state::machine_start()
{
	....
	m_iobank->configure_entry(0, memregion("nvram")->base());
	m_iobank->configure_entry(1, memregion("gpibregs")->base());
	m_iobank->configure_entry(2, ?? DIP switches);	
}

ROM_START( hp3478a )
	...
	ROM_REGION( 0x100, "nvram", 0 )	/* Calibration RAM, battery-backed */
	ROM_LOAD_OPTIONAL( "calram.bin", 0, 0x100, CRC(0))
ROM_END


As I have written it, I doubt the DIP switches can be handled like that with banking.

My first thought was to have no banking but a general IO rw callback. But, I couldn't find out how to access the nvram region from within there. I don't even want to think of eventually mapping the GPIB driver that way (should "map" to 0x00-0x07)

All the examples I looked at (don't remember all, but at least namcos12, simpsons, hp9122, attache) have vastly different addressing spaces. I haven't seen any device with such different crap multiplexed on the same bus, with bitbanged chipselect lines. They always seem to be conveniently mapped at different addresses...

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114278
11/13/18 06:30 AM
11/13/18 06:30 AM
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
Vas Crabb Online content
Very Senior Member
Vas Crabb  Online Content
Very Senior Member
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
You use the address_map_bank_device for this, not the memory bank thing. The memory bank thing can only bank flat memory, the address_map_bank_device banks a window into an address map that can contain arbitrary handlers. Look for drivers with ADDRESS_MAP_BANK in them (e.g. intellec4.cpp, sitcom.cpp, or trs80m3.cpp).

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114279
11/13/18 12:57 PM
11/13/18 12:57 PM
Joined: Mar 2001
Posts: 16,070
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,070
USA
Yup, I/O and memory banked at the same place is what bankdev / address_map_bank does really, really well.

Page 2 of 3 1 2 3

Who's Online Now
3 registered members (Vas Crabb, xinyingho, Olivier Galibert), 111 guests, and 2 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,606
Posts112,516
Members4,827
Most Online296
Dec 5th, 2018
Powered by UBB.threads™ PHP Forum Software 7.6.1.1
(Release build 20180111)
Page Time: 0.056s Queries: 14 (0.012s) Memory: 5.7323 MB (Peak: 5.9547 MB) Zlib enabled. Server Time: 2018-12-16 11:34:36 UTC