X-MEM - SymbOS - PlayCity

[TFM]

Hmm... getting more and more mysterious. Can you try to use an older version of Symbos maybe? Sorry, don't have any better idea.

[TotO]

OK, thank you.

[Prodatron]

The ROM Version of SymbOS always tries to boot from IDE harddisc first (Master, Partition 1/unpartitioned). If this failed, it loads from drive A.
It seems, that something crashes, when the PlayCity is connected and SymbOS tries to access the (non-existing) IDE device.
I never tried this combination (booting with the ROM Version, PlayCity is connected, no IDE), but it's probably an issue with the detecting routine. Please give me some time to examine and fix this.

[TotO]

Is, for any reason, SymbOS test if the CPC BUS return the &FF value if "not used"?

[Prodatron]

This should return CF=1 if there is no IDE device connected.

Code Select Expand


ideprtsta   equ #fd0f           ;Portaddress + #f (Status/Command)

;### IDERDY -> Wait for IDE device beeing ready for command
;### Output    CF=0 -> ok, CF=1 -> timeout
iderdy  push bc
        push hl
        ld bc,ideprtsta
        ld hl,256*60
iderdy1 in a,(c)
        and #80
        jr z,iderdy2
        dec l
        jr nz,iderdy1
        rst #30  ;wait 1/50 second
        dec h
        jr nz,iderdy1
iderdy3 ld a,stoerrabo   ;error code
        scf
iderdy2 pop hl
        pop bc
        ret


But it seems, if the PlayCity is connected, if returns CF=0. That would mean, when reading port #FD0F (Status/Command) bit 7 is cleared. Could this be caused by the PlayCity?
I still didn't try it on real hardware, as I won't have access to my machine until tomorrow.

[TotO]

This should return CF=1 if there is no IDE device connected.

Code Select Expand


ideprtsta   equ #fd0f           ;Portaddress + #f (Status/Command)

;### IDERDY -> Wait for IDE device beeing ready for command
;### Output    CF=0 -> ok, CF=1 -> timeout
iderdy  push bc
        push hl
        ld bc,ideprtsta
        ld hl,256*60
iderdy1 in a,(c)
        and #80
        jr z,iderdy2
        dec l
        jr nz,iderdy1
        rst #30  ;wait 1/50 second
        dec h
        jr nz,iderdy1
iderdy3 ld a,stoerrabo   ;error code
        scf
iderdy2 pop hl
        pop bc
        ret


But it seems, if the PlayCity is connected, if returns CF=0. That would mean, when reading port #FD0F (Status/Command) bit 7 is cleared. Could this be caused by the PlayCity?
I still didn't try it on real hardware, as I won't have access to my machine until tomorrow.

The PlayCity only decode ports #F8xx and #F9xx.
I shouldn't try today too, because I have sent my PlayCity at gift for Christmas. 
(I have to rebuilt one and test)

[Ast]

I've made some test using Playcity YMZ features to play music with Digidrums. It works really good. But i don't know why my samples use the same machine time as if i had used the Cpc ay chip. If someone has any idea, please, Tell me.
Is YMZ updated at each Hbl as DMA Sound on Cpc Plus? I don't think so...
Can you Tell me how is Time taken between 1 and 2 values ? 4 nops per values when register is selected?

[Prodatron]

The PlayCity only decode ports #F8xx and #F9xx.
I shouldn't try today too, because I have sent my PlayCity at gift for Christmas. 
(I have to rebuilt one and test)

With connected PlayCity I get
INP(&FD0F)=0
So it seems, that it returns values in these port ranges, too. In any case this is the reason why the IDE routine hangs with connected Playcity. I will have a look at the IDE status register now, maybe some other bits can be checked, too.

CU,
Prodatron

[TotO]

To decode the $FDxx range, you must have:
1111 1101 xxxx xxxx

The PlayCity CPLD schematic hard decode:
1111 100x xxxx xxxx

That allow to handle F8xx and F9xx ports range exclusively.
Than mean, a hypothetical HD conflict with a working PlayCity is:
1111 1x0x xxxx xxxx

Checking the schematic, the bit10 and the bit9 are always compared to GND.
That mean, PlayCity only decode F8xx and F9xx, not FDxx.

[Prodatron]

Have a look
Without PlayCity:
[attach=2]
With PlayCity:
[attach=3]
At least here it seems, that it influences #FD0F as well...?

CU,
Prodatron

[TotO]

Your test is not OK, as you are not testing the address decoding but a value read on the CPC bus.
This value is not guarented to be &FF, as it is Hi-Z states of the CPC bus. (it is not &FF on PLUS computers)

It's why I have asked that, some posts ago:
X-MEM - SymbOS - PlayCity

[Prodatron]

But why is there a difference at more port ranges with/without the PlayCity?
Here is another test:
Without PC: [attach=2] With PC: [attach=3]
How should I test it in a way that it's ok? (sorry, my hardware knowledge is limited)

[gerald]

The Z80 bus is in high impedence mode when no peripheral is driving the bus during a IO/memory read. On a regular CPC, the bus will slowly goes from the last value to 0xFF due to the TTL input design. Time to do this is related to the component on that bus.
To my knowledge, the PlayCity has a pull down resistor network on the data bus. This will slow down the transition to FF and may even prevent it.

The proper way to detect a device on the bus would be to have a dedicated register, a floating bus is never a good way.

We already had a discussion about this.

[Prodatron]

Interesting, so even if a hardware isn't decoding a special port range, it could influence the INs of these ports...

[arnoldemu]

Interesting, so even if a hardware isn't decoding a special port range, it could influence the INs of these ports...

yes.

You should attempt to access it as if it were there but in a way that it does something you can verify it's existance.

e.g.

trigger the nmi to happen.

if it doesn't happen with the expected time, then the device doesn't exist at that port.

other ways are to write and then read back a value - but this only works if the device provides a read port.

[TotO]

But why is there a difference at more port ranges with/without the PlayCity?

Because the PlayCity set the data bus to GND instead of let it floating to allow to handle RM2 vectorial interrupt and PLUS compatibility. So, all "false 255" values goes 0. Real values write on the bus by each devices (like 128, 90 on the screen) are not affected.

How should I test it in a way that it's ok? (sorry, my hardware knowledge is limited)

You have to read a real expected value on the data bus.
For example, the CPC Booster and the MiniBooster write 170 on the &FF00 address to allow to detect them.
To check if a harddrive is connected, you have to communicate with the device to read a know value.

[arnoldemu]

I've made some test using Playcity YMZ features to play music with Digidrums. It works really good. But i don't know why my samples use the same machine time as if i had used the Cpc ay chip. If someone has any idea, please, Tell me.
Is YMZ updated at each Hbl as DMA Sound on Cpc Plus? I don't think so...
Can you Tell me how is Time taken between 1 and 2 values ? 4 nops per values when register is selected?

How are you making the digidrums?
are you programming the z80ctc to generate an interrupt, then processing the interrupt to write to a ymz?
or are you using the traditional digidrum method of waiting x nop cycles and doing a write?

[Ast]

I use the traditionnal method which consist of waiting x nops between each values sent.
I don't know if NMI can be used in DualYM, so, i can test.
Using NMI Ctc interrupt don't waste Cpc time? Is it that ?

[Prodatron]

Ok thanks for the explanation. I will add a real IDE detection now, which should be quite simple, as you can read/write the sector/cylinder/SDH registers (though I never did this on the CPC, only on the MSX).

[Prodatron]

But i don't know why my samples use the same machine time as if i had used the Cpc ay chip.

About what "machine time" you are speaking? If you add NOPs between each sample it is obvious I would say

[Ast]

Yes, you 're right... My question would have to be : how to do to play sample with Playcity without wasting all Cpc time.
I think i've now the answer 

[TotO]

Ok thanks for the explanation. I will add a real IDE detection now, which should be quite simple, as you can read/write the sector/cylinder/SDH registers (though I never did this on the CPC, only on the MSX).

Exactly.

[TFM]

Ok, seems that you found a solution here. And I second that approach.    Under FutureOS I use the following philosophy for hardware detection: Check if you can write a byte and read a byte to an designated I/O port in a way that you get a value back which distinguishes one hardware clearly from others.
Of course in same cases there is nothing to read / write, then one has to work around.
Its right what @gerald told: One can not expect an unused port of an CPC to be always the same. There are different PCBs and the deliver different values, also a bus buffer (part of some expansions) can move unused ports to 0 or to 255. There are examples for both. Furthermore there is the cost down PCB which is different again.


For the SF2 detection for FutureOS for example I write a byte in the millennium of the watch, then I read it again and see it it is ok. The same can be done for the IDE part.


Now since we got the wonderful X-MASS expansion a separate detection routine is needed anyway. 

[Ast]

For Playcity, i use NMI détection. I put values in reg x, send a value y in a reg using NMI and test the final. Guess who is who?