forums.marpirc.net

0.86
----

While there are no new working games in this release it remains
interesting from a technical and development point of view mainly
due to the new PPC core as well as the Hyperstone and 37710 fixes.
It should also be a fairly stable release after the many input changes
which have taken place recently.

Driver Improvements:
--------------------

M37710, NamcoSS22 and C352 improvements [R.Belmont]
M37710 changes (m37710.diff):
- Data bus is actually 16 bit, not 8
- Fixed saving of status register on interrupts
- Fixed errors in PHB, PHT, PLT, and ANDB opcodes
- Added XAB, PLB, and ROLB opcodes
- Fixed IRQ dispatch errors
- Various get_info fixes

NamcoSS22 changes (s22.diff):
- All CPU clocks changed to measured-by-Guru values
- Handle the changed M37710 bus width
- Temporarily disconnect shared RAM. There's a
problem where the 68020's shared RAM test wipes out
the 37710's work variables and causes it to crash. I
suspect there's a register that halts or resets the
37710. (note: Prop Cycle has no POST and doesn't
cause this problem, but all the other games do).

C352 change (c352.diff):
- Remove debug printf that accidentally snuck in

SPI Improvements [Ville Linde]
- Improved (but not yet correct) tilemap decryption
- Preliminary sprite priority support

PowerPC 403 core [Ville Linde, Bart Trzynadlowski, Stefano Teso]
This is basically SuperModel (Sega Model 3 emu)'s PPC
core minus the FPU and 6xx-series specific
instructions (that stuff isn't ported to MAME yet).
As such, it's passed all manner of synthetic PPC
torture tests and should be quite reliable for any
PPC403-based hardware.

Virtua Racing improvements [Olivier Galibert, Andrew Gardner]

Hyperstone CPU Core Improvements [Tomasz Slanina, Pierpaolo Prazzoli]
Tomasz Slanina
- interrputs after call and before frame are prohibited now
- emulation of FCR register
- Floating point opcodes (preliminary)
- Fixed stack addressing in RET/FRAME opcodes
- Fixed bug in SET_RS macro
- Fixed bug in return opcode (S flag)
- Added C/N flags calculation in add/adc/addi/adds/addsi and some
shift opcodes
- Added writeback to ROL
- Fixed ROL/SAR/SARD/SHR/SHRD/SHL/SHLD opcode decoding (Local/Global
regs)
- Fixed I and T flag in RET opcode
- Fixed XX/XM opcodes
- Fixed MOV opcode, when RD = PC
- Fixed execute_trap()
- Fixed ST opcodes, when when RS = SR
- Added interrupts
- Fixed I/O addressing

Pierpaolo Prazzoli
- Fixed fetch
- Fixed decode of e132xs_xm opcode
- Fixed 7 bits difference number in FRAME / RET instructions
- Some debbugger fixes
- Added generic registers decode function
- Some other little fixes.

Jaleco Mahjong Driver update [Angelo Salese]
some games are *almost* playable but still have protection issues

Adjusted Top Speed volume balance

Changes to the main program:
----------------------------

Misc Fixes [Nathan Woods]
src/inptport.c:
src/inptport.h:
- Fixes PORT_INCLUDE by making the final IPT_END appended within
input_port_allocate()
- Added some MESS specific defaults
- Spelling fix in IPT_BILL default

Fixed some Multisession win32 bugs [Chris Kirmse]

New Games supported or promoted from GAME_NOT_WORKING status:
-------------------------------------------------------------
none

New Clones supported or promoted from GAME_NOT_WORKING status:
--------------------------------------------------------------
Field Goal (different) [Andy Welburn]


New Non-Working games / clones supported
----------------------------------------

Various Konami PPC based games [Ville Linde]
gticlub, gradius4, sscope, sscope2, racingj, racingj2, thrilld
midnrun, windheat
These are to demonstrate the PPC core in action, they contain only
very preliminary emulation and do nothing more than display the initial
test screens.
Cool Riders [David Haywood]
skeleton driver, to be continued at a later date
Pit Boss
added to merit driver, not investigated the issues yet
Tatakae! Big Fighter [Tomasz Slanina]
serious protection issues
Cool Mini
Hyperstone based game, incomplete set
----------------------------------------------------------


Scary... isn't it? Soon they're going to have to pull a Cowering and release Mame 0.992a or something... only 14 more releases to make 1.00 otherwise

Mame has come a long, long way baby.


Kelly

Says who? After 0.99 will be 0.100.

mahlemiut wrote:Says who? After 0.99 will be 0.100.

But then kiddies will think that someone just released a copy of Mame v0.1 with a nasty virus in..... HEY! THAT COULD WORK!

[grins evilly]



Kelly

What came after 0.9? 0.10. Make any sense to you yet?

mahlemiut wrote:What came after 0.9? 0.10. Make any sense to you yet?

I'm no math Advnced Math Major or anything.. but yet again, would that not be 1.0..

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.1 1.2 1.3 1.4

Unless you refer to hat I pointed out.. where it could be 0.90 0.901 0.902

It's kinda like the whole issue with them making that HUGE jump a long time ago in the #'ing system. 0.100 is the exact same thing as 0.1..the very first version... just a bunch more 0's at the end. But then you could literally do this as it is and call this version 0.860 ...


Granted I'm tired atm, and who knows exactly what the MameTeam will decide to do when the time comes, but I know I won't lose any sleep over it [Curls up in a ball and goes to sleep. zzzzzz]


Kelly

Version numbering has what to do with maths?

Nothing.

mahlemuit wrote:Version numbering has what to do with maths?

mr. Flewin wrote:it could be 0.90 0.901 0.902

there was a jump from m.a.m.e. 37 to 53

tar wrote:there was a jump from m.a.m.e. 37 to 53

For the 16 betas that were released in the 0.37 cycle.

Does it matter? If the mame team decides it might as well be v 1000 People will worship them anyway

QRS wrote:Does it matter? If the mame team decides it might as well be v 1000 People will worship them anyway

HEHEHE, Now there's an answer that satisifies it all


Kelly

we really haven't decided yet..

maybe we'll just use a random number generated before each release.. that should confuse a few people ;p

Mr. Kelly R. Flewin wrote:

mahlemiut wrote:What came after 0.9? 0.10. Make any sense to you yet?

I'm no math Advnced Math Major or anything.. but yet again, would that not be 1.0..

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.1 1.2 1.3 1.4

Unless you refer to hat I pointed out.. where it could be 0.90 0.901 0.902

It's kinda like the whole issue with them making that HUGE jump a long time ago in the #'ing system. 0.100 is the exact same thing as 0.1..the very first version... just a bunch more 0's at the end. But then you could literally do this as it is and call this version 0.860 ...

It makes no sense for apps to have versions like 1.1 and 1.11 then 1.2 - 11 is a bigger number than 2, so I view them in the order of 1.1 -> 1.2 -> 1.11, not 1.1 -> 1.11 -> 1.2. If they need a subversion, they should be using it as 1.1.1, a minor update to 1.1. Or use 1.10/1.11/1.20, not have the extra zeroes "implied" or whatever. So having 0.100 after 0.99 isn't anything crazy or wrong.

Maybe they should start using random two letter groups as the version, like half of the other programs these days. MAME FT, MAME XM, MAME WD, etc That'll make sure everybody is confused, not just the ones that can't figure out a simple version number scheme.

Anyway, it just bothers me when people can't deal with a sensible version numbering. And the "huge jump" was explained somewhere else in this thread.

Anyone who equates version numbering to decimals but get really confused when they open a command prompt...

Maybe you guys are too young...but remember the version system for Kermit?

It was similar to what MAME has done to a degree.

I think when MAME reches 0.99 then it will go to either 0.991, 0.992, etc. or do exactly what kermit did which was 0.99(1), 0.99(2), etc.

so you have a new "number" for each build beyond 0.99.

I can't remember the last version of Kermit but it was something like 0.99(187). hehe