Previous Thread
Next Thread
Print Thread
Page 1 of 3 1 2 3
Adding new system - HP 3478A multimeter #114162
11/04/18 09:09 PM
11/04/18 09:09 PM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
Hi,
Just thought I'd share a project I'm starting; I expect I'll need some help with MAME internals to get this done !

Target is a popular old piece of electronic test equipment, the HP 3478A DMM. Full service manual and shematics are available, as well as a full ROM dump hosted on KO4BB . I have dumped my own unit with a logic analyzer and confirmed they were identical.

Some pics on https://sigrok.org/wiki/HP_3478A

Hardware is fairly simple, with a twist.

- Intel i8039 (MCS-48 family, already supported in MAME I believe, for some "kaypro" gadget ?) , internal OTP ROM not used
- 8kB EPROM (dumped)
- 256-byte calibration RAM, also dumped but not function-critical
- LCD display module accessed through a weird 4-signal serial link; I've identified that code in the ROM so the first iterations will have those parts patched / bypassed
- Main CPU talks to a secondary CPU on the analog side, over a half-duplex serial link. This part is of no interest to me, and will be summarily patched too.

The twist is that the 8039 has a 4kB address space. The 3478 hardware implements hardware banking, where one of the IO pins drives the A12 address line.

My partially annotated ROM disassembly along with some notes :
https://github.com/fenugrec/hp3478a_utils/tree/master/ROM_disasm

My goal isn't to have a full emulation working - a bit meaningless for a test instrument. But I'd like to have the firmware run properly and handle the UI (4x4 keypad and display) so I can move on to part 2, which is modifying the ROM to add a missing feature.

Last edited by fenugrec; 11/04/18 10:24 PM. Reason: added direct ROM link
Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114163
11/04/18 09:27 PM
11/04/18 09:27 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
Welcome!

Banked address spaces are something we get day in day out around this place so that's not a problem. The 4-wire LCD controller sounds like possibly I2C or some similar serial protocol. Was there software for any HP computers that talked to this thing over (G/H)PIB?

ROM links for things that aren't games are almost always fine, we do a lot of work off of things available from bitsavers.org, after all.

Re: Adding new system - HP 3478A multimeter [Re: R. Belmont] #114164
11/05/18 12:39 AM
11/05/18 12:39 AM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
Originally Posted by R. Belmont

Banked address spaces are something we get day in day out around this place so that's not a problem. The 4-wire LCD controller sounds like possibly I2C or some similar serial protocol. Was there software for any HP computers that talked to this thing over (G/H)PIB?


Thanks. Do you (or anyone) have an example of a device I could refer to that implements this kind of simple banking ?

LCD : I2C wasn't very popular when these units were introduced; it's actually a clocked serial protocol that IIRC some other HP units share and I think has been documented to some extent, I vaguely remember an eevblog thread about this.

GPIB/HPIB indeed : the manuals mention an HP 85B / 9000 series computer, not sure about special software - probably not, the commands are pretty simple. That's about the extent of my knowledge of that side of things, though.

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114165
11/05/18 08:50 AM
11/05/18 08:50 AM
Joined: May 2004
Posts: 862
Germany
D
Duke Offline
Senior Member
Duke  Offline
Senior Member
D
Joined: May 2004
Posts: 862
Germany
The eevblog thread about the LCD is here: https://www.eevblog.com/forum/projects/led-display-for-hp-3457a-multimeter-i-did-it-)/25/

It's for a different model, but looks like all the info is there.

Last edited by Duke; 11/05/18 08:50 AM.
Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114210
11/09/18 03:41 PM
11/09/18 03:41 PM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
Ah ! with some pointers from the folks in #mame-dev, I was finally able to compile mame and add an initial driver for this.

hp3478 git branch

So far only the CPU and hardware ROM banking are implemented; seems to work so far. Any comments ? especially on the IO port handling, I mix-and-matched code snippets found in other drivers...

next steps, ideas are very welcome :
- find a way to import my annotated disasm comments / symbols into mame's debugger so I don't go insane for the rest of this project
- patch / hook ? into ROM display functions to implement a primitive display without having to emulate the serial protocol
- patch (maybe the cheat mechanisms would be useful here ?) a few areas of the ROM that would hang waiting for unemulated hardware
- implement keypad reading and tie to a UI element, or maybe just keyboard shortcuts. Don't want to spend hours on this

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114234
11/11/18 12:15 AM
11/11/18 12:15 AM
Joined: May 2012
Posts: 490
S
shattered Offline
Senior Member
shattered  Offline
Senior Member
S
Joined: May 2012
Posts: 490
Originally Posted by fenugrec

next steps, ideas are very welcome :
- find a way to import my annotated disasm comments / symbols into mame's debugger so I don't go insane for the rest of this project
- patch / hook ? into ROM display functions to implement a primitive display without having to emulate the serial protocol
- patch (maybe the cheat mechanisms would be useful here ?) a few areas of the ROM that would hang waiting for unemulated hardware
- implement keypad reading and tie to a UI element, or maybe just keyboard shortcuts. Don't want to spend hours on this


You can abuse breakpoints to do some of these - breakpoint handler will execute debugger expressions (print messages to debugger window or logs, modify registers and memory &c). For example, a "bp fc4b8,1,{do cx=1;go}" will pretend that some check has actually passed.

Another example: log syscall handler entry and pretty-print its arguments (this is for GRiD Compass driver):

bpset fec9c,1,{ logerror "%% OsDskDriver "; go }
bpset feca5,1,{ temp2 = w@(ss*10+bp+0xc); temp1 = w@(ss*10+bp+0xc+2); temp0 = temp2 + temp1*10; logerror "(r = %2d) (xn %04x pBuffer %08x pos %08x length %04x mode %02x numbuf %02x intAddr %02x pOverflow %08x\n" ,w@(ss*10+bp+10) ,w@(temp0) ,d@(temp0+2) ,d@(temp0+2+4) ,w@(temp0+2+4+4) ,b@(temp0+2+4+4+2) ,b@(temp0+2+4+4+2+1) ,b@(temp0+2+4+4+2+1+1) ,d@(temp0+2+4+4+2+1+1+1) ; go }

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114237
11/11/18 01:04 AM
11/11/18 01:04 AM
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
MAME's debugger supports per-address comments, but the on-disk file format is kind of icky. You can get around it by converting your comment list to a text file of the form:

comadd 0x0, Boot
comadd 0x3, jump to secondary boot handler
comadd 0x38 IRQ

and then "source file.txt" when you start the debugger.

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114239
11/11/18 04:35 AM
11/11/18 04:35 AM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
Thanks for the replies.

Quote
You can abuse breakpoints to do some of these

Ah yes, but can those work from within a device driver ? That's actually so ugly, I'm embarassed of even considering it. Other things I've thought of was inserting illegal opcodes and if possible trapping those. Meh.


Quote
and then "source file.txt" when you start the debugger.

Ok, that could work.

So, I spent the evening writing LCD emulation code I didn't want to write. It started out because I thought it would marginally simpler... still not sure about that one. On the plus side :
[Linked Image]
"TSET FLES" => SELF TEST, indeed.

What would be the simplest option to have this displayed "properly" (i.e. not in the error log !), with minimum amount of pain ? "terminal" sounds like not what I want; I saw references to 16-segment LEDs but I can't be bothered to map the entire charset to segments. There has to be a raw text renderer, I haven't found it yet...

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114240
11/11/18 06:22 AM
11/11/18 06:22 AM
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
Vas Crabb Offline
Very Senior Member
Vas Crabb  Offline
Very Senior Member
Joined: Feb 2004
Posts: 2,012
Sydney, Australia
The artwork system can do this. If you leave it how it is, eventually someone else (probably me) will hook it up. I did the Westinghouse thing we don't know the purpose of, ET3400, SITCOM, and a bunch of other things.

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114251
11/11/18 02:48 PM
11/11/18 02:48 PM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
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...

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 Offline
Very Senior Member
Vas Crabb  Offline
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 Offline
Very Senior Member
Vas Crabb  Offline
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 Offline
Very Senior Member
Vas Crabb  Offline
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 Offline
Very Senior Member
Vas Crabb  Offline
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.

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114281
11/13/18 05:20 PM
11/13/18 05:20 PM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
Thanks. Finally got it to sortof work (as far as I can tell...) with some #IRC help, and it even almost looks like the real thing, after a few beers:

[Linked Image]

Feels like the CAL RAM was one major obstacle; I don't expect the other short-term TODO items (keypad, DIP switch) will be as difficult.

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114282
11/13/18 06:45 PM
11/13/18 06:45 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
Nice. Congrats!

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114335
11/24/18 07:17 AM
11/24/18 07:17 AM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
keypad actually works now and UI responds mostly as expected. Next order of business : nvram write-protect switch. There is a physical switch that enables writing to the nvram but isn't read directly by the CPU.

I have something like this
Code
map(0x000, 0x0ff).ram().region("nvram", 0).share("nvram");


(full code)

my first idea would be to configure that region to have a custom WRITE8 handler that discards writes while write-protected ?

About that switch, how about something like
Code
PORT_START("config")
PORT_CONFNAME(1, 0, "CAL enable")

Re: Adding new system - HP 3478A multimeter [Re: fenugrec] #114336
11/24/18 10:52 AM
11/24/18 10:52 AM
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
Yep, sounds like you've got it! You would have a custom write handler that checks BIT(m_config->read(), 0) or whatever, and skips the write to NVRAM. There doesn't seem to be a write-protect function for the NVRAM device: perhaps there should be. smile

Re: Adding new system - HP 3478A multimeter [Re: Just Desserts] #114346
11/26/18 12:19 AM
11/26/18 12:19 AM
Joined: Nov 2018
Posts: 11
F
fenugrec Offline OP
Member
fenugrec  Offline OP
Member
F
Joined: Nov 2018
Posts: 11
Originally Posted by Just Desserts
Yep, sounds like you've got it!

I wish. I still can't figure out how do "forward the write" to the NVRAM.

Code
WRITE8_MEMBER( hp3478a_state::nvwrite ) {
	if (m_calenable->read()) {
		* (uint8_t *) space.get_write_ptr(offset) = data;     		//XXXXX segfault

		m_nvram->write_byte(offset, data); 		//XXXXX segfault, since it ends up calling this handler

		((uint8_t *)space.map()->m_device->memshare("nvram")->ptr())[offset] = data;		//XXXXX segfault

		space.map()->??		// this isn't the member you're looking for

		m_nvram->get_base()		// haha, nice try



how hard can this be ?
[EDIT] solved, thanks to @cuavas. It needed some "required_shared_ptr" magic...

Last edited by fenugrec; 11/26/18 01:28 AM. Reason: solved
Page 1 of 3 1 2 3

Who's Online Now
2 registered members (xinyingho, 1 invisible), 121 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.045s Queries: 14 (0.016s) Memory: 5.8845 MB (Peak: 6.1890 MB) Zlib enabled. Server Time: 2018-12-16 10:22:41 UTC