I'am not sure if this is the correct section, but I try to explain my problem :-)
I have the X-MEM an the PlayCity - SymbOS is installed in the X-MEM ROM (Slot 10-13) - also I'am working with the PS/ mouse adapter.
The configuration (symbos.ini) is on disk A.
When I start symbos out of the rom - the configuration isn't loaded from A (desktop-background) - also I cant start any app.
The apps are not reacting on any klick from the mouse. (PlayCity Installed)
When I'am booting without the PlayCity installed it works without a problem...
When I'am booting from floppy with PlayCity installed it's also working
I installed the X-MEM new (init/install - without ramdisk and CP/M extra ROMs)
Now I'am really confused where the problem is, because in the video about symbos and play city there seems to be no problem :-)
Have you tested without the PS/ mouse adapter?
Do you use a 3"1/2 floppy drive or something like on the +5V CPC power supply?
I confirm that I have no problem to use SymbOS from a X-MEM with PlayCity. (and X-MASS too :D )
So, may be your power supply is not enough for all your expansions?
Yes - I've tried it without the mouse adapter - same thing ;-)
I've only a HXc with it's own power supply - when i remove the PlayCity it's working in all combinations
With the PlayCity installed it only works when SmbOS is not started from ROM.....
I sounds like q power supply issue. Are you using a mother 4x, and does it have an external power supply? I have a similar issue but only when I plug in my xmass. All is good without the xmass, but with it I also have to remove the play city and minibooster. I was thinking it may be a xmass issue, especially since my reset buttons also fail to function as soon as the xmass is connected. Even the internal one as well as the mother 4x one.
I've contacted TotO and he is thinking about it. I have every confidence that a fix is not too far away.
How can a reset button fail? :D What happens when you press the button?
Bryce.
I have only see 2 times the CPC reset button fail, when I done tests:
1- I forgot to solder the button. :-\
2- The PlayCity's NMI signal produced by the CTC was configured in a wrong way[nb]reset occure, but as the RAM is not empty and the NMI routine start at &0066, the firmware code is mainly ignored and all continue like no reset was done.[/nb] and took control over all.
Quote from: TotO on 10:27, 05 January 15
I have only see 2 times the CPC reset button fail, when I done tests:
1- I forgot to solder the button. :-\
2- The PlayCity's NMI signal was configured in a wrong way[nb]reset occure, but as the RAM is not empty and the NMI routine start at &0066, the firmware code is mainly ignored and all continue like no reset was done.[/nb] and took control over all.
Doesn't pulling /BUSRESET to ground override absolutely everything? It shouldn't matter what state the NMI is in.
Bryce.
As explained on the NB, you reset... But the firmware don't take control of the CPC to init all things.
So, the program continue to run properly, as the RAM content is not erased.
Ah, didn't notice the NB. What happens the program counter in that situation, isn't it reset? A running basic program wouldn't continue to run would it?
Bryce.
When I have my xmass plugged in then the reset will cause screen corruption but yes sometimes everything keeps running.
Interesting. I hope a solution is found soon (so that I can order mine :)).
Bryce.
Quote from: Bryce on 11:07, 05 January 15
Ah, didn't notice the NB. What happens the program counter in that situation, isn't it reset? A running basic program wouldn't continue to run would it?
On PlayCity, all the circuits reset when the firmware write the &F8FF port.
So, for a standard usage, there is no problem at all. If you configure NMI for a special usage, you have to know what you are doing to take the hand over it. :)
---
About the X-MASS reset problem on the Craigsbar board, I have not noticed this issue when I have made the individual and integration tests.
But, I'm afraid that his CPC configuration got a power supply problem, because I have already exchanged the MiniBooster and its BT module few weeks ago. After testing them back, the BT module is HS and the MiniBooster is defective. (that was not when I have shipped them)
So, better to stop to plug your expansions boards now and check you CPC and PSU alone to detect the real problem!!!
What failed on the Mini-booster? It might indicate what's wrong with Craigs CPC?
Bryce.
The BT module is dead. Because it's a 5V to 3.3V I/O, I suggest that it received too much voltage.
The MiniBooster look to work during few minutes, but after that the CPC start to display stranges chars to the screen.
This problem is probably due to a defective 74HCT541 chip that drive the address bus to avoid problem between the ATMega and the CPC itself.
I have not tried to repair it now, as I have replaced it and I'm actually building the X-MASS.
Quote from: TotO on 13:19, 05 January 15
On PlayCity, all the circuits reset when the firmware write the &F8FF port.
So, for a standard usage, there is no problem at all. If you configure NMI for a special usage, you have to know what you are doing to take the hand over it. :)
---
About the X-MASS reset problem on the Craigsbar board, I have not noticed this issue when I have made the individual and integration tests.
But, I'm afraid that his CPC configuration got a power supply problem, because I have already exchanged the MiniBooster and its BT module few weeks ago. After testing them back, the BT module is HS and the MiniBooster is defective. (that was not when I have shipped them)
So, better to stop to plug your expansions boards now and check you CPC and PSU alone to detect the real problem!!!
I cannot explain the minibooster. As I only swapped the BT module. The minibooster I sent back was the replacement which never even got plugged into any of my machines, as soon as I swapped the BT my original minibooster worked fine again, so I sent back the replacement as it was no longer needed.
I have tested with multiple cpcs and multiple supplies. The result is always the same. As soon as the xmass is connected no reset switch works. This certainly seems odd. But I am sure you can work it out.
When I just have the xmass and xmem then symbos works fine, but no reset button. When I add either the minibooster or play city then the xmass fails to work. Like I said it is odd. I have tested my power supplies and they are both fine. The CPC itself is my 4128 which Bryce gave a clean bill of health to. And the Symbiface works fine with.
It seems that something is fishy with the xmass I have. But no worries, I am probably gonna post it back to TotO for a fix. As I am sure he will have the same issues as me. I can replicate them with or without the mother 4x on 3 plus machines and 2 CPC 6128s.
Quote from: Bryce on 13:22, 05 January 15
What failed on the Mini-booster? It might indicate what's wrong with Craigs CPC?
Bryce.
nothing, only the BT module.
Thank you for your new feedback Craigs. So, I really don't understand!!! :-X
Please, send me back the X-MASS. It's own reset line is probably defective.
I will refund you the postage and will send you a new board.
Quote from: TotO on 14:01, 05 January 15
Thank you for your new feedback Craigs. So, I really don't understand!!! :-X
Please, send me back the X-MASS. It's own reset line is probably defective.
I will refund you the postage and will send you a new board.
no need to refund the postage. I am not gonna leave you out of pocket. You prices are too low already IMHO.☺
Sorry, but my website system don't allow peoples to chose their wished prices about each board. ;D
Last two posts just made my day!!! :) :) :)
@Jungsi (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1231) : Does your setup work now? Was it the power supply?
Quote from: TFM on 19:49, 05 January 15
@Jungsi (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1231) : Does your setup work now? Was it the power supply?
It's the Mother X4 and I've tried it also with a 5V power supply for it - nothing changed in the result :-)
When the PlayCity is connected and loading SymbOS by Xmem, the configuration from drive a isn't loading.
Drive A is spinning a little moment but not loading anything - I can do a short video if it's helping you.....
I have to make some tests for trying to reproduce your problem.
Please, can you let me know the ROM (and the ID for each of them) that you are using to make the same configuration?
Thank you.
Do you need more infos?
After loading from ROM the configuraton file should be loaded from Diskdrive A....
Quote from: Jungsi on 21:03, 05 January 15
It's the Mother X4 and I've tried it also with a 5V power supply for it - nothing changed in the result :-)
When the PlayCity is connected and loading SymbOS by Xmem, the configuration from drive a isn't loading.
Drive A is spinning a little moment but not loading anything - I can do a short video if it's helping you.....
Vid could help. But do you have problems in general or is it only symbos. Any problems with CyberChicken when using PlayCity? It's hard to understand what's going on. :-X
EDIT: Your ROM setup is probably not the problem.
Quote from: TFM on 21:37, 05 January 15
Vid could help. But do you have problems in general or is it only symbos. Any problems with CyberChicken when using PlayCity? It's hard to understand what's going on. :-X
EDIT: Your ROM setup is probably not the problem.
I think CyberChicken is working the correct way - music from the internal speaker - sounds from the play city....
Hmm... getting more and more mysterious. Can you try to use an older version of Symbos maybe? Sorry, don't have any better idea.
OK, thank you.
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.
Is, for any reason, SymbOS test if the CPC BUS return the &FF value if "not used"?
This should return CF=1 if there is no IDE device connected.
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.
Quote from: Prodatron on 10:35, 06 January 15
This should return CF=1 if there is no IDE device connected.
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. ;D
(I have to rebuilt one and test)
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?
Quote from: TotO on 12:56, 06 January 15
The PlayCity only decode ports #F8xx and #F9xx.
I shouldn't try today too, because I have sent my PlayCity at gift for Christmas. ;D
(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
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.
Have a look :)
Without PlayCity:
[attach=2]
With PlayCity:
[attach=3]
At least here it seems, that it influences #FD0F as well...?
CU,
Prodatron
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 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/x-mem-symbos-playcity/msg91985/#msg91985)
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)
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.
Interesting, so even if a hardware isn't decoding a special port range, it could influence the INs of these ports...
Quote from: Prodatron on 14:09, 09 January 15
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.
Quote from: Prodatron on 13:39, 09 January 15But 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.
Quote from: Prodatron on 13:39, 09 January 15How 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.
Quote from: Ast on 11:43, 09 January 15
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?
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 ?
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).
Quote from: Ast on 11:43, 09 January 15
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 :)
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 :laugh:
Quote from: Prodatron on 14:57, 09 January 15
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. :)
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 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=250) 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. :)
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?