Home Page

0.147 is out

Posted By: Robbbert

0.147 is out - 09/17/12 11:27 AM

Please note that the MAME source is the only source available as from now. MESS can be built by using the usual compile switches.

Source -> http://mamedev.org/release.html

Official binaries -> http://mess.redump.net/downloads

MESSUI -> http://messui.the-chronicles.org/

Quote:
0.147
-------


MAMETesters Bugs Fixed
----------------------
- 05003: [Graphics] (gb.c) gbcolor [commandk, dkongc, zeldaldx]:
Graphics corruption in many sets (s.ronco)
- 04981: [Graphics] (coleco.c) coleco: [frogger] Blinking graphic
glitches across top half of screen (hap)

New System Drivers Supported:
-----------------------------
(none)

Systems Promoted from GAME_NOT_WORKING:
---------------------------------------
(none)

Skeleton drivers:
-----------------
- AlphaSmart Pro [JCCyC]

System Driver Changes:
----------------------
-mz2000: added and hooked up software lists for tapes and
floppies. tapes do not work, and we need proper dumps of the cassette
BASIC. [Fabio Priuli]

-vip: Fixed VP-700 Tiny BASIC ROM mapping and VP-620 ASCII
keyboard. [Curt Coder]

-i8550021: Added keyboard ROM. [John Elliott]

-hr16: Added preliminary sound emulation. [Sandro Ronco]

-vboy: Improved framebuffer busy / drawing flags for Virtual Boy, golf
doesn't crash anymore and nesterfb does a bit more [Angelo Salese]

-vboy: correct timer handling, gives proper sound/music. [R. Belmont]

-VK100 IO mirroring, also a lot of prom tracing and comment
updates [Lord Nightmare]

-c64: Added floating bus read support to cartridge interface. [Curt Coder]

-plus4: Added floating bus read support to TED and
cartridge interface. Implemented some Diag264 test cartridge loopback
connectors. [Curt Coder]

-c64: Fixed CPU port, tsuit215 CPUPORT test passes now. [Curt Coder]

-VK100: Correctly hooked up vsync interrupt to crtc instead of
video subsystem; Figured out the low two bits of SYSTAT_A from tracing
and hooked both up, and updated the SYSTAT_A documentation comments.
Additional documentation comments for the SMC COM5016T baud rate
divider. Made the DU/DVM/DIR/WOPS 8*4bit register file an actual
4-entry array, to simplify address decoding later. [Lord Nightmare]

-VK100: simplification of the code by emulating the register
file as an array. [Lord Nightmare]

-apple2gs: Improved Ensoniq sound emulation for many games/apps. [R. Belmont]

-apple2gs: Save states now officially supported. [R. Belmont]


Software Lists:
----------------
-vic1001_cart.xml: Added a few more carts. [K1W1]

-ibm5170.xml: Added some more disks. [Kaylee]

-pcw.xml: Dumped UK and FR system disks. [breiztiger]

-mz700: added a software list to document tape dumps [FatArnold]

-channelf.xml: added a bunch of proto carts dumped a few years
ago. [K1W1]

-snes.xml:
* Huge prototype update, tons of invaluable documentation added
[ReadOnly] Many thanks to all the contributors, in no particular
order: TheRedEye, Adam K, Van Halen, Mike, JackHead, badinsults,
Yakushi~Kabuto
* New dumps deluge
[JachHead, Mike, Yakushi~Kabuto, badinsults, RedScorpion]
* Many new carts profiles added, thanks to RedScorpionís donation
[ReadOnly]
* Rationalization of the undumped list [ReadOnly]
* Plethora of fixes and additions [ReadOnly]

-pico.xml: new US dumps. [TeamEurope]


Source Changes:
----------------
-Fixed vertical sprite wrap-around in SNES driver [Angelo Salese]

-Rewritten cycle steal code from scratch and nailed it directly
in the G65816 CPU core [Angelo Salese, byuu]

-Added PET cassette port slot interface to vic20, c64, and
plus4. Implemented 1530/1531 datassette as slot devices. Converted
MOS6581 interface to devcb. [Curt Coder]

-vic20: Added floating bus read support to VIC and cartridge interface.
[Curt Coder]

-vic10: Added floating bus read support to VIC-II and cartridge interface.
[Curt Coder]

-Fixed incorrect SPC700 IPL ROM behaviour in SNES driver(s),
fixes some (not all) crashes at soft reset [Angelo Salese]

-Added Sound Blaster 16, and proper 16 bit ISA DMA handling [Carl]

-Added IBM VGA card [Carl]

-m6502: Fixed CPU peripheral port behavior by introducing pull-up and
pull-down masks to the CPU interface. [Curt Coder]

-isa_blaster: Adds 2,3 and 4bit ADPCM support [Carl]

-Preliminary support for cassette images in MZ-2000
[Angelo Salese]

-Added keyboard inputs for Pasopia and Pasopia 7, z80pio irq
still doesn't work [Angelo Salese]

-Added paddles and light pen VCS control devices. [Curt Coder]

-support for writing to compressed hard drives using diff files. [smf]

-pc hardware: cleanup the end-of-dma notifications [O. Galibert]

-isa_blaster: improves the adpcm and simplifies the dsp
protection, based on the ATI Stereo FX rom. [Carl]

-pc_joy: made pc joystick a device for the many isa audio adapters with
joy ports to share. [Carl]

-cbmb: Added PLA dumps. [Edward Shockley]

-ATI Stereo F/X ISA card support [Carl]
Posted By: KevinP

Re: 0.147 is out - 09/26/12 08:11 AM

Question?
Also someone can move this to the appropriate thread if it doesn't relate.

I've just found 10 minutes out of my busy schedule to try the new MESS out and have updated everything including using the software lists with the divided roms, namely Coleco.

I set my software directory to the MESS Coleco yet it refuses to display all the titles and it cannot find the software while divided into several parts.

Setting the directory to my nointro Coleco directory works as intended.
Is there a new way of loading roms?
I've tried loading the divided roms as a zip and unzipped clicking on the first rom in the series.

Either way no dice using divided roms.
Also, pugzy's software does not display in the tab and I know that I have that configured correctly.

Many thanks.
Posted By: etabeta78

Re: 0.147 is out - 09/26/12 09:50 AM

no new way of loading. you clearly did something wrong.
do you use MESS or MESSUI or MESS+QMC2?

in any case, softlist roms go simply inside roms/coleco/, each game in a separate zip named after the softlist name.

Quote:
Either way no dice using divided roms.


we want to document the content of the carts. you don't care? very well, just stick to nointro set... we will never remove the capability of loading your romset of choice

Quote:
Also, pugzy's software does not display in the tab and I know that I have that configured correctly.


what is "pugzy's software"?
if by any chance you meant Pugsy's cheats, then you need to load games using softlists to have the cheats displayed, because the cheats are loaded based on softlist names.
Posted By: KevinP

Re: 0.147 is out - 09/26/12 10:01 AM

Here to solve an issue not respond to sny comment.

Yes, I did misspell Pugsy. And my thoughts exactly that it comes up based on software names.

I used the Mess 86, mess64 messUI and MESS64UI
I deleted ini, changed ini. everything including config and start from scratch.

Using command prompt with MESS because you guys swear by 1980's technology, it loads mess, I can bring up the colecovision however if I try Mess Coleco Pitfall it can't find the 2 pitfall roms even when I use roms/coleco.

I already know the reasons for splitting roms so you guys have fun with that.

I'm going to try one more thing but I think no matter how it's configured with an ini for the gui and an ini for mess then .cfg files for individual systems it's going to use default directories no matter what I want.


OK, update......
As a wild guess, logical as the reason for rain I moved everything from my ever so commented Colecovision Cartridges Directory into the wildly non descriptive coleco and moved into the roms directory as shown from the poster above.
Yea it works as suspected using default programing from what, 11 years ago?
Let's clump everything into one directory and forget the ini structure, all the advancements in programming and naming conventions. Let's use the Dos prompt, clump everything in one directory and hope for the best.

The reason I didn't figure out on my own was based off I was using common sense and modern practices.

Well, got it working anyway.
I thing it's time to just stick with TOSEC and NoIntro so I can reclaim 120 gigs of repetitive hard drive space. thank Christ I never collected the Saturn CHD's
Posted By: etabeta78

Re: 0.147 is out - 09/26/12 10:09 AM

I don't know what to tell you. here if I put the rom in

roms/coleco/pitfall.zip

and I launch from command line

mess coleco -cart pitfall

it just works...

having only access to a macbook, I cannot test if the problem is in the UI
Posted By: KevinP

Re: 0.147 is out - 09/26/12 10:25 AM

aside from my sarcasm, it does work in Mess64UI as long as it's at default form.
It will not use the ini files no matter what. Mess or MessUI

Bug? Intentional? No idea.
Posted By: qmc2

Re: 0.147 is out - 09/26/12 10:36 AM

What do you mean with "default form"?

If you mean where to place the software "ROMs" then with software-lists you pretty much HAVE TO use '<rompath>/<software-list-name>/<software-name>.zip'...
Posted By: KevinP

Re: 0.147 is out - 09/26/12 10:49 AM

Then whatever happened to put roms, samples and software wherever you want then using a path?

You guys want to remain using the dos prompt type in Mess System then game. Well, that kind of get's annoying when you have 50,000 games.

I don't have that problem with Mame. I can have my roms on a network drive, Samples on a pen drive and the executable sticking out my rear as long as I have the paths set.

Mess seems to REQUIRE directories to be in a predetermined path and name in order to use the software lists.

This reminds me of Gamebase and how it's set up and for whatever reason they are still using Visual basic from 15 years ago and you are not getting that sucker to work unless you have the default C:Gambase.
Could this be because you are using XML scripts?
What is it?

Certainly just dragging and dropping a file you want to run in MESS would be to modern for you.
Posted By: qmc2

Re: 0.147 is out - 09/26/12 10:54 AM

Note that <rompath> can be a LIST of paths, separated with ";", so when you store the software separated from the BIOS ROMs, simply add this path to 'rompath' and you're set... however, the rest of the naming convention has to be kept... also, this only applies to software-lists.
Posted By: KevinP

Re: 0.147 is out - 09/26/12 11:02 AM

How about a compromise then....
Being arguing over someone else's idea. how about being able to use the split roms WITHOUT using the software lists and they can be anywhere on your hard drive as long as you point to it?

You know what, never mind.
Brick wall.

This is as far as you guys can see.

Using a DOS prompt....
Mess SodaMachine Coke.

While I'm aboard the Star Ship Enterprise with my touch screen display and after touching an Icon that represents QBert I play it. Taaa Daaaaa
Posted By: KevinP

Re: 0.147 is out - 09/26/12 11:05 AM

Maybe my mind is closed this early in the morning but I tried all that and at least under .147 it didn't work for me.
Maybe I'm doing something wrong.
Posted By: etabeta78

Re: 0.147 is out - 09/26/12 11:05 AM

KevinP, can you please stop assuming that things do not work due to MESS problem and you start trying to fix issues at your end?

you want multiple rom paths, to keep softlists roms separated from the bios? very well, just put in mess.ini

rompath roms;my/other/path1;my/other/path2

and it will work, exactly like it works in MAME. notice that you need to put quotes if any of the paths includes a space in the name, so e.g.

rompath "roms;my/other/path1 with space;my/other/path2"
Posted By: qmc2

Re: 0.147 is out - 09/26/12 11:05 AM

Excuse me, but I have to start laughing now... and I have no idea what your Star Ship Enterprise's touchscreen has to do with your inability to correctly setup MESS and/or a front-end.
Posted By: R. Belmont

Re: 0.147 is out - 09/26/12 12:23 PM

I find it amusing that he's apparently configured the rom path for MAME no problem but can't figure out that MESS is configured exactly the same way.
Posted By: Darkstar

Re: 0.147 is out - 09/26/12 02:20 PM

I especially like the part where he assumes that his path problems are the result of MESS being a command line program. He probably doesn't realize that the path handling would not change if MESS had a GUI...
Posted By: M. Twitty

Re: 0.147 is out - 09/26/12 02:40 PM

Originally Posted By R. Belmont
I find it amusing that he's apparently configured the rom path for MAME no problem but can't figure out that MESS is configured exactly the same way.


They can't be configured the same way. If they could my ume.ini configuration would just work. Oh, that's right...it does. smile

When are you mame devs going to stop forcing people to use your crappy command line software?

O/T, when did ume happen, anyway? I never heard of it until I saw qmc2-sdlume in the last binary package. It works very well, btw. Congrats to all involved.
Posted By: remax

Re: 0.147 is out - 09/26/12 04:44 PM

Originally Posted By M. Twitty
When are you mame devs going to stop forcing people to use your crappy command line software?


The answer to your question is in your post : use frontends (and QMC2 if you can!).

I prefer MAME/MESS people spend times developping drivers than trying to maintain an UI that would need to work for each system.
Posted By: R. Belmont

Re: 0.147 is out - 09/26/12 04:54 PM

Also, forced-GUI emulators are much harder to deal with in a cabinet type setup. Generally you want your frontend to be fullscreen then and handle everything, with no seeing Windows or having to use a mouse.
Posted By: qmc2

Re: 0.147 is out - 09/26/12 05:04 PM

@remax: I think M. Twitty's comment was ironical wink...
Posted By: Kaylee

Re: 0.147 is out - 09/26/12 07:42 PM

Originally Posted By Darkstar
I especially like the part where he assumes that his path problems are the result of MESS being a command line program. He probably doesn't realize that the path handling would not change if MESS had a GUI...


Mess Had a GUI ages ago, from before Noah went into the Ark, but when he left the ark the GUI was dropped since it didn't work anymore :P
Posted By: qmc2

Re: 0.147 is out - 09/26/12 08:15 PM

Originally Posted By Kaylee
Mess Had a GUI ages ago, from before Noah went into the Ark, but when he left the ark the GUI was dropped since it didn't work anymore :P

Hehe... the GUI was sad because it had no "female GUI counterpart"? smile
Posted By: M. Twitty

Re: 0.147 is out - 09/26/12 09:32 PM

Originally Posted By qmc2
@remax: I think M. Twitty's comment was ironical wink...


I think so, too. But he must've set the irony dial to 11 by mistake.
Posted By: remax

Re: 0.147 is out - 09/26/12 10:20 PM

Originally Posted By M. Twitty
I think so, too. But he must've set the irony dial to 11 by mistake.


My bad! Irony is harder to spot in foreign language blush
Posted By: Robert Gault

Re: 0.147 is out - 09/28/12 09:00 PM

Robbbert,
Is there any chance that wimgtool could be resurrected so that it could be built along with a "make tools TARGET=mess OSD=winui" build?
Posted By: Anna Wu

Re: 0.147 is out - 09/29/12 05:04 AM

Originally Posted By Robert Gault
Robbbert,
Is there any chance that wimgtool could be resurrected so that it could be built along with a "make tools TARGET=mess OSD=winui" build?


It is possible, you have to restore the missing files (see the link below).
I use (GCC 4.4.7):

make all TARGET=mess OSD=winui

Unofficial DL

PS: The tool is still buggy.
Posted By: Robert Gault

Re: 0.147 is out - 09/30/12 02:42 AM

Thank you Anna. That worked very well.

Actually I only needed to add the directory

src\mess\tools\imgtool\windows

and add the few lines

# include OS-specific MESS stuff
# the following expression is true if OSD is windows or winui
ifeq ($(OSD),$(filter $(OSD),windows winui))
include $(MESSSRC)/tools/imgtool/windows/wimgtool.mak
TOOLS += $(WIMGTOOL)
endif

to the main tools.mak file.

The product still has font problems with certain aspects of coco disks. This was the same for your included wimgtool.exe and the one I built.
For example, attempting to Extract a file from a coco.dsk gives the following modes:
||i|
|w
instead of
ascii
raw

It must be a result of the way the utf8 font is used, but I don't see what is causing the problem.
Posted By: tpreitzel

Re: 0.147 is out - 10/06/12 06:37 AM

I like the new changes, i.e. the ability to compile MESS without patching the MAME source. Now that Slackware has gconf installed by default, I don't even need to patch the source at all... wink

Anyway, my screen scrambles with the CoCo2 driver when graphics are displayed, e.g. running McPaint. Granted, my system's windowing manager is beta Enlightenment E-17 with composting enabled, but I didn't have this problem with SDLMESS 0.142 and nothing else has changed. I have the option, video opengl, selected because selecting the option, video soft, just displays a black, blank screen when running mess64...

Insights?

BTW, please don't delete my account since I'm using my real name and haven't filled out some form or another. I'm not real clear on your new procedures to combat spam.

TIA
Posted By: Robert Gault

Re: 0.147 is out - 10/06/12 11:32 AM

tpreitzel,
I don't have McPaint to test and am on a Windows 32-bit system, but have no trouble with graphics in coco2 emulation. Set for 64K memory, video D3D. I don't see an option for openGL in MESS.
Posted By: qmc2

Re: 0.147 is out - 10/06/12 11:44 AM

I can't test McPaint (don't have any coco2 software), but I see no 'garbage' using this driver with '-video opengl' on Linux.

And since '-video soft' apparently doesn't work correctly on tpreitzel's system as well, I'd argue it's a local issue.
Posted By: R. Belmont

Re: 0.147 is out - 10/06/12 11:51 AM

Yeah, I would suggest disabling compositing in the window manager and trying again. It took GNOME and KDE several tries to interact properly with apps (especially apps using OpenGL), and people actually use and test those ;-)

Alternatively, you can tell us if other drivers actually work correctly, or if the MAME overlays display properly when the screen goes bad (e.g. the Tab menu or the F4 palette viewer).
Posted By: tpreitzel

Re: 0.147 is out - 10/06/12 08:14 PM

It might be an issue with E-17 since I do see some similar window distortion occasionally in other parts of E-17, but I'm not totally convinced those occasional glitches are related to the issue with McPaint. As I said, I was using SDLMESS 0.142 with the EXACT same setup and I had NO scrambling of the screen when running Milliluk's McPaint until I switched to SDLMESS 0.147. I even switched to testing SDLMESS 0.147 on the latest version of XFCE on Slackware64 14.0 with EXACTLY the same result for McPaint 2.10. Notice that other graphics programs seem to run alright on SDLMESS 0.147 with the coco2 driver, but NOT McPaint. On McPaint, the opening graphics screen (color test) appears unscrambled and as soon as the user presses the <enter> key, the screen immediately scrambles. If I get time, I'll post a screenshot.

BTW, I'm NOT switching away from E-17 as it's one of the best windowing managers! LoL ... smile
Posted By: tpreitzel

Re: 0.147 is out - 10/06/12 08:22 PM

Robert,

I'm using SDLMESS compiled on GNU/Linux. I've abandoned MS Windows years, err decades, ago by now which shows my age. Yikes! wink

BTW, most of my graphics programs run just fine on SDLMESS 0.147 with the coco2 driver as well, but Milliluk's McPaint 2.10 doesn't run properly for some unidentified reason... bizarre.

I just noticed on Aaron's website that the updated RGB-DOS ROM has already been posted in Updates.zip. Finally, thanks, Robert, for your interest and work with Tandy's Color Computer over the years. I appreciate it and have for DECADES now.
Posted By: Robert Gault

Re: 0.147 is out - 10/06/12 10:57 PM

It is possible that McPaint 2.10 itself is the problem not MESS. Is the program available somewhere for download?

If I could test McPaint, we could determine if it works with other emulators, Windows vs SDL, or different versions of MESS. That would go a long way to locating what is wrong.
Posted By: Robert Gault

Re: 0.147 is out - 10/07/12 01:59 AM

OK. Found a copy of MCPaint 2.10 and have tried it with several versions of MESS (coco2 emulation) on a Windows system. The program will work correctly with MESS 0.142 but later versions fail to correctly handle screen refresh after the first mouse click.

Any version of MESS will run the program under coco3 emulation.

Clearly there is a problem with coco2 and coco2b emulation with current versions of MESS when using MCPaint. I expect it does not matter whether it is Windows or SDL.
Posted By: tpreitzel

Re: 0.147 is out - 10/07/12 03:26 AM

Thanks Robert!

BTW, I've also noticed that CoCo Max 3 no longer responds to mouse input with the CoCo Max 3 input selected on either port. I noticed that the input options were rearranged from 0.142 to 0.147 as well... I don't think this problem is merely an improper selection of an option on my part, but it could be. I'd appreciate if someone else can verify the input options using the coco3 driver or for all of the coco drivers. CoCo Max 2 should work as well IF the Coco Max cartridge was implemented for the coco2/2b drivers. I can't recall for sure from memory.

Posted By: Robert Gault

Re: 0.147 is out - 10/07/12 12:13 PM

I can confirm the CoCo Max 3 problems. Neither of the high res mouse inputs Tandy nor CoCoMax will work in 0.147 but do in 0.142.
Posted By: tpreitzel

Re: 0.147 is out - 10/08/12 09:33 AM

Neither TS/Edit OS9 nor Micro Illustrator will boot in the coco2 driver as well. Apparently, no one has been testing the color computer drivers for some time ...
Posted By: Tafoid

Re: 0.147 is out - 10/08/12 09:52 AM

Originally Posted By tpreitzel
Neither TS/Edit OS9 nor Micro Illustrator will boot in the coco2 driver as well. Apparently, no one has been testing the color computer drivers for some time ...


To presume that there is no testing being done is incorrect. Normal automated testing of a system in MESS include basic power on and initial device and visual tests. Unless users of said systems report their confirmed regressions to mametesters.org, there isn't a lot that can be done about fixing it. Regressions are always unwelcome but they happen in a project the size of MAME/MESS.

Posted By: tpreitzel

Re: 0.147 is out - 10/08/12 11:55 AM

Originally Posted By Tafoid
Originally Posted By tpreitzel
Neither TS/Edit OS9 nor Micro Illustrator will boot in the coco2 driver as well. Apparently, no one has been testing the color computer drivers for some time ...


To presume that there is no testing being done is incorrect. Normal automated testing of a system in MESS include basic power on and initial device and visual tests. Unless users of said systems report their confirmed regressions to mametesters.org, there isn't a lot that can be done about fixing it. Regressions are always unwelcome but they happen in a project the size of MAME/MESS.



I was thinking on this issue more after my post. It's pretty clear that MAME/MESS needs a more sophisticated test suite which will naturally burden the release cycle, but should significantly lessen the number of buggy drivers released to users. True, the MAME/MESS developers won't be able to crank out releases as fast, but maybe the latter restraint is a GOOD path to follow. After dealing with the regressions for nearly a decade myself in a project the size of MAME/MESS, I can understand why users are tempted to look elsewhere for emulation. Personally, I'm content to do my part, but I'm fairly sure a more elaborate test suite and slower release cycle would probably benefit everyone.
Posted By: Haze

Re: 0.147 is out - 10/08/12 12:07 PM

There's no sensible way to test every case. Most of the systems require non-trivial interaction to operate, you have no idea if you're likely to see a bug in the first 5 seconds or 5 minutes. Even with just MAME this is hard and most things there don't require any kind of complex system configurations, or knowledge of how to use the machine to get anywhere.

Really the best way for things to get tested is for people to use them, the best way to get people to use them is better exposure of the project. Things get broken, things get fixed, we're not in some security critical environment here ;-)

If every system had just one knowledgeable user running stuff after each release than serious issues would get noticed quickly, maybe not fixed instantly as quite often things break because they were relying on other incorrect behaviour, but at least they'd be logged. A knowledgeable user will pick up on problems MUCH more quickly than any automated testing.

MAME / MESS teams can try their best to avoid putting out buggy releases, not putting major changes in without some light testing etc. but slowing down the entire project in a rather futile attempt to avoid having any issues just isn't going to fly ;-) Nicola's late MAME philosophy was similar to this, and it almost killed the project stone dead as delays built up and you never actually source a new release or source drop.

As things mature they tend to become less fragile anyway, behaviour becomes trusted across multiple platforms, any breakage is really just part of this process, with the majority leading to a need for a better understanding of something rather than a 'quick fix hack'. Delaying releases until everything is fixed will only IMHO result in more 'quick fix hacks' which is what you see in commercial products with shipping deadlines.

In terms of users, most users sync to full updates, not u updates, that means most testing gets done on full updates, it might seem a meaningless number, or just another SVN revision to people working on it, but full releases tend to be the point where people sync up all their roms etc. Again delaying release cycles for extensive internal testing is only likely to result in less (higher quality, real use) external testing. It's a game of balance.

Posted By: R. Belmont

Re: 0.147 is out - 10/08/12 12:51 PM

The actual problem here is simple: the Rat Shack drivers don't have an active maintainer and none of us knows jack about how those computers are meant to work. If either of y'all knows C++ there's a great way to insure the CoCo doesn't rot, since you both clearly understand the CoCo at a high level of detail.
Posted By: Robert Gault

Re: 0.147 is out - 10/08/12 04:35 PM

Sorry but I'm not good enough at C or C++ to be a maintainer. On the other hand, I'd be happy to engage in private e-mail with any maintainer willing to work on the Coco code.
I can supply test programs to demonstrate bugs, and often can even intuit the blocks of code responsible for errors, though I don't know how to fix them.
Posted By: tpreitzel

Re: 0.147 is out - 10/09/12 02:10 AM

Originally Posted By R. Belmont
The actual problem here is simple: the Rat Shack drivers don't have an active maintainer and none of us knows jack about how those computers are meant to work. If either of y'all knows C++ there's a great way to insure the CoCo doesn't rot, since you both clearly understand the CoCo at a high level of detail.


Reliance on human familiarity with the operation of MAME/MESS' drivers is bound to fail as time passes since humans die.
Posted By: tpreitzel

Re: 0.147 is out - 10/09/12 02:21 AM

Originally Posted By Haze
There's no sensible way to test every case. Most of the systems require non-trivial interaction to operate, you have no idea if you're likely to see a bug in the first 5 seconds or 5 minutes. Even with just MAME this is hard and most things there don't require any kind of complex system configurations, or knowledge of how to use the machine to get anywhere.

Really the best way for things to get tested is for people to use them, the best way to get people to use them is better exposure of the project. Things get broken, things get fixed, we're not in some security critical environment here ;-)

If every system had just one knowledgeable user running stuff after each release than serious issues would get noticed quickly, maybe not fixed instantly as quite often things break because they were relying on other incorrect behaviour, but at least they'd be logged. A knowledgeable user will pick up on problems MUCH more quickly than any automated testing.

MAME / MESS teams can try their best to avoid putting out buggy releases, not putting major changes in without some light testing etc. but slowing down the entire project in a rather futile attempt to avoid having any issues just isn't going to fly ;-) Nicola's late MAME philosophy was similar to this, and it almost killed the project stone dead as delays built up and you never actually source a new release or source drop.

As things mature they tend to become less fragile anyway, behaviour becomes trusted across multiple platforms, any breakage is really just part of this process, with the majority leading to a need for a better understanding of something rather than a 'quick fix hack'. Delaying releases until everything is fixed will only IMHO result in more 'quick fix hacks' which is what you see in commercial products with shipping deadlines.

In terms of users, most users sync to full updates, not u updates, that means most testing gets done on full updates, it might seem a meaningless number, or just another SVN revision to people working on it, but full releases tend to be the point where people sync up all their roms etc. Again delaying release cycles for extensive internal testing is only likely to result in less (higher quality, real use) external testing. It's a game of balance.



Although I basically agree with your overall sentiment, enhanced testing prior to releases really isn't an option if MAME/MESS is to survive. Reliance on human familiarity with the operation and testing of these drivers will only worsen as time passes since humans die. Sure, in the future there will probably always be a very small number of individuals willing to learn the operation of one of the various drivers included in MAME/MESS, but the available pool of people will be miniscule compared to today. A balance must be struck between enhanced testing and delays in the release cycle. Can enhanced automated testing be reasonably integrated into MAME/MESS by generalizing software systems, e.g. input, disc, display, etc.? One could even CAREFULLY adopt ~ a half dozen applications or so for each driver to ensure some semblance of reliability before release. Sure, the result would be to literally test thousands of pieces of software, but even catching 60% of the bugs that would be released without such enhanced testing would probably be worth the initiative.

Posted By: Just Desserts

Re: 0.147 is out - 10/09/12 02:32 AM

199x: "MAME will soon die if it doesn't adopt a more professional work ethic!"

200x: "MAME will die really soon now if it doesn't adopt a more professional work ethic!"

201x: "MAME is most definitely, absolutely going to die in a matter of seconds if it doesn't adopt a more professional work ethic!"
Posted By: tpreitzel

Re: 0.147 is out - 10/09/12 02:50 AM

Originally Posted By Just Desserts
199x: "MAME will soon die if it doesn't adopt a more professional work ethic!"

200x: "MAME will die really soon now if it doesn't adopt a more professional work ethic!"

201x: "MAME is most definitely, absolutely going to die in a matter of seconds if it doesn't adopt a more professional work ethic!"


Work ethic isn't quite the same as the availability of knowledgeable HUMAN operators capable of reporting bugs. wink
Posted By: Haze

Re: 0.147 is out - 10/09/12 02:51 AM

Originally Posted By tpreitzel
Originally Posted By Haze
There's no sensible way to test every case. Most of the systems require non-trivial interaction to operate, you have no idea if you're likely to see a bug in the first 5 seconds or 5 minutes. Even with just MAME this is hard and most things there don't require any kind of complex system configurations, or knowledge of how to use the machine to get anywhere.

Really the best way for things to get tested is for people to use them, the best way to get people to use them is better exposure of the project. Things get broken, things get fixed, we're not in some security critical environment here ;-)

If every system had just one knowledgeable user running stuff after each release than serious issues would get noticed quickly, maybe not fixed instantly as quite often things break because they were relying on other incorrect behaviour, but at least they'd be logged. A knowledgeable user will pick up on problems MUCH more quickly than any automated testing.

MAME / MESS teams can try their best to avoid putting out buggy releases, not putting major changes in without some light testing etc. but slowing down the entire project in a rather futile attempt to avoid having any issues just isn't going to fly ;-) Nicola's late MAME philosophy was similar to this, and it almost killed the project stone dead as delays built up and you never actually source a new release or source drop.

As things mature they tend to become less fragile anyway, behaviour becomes trusted across multiple platforms, any breakage is really just part of this process, with the majority leading to a need for a better understanding of something rather than a 'quick fix hack'. Delaying releases until everything is fixed will only IMHO result in more 'quick fix hacks' which is what you see in commercial products with shipping deadlines.

In terms of users, most users sync to full updates, not u updates, that means most testing gets done on full updates, it might seem a meaningless number, or just another SVN revision to people working on it, but full releases tend to be the point where people sync up all their roms etc. Again delaying release cycles for extensive internal testing is only likely to result in less (higher quality, real use) external testing. It's a game of balance.



Although I basically agree with your overall sentiment, enhanced testing prior to releases really isn't an option if MAME/MESS is to survive. Reliance on human familiarity with the operation and testing of these drivers will only worsen as time passes since humans die. A balance must be struck between enhanced testing and delays in the release cycle. Can enhanced automated testing be reasonably integrated into MAME/MESS by generalizing software systems, e.g. input, disc, display, etc.? One could even CAREFULLY adopt ~ a half dozen applications or so for each driver to ensure some semblance of reliability before release. Sure, the result would be to literally test thousands of pieces of software, but even catching 60% of the bugs that would be released without such enhanced testing would probably be worth the initiative.


I would argue that a balance has been struck, Tafoid runs a bunch of regression tests, they catch a decent number of issues. Even in just testing the MAME side a lot of the components used in MESS get tested because many systems, components and other devices were shared between arcade and home use.

*maybe* you could do some light testing of 1 or 2 pieces of software on each system in MESS as part of that, some custom .inp files to make sure the games get loaded, but that adds additional fragility to the testing and a change doesn't always equal a bug. I have said that MESS could probably do with some 'helper' scripting as an extension of the software lists + debugger for some systems (other computer emus have similar) but for now it only has inps, they're bit fragile for that and represent a raw input stream for every frame, not something a user could edit.

At the end of the day you've found a bug in a system you happen to like, there's a high chance that even if that bug had been found before nobody would have fixed it immediately because there isn't an active developer with an interest / understanding of the system. MESS development over the last 3-4 years has been very good, but there is still older code in there which simply needs rewriting and no amount of bandaid fixes will help with. I can't say if the CoCo is one of those, but it's possible.

Even in other current areas of the code things get broken, for example, the Floppy Disc emulation for PC based systems (and others) isn't really working right now because there's an ongoing attempt by one of the developers to consolidate all knowledge and produce something which actually works better, and is more reliable than any code already there.

Remember, this is a community research project, it relies on having active developers who understand the hardware and new developers coming along to advance that knowledge and take things even further. It is not a commercial product, often you're working against unknown targets, having to understand and emulate subtle misbehaviour of real hardware, not working to a fixed clean specification of 'this goes in' 'this comes out'. As a result commercial development patterns do not work for it. This might sound weird, but even technical manuals only tell you how things are meant to work under normal conditions, often how they really work is another matter altogether.

Yes, it's an issue, it's also one of the reasons I do promote trying to add 'user-friendly' features to the emulator, establish a userbase etc. Yes, as generations pass less and less people are going to care about a system like the CoCo so it's probably going to see less testing and less people who know how to use it or are willing to learn (back to my first point of bubble wrapping it and making it user friendly) but there is only so much we can do.

At the end of the day the most important thing is that MAME / MESS stay active and show this with a decent release schedule and by ensuring they always run on current operating systems. Bugs will come and go, it is part and parcel of the development process and has always happened.
Posted By: R. Belmont

Re: 0.147 is out - 10/09/12 12:26 PM

I don't quite get the "people are going to die so nobody should maintain drivers" argument. You don't have to outlive the project, just Micko's and Aaron's final core style consolidations and any major bugs in the driver.

As usual when this situation pops up, I point to mizapf, who went from wondering why the TI drivers were decaying to making them best-in-breed in emulation quality, add-on peripheral support, and modernized code. It's true that he's probably not immortal, but the drivers are in far, far better shape than if he hadn't bothered.
Posted By: tpreitzel

Re: 0.147 is out - 10/09/12 03:59 PM

Originally Posted By R. Belmont
I don't quite get the "people are going to die so nobody should maintain drivers" argument. You don't have to outlive the project, just Micko's and Aaron's final core style consolidations and any major bugs in the driver.

As usual when this situation pops up, I point to mizapf, who went from wondering why the TI drivers were decaying to making them best-in-breed in emulation quality, add-on peripheral support, and modernized code. It's true that he's probably not immortal, but the drivers are in far, far better shape than if he hadn't bothered.


So, can currently former users of the Color Computer drivers in MESS expect you to become their "mizapf" so they can use MESS again? Great! Are you taking requests for additional peripheral support as well? wink Interestingly, you very noticeably overlooked the impact of these malfunctioning drivers on potential USERS of MESS and concentrated on one maintainer who rescued and enhanced ONE bit-rotting driver. How long did potential USERS of the TI driver have to abandon MESS due to the bit-rotting driver? How many other drivers are bit-rotting while waiting for their "mizapf" to rescue them and their potential USERS?
Posted By: mizapf

Re: 0.147 is out - 10/09/12 04:19 PM

Originally Posted By R. Belmont
... It's true that he's probably not immortal, but the drivers are in far, far better shape than if he hadn't bothered.

Well, I always say I hope for a lifetime of, say, 300 years or so (add: in full consciousness). I just can't stand the perspective that I'll miss the end of all those hassles in the world. Will we have fusion reactors? Peace in middle-east? Debt-free state budgets? The Borg Hive, evolved from the Internet? :-)

Back to our drivers, I guess you'll always need somebody with a good knowledge on the specific driver who maybe just plays around and finds some errors by chance.

After I rewrote the TMS9900 CPU things seemed to run well - until I played a game called Microsurgeon and noticed that many patients in the game were already dead from the beginning. I could trace that back to a mistake in the handling of a rarely used addressing mode of the CPU. That is, particularly in MESS it is extremely difficult to do exhaustive tests and say the driver is good now.

However, it's also true that once the driver is cleaned up there is less chance that it decays after some time. I did not have to put hands on for more than half a year now.

Michael
Posted By: mizapf

Re: 0.147 is out - 10/09/12 04:24 PM

Originally Posted By tpreitzel
How long did potential USERS of the TI driver have to abandon MESS due to the bit-rotting driver?

Users of the MESS TI emulation kept using version 0.97 while MESS had already advanced to 0.114. This was the time when I started to repair it.

The others switched to other emulators.

Michael

Posted By: Haze

Re: 0.147 is out - 10/09/12 04:33 PM

Originally Posted By tpreitzel
Originally Posted By R. Belmont
I don't quite get the "people are going to die so nobody should maintain drivers" argument. You don't have to outlive the project, just Micko's and Aaron's final core style consolidations and any major bugs in the driver.

As usual when this situation pops up, I point to mizapf, who went from wondering why the TI drivers were decaying to making them best-in-breed in emulation quality, add-on peripheral support, and modernized code. It's true that he's probably not immortal, but the drivers are in far, far better shape than if he hadn't bothered.


So, can currently former users of the Color Computer drivers in MESS expect you to become their "mizapf" so they can use MESS again? Great! Are you taking requests for additional peripheral support as well? wink Interestingly, you very noticeably overlooked the impact of these malfunctioning drivers on potential USERS of MESS and concentrated on one maintainer who rescued and enhanced ONE bit-rotting driver. How long did potential USERS of the TI driver have to abandon MESS due to the bit-rotting driver? How many other drivers are bit-rotting while waiting for their "mizapf" to rescue them and their potential USERS?


Abracadabra, is that you?

Better testing won't stop drivers 'rotting' because things will break which people can't just wave a magic wand and fix.

Things will often break because they were done wrong in the first place, and can ONLY be fixed if somebody with a better understanding of the system comes along, however long that takes.

GiJoe in MAME for example has some broken graphics for maybe 5 years now because a certain amount of code had to be removed / disabled because it was abusing the entire MAME system to do a special effect, I don't know what the holy hell the original code was meant to be doing but it was touching all sorts of things it shouldn't have been touching (performing graphic operations on what should be the *private* tilemap cache via all sorts of abuse). It will remain broken until somebody comes along and fixes it properly, you can't just revert the change that broke it because safeguards have been put in place to prevent the very thing that it was doing and prevent further abuse of the system.

There was another game (can't remember title) which broke for a significant amount of time too when the various Address Bus Errors were implemented on the 68k core. Turns out the game had protection that nobody noticed before and tripped Address Errors if the checks failed. Without the (correct) emulation of the Bus Errors the game worked fine, with the Bus Error emulation we had to wait until somebody could reverse engineer the code well enough to simulate the protection before it worked again. Holding back genuine fixes because they broke one game wouldn't have been realistic.

Trolling won't help. One day it will be fixed, but until it is you'll just have to use an older version.
Posted By: R. Belmont

Re: 0.147 is out - 10/09/12 04:52 PM

Originally Posted By tpreitzel
So, can currently former users of the Color Computer drivers in MESS expect you to become their "mizapf" so they can use MESS again?)


I'm spoken for by the Apple II and Mac drivers. Curt's got Commodore, Atari ST and NeXT has OG, X68000 and FM Towns are all Barry, Carl is the PC wizard, and so on.

Originally Posted By tpreitzel
Interestingly, you very noticeably overlooked the impact of these malfunctioning drivers on potential USERS of MESS and concentrated on one maintainer who rescued and enhanced ONE bit-rotting driver.


On the contrary, most of us that maintain home computer drivers in MESS do so because we love and use those machines, and we want to see them get their best possible presentation in the project. The ability to make sure the emulation picks your specific nits as a user is of course very nice as well smile
Posted By: judge

Re: 0.147 is out - 10/09/12 05:56 PM

And I just work on systems no one gives a damn about wink
Posted By: R. Belmont

Re: 0.147 is out - 10/09/12 05:58 PM

Technically that's Kale ;-)
Posted By: judge

Re: 0.147 is out - 10/09/12 06:01 PM

AnnaWu cares about those wink
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 07:57 AM

Originally Posted By mizapf
Originally Posted By tpreitzel
How long did potential USERS of the TI driver have to abandon MESS due to the bit-rotting driver?

Users of the MESS TI emulation kept using version 0.97 while MESS had already advanced to 0.114. This was the time when I started to repair it.

The others switched to other emulators.

Michael



As long as those users didn't upgrade their operating systems to newer versions of GCC or have to recompile MAME/MESS. wink At least, you're honest.
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 08:01 AM

Originally Posted By Haze
Originally Posted By tpreitzel
Originally Posted By R. Belmont
I don't quite get the "people are going to die so nobody should maintain drivers" argument. You don't have to outlive the project, just Micko's and Aaron's final core style consolidations and any major bugs in the driver.

As usual when this situation pops up, I point to mizapf, who went from wondering why the TI drivers were decaying to making them best-in-breed in emulation quality, add-on peripheral support, and modernized code. It's true that he's probably not immortal, but the drivers are in far, far better shape than if he hadn't bothered.


So, can currently former users of the Color Computer drivers in MESS expect you to become their "mizapf" so they can use MESS again? Great! Are you taking requests for additional peripheral support as well? wink Interestingly, you very noticeably overlooked the impact of these malfunctioning drivers on potential USERS of MESS and concentrated on one maintainer who rescued and enhanced ONE bit-rotting driver. How long did potential USERS of the TI driver have to abandon MESS due to the bit-rotting driver? How many other drivers are bit-rotting while waiting for their "mizapf" to rescue them and their potential USERS?


Abracadabra, is that you?

Better testing won't stop drivers 'rotting' because things will break which people can't just wave a magic wand and fix.

Things will often break because they were done wrong in the first place, and can ONLY be fixed if somebody with a better understanding of the system comes along, however long that takes.

GiJoe in MAME for example has some broken graphics for maybe 5 years now because a certain amount of code had to be removed / disabled because it was abusing the entire MAME system to do a special effect, I don't know what the holy hell the original code was meant to be doing but it was touching all sorts of things it shouldn't have been touching (performing graphic operations on what should be the *private* tilemap cache via all sorts of abuse). It will remain broken until somebody comes along and fixes it properly, you can't just revert the change that broke it because safeguards have been put in place to prevent the very thing that it was doing and prevent further abuse of the system.

There was another game (can't remember title) which broke for a significant amount of time too when the various Address Bus Errors were implemented on the 68k core. Turns out the game had protection that nobody noticed before and tripped Address Errors if the checks failed. Without the (correct) emulation of the Bus Errors the game worked fine, with the Bus Error emulation we had to wait until somebody could reverse engineer the code well enough to simulate the protection before it worked again. Holding back genuine fixes because they broke one game wouldn't have been realistic.

Trolling won't help. One day it will be fixed, but until it is you'll just have to use an older version.


Of course, enhanced testing will improve the mess with MESS and please spare me the trolling nonsense. Furthermore, see my response to mizapf... using OLDER versions of MESS isn't always possible especially on GNU/Linux which I won't be abandoning any time soon. wink I wouldn't even have attempted upgrading MESS if my older version wasn't buggy also. Apparently, for the user of MAME/MESS, it's a choice of which bugs to tolerate due to the lack of adequate testing.
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 08:04 AM

Originally Posted By R. Belmont
Originally Posted By tpreitzel
So, can currently former users of the Color Computer drivers in MESS expect you to become their "mizapf" so they can use MESS again?)


I'm spoken for by the Apple II and Mac drivers. Curt's got Commodore, Atari ST and NeXT has OG, X68000 and FM Towns are all Barry, Carl is the PC wizard, and so on.

Originally Posted By tpreitzel
Interestingly, you very noticeably overlooked the impact of these malfunctioning drivers on potential USERS of MESS and concentrated on one maintainer who rescued and enhanced ONE bit-rotting driver.


On the contrary, most of us that maintain home computer drivers in MESS do so because we love and use those machines, and we want to see them get their best possible presentation in the project. The ability to make sure the emulation picks your specific nits as a user is of course very nice as well smile


Cute ... not. Your rather arrogantly silly reply just reinforces your previous comments where you clearly don't really give a damn about the users of MAME/MESS, just maintaining the status quo where the lack of quality due to insufficient testing of MAME/MESS is CLEARLY evident.
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 08:05 AM

Originally Posted By judge
And I just work on systems no one gives a damn about wink


Nathan, you're one of few dedicated and helpful developers of MESS. Thanks for all your past and future work.
Posted By: Haze

Re: 0.147 is out - 10/10/12 08:33 AM

Originally Posted By tpreitzel

Of course, enhanced testing will improve the mess with MESS and please spare me the trolling nonsense. Furthermore, see my response to mizapf... using OLDER versions of MESS isn't always possible especially on GNU/Linux which I won't be abandoning any time soon. wink I wouldn't even have attempted upgrading MESS if my older version wasn't buggy also. Apparently, for the user of MAME/MESS, it's a choice of which bugs to tolerate due to the lack of adequate testing.


So how do you propose better testing solve the issues I mention? It wouldn't, and very often breakages have nothing at all to do with 'inadequate testing'

The ones which are down to inadequate testing /usually/ get fixed pretty quickly, the deeper issues, for which there is no quick fix are the ones which linger.

That isn't a hard and fast rule (some stuff does get overlooked) but for long term breakages it's by far the most common case.
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 08:33 AM

Lastly, REGRESSIONS don't occur in MAME/MESS due to the lack of maintainers. REGRESSIONS occur in releases due to inadequate testing ... LoL .. wink
Posted By: Osso

Re: 0.147 is out - 10/10/12 08:34 AM

Originally Posted By tpreitzel
Originally Posted By judge
And I just work on systems no one gives a damn about wink


Nathan, you're one of few dedicated and helpful developers of
MESS. Thanks for all your past and future work.


At least get the facts straight. Judge isn't Nathan.

Wilbert Pol = Judge

Nathan Woods = Bletch
Posted By: etabeta78

Re: 0.147 is out - 10/10/12 08:41 AM

except he's Wilbert Pol, not Nathan...

and your 'enhanced testing' makes basically no sense. Robert Gault has been the most active tester we had about CoCo issues (and we tried to fix all the reported ones, whenever we were capable of), and still he did not even had the program which shows the bug you reported.
how would you suggest to perform, before each release, the testing of thousands of pieces of software for each emulated system, when some of them do not even show the bug unless you trigger very specific actions?


finally, from the rest of your reply to Arbee's comment, the only thing which is "CLEARLY evident" is that you don't know what you're talking about.
so we can move on, and hope someone with CoCo knowledge and C++ skill appears...
Posted By: Haze

Re: 0.147 is out - 10/10/12 08:42 AM

Originally Posted By tpreitzel
Lastly, REGRESSIONS don't occur in MAME/MESS due to the lack of maintainers. REGRESSIONS occur in releases due to inadequate testing ... LoL .. wink


false

even just the other day hap has decided that my way of making tri-sports work in MAME isn't correct, and has removed the code, which at the time I thought was a decent solution, in retrospect, it probably wasn't.

quite a few regressions occur *intentionally* with full knowledge of the developers due to fixing other things, and not having a clean way to deal with them.

the single pixel offset for one of the layers in Boulderdash with MAME is the same, it's an odd case which defies the logic set by everything else, I don't want to kludge it, so it regresses until it's better understood, it uses the same chips as everything else, it should work the same, not rely on it's own implementation as it was doing before.

discrete sound simulation was the same, a lot of people moaned when samples were dropped from certain drivers, because the discrete sound at the time didn't sound as good. these days the majority of the implementations of matured to a point where they surpass the samples. It was an intentional 'regression'.

Posted By: Anna Wu

Re: 0.147 is out - 10/10/12 08:44 AM

Is it possible to continue the discussion in a separate thread? smile
It is not 0.147 release specific.
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 08:44 AM

Originally Posted By Osso
Originally Posted By tpreitzel
Originally Posted By judge
And I just work on systems no one gives a damn about wink


Nathan, you're one of few dedicated and helpful developers of
MESS. Thanks for all your past and future work.


At least get the facts straight. Judge isn't Nathan.

Wilbert Pol = Judge

Nathan Woods = Bletch


My mistake as it's been awhile since I've looked at the mess with MESS so thanks for the correction. Unlike many of you, I rarely stay current with developments of MESS and the reasons should be obvious. I really want other alternatives to MESS on GNU/Linux. Hopefully, VCC will soon gain Coco 1/2 emulation... My specific thanks to Nathan still stands. Is Nathan still a developer of MESS?
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 08:50 AM

Originally Posted By etabeta78
except he's Wilbert Pol, not Nathan...

and your 'enhanced testing' makes basically no sense. Robert Gault has been the most active tester we had about CoCo issues (and we tried to fix all the reported ones, whenever we were capable of), and still he did not even had the program which shows the bug you reported.
how would you suggest to perform, before each release, the testing of thousands of pieces of software for each emulated system, when some of them do not even show the bug unless you trigger very specific actions?


finally, from the rest of your reply to Arbee's comment, the only thing which is "CLEARLY evident" is that you don't know what you're talking about.
so we can move on, and hope someone with CoCo knowledge and C++ skill appears...
)

Like loading of a disk for example? wink Actually, your comments illustrate that YOU and the rest of the current developers of MAME/MESS don't know how to implement adequate testing so you falsely attack the messenger.
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 08:59 AM

Originally Posted By Haze
Originally Posted By tpreitzel
Lastly, REGRESSIONS don't occur in MAME/MESS due to the lack of maintainers. REGRESSIONS occur in releases due to inadequate testing ... LoL .. wink


false

even just the other day hap has decided that my way of making tri-sports work in MAME isn't correct, and has removed the code, which at the time I thought was a decent solution, in retrospect, it probably wasn't.

quite a few regressions occur *intentionally* with full knowledge of the developers due to fixing other things, and not having a clean way to deal with them.

the single pixel offset for one of the layers in Boulderdash with MAME is the same, it's an odd case which defies the logic set by everything else, I don't want to kludge it, so it regresses until it's better understood, it uses the same chips as everything else, it should work the same, not rely on it's own implementation as it was doing before.

discrete sound simulation was the same, a lot of people moaned when samples were dropped from certain drivers, because the discrete sound at the time didn't sound as good. these days the majority of the implementations of matured to a point where they surpass the samples. It was an intentional 'regression'.



Wow, just wow. So you're admitting that some of the developers don't really know the full extent of the ramifications of their tinkering on MAME/MESS BEFORE they make such changes. No, I'm right. REGRESSIONS are occurring because of inadequate design prior to tinkering with the code and inadequate testing after tinkering with the code. You just fully admitted that fact. What was an intentional 'regression', the tinkering or the unknown effects of the tinkering? Wowzers!
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 09:02 AM

Originally Posted By Anna Wu
Is it possible to continue the discussion in a separate thread? smile
It is not 0.147 release specific.


Maybe, it's not just SPECIFIC to 0.147, but it's certainly specific to ALL MAME/MESS releases as it addresses the issue of inadequate testing which is long outstanding.
Posted By: Haze

Re: 0.147 is out - 10/10/12 09:09 AM

Originally Posted By tpreitzel

Wow, just wow. So you're admitting that some of the developers don't really know the full extent of the ramifications of their tinkering on MAME/MESS BEFORE they make such changes. No, I'm right. REGRESSIONS are occurring because of inadequate design prior to tinkering with the code and inadequate testing after tinkering with the code. You just fully admitted that fact. What was an intentional 'regression', the tinkering or the unknown effects of the tinkering? Wowzers!


Correct, maybe you should try writing an emulator with the scope of MAME / MESS, getting all the pieces to fit together is hard. If you're only doing one or two things on a smaller scale (like emulating JUST the CoCo) you can get away with a lot of hacks and wrong behavior without even noticing it, because the CoCo alone doesn't care. It doesn't mean your code is good / better, it just means you don't notice the ways in which it is wrong.

That's why the most mature stuff is also the most stable.

Regressions can be good, they reveal your edge cases, and areas which will need more investigation in the future.

I'm currently in the process of unifying 20 odd different implementations of the same Sprite chip for Video System games, each one slightly incomplete in it's own way because the specific game it was written for didn't use all the functionality and bad assumptions were made.

Will there be regressions, almost certainly. Will it eventually lead to a better single, much more trusted *complete* implementation, yes, yes it will. Will users see every bit of work in progress in the live code, again, yes.

However, it's not inadequate testing if we already fully know of the regressions and accept them as part of the ongoing progress.
Posted By: mizapf

Re: 0.147 is out - 10/10/12 10:11 AM

Ehm ... I seem to have forgotten what are we trying to sort out in this thread.

Is there any suggestion what we should change or where things are inadequate? Apart from telling people that the only reasonable kind of programming is test-oriented programming or whatever?

Michael
Posted By: tpreitzel

Re: 0.147 is out - 10/10/12 10:28 AM

Originally Posted By mizapf
Ehm ... I seem to have forgotten what are we trying to sort out in this thread.

Is there any suggestion what we should change or where things are inadequate? Apart from telling people that the only reasonable kind of programming is test-oriented programming or whatever?

Michael


No worry. I'm out of this thread and likely MAME/MESS in the not too distant future. Due to recurring problems with MESS, I decided to look at more alternatives than merely the Windows-based VCC for the Color Computer 3. I just compiled and installed XRoar on Slackware64 which seems to be a more than acceptable alternative to the CoCo 2 driver for MESS. Although I don't really care for running two separate emulators for the Color Computer, the alternative is clearly worse. Ciao and good luck with MESS!
Posted By: Robbbert

Re: 0.147 is out - 10/10/12 11:54 AM

Yeah, bye bye.
Posted By: Just Desserts

Re: 0.147 is out - 10/10/12 12:12 PM

Originally Posted By tpreitzel
No worry. I'm out of this thread and likely MAME/MESS in the not too distant future.


You won't be missed.
Posted By: R. Belmont

Re: 0.147 is out - 10/10/12 12:35 PM

Originally Posted By tpreitzel

Originally Posted By rbelmont
On the contrary, most of us that maintain home computer drivers in MESS do so because we love and use those machines, and we want to see them get their best possible presentation in the project. The ability to make sure the emulation picks your specific nits as a user is of course very nice as well smile


Cute ... not. Your rather arrogantly silly reply just reinforces your previous comments where you clearly don't really give a damn about the users of MAME/MESS, just maintaining the status quo where the lack of quality due to insufficient testing of MAME/MESS is CLEARLY evident.


So the part where I volunteer my time to ensure that drivers for computers I USE are top quality is somehow proof that I hate users? LOL.

PS: Your beloved Nathan caused the error you're talking about about when he rewrote CoCo from scratch in November of 2011. Robert Gault found all the serious regressions from that back at that time; this particular error isn't due to core changes or any of the "normal" regression vectors. Assuming you actually understand the CoCo h/w you probably could've fixed it in the time you've spent arguing with people here.
Posted By: Tafoid

Re: 0.147 is out - 10/10/12 12:38 PM

Originally Posted By tpreitzel
Originally Posted By Osso
Originally Posted By tpreitzel
Originally Posted By judge
And I just work on systems no one gives a damn about wink


Nathan, you're one of few dedicated and helpful developers of
MESS. Thanks for all your past and future work.


At least get the facts straight. Judge isn't Nathan.

Wilbert Pol = Judge

Nathan Woods = Bletch


My mistake as it's been awhile since I've looked at the mess with MESS so thanks for the correction. Unlike many of you, I rarely stay current with developments of MESS and the reasons should be obvious. I really want other alternatives to MESS on GNU/Linux. Hopefully, VCC will soon gain Coco 1/2 emulation... My specific thanks to Nathan still stands. Is Nathan still a developer of MESS?


Yes, Nathan is just not as active as he once was as MESS Lead Coordinator. Ironically, Nathan was the one to completely rewrite the COCO family driver and associated drivers nearly a year ago (11/15/2011) - causing a few regressions which may be related to your problems you are having. In any case, proper bug reports have been made (Thanks for R. Gault) and it is of no benefit to continue pound home the fact that something isn't working 100% or whining about not being able to determine it was regression in behavior in the first place.

While the project appreciates all positive feedback and valid bug reports that might come to light, we (those who test/develop/use the project regularly) do NOT appreciate the constant threatening "fix it or else" phrasing which seems to surround all your posts. You've done this more than once at this forum and were harping on MESS over 3 year ago about other coco issues.

I'd say.. make friends with the door.
Posted By: Haze

Re: 0.147 is out - 10/10/12 12:49 PM

So essentially there were problems in driver before said user bitched about.

Nathan probably looked at the driver, realised it was ancient MESS code, from the time when MESS drivers really weren't very good, weren't very flexible or extensible, and couldn't just be 'fixed' so rewrote it.

Rewriting something is a major undertaking, and is bound to introduce new issues while solving other ones but often it's needed in order to actually open the driver up to further progress, progress which evidently hasn't happened yet.

Sometimes you just have to commit yourself to one direction if you're to make any progress at all, that appears to have been the case here.

So yes, I'd say it comes down more to lack of active developers with an interest in taking that progress further, with the last person who touched it being mostly inactive.
© 2020 Forums