PPI Control port issue

[Devilmarkus]

Hello people,
while coding the brilliant Sundance demo, I found a problem running this demo on a real CPC 6128.

In every emulator I tested it, it ran fine. On the real CPC it crashed.

So I checked again my equalizer code, which reads the PSG values.

The solution: Bit 6 @ PPI control port seems to cause a reset (or similar?)

Thanks to cngsoft for your help!

Just want to show you the difference in the code:

Bad code (Works fine on emulator but lets the real CPC crash)

Code: [Select]


.read_from_psg
        ld        b,#f4
        out        (c),e
        ld        bc,#f6c0
        out        (c),c
        xor        a
        out        (c),a
        ld        bc,#f7d2
        out        (c),c
        ld        bc,#f640
        out        (c),c
        ld        b,#f4
        in        a,(c)
        ld        bc,#f7c2
        out        (c),c
        ld        bc,#f600
        out        (c),c
        ret

The good code:

Code: [Select]


.read_from_psg
        ld        b,#f4
        out        (c),e
        ld        bc,#f6c0
        out        (c),c
        xor        a
        out        (c),a
        ld        bc,#f792
        out        (c),c
        ld        bc,#f640
        out        (c),c
        ld        b,#f4
        in        a,(c)
        ld        bc,#f782
        out        (c),c
        ld        bc,#f600
        out        (c),c
        ret

[arnoldemu]

PPI is put into "mode 2" operation. Port A becomes bi-directional.
Port B and C change operation. hmmm.. vsync may trigger stuff to happen. I didn't check that.

mode 0, mode 1 and mode 2 operation are all emulated in wip of arnold. tested against 3 models of 8255 that I have.

I have emulated as much as I can, trouble is the cpc has fixed inputs so the modes don't work fully as intended. I didn't check for vsync input causing some changes, or cassette, so I may try those to see what happens.

but I've implemented as much as I can so far.

it's one of those "cpc doesn't use it so why emulate it". Why? because I want to and things like this appear

Same as I emulate the unused areas of the asic ram; emulated even better in wip of arnold too.

Time to build a binary for people to try out.

[CraigsBar]

Any chance of an osx and android binary as well as the Linux and Windows ones

[arnoldemu]

Any chance of an osx and android binary as well as the Linux and Windows ones

The code uses wxwidgets and sdl libraries.
I don't have an osx based machine so i can't test it on that but in theory it should work.

If I could get access to one and install the necessary stuff, then I could make sure it works on osx.
I was even contemplating finding an old g3/g4 which can just about have osx on it.

No chance of an android binary yet - I have access to a device but I would have to strip out the wxwidgets stuff for it.


EDIT: If anyone has a mac with osx and can help, send me a private message. i will tell you the location of the server with the source on it.
Or if anyone can help me to get an osx machine to get it working that would be great.

[CraigsBar]

I have a power Mac G5 gathering dust. I was considering selling. A nice dual core 2 ghz one with internal raid chassis and controller. But for development you'd be better with an Intel one, as that is more likely to work on new Macs. Support for ppc universal binaries is now dropped from osx.

[CraigsBar]

A Mac mini capable of running 10.8 or 10.9 won't be much second-hand if you look for the late core2 duo ones. The i5 and i7 ones are still bonkers money even 2nd hand.

[arnoldemu]

A Mac mini capable of running 10.8 or 10.9 won't be much second-hand if you look for the late core2 duo ones. The i5 and i7 ones are still bonkers money even 2nd hand.

I need to put the money into other things at the moment.

I need to do some maintenance to our house.

[SyX]

So I checked again my equalizer code, which reads the PSG values.

A few years ago, when you made me the same question, i patched your code to read the values directly from the sound player... Markus, you forget things too fast

[Devilmarkus]

I really have too many things in my vacuum-head, SyX

[CraigsBar]

I need to put the money into other things at the moment.

I need to do some maintenance to our house.

I can build you an osx server VM for use with virtualbox or vmware if you like. It'll be osx server 10.8 on virtual Intel hardware?

Craig

[SyX]

I really have too many things in my vacuum-head, SyX

And as i always tell you, you are able to do a lot more... sometimes you take the lazy/immediate way, when with enough time you can do better things as Barbarian, the mapper tool, Bing, ...

[arnoldemu]

I can build you an osx server VM for use with virtualbox or vmware if you like. It'll be osx server 10.8 on virtual Intel hardware?

Craig

that would be great. Could you make it for virtualbox please?
P.M. Me with the download details.

[Gryzor]

* Gryzor wants

[CraigsBar]

that would be great. Could you make it for virtualbox please?
P.M. Me with the download details.

If I get it done tonight I can pop it on my MacBook Pro and I am over barnsley way next week (Off the the BTCC at croft this weekend) so if you are still around sheffield way they that would save me a massive upload ;-)


Craig

[arnoldemu]

If I get it done tonight I can pop it on my MacBook Pro and I am over barnsley way next week (Off the the BTCC at croft this weekend) so if you are still around sheffield way they that would save me a massive upload ;-)


Craig

Thanks Craig. Yes I am still at the same house in Sheffield.

You will see the new paving I am putting down (to stop water going into the ground at the front and finding it's way into our cellar).

[AMSDOS]

So I was wondering if these Ports are being exposed, if emulators are emulating this stuff when it's crashing on a real machine, then perhaps a guide of Illegal Ports should be mapped?

[Executioner]

The solution: Bit 6 @ PPI control port seems to cause a reset (or similar?)

Strange, the JEMU PPI implementation isn't CPC specific and should emulate the other PPI port modes also.

[ralferoo]

The problem is most likely driving something that should be an input, which would cause a short. This could cause a reset by providing a lower resistance than the power supply of one of the drivers, which then causes that chip to stop driving and then when power is restored, the CPU would reinitialise everything back to a safe state.

It'd be hard to know exactly which pin is causing the problem, but as arnoldemu suggested, the vsync pin would be a likely candidate.

The nature of NMOS is that 5V levels are generally not "driven" but are the default, so a resistor to the power line and only 0V is driven low. However, the PPI is intended to drive data for a long distance (e.g. the printer port), so there will be active drivers on the output buffer, so this is most likely the issue - where a pin is driven to 5V by the PPI and pulled to 0V by something else on the CPC.

The other emulator issue I have is when changing PPI mode between read and write - changing the direction of any port actually causes the data value to be reset to 0 on all ports, so e.g. if the tape motor is on, it'll be turned off and even if you then immediately rewrite to the port to turn it on, the relay will click (and so be buzzing if you do this regularly) and cause loading errors. For this reason, you can't play music and scan the keyboard whilst loading from tape, something which isn't emulated very well in general.

[arnoldemu]

Markus, is the code actually causing a reset of the cpc, meaning the basic prompt appears, or do you mean that the code doesn't work correctly?

Perhaps it does reset, but because firmware is active this is what causes a soft reset.

Ralf may be refering to a hard like reset, but it may be more of a soft reset.

[arnoldemu]

@ralferoo: turning the tape on/off is that causing errors through the tape motor slowing down briefly or is it the reset which is causing bad values to be read and misinterpreted as an edge?

I assume that the tape motor takes a bit of time to achieve maximum speed from the time you start it, and the same with the stop? it takes a bit of time to stop completely after you stop it through code?

[ralferoo]

@ralferoo: turning the tape on/off is that causing errors through the tape motor slowing down briefly or is it the reset which is causing bad values to be read and misinterpreted as an edge?

I didn't analyse it in detail as I didn't want to destroy the relay / motor, but it was detecting some edges just not reliably. I would have left port B as read, I was only changing port A between input and output, but that's enough to clear the data in port C output and so turn the motor off, although it would have turned back on when I next wrote to port C to change BC1 and BDIR to the inactive state.

The other interesting thing is that the hardware of the CPC disables tape input when the motor is disabled, so even if you're using a tape adaptor if the motor is off, no signal will be read and no sound will come out of the speaker. Again, most emulators get this wrong too...

[Devilmarkus]

Markus, is the code actually causing a reset of the cpc, meaning the basic prompt appears, or do you mean that the code doesn't work correctly?

Perhaps it does reset, but because firmware is active this is what causes a soft reset.

Ralf may be refering to a hard like reset, but it may be more of a soft reset.

The real CPC can give out funny bytes overall on screen, stop music, freeze, etc...
And maybe it also can reset. It simply C.R.A.S.H.E.S.