Active Threads

Active Threads | Active Posts | Unanswered Today | Since Yesterday | This Week

Re: Netlist: 280-ZZZAP sound problems Colin Howell 07/16/20 06:40 AM

I tried your suggestion, Aaron, and it does work for clamping the output to following stages. cleaning up the glitchy sounds. So that is a potential workaround for now. Thanks for the tip.

In the long term, something more thorough is necessary, both because the out-of-range voltages will still feed back to the op-amp inputs and thus affect the op-amp circuit's own behavior, and because it is wasteful to include components like the voltage-limiting diodes within the op-amp model if they don't actually perform the function they're supposed to.

52 3,661 Read More

MAME

Re: SVN builds - new driver flood Duke 07/15/20 10:46 PM

Well it writes to the MIDI register which we don't handle at all currently. It might wait for an interrupt from it.

5,335 15,659,402 Read More

Non-Windows MAME Support

MAME Linux documentation Stiletto 07/15/20 10:39 PM

MAME's Linux documentation - aka the MAN files:
https://github.com/mamedev/mame/tree/master/docs/man

Could one of our friendly Linux devs or package maintainers please check that the MAN files are still in sync with https://github.com/mamedev/mame/tree/master/docs/source / https://docs.mamedev.org/
at some point? And if not, re-sync them?

It doesn't need to be right away, but it would be nice to know if they were in sync. We do have people who tend to look after such things but most of them are Windows users.

0 17 Read More

MAME

Re: Netlist: 280-ZZZAP sound problems AaronGiles 07/15/20 09:41 PM

As a quick hack have you tried using an AFUNC to hard-limit to the output?

AFUNC(LIMITER, 1, "max(min(A0, <rail_voltage>), 0)")
NET_C(LIMITER.A0, <opamp_output>)
NET_C(LIMITER.Q, <downstream_connections>)

It may not work (as I discovered) if there is feedback between multiple AFUNCs, as they will eventually force a super-small timestep, but for one-off cases it could be something to experiment with.

52 3,661 Read More

MAME

Re: SVN builds - new driver flood Haze 07/15/20 08:28 PM

re: Sam Coupe, I'm still curious about what one of the few cassette dumps we have actually needs (snare in the software list) or if it's simply just a bad dump.

5,335 15,659,402 Read More

MAME

Re: SVN builds - new driver flood Duke 07/15/20 08:18 PM

I've committed the bulk of the Sam Coupe changes. Here's an example how to use the Atom HDD interface:

1. Create suitable CHD. For example, use the "Conner CFA170A" template:

Code

chdman createhd -tp 0 -o samhdd.chd

2. Load MAME with the Atom BIOS, attach Atom interface (and Dallas clock interface) and HDD, boot BDOS 1.5a floppy:

Code

mame64 samcoupe -bios atom -drive2 atom -drive2:atom:ata:0 hdd -flop1 bdos15a.dsk -hard samhdd.chd -exp dallas

We can then load the "formatter" tool:

[Linked Image from i.imgur.com]

The HDD is now usable and basically functions the same as 210 floppies (in this case). To make it bootable we can use the "makeboot" tool:

[Linked Image from i.imgur.com]

To copy the whole bdos15a disk to HDD we can use "copy record 0 to record 1".

After shutting down MAME we can now run it with just the HDD and it will boot it:

Code

mame64 samcoupe -bios atom -drive2 atom -drive2:atom:ata:0 hdd -hard samhdd.chd -exp dallas

In theory this interface also supports CD-ROMs, and you would be able to copy disk images from CD to the HDD, but once you attach one the HDD/CD detection will hang in an infinite loop. The detection code seems really basic (too basic), so I'm not sure how it works on real hardware.

5,335 15,659,402 Read More

MAME

Re: Netlist: 280-ZZZAP sound problems Colin Howell 07/15/20 07:48 PM

So, there's one problem here. Unfortunately, it's a big one, not just with 280-ZZZAP but with op-amps in general in the netlist system.

With the zener noise now being strong enough to saturate the op-amp, what should be happening is that the op-amp's output would be "rail-to-rail": its voltage should be swinging abruptly from values near the power supply voltage to values near the ground voltage, with little time spent in between. This is because the op-amp is amplifying the input noise with practically its full open-loop gain, a factor of several thousand times.

The problem is that in the netlist emulation, the output frequently swings far *beyond* rail-to-rail, producing voltages spikes up to hundreds of volts in magnitude, which is blatantly unphysical. It does this despite the fact that the op-amp model includes specifications which are supposed to limit how closely the output voltage can approach either power rail (power and ground, in this case). These specifications simply aren't working effectively.

The resulting extreme voltages propagate through the rest of the circuit, causing objectionable noise and probably convergence problems as well.

Looking at the details of the op-amp model, it seems that voltage limiting is implemented with a pair of internal diodes associated with the upper and lower power rails, using a model borrowed from the Output Voltage Limiting page in the discussion of op-amps at eCircuit Center. These diodes should divert voltages in excess of the output limits. The trouble with using this model here is that it assumes the gain module G1 (a voltage-controlled current source) can only produce up to a certain maximum amount of current, when one of the amplifier's input transistors is fully on and the other is fully off. The limiting diodes can then be appropriately sized to pass that current in the worst case. But in the netlist implementation, there is no mechanism to limit the gain module's current in that way. The diode can simply be overwhelmed, and the output voltage will not be limited at all.

I noticed the netlist library includes an "LVCCS" (limited voltage-controlled current source), which would seem to be what is required, but this is not presently used by anything. Just as a test, I hacked the op-amp model to use the LVCCS for G1, and set its CURLIM parameter to a low value to see what would happen. The op-amp did limit its voltage better (there were still spikes in the output, but much shorter ones). Unfortunately, performance also went into the toilet, the speed dropping by a factor of 4 or 5.

So we still need to come up with a more reasonable means of effectively limiting op-amp output voltage.

52 3,661 Read More

MAME

Re: Netlist: 280-ZZZAP sound problems R. Belmont 07/15/20 12:33 PM

Neat. Can't wait to hear it.

52 3,661 Read More

MAME

Re: Netlist: 280-ZZZAP sound problems Colin Howell 07/15/20 05:15 AM

OK, I am now certain I made 280-ZZZAP's noise *far* too weak.

All that time messing around with Gun Fight again, which also uses a zener-diode noise generator, taught me quite a bit about how noise is generated with a "zener" (really an avalanche diode) and roughly how strong you can expect that noise to be for a given zener current. Gun Fight runs around 2 microamps of current through its zener and probably gets a few millivolts of noise from that. 280-ZZZAP runs about 25 microamps of current through its zener and so should probably get tens of millivolts of noise The noise figure I used for 280-ZZZAP is 10 *microvolts*, three orders of magnitude too low.

In 280-ZZZAP the zener noise is amplified by an LM3900 Norton op-amp, not by a simple transistor-based common-emitter amplifier as in Gun Fight. I mistakenly assumed that the noise generated was intended to be relatively undistorted by that op-amp, and based on that I figured an upper limit on the strength of the noise. The truth appears to be the opposite: the noise is expected to *completely saturate* the op-amp, which converts it into a rail-to-rail, quasi-digital noise signal. In retrospect, this makes a lot more sense, given that zener (avalanche) diodes are extremely variable in the strength of their noise, even within the same batch. This saturated op-amp setup must have been a way of getting a more controlled, predictable noise signal regardless of the particular zener's qualities. (Eventually, people switched to the even more predictable linear-feedback shift register type of digital "noise" generator.) Once the saturated rail-to-rail noise is generated, the subsequent filters convert it into the desired forms for sounds.

With the zener's noise cranked up into the millivolts range, the skid noise becomes quite prominent, and there's much more low-frequency rumble on the crash, not just the extreme bass "thump". The post-crash noise is still a peculiar screech, but that's true on real machines too—it's hard to figure out what the designer was thinking with that one.

52 3,661 Read More

MAME

Re: Gun Fight: effects of final amplification Colin Howell 07/14/20 11:28 PM

Just submitted a PR for my Gun Fight improvements. Took me bloody long enough.

In retrospect, I spent too much time and effort going down the avenue described above. I've pretty much punted the issue, other than explaining it in source comments. What's there already works pretty well. The issue may be worth revisiting later if more detailed info becomes available on Gun Fight's noise generator voltage and how its power amplifiers, speakers, and cabinet behave, together with an infrastructure better able to use such info. But for now, this is good enough.

couriersud's points are valid, but I really didn't intend to get into details of modeling speaker, cabinet, and microphone acoustics. Mostly I was looking for a sanity check on my thoughts.

Also, one needs to be careful modeling circuits in LTspice. Turns out my noise generation was a bit off: it was using a uniform distribution instead of a normal one.

3 353 Read More

MAME

Re: Fairlight CMI SynaMax 07/14/20 10:33 PM

That makes sense about the interrupts. It seems to be a lot more stable than the MESS build; I don't get anymore errors about file tabbing and Page R finally plays patterns, so that's awesome! Also, having MAME control the CMI via MIDI would be absolutely incredible so I'm glad that's an option.

The two other things that I would like to add for issues are:
- Incorrect sample looping
- Microphone support for Page 8

When I load a sample into memory and I play it via Page R, the sound loops incorrectly and plays forever.

I can't seem to find anything online to answer this question, so I figured I'll ask here: does MAME support microphone input?

85 24,122 Read More

MAME

Re: Fairlight CMI Just Desserts 07/13/20 09:41 PM

I actually forget which specific change it was that I made. I believe it had something to do with interrupts.

At the time those screenshots were posted, the driver still had a number of problems. One of the worst was that performance would tank down to about 10-20% of full speed on my beastly system whenever the display was updated.

I've done a complete re-write of how memory mapping is handled since then, and so performance is no longer so much of an issue. Now, the issues are as follows, in no particular order:
- No envelope ramping support.
- No filter support.
- Potentially incorrect pitch.
- No SMIDI support.
- No AIC support.

The first three are the most important for it to sound good, and the SMIDI card is the most important for it to be usable from an end user's standpoint. Since MAME supports plumbing emulated MIDI ports to actual MIDI interfaces on the host machine, this would be the most expeditious way of making it usable as an actual CMI IIx emulator.

I haven't had much luck with envelope ramping support, but Phil has said he'll look into it soon-ish.

85 24,122 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child 07/13/20 09:32 PM

Hi AJR,

I've been reading the upd7810 datasheet and yes, you're right, the NMI shouldn't get stopped by the iff (interrupt enable flip flop).

I did come across this while trying to understand the interrupt flags:

It looks like the INTOV flag is kept in the IRR but it gets set in the ITF.

Code

grep INTOV src/devices/cpu/upd7810/ -r
src/devices/cpu/upd7810/upd7810_opcodes.cpp:	if (IRR & INTOV)
src/devices/cpu/upd7810/upd7810_opcodes.cpp:	IRR &= ~INTOV;
src/devices/cpu/upd7810/upd7810_opcodes.cpp:	if (0 == (IRR & INTOV))
src/devices/cpu/upd7810/upd7810_opcodes.cpp:	IRR &= ~INTOV;
src/devices/cpu/upd7810/upd7810.h:		INTOV   = 0x1000,
src/devices/cpu/upd7810/upd7810.cpp:					ITF |= INTOV;   /* set overflow flag if counter wrapped */

550 115,737 Read More

MAME

Re: Fairlight CMI SynaMax 07/13/20 06:06 PM

OMG, yes! Excellent work, JD! How did you get the system disk to boot?

85 24,122 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child 07/13/20 11:26 AM

Thanks guys for having a look, I don't think there's a quick fix to the ap2000.

I wanted to make sure that it's getting data from the parallel port, and it didn't seem to be getting data.

It seemed to have a lot of trouble with the m_centronics_busy check so after removing the check, it would get data.

Code

WRITE_LINE_MEMBER( e05a30_device::centronics_input_strobe )
{

//       if (m_centronics_strobe == true && state == false && !m_centronics_busy) {
   if ((state == false) && (m_centronics_strobe == true)) {

         printf("ACCEPT_STROBE **** Strobe %x\n",m_centronics_data);

                m_centronics_data_latch   = m_centronics_data;
                m_centronics_data_latched = true;
                m_centronics_busy         = true;
                m_write_centronics_busy(m_centronics_busy);
        }

        m_centronics_strobe = state;
}

Adding a few prints to see if the ap2000 is reading the data:

Code

uint8_t e05a30_device::read(offs_t offset)
 
        switch (offset) {
        case 0x02:
                result = m_centronics_data_latched << 7;
+                printf("0x02 CENTRONICS DATA LATCHED === %x     %s\n",m_centronics_data_latched,machine().describe_context().c_str());
                break;
        case 0x03:
+                printf("0x03 CENTRONICS DATA LATCH === %x     %s\n",m_centronics_data_latch,machine().describe_context().c_str());
                result = m_centronics_data_latch;
                m_centronics_data_latched = false;
                break;

but the ap2000 would grab a couple of bytes and then happily run off into the weeds...where it hangs on JR FF which is an infinite loop.

After typing PR#1

Code

ACCEPT_STROBE **** Strobe 8d  enter
ACCEPT_STROBE **** Strobe 8a  linefeed
ACCEPT_STROBE **** Strobe dd  ] basic prompt
ACCEPT_STROBE **** Strobe c1  A
ACCEPT_STROBE **** Strobe c1  
ACCEPT_STROBE **** Strobe c1
ACCEPT_STROBE **** Strobe c1
ACCEPT_STROBE **** Strobe c1
ACCEPT_STROBE **** Strobe cf   O    hitting O and L trying to get online
ACCEPT_STROBE **** Strobe cc  L
0x02 CENTRONICS DATA LATCHED === 1     ':sl1:parallel:pic_ctx:ap2000:maincpu' (2096)
0x02 CENTRONICS DATA LATCHED === 1     ':sl1:parallel:pic_ctx:ap2000:maincpu' (209C)
0x03 CENTRONICS DATA LATCH === cc     ':sl1:parallel:pic_ctx:ap2000:maincpu' (209C)

yay it did get a single byte!

0x02 CENTRONICS DATA LATCHED === 0     ':sl1:parallel:pic_ctx:ap2000:maincpu' (2096)
0x02 CENTRONICS DATA LATCHED === 0     ':sl1:parallel:pic_ctx:ap2000:maincpu' (2096)
0x02 CENTRONICS DATA LATCHED === 0     ':sl1:parallel:pic_ctx:ap2000:maincpu' (2096)
0x02 CENTRONICS DATA LATCHED === 0     ':sl1:parallel:pic_ctx:ap2000:maincpu' (2096)

Changing the code to make the block a different color based on m_online_led shows it flickering like crazy.

[Linked Image from i.imgur.com]

red here, also comes in green [Linked Image from i.imgur.com]

Code

uint32_t epson_lx810l_device::screen_update_lx810l(screen_device &screen, bitmap
        copyscrollbitmap(bitmap, m_bitmap, 0, nullptr, 1, &scrolly, cliprect);
 
        /* draw "printhead" */
-       bitmap.plot_box(m_real_cr_pos + CR_OFFSET - 10, PAPER_HEIGHT - 36, 20, 36, 0x888888);
+
+       bitmap.plot_box(m_real_cr_pos + CR_OFFSET - 10, PAPER_HEIGHT - 36, 20, 36, m_online_led ? 0x008800 : 0x880000);
 
        return 0;
 }

So, no joy in Mudville... 8-)

550 115,737 Read More

MAME

Re: TMS-09xx/1xxx thread (was New Dumps) Mr. Do 07/13/20 12:30 AM

Originally Posted by Haze

Originally Posted by Just Desserts

Originally Posted by AJR

The supposedly bugfixed purple version of Judge doesn't seem to have been preserved yet.

Correct. Likewise, a bugfixed alternate version of (I think) Chef is also not preserved.

The good news is that the bugfixed version of Judge is in a different case color, and so should be relatively easy to track down if anyone is willing to put in the time. The bad news is that the bugfixed version of Chef requires opening the case and reading the marking on the chip package, which I doubt any seller would be willing to do.

I was aware of Judge and Helmet, what's meant to be fixed in Chef?

For Helmet, I thought we had the fixed version (or am I mistaken) so low serial number Japanese originals are probably going to have the buggy version.

I think Helmet is what JD was thinking of. And correct... we have the fixed version today... the only way to tell 100% is by checking inside the case; the pcb for the one we need will be marked CN-07, instead of CN-17 (bugfix).

And just to expand a bit on what hap mentioned:

Judge... just need to find a purple one.

Egg... the SVG on this one is really poor, plus the ROM dump needs to be verified, and to make sure the background overlay is indeed the same as Mickey Mouse.

Table-Top Cement Factory... need the one with the "not Queen" startup music.

3,627 2,257,757 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS AJR 07/12/20 05:48 PM

I might not be able to for a while, since my development machine is now on its last legs. I do think my change here is logically correct: NMI should be nonmaskable.

Code analysis: NMI is sourced from the E05A30, which asserts it (once) in device_reset. NMIs at reset have been known to cause problems with other CPUs (e.g. sdk85), because the internal flipflop will be set by the (synced) transition after the CPU's device_reset has already finished. Behavior may not be accurate in this particular case anyway.

550 115,737 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS R. Belmont 07/12/20 05:04 PM

I've tagged the change to the upd7810 interrupt behavior so AJR can take a look.

550 115,737 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child 07/12/20 03:23 PM

Fiddling with the ap2000, I was able to get the printer to have the moving block by changing this line in upd7810.cpp, there was quite a bit of change between 219 and 220 in upd7810 that seemed to make it stop working. I have no idea what this breaks, but at least it shows activity.

It just puts that line back to the way it was in 219.

Unfortunately, it still doesn't seem to get any data.

Code

git diff src/devices/cpu/upd7810/upd7810.cpp
diff --git a/src/devices/cpu/upd7810/upd7810.cpp b/src/devices/cpu/upd7810/upd7810.cpp
index bd459b2f141..25ac83fa794 100644
--- a/src/devices/cpu/upd7810/upd7810.cpp
+++ b/src/devices/cpu/upd7810/upd7810.cpp
@@ -749,7 +749,8 @@ void upd7810_device::upd7810_take_irq()
        int irqline = 0;
 
        /* global interrupt disable? */
-       if (0 == IFF && !(IRR & INTNMI))
+        if (0 == IFF)
+//     if (0 == IFF && !(IRR & INTNMI))
                return;
 
        /* check the interrupts in priority sequence */

550 115,737 Read More

MAME

Re: SVN builds - new driver flood Just Desserts 07/12/20 04:44 AM

Just a small update, I've managed to fix the issues that were ailing the V.Smile controller. It now works in every game I've tested, including all of the games previously flagged in vsmile_cart.xml as "no inputs" which use a standard controller.

5,335 15,659,402 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child 07/11/20 08:42 PM

Hi RB,

I haven't pulled for a week or so, but it's at least 222.

Code

mame 0.222	
Copyright (C) Nicola Salmoria and the MAME team

Debug Build: Disabling input grab for -debug
[MAME]> at93c06 NOT FOUND (NO GOOD DUMP KNOWN) (tried in ap2000 apple2p apple2)
WARNING: the machine might not run correctly.

MAME debugger version 0.222 (mame0222-276-g4999038a1c9-dirty)
Currently targeting apple2p (Apple ][+)
[MAME]> 

>g
[MAME]> Segmentation fault (core dumped)

550 115,737 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS R. Belmont 07/11/20 08:04 PM

Have you tried it on latest? Several crashes in BGFX (especially related to tearing down a context and opening a new one) were fixed for 0.222.

550 115,737 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child 07/11/20 07:32 PM

Thanks for having a look, RB.

While fiddling around, I was changing the video options while having the dual screens active for the apple and the ap2000, and noticed that changing the screen from left to right, then single, then back again would give a segfault under -video bgfx and would be fine under -video soft or -video opengl. (Running under Ubuntu 19.10)

[Linked Image from i.imgur.com]

change to single (screen 0)
[Linked Image from i.imgur.com]

change to single (screen 1)
change back to left to right.
then segfault.

I think it happened somewhere between 214 and 215 because 215 will segfault immediately when changing screens around and 214 seems ok for me.

550 115,737 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS R. Belmont 07/11/20 11:52 AM

So the AP2000 regressed? That's too bad, I had it working a while ago. I'll have to check the git logs.

550 115,737 Read More

MAME

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child 07/11/20 10:04 AM

Hi guys,

I was fiddling around trying to get the ap2000 working on the apple2 parallel interface and couldn't get it to work. It looks like somewhere between 219 and 220 that the little printhead block stopped moving on the ap2000 when you boot.

Typing PR#1 should activate the printer but it doesn't seem to do anything.

./mame64 apple2p -sl1 parallel -sl1:parallel:pic_ctx ap2000

I tried it with the cpc6128 and got the same behavior.

./mame64 cpc6128 -centronics ap2000

[Linked Image from i.imgur.com]

By default, the keys for the ap2000 are mapped to FLEO for Form Feed / Line Feed / Eject / Online so hitting O will move the printhead from the center to the left under 219, so it's alive (at least a little 8-)

Trying the cpc6128 and typing PRINT #8,"QQQQQQ" will hang the command line until you type O but it won't print anything. Subsequent PRINT #8 will hang.

550 115,737 Read More

Page 1 of 5