News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_PulkoMandy

Albireo - USB/SD/Serial interface for CPC

Started by PulkoMandy, 15:54, 18 October 15

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

TotO


Quote from: PulkoMandy on 22:41, 23 October 15I dont understand what I could damage? I'm triggering interrupts with an open collector driver
When your board will trigger the NMI signal, it will go to the CTC Zc1/To1 output (not open drain).
About the CURSOR signal, I have said shit... Change nothing on your board for it.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

netmercer

Hi PulkoMandy!
I want to preorder one board, please.  :D

What you have been developed, seems to be very impressive !!!

Best regards
netmercer

TFM

Quote from: TotO on 19:00, 24 October 15
When your board will trigger the NMI signal, it will go to the CTC Zc1/To1 output (not open drain).


Does this mean that if there is another board at the side of the PlayCity generating an NMI, that this will destruct the PlayCity? Can it be protected? Sorry for a basic question, but I guess a lot of people would like to know.  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

PulkoMandy

Quote from: TFM on 16:33, 26 October 15

Does this mean that if there is another board at the side of the PlayCity generating an NMI, that this will destruct the PlayCity? Can it be protected? Sorry for a basic question, but I guess a lot of people would like to know.  :)


Yes. This means it is incompatible also with the multiface 2 or anything generating an NMI. I don't know if it will destroy the CTC, but it will short circuit its output. Multiple options are possible:
* The CTC overheats and is destroyed
* The CTC "wins" and the NMI does not work
* The CTC is not destroyed, and things still work


The problem is on the PlayCity side, the interrupt and NMI signals are meant to be driven with open collector outputs to avoid this kind of conflict (otherwise there would be only one interrupt source). I can't do anything about it, except warning users of the problem and advising them to not use the NMI mode when they also have a PlayCity.

TFM

Thank's for the update. This is important information, especially since there is a MX4 version of the Multiface II (Talreks clone). So it's better to know about this issue.


Of course problems can be omitted by using the right kind of software, which only activates one NMI source at a time. However in case of the MF2 no software 'knows' when the user will press the button. So maybe a general warning about using the MF2 for all devices capable of generating an NMI would be good (on software side when using NMI features).  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

PulkoMandy

Well, the problem is on the PlayCity side. I would have to check the multiface 2 schematics to know if it also has a problem. My board is doing things the "right way" and if everyone did the same, there would not be a problem here.

Bryce

Sorry to say it, but that's a really sloppy design if that's the case. Especially as it could have been easily avoided with a single diode.

Bryce.

TotO

Absolutly not... Just keep in mind that only one NMI source must exist into a computer design to work properly.
Chose if you want to use a Multiface II or a Playcity or ... But only one.
More that one NMI signal = Not Maskable Interrupt goes Maskable!  :picard:
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

gerald

Quote from: TotO on 22:08, 26 October 15
Just keep in mind that only one NMI source must exist into a computer design to work properly.
source ?

TotO

#84

Not you...  :-\
NMI can't be vectored. Witch routine to exec to $0066 for witch device if you can't know who send it?
What is going if two NMI was received by the Z80 at the same time?
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

gerald

Quote from: TotO on 22:15, 26 October 15
NMI can't be vectored. Witch routine to exec to $0066 for witch device if you can't know who send it?
What is going if two NMI was received by the Z80 at the same time?
NMI is usually reserved for system critical interrupt such as memory error detection, debugger ...
While it simplify the design, nothing forbid it to be driven by multiple devices with the help of an interrupt controller.

However, in the CPC case, you will have to handle the allowed source in SW.
Also, NMI is edge triggered. This mean that if a device is driving it low all time until acknowledged, any other source will not be able to trigger it and this can be a problem.

Now for the PlayCT NMI, if it is driven from the PLD, you just need to replace your output driver by a tri state on and only allow it to be driven low or high-Z. Or use a diode.

PulkoMandy

The interrupt routine could scan all devices to find which one triggers the NMI. I agree this can create problems if multiple sources are used at the same time, of course. But, this doesn't mean there can't be multiple sources, used one at a time. Something like this:

       
  • User types ùSNA, Albireo is configured to use NMI, and a snapshot is loaded using an interrupt-driven serial code (or a file is loaded from USB or...)
  • At the end of the loading, Albireo is reconfigured to disable its NMI support
  • Then, the program starts, and it uses PlayCity's NMI
In that case, only one NMI at a time is used, and there is no problem handling them. During the program run, there is no problem (Albireo doesn't care what you do with the NMI line). But during the loading, PlayCity is trying to prevent Albireo to trigger an NMI?
There is also the same problem with the Mulitface design. There, there is no conflict, because when the MF2 triggers an NMI, it also maps in a ROM at &0066 to override the interrupt vector (yep, that's essentially a way to do vectored NMIs!). When the PlayCity NMI is triggered, it gets to the internal RAM or ROM (or whatever is mapped to the z80 at that time). Again, no conflict, except the PlayCity will be trying to keep the NMI signal high while the Multiface is trying to drive it low...


Another argument: on the CPC schematics, you can see that there is a pull-up on NMI to allow it to be used this way (same on BUSRQ for DMA transfers). (the pull up for INT is inside the gate array). It really shouldn't be an all-exclusive direct drive signal.

TotO

#87
I have never seen any system designed to use more than one NMI signal.
In example, the PCW don't provide NMI on the expansion port because it is used by the FDC.

Looking the Z80 CPU datasheet, you can see that pull-up is only required for the INT applications.
The CPC was not designed to use more than one NMI signal, but to work if no NMI signal exist.
(the pull-up on the NMI pin is only here to avoid to indefinitely loop on the &0066 address)

By the way, the PlayCity (AKA CTC-AY) was designed to allow to free some CPC potential by mainly:
- Adding the missing Z80 counter/timer companion
- Fixing the IM2 mode to allow to use vector interrups
- Using the NMI signal as very high priority rasterlines generator
- Using CURSOR registers to acuratly configure them

It was not intended than other device use NMI while this board is plugged because that.
Sorry for the Off Topic. I stop here.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Bryce

The Commodore 64 has 3 devices connected to the /NMI.

Bryce.

TotO

Yes, and those 3 devices (CPU, CIA, CARTRIDGE) receive the NMI signal from the RESTORE key.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Shining

TGS is back

Download my productions at:
cpc.scifinet.org

TFM

Ok, so taken all together, as long as we program responsible, it's not a problem with the NMIs.  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Grim

All I would like to know is if the PlayCity can be fixed/protected, and how, so that it can not possibly be damaged by foreign NMIs, or not. Thank you.
Sorry if I give the impression of not caring at all about NMI theology and who's right and who's wrong, I really don't :)

PulkoMandy

All you need is adding a diode between the CTC output and the NMI pin. I don't know how easy this is on the playcity, it depends on the PCB layout, if the chip is on socket, etc.

archcosmo

Hi PulkoMandy

put me down for one unit please

PulkoMandy

Current waiting list
0 - PulkoMandy
1 - OffseT
2 - TFM (x2)
4 - ||C||-||E||
5 - majikeyric (x2)
7 - CraigsBar (x2)
9 - pelrun
10 - Optimus
11 - AsT
12 - Gryzor
13 - hsimpson
14 - SOS
15 - tonio8bits (x2)
17 - Audronic
18 - gros_minet
19 - Fessor
20 - Sykobee (Briggsy)
21 - skywalky
22 - Jungsi
23 - Poliander
24 - Yannis_uno
25 - Rennert
26 - HAL6128
27 - Joseman
28 - Tai
29 - Grim
30 - reidrac
31 - cosa_nostra_6128
32 - Targhan
33 - oratyper
34 - NiNxPe
35 - Vandalsk (x2)
37 - Dirtybb
38 - Dubliner
39 - ronaldo (x2)
41 - cpcmaniaco (x2)
43 - Munchausen (x2)
45 - jrodriguezv (x2)

47 - netmercer
48 - Shining
49 - archosmo

Targhan

About this NMI thingy, does it mean that I can't make a program that receives data from the PC and them send to the Playcity in realtime? (else, big fire?)
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

PulkoMandy

#97
Since Albireo is flexible, you can configure it to use the regular INT or no interrupts at all (and poll the status yourself).



OUT &FEB4, 0 ' No interrupts!
OUT &FEB4, 4 ' Interrupts on INT
OUT &FEB4, 8 ' Interrupts on NMI - Do not use with unpatched PlayCity!


See the programming manual for details on the interrupt management: http://pulko.mandy.pagesperso-orange.fr/shinra/albireo.shtml#heading_toc_j_13

Unrelated news: I'm getting the first package of components this evening, so I can start checking that all the IC footprints on the board have the correct size and that the ICs don't accidentaly overlap.

TFM

#98
What's about this: NMI creating devices which are in danger could be placed on an adapter for MX4 boards. Ok, it gets probably about 2 cm higher, but this small adapter can hold the diode (or what ever suits best) to protect the card.
Still (in case I understood that) a careful way of coding would be enough to omit trouble, by doing this:
- Use NMIs of one source at a time
- Switch off NMIs when not needed

(That's what we have to do anyway if we don't want to face a crash after f.e. starting an new app or soft reset of the CPC).
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Bryce

Quote from: TFM on 16:20, 28 October 15
What's about this: NMI creating devices which are in danger could be placed on an adapter for MX4 boards. Ok, it gets probably about 2 cm higher, but this small adapter can hold the diode (or what ever suits best) to protect the card.
Still (in case I understood that) a careful way of coding would be enough to omit trouble, by doing this:
- Use NMIs of one source at a time
- Switch off NMIs when not needed

(That's what we have to do anyway if we don't want to face a crash after f.e. starting an new app or soft reset of the CPC).

But there only is ONE device that needs the diode and that's the PlayCity. All other devices should have the NMI implemented correctly.

Bryce.

Powered by SMFPacks Menu Editor Mod