| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8603
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
Haze: looking-back-at-a-list
#388968 - 12/10/20 09:02 AM
|
|
|
|
|
| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8603
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
btw:
[Re: gregf]
#388969 - 12/10/20 09:45 AM
|
|
|
*an excerpt of what Haze wrote...the sentence that I set in bold holds true since this is likely how Nicola maybe envisioned during early years of when MAME was just underway with thought 'Maybe someone else will come along later and improve things..' *
--
Back in May of 2013 I wrote up a small article looking at some of the things MAME had not yet conquered.
Conclusion
Even as somebody close to the project, what I wanted to see happen, and even thought would happen based on the difficult of the tasks etc. had no bearing on what actually ended up happening.
A lot of the things I thought we’d see progress on, no progress was made, while others, that I thought were maybe a bit unrealistic did end up happening. 3 of the items on that list that did end up seeing significant progress to the point of promotion to working state only did so due to the efforts of Morten Kirkegaard who is sadly no longer with us.
Really the only way to be sure that something you want to see done gets done is to do it yourself. Creating lists of things you’d like to see is basically pointless, as even here, where I’d created an educated list based on what I felt was likely to happen from my own experience with the project, most of it missed the mark entirely.
Maybe the thing that amazes me most however is how many things did happen that weren’t even on my radar at the time.
-
*end of excerpt from Haze's blog entry.*
My own take when when looking back starting from May of 2013 in what was in MAME or not yet in MAME at the time....either in initial stages of being supported or yet to be supported in MAME:
*as best as I recall from memory [pardon if incorrect here and there] without looking things up*
a. netlist was only in MAME for a year with pong supported in May 2012
b. MAME had incorporated MESS source code into MAME source code, but not into full build MAME incorporating/merging with MESS until around 2015 iirc
c. MCU decaps progress was here and there...the Toaplan games missing sound didn't happen until about 2015 or 2016 iirc.
d. softlist support somewhat in early stages even though already underway when first supported around 2010/2011.
e. emulation of various items supported in MESS were maybe being overhauled here and there.
f. handheld games or some console games were in early stages such as Merlin iirc around 2012 or 2013. The handheld games with LED and VFD happening in 2013 and 2014. And some of the initial lcd games such as Tiger Electronics and Nintendo G&W support wouldn't happen for about another two years.
g. Apple II floppy diskettes preservation (4AM's work) was in early stages and Applesauce /.WOZ images eventually happened around 2016/2017 time frame.
h. SGI and some of the minicomputer systems had either not happened yet or were in initial stages.
i. MAME's HLSL and other monitor features were just getting started.
j. The UI evolving/transformation for MAME probably underway with initial updates.
k. initial MIDI support
l. Some of the most want coinop games (now supported) were yet to be found (El Fin Teimpo or Purple Magic etc.)
m. plug and play hardware not until Jan 2018, chessboard emulation maybe in initial stages before overhaul work in 2019.
Edited by gregf (12/10/20 10:00 AM)
|
|
|
|
Re: btw:
[Re: gregf]
#388974 - 12/11/20 02:59 AM
|
|
|
Quote:
Really the only way to be sure that something you want to see done gets done is to do it yourself. Creating lists of things you’d like to see is basically pointless, as even here, where I’d created an educated list based on what I felt was likely to happen from my own experience with the project, most of it missed the mark entirely.
Good to know. That'll save me the trouble of creating one.
Though, it's easy to say to do it yourself, but that's not really very helpful when most people cannot learn programming at all.
|
"Note to Noobs:
We are glad to help you but simply posting that something does not work is not going to lead to you getting help. The more information you can supply defining your problem, the less likely it will be that you will get smart-alec replies.
C.D.~"
|
|
|
Re: btw:
[Re: Master O]
#388975 - 12/11/20 04:12 AM
|
|
|
Quote:
Though, it's easy to say to do it yourself, but that's not really very helpful when most people cannot learn programming at all.
That and there is also deciphering program rom code; something I have yet to figure out to this day :S.
|
-.-
|
|
|
Re: btw:
[Re: Hydreigon]
#388978 - 12/11/20 12:52 PM
|
|
|
> Though, it's easy to say to do it yourself, but that's not really very helpful when
> most people cannot learn programming at all.
> That and there is also deciphering program rom code; something I have yet to figure
> out to this day :S.
I spent probably the first 6 or 7 years doing this, the period some people consider to be my 'best' work*, without really having any understanding of this either, instead just by looking at what accesses were being made and going from there.
Likewise, I don't really consider myself to be a good programmer, and if some of the devs are to be believed, I'm even worse than that.
Plenty more people could be doing this than actually are, it's all about putting in the effort to overcome other shortcomings.
* which is infuriating when you try telling people that, and how much things have improved, but all you get is "lalala, not listening, MAME2003 is the best"
|
|
|
|
Re: btw:
[Re: Master O]
#388979 - 12/11/20 02:21 PM
|
|
|
“Though, it's easy to say to do it yourself, but that's not really very helpful when most people cannot learn programming at all.”
I know I don’t know how to program and I realize it is because I am not able to put in the time and effort to learn. Along with that I don’t have an expectation that others will do it for me. Most importantly ANYONE with a PC and internet connection CAN learn to program. If they don’t it is because they choose not to make it a priority.
|
|
|
|
Re: btw:
[Re: Haze]
#388980 - 12/11/20 02:32 PM
|
|
|
> Likewise, I don't really consider myself to be a good programmer, and if some of the
> devs are to be believed, I'm even worse than that.
The quality of your submissions has improved enormously in the last few years. You’re definitely a far better programmer than you used to be.
|
|
|
|
Re: Haze: looking-back-at-a-list
[Re: gregf]
#388992 - 12/13/20 06:19 PM
|
|
|
An interesting read although im surprised the Seibu / Tad Corp games which used the deadly cop protection schemes
didn't make the list, i suppose if you had asked Haze at the time he might well have thought it unlikely we'd see
them fully emulated only several months on from when that list was compiled.
|
Arcade Addict
|
|
|
Re: btw:
[Re: Haze]
#388993 - 12/13/20 06:36 PM
|
|
|
>
> Likewise, I don't really consider myself to be a good programmer, and if some of the
> devs are to be believed, I'm even worse than that.
Ya know i dont just read any ole nonsense yet i have read in depth all of your writeups
if your dev skills are questioned by some im sure your journalistic credentials are not 
|
Arcade Addict
|
|
|
Re: Haze: looking-back-at-a-list
[Re: gregf]
#388996 - 12/13/20 09:40 PM
|
|
|
Quote:
Konami – GX Type 1 – Racin’ Force & Golfing Greats 2 (Arcade)
No public progress shown. More is known about the chips involved now than was back then, but there’s nothing at all to show for it.
Do we know if the 056540 (PSAC4) is custom hardwired logic or an MCU/DSP? Some 3d effects seen from pcb recordings may as well be a dead giveaway a DSP/MCU was used for additional 3d calculations.
|
-.-
|
|
|
Re: Haze: looking-back-at-a-list
[Re: Hydreigon]
#389000 - 12/13/20 09:59 PM
|
|
|
> Konami – GX Type 1 – Racin’ Force & Golfing Greats 2 (Arcade)
>
> No public progress shown. More is known about the chips involved now than was back
> then, but there’s nothing at all to show for it.
> Do we know if the 056540 (PSAC4) is custom hardwired logic or an MCU/DSP? Some 3d
> effects seen from pcb recordings may as well be a dead giveaway a DSP/MCU was used
> for additional 3d calculations.
It's a Voxel renderer, no real reason it would be a DSP/MCU, it just stretches single pixels to be much taller depending on certain params + additional data in the tile roms, that is basically a height map rather than colour data.
It's a post-process effect on the ROZ output basically
|
|
|
|
Re: Haze: looking-back-at-a-list
[Re: gregf]
#389003 - 12/14/20 02:34 AM
|
|
|
I'll ask here,
Gals panic II is because of an undumped protection chip if I remember correctly isnt it? If so was a chip ever sourced for it or is it still needed ?
|
Only here to annoy...
|
|
|
Re: Haze: looking-back-at-a-list
[Re: Renegade]
#389005 - 12/14/20 07:47 AM
|
|
|
There's at least one available, yes. The 'PISCES' protection chip is believed to be based on a NEC uPD78324.
|
.
|
|
|
Re: Haze: looking-back-at-a-list
[Re: Renegade]
#389009 - 12/14/20 09:07 PM
|
|
|
Info from MameC:
There is an MCU "PISCES" that is either a NEC uPD78322 (with 16K internal ROM) or NEC uPD78324 (with 32K internal ROM) that's used for protection. The MCU needs to decapped and have the ROM read out. This chip is a 16/8-Bit single-chip Microcontroller of the 78K/III series CPU and currently doesn't have a CPU core for MAME. There is partial simulation of the MCU but the game will not really be playable until the chip is decapped, decoded and a core written.
Info from Haze:
Gals Panic 2 is 2x68k, protection mcu handles the communication between the cpus so it doesn't work. Update:
The MCU needs decapping and dumping. Ogoun reported some limited success decapping an MCU of the same type from Brap Boys / Shogun Warriors a few months back, but thus far we haven't seen any imaging of said MCU, and don't have a CPU core for it, so no progress can be made at the moment. If the MCU on those is successfully decapped, imaged and emulated then the chances of the MCU on Gals Panic 2 being done increase greatly (as it appears to be the same type of chip, with different internal ROM)
Edited by hider93228 (12/15/20 04:25 PM)
|
|
|
|
Re: Haze: looking-back-at-a-list
[Re: hider93228]
#389010 - 12/14/20 09:43 PM
|
|
|
The info from "MameC", whatever that is, is outdated. MAME now has a uPD 78K series CPU core. So as long as it can be dumped, and it doesn't run into any features that AJR hasn't hooked up yet, it should be relatively straightforward.
|
|
|
|
Re: Haze: looking-back-at-a-list
[Re: MooglyGuy]
#389021 - 12/16/20 07:09 AM
|
|
|
> The info from "MameC", whatever that is, is outdated. MAME now has a uPD 78K series
> CPU core. So as long as it can be dumped, and it doesn't run into any features that
> AJR hasn't hooked up yet, it should be relatively straightforward.
I hate to point this out, but the unemulated features include the 78K CPU cores themselves. It's something I may get around to eventually, probably after the long-planned MCS-51 rewrite.
One slightly odd thing about the 78K/III subseries (which the Kaneko protection MCUs belongs to) is that μPD78310 and μPD78312 (the models for which I added stub devices for various synthesizer products) have different instruction timings from the later 78K/III MCUs; even a few of the instruction types and encodings are incompatible. (They had a single decimal adjust instruction which made use of an PSW flag to determine if the last arithmetic operation was a subtraction; NEC later decided that that instruction was better off split in two.)
78K/II is a fair bit different from 78K/III (it has a 1M banked address space), and 78K/0 came later and completely revamped the microarchitecture. 78K/I wasn't really used for much, but I added it for completeness. 78K/IV (which replaced 78K/II application-wise) is mostly backward-compatible with the later 78K/IIIs; it would be interesting to add if there were dumps for it.
|
|
|
| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8603
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
Re: Haze: looking-back-at-a-list
[Re: AJR Hacker]
#389023 - 12/16/20 08:36 AM
|
|
|
>> The info from "MameC", whatever that is, is outdated.
--
but the unemulated features include the 78K CPU cores themselves. It's something I may get around to eventually, probably after the long-planned MCS-51 rewrite.
One slightly odd thing about the 78K/III subseries (which the Kaneko protection MCUs belongs to) is that μPD78310 and μPD78312 (the models for which I added stub devices for various synthesizer products) have different instruction timings from the later 78K/III MCUs; even a few of the instruction types and encodings are incompatible. (They had a single decimal adjust instruction which made use of an PSW flag to determine if the last arithmetic operation was a subtraction; NEC later decided that that instruction was better off split in two.)
78K/II is a fair bit different from 78K/III (it has a 1M banked address space), and 78K/0 came later and completely revamped the microarchitecture. 78K/I wasn't really used for much, but I added it for completeness. 78K/IV (which replaced 78K/II application-wise) is mostly backward-compatible with the later 78K/IIIs; it would be interesting to add if there were dumps for it.
-
Knowing that this game will get more similar questions in the future, that's the type of info that would be ideal to read on the entry of
--
https://wiki.mamedev.org/index.php?title=MNW
galpani2
Kaneko protection MCU with internal rom, managing CPU comms. Decap should possible, should be the same for all games / sets.
-
Or if possible, maybe someone sneak in the info on to Gals Panic II entry on Bobby's Kaneko page. 
https://unmamed.mameworld.info/non_kaneko.html#GalsPanic2
Meanwhile, I am looking to fill in more details of some 'pong ball paddle' variety coinop games / non-cpu stuff. https://unmamed.mameworld.info/no_cpu.html
|
|
|
|
Re: Haze: looking-back-at-a-list
[Re: AJR Hacker]
#389047 - 12/18/20 01:19 PM
|
|
|
> > The info from "MameC", whatever that is, is outdated. MAME now has a uPD 78K series
> > CPU core. So as long as it can be dumped, and it doesn't run into any features that
> > AJR hasn't hooked up yet, it should be relatively straightforward.
>
> I hate to point this out, but the unemulated features include the 78K CPU cores
> themselves. It's something I may get around to eventually, probably after the
> long-planned MCS-51 rewrite.
OTOH, give me a gals panic 2 mcu dump and I may look at adding the cpu core myself :-)
Without a dump it's severely less interesting.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: btw:
[Re: Haze]
#389157 - 12/24/20 04:11 AM
|
|
|
> > That and there is also deciphering program rom code; something I have yet to figure
> > out to this day :S.
>
> I spent probably the first 6 or 7 years doing this, the period some people consider
> to be my 'best' work*, without really having any understanding of this either,
> instead just by looking at what accesses were being made and going from there.
I'm not great at reading Z80 but I've emulated a fair amount of stuff running on it just from hooking it up and watching the memory access patterns. One of the great benefits of working within the MAME framework is that the CPU cores do what they're supposed to and you don't have to reverse-engineer the ROM code to make something run.
|
|
|
Index 
Threaded 
Haze: looking-back-at-a-list
Reply
[Re: 
