Previous Thread
Next Thread
Print Thread
Page 2 of 7 1 2 3 4 5 6 7
Re: Ap2000 signs of life [Re: Golden Child] #117582 07/21/20 11:53 PM
Joined: Feb 2014
Posts: 446
G
Golden Child Offline OP
Senior Member
OP Offline
Senior Member
G
Joined: Feb 2014
Posts: 446
Making calendars with Printmaster:

(I wonder how many people in the world are still using Printmaster and Dot Matrix Printers?)

[Linked Image from i.imgur.com]

While fiddling around with the cpc6128 I did encounter a strange bug. For some reason when running with the cpc6128 some of the ap2000's input ports all of a sudden went from active low to active high. This makes the printer boot up into "Data Dump Mode" because it thinks I'm holding down the Line Feed and Form Feed buttons when it starts. It's really weird that the cpc6128's doing that, because the apple2 and the amiga don't have that problem.

I'm doing a subtarget/sources build, could that be causing a problem?

Re: Ap2000 signs of life [Re: Golden Child] #117583 07/22/20 03:48 AM
Joined: Feb 2014
Posts: 446
G
Golden Child Offline OP
Senior Member
OP Offline
Senior Member
G
Joined: Feb 2014
Posts: 446
So let's see if the ibm5150 will work with print shop.

Testing the printer gives an error.

[Linked Image from i.imgur.com]

So let's see if we can figure out where it's hanging up.

We'll set an i/o watchpoint with wpi 378,8,r and then when it hits, set al=df (ack is active low) and then printshop will continue.
After doing that we disable the watchpoint.

[Linked Image from i.imgur.com]

This diagram from art of asm shows the status register.

So going into src/devices/machine/pc_lpt.cpp and adding an xor on STATUS_ACK seems to fix the error message.
Code
int8_t pc_lpt_device::status_r()
{
        return m_cent_status_in->read() ^ STATUS_BUSY ^ STATUS_ACK;
}



[Linked Image from i.imgur.com]

Re: Ap2000 signs of life [Re: Golden Child] #117623 08/05/20 10:46 PM
Joined: Feb 2014
Posts: 446
G
Golden Child Offline OP
Senior Member
OP Offline
Senior Member
G
Joined: Feb 2014
Posts: 446
Just for fun, I thought I'd play with svgedit and inkscape to see if I could make something that looks like the control panel.

[Linked Image from i.imgur.com]

Re: Ap2000 signs of life [Re: Golden Child] #117652 08/11/20 02:38 AM
Joined: Feb 2014
Posts: 446
G
Golden Child Offline OP
Senior Member
OP Offline
Senior Member
G
Joined: Feb 2014
Posts: 446
More silly fun:

I was thinking about having the printer make some noise while it was printing and I was able to get it to squawk a little.


[video:youtube]https://youtu.be/nXu1cxIHsZc[/video]

I think my "pin-firing" detection is missing half of the pin firings so it's pretty quiet when printing some areas.

Re: Ap2000 signs of life [Re: Golden Child] #117659 08/14/20 09:41 AM
Joined: Feb 2014
Posts: 446
G
Golden Child Offline OP
Senior Member
OP Offline
Senior Member
G
Joined: Feb 2014
Posts: 446
So I wanted to see what kind of waveforms were being generated by mame audio. With ubuntu, I had to use pavucontrol to select the monitor of Built-in audio to get the system-generated sound for Audacity to record.

[Linked Image from i.imgur.com]



I did discover something interesting, that the 1-bit DAC was generating a signal when it wasn't actually doing anything. I suppose this is correct behavior, but it does answer why I am always hearing pops and crackles. When there's an audio dropout, the waveform drops to zero and there's a "click" sound.


The dac corresponds to this code:
Code

   /* audio hardware */
        SPEAKER(config, "speaker").front_center();
        DAC_1BIT(config, "dac", 0).add_route(ALL_OUTPUTS, "speaker", 0.25);
        voltage_regulator_device &vref(VOLTAGE_REGULATOR(config, "vref"));
        vref.add_route(0, "dac", 1.0, DAC_VREF_POS_INPUT);





Lowering the volume slider to zero for the 1 bit DAC makes the clicking disappear and the VU meters go down to no signal.

[Linked Image from i.imgur.com]

[Linked Image from i.imgur.com]


If you look at the recorded waveform, there's no actual sound being played, there's just a bunch of "dropouts" where other tasks are grabbing the cpu (probably because I'm doing a bunch of printf's)

Audacity's monitor shows -46 db on the VU meter.

[Linked Image from i.imgur.com]


It's interesting when I have the mockingboard enabled as there are multiple outputs which can contribute to the clicking.
If you change the volume on the different channel volumes, the biasing can constructively and destructively interfere and audacity's VU meters will go up and down.

Re: Ap2000 signs of life [Re: Golden Child] #117660 08/14/20 09:51 AM
Joined: May 2009
Posts: 1,872
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,872
Why not just use -wavwrite

Re: Ap2000 signs of life [Re: Golden Child] #117661 08/14/20 01:44 PM
Joined: Mar 2001
Posts: 16,576
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,576
The speaker click device the A2 uses simulates capacitive coupling because otherwise it was impossible to mix its output with a Mockingboard AY-3 or the GS's ES5503. After all, the definition of a speaker click device is that the voltage is either 0 or 5 volts, nothing in between.

Can we get back to what exactly made the AP2000 work? It was the NMI-at-startup and then something with the ADCs?

Re: Ap2000 signs of life [Re: R. Belmont] #117662 08/14/20 02:41 PM
Joined: Feb 2014
Posts: 446
G
Golden Child Offline OP
Senior Member
OP Offline
Senior Member
G
Joined: Feb 2014
Posts: 446
Ok, sorry I tend to go off on tangents. 8-)

I think that the NMI would be fixed if it didn't hit right as it starts up, maybe delayed by a little bit.


I found the ADC conversion wasn't timing correctly.

Making some crap macros to help me see how many cycles and how much time ran in between.

Code

#define LASTPASSDIFFERENCE(t, name, func, str) \
  static t staticlast##name; \
  t last##name = staticlast##name; \
  t diff##name; \
  t cur##name = func; \
  diff##name = cur##name - staticlast##name;  diff##name=diff##name;\
  printf(#name": "); \
  printf(str "\n",cur##name-last##name);\
  printf("\n");\
  staticlast##name = cur##name;

#define LASTPASSPRINT(name, str, item) \
  printf(str "\n",item##name);




so I could do

Code
LASTPASSDIFFERENCE(long int, ADCONVSCANEACH_CYCLES, total_cycles(), "T cycles = %ld   expected to see 192");
LASTPASSDIFFERENCE(double,  ADCONVSCAN_TIME,   machine().time().as_double(), "time = %e");
LASTPASSDIFFERENCE(long int, ADCONVSCAN_CYCLES, total_cycles(), "T cycles = %ld   expected to see 768");

LASTPASSDIFFERENCE(double,   ADCONVSCAN_TIME,   machine().time().as_double(), "time = %e");
LASTPASSDIFFERENCE(long int, ADCONVSCAN_CYCLES, total_cycles(), "T cycles = %ld   expected to see 768");
//printf("m_adcnt = %d\n",m_adcnt);
//LASTPASSPRINT(ADCONVSCAN_CYCLES, "T last = %ld", last);
//LASTPASSPRINT(ADCONVSCAN_CYCLES, "T cur = %ld", cur);
//LASTPASSPRINT(ADCONVSCAN_CYCLES, "T diff = %ld", diff);




so now I get something that looks pretty good and it fixes the super fast beeping when you press a control panel button.


Code
ADCONVSCANEACH_CYCLES: T cycles = 190   expected to see 192

ADCONVSCANEACH_CYCLES: T cycles = 195   expected to see 192

ADCONVSCANEACH_CYCLES: T cycles = 194   expected to see 192

ADCONVSCANEACH_CYCLES: T cycles = 190   expected to see 192

ADCONVSCANEACH_CYCLES: T cycles = 188   expected to see 192



I'll try to work up a patch, it doesn't change very much in the code.

Re: Ap2000 signs of life [Re: Golden Child] #117663 08/14/20 03:38 PM
Joined: Mar 2001
Posts: 16,576
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,576
Ok, that's useful, thanks!

AJR, any thoughts on the ADC timing GC observed?

Re: Ap2000 signs of life [Re: Golden Child] #117664 08/14/20 04:31 PM
Joined: Dec 2015
Posts: 119
A
AJR Offline
Senior Member
Offline
Senior Member
A
Joined: Dec 2015
Posts: 119
I'm not AWJ, but I'll add a few thoughts anyway.

If this really is a problem with inexact timing, then that exemplifies a common problem with MAME's MCU cores, many of which just execute each instruction all at once and then go back and run the timers and timer-based peripherals for the same number of cycles. This works fine for purely internal interrupt timers but often fails for more sensitive cases such as serial ports.

In the past, Vas Crabb has suggested "separate icount and bcount" as the one proper solution to this problem, but much like the modern floppy system (which at least does have some readable technical documentation), only Olivier Galibert seems to have fully mastered its implementation details. While I only half-understand how it works, I'm not convinced of its effectiveness as a solution, especially after finding that Olivier Galibert's MCS-96 core, despite having this thing called "bcount" (not defined in MAME's execution core), triggers high-speed outputs at the wrong times.

Page 2 of 7 1 2 3 4 5 6 7

Who's Online Now
0 registered members (), 48 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,814
Posts115,990
Members4,915
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.3