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 1 Guest are viewing this topic.

TFM

Quote from: Bryce on 16:32, 28 October 15
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.

Well, then it would be nice to know:
- Which Diode
- Where to cut a line on the PCB
- Where to put the diode in
- In which direction

Of course a picture can tell it all. Now... I got the CPC-AY (predecessor of the PlayCity), in this case it may look different again. As you know I do the software, you do the hardware.  :laugh: :laugh: :laugh:  What I try to tell... not everybody will be perfect in soldering and will be able to patch the PlayCity, so IMHO it would be desirable to care about the problem from the software side (just to be on the save side).
As Grim I don't care who is right or wrong, just want to see it all running together in harmony.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

PulkoMandy

Well, on the software side, all I can tell is "don't use NMI if you have a playcity connected". On the hardware side, I would like to help, but I don't have the PlayCity nor the CTC-AY, and there are no schematics or PCB drawings available as far as I know. Give me one of these and I can tell you where the fix goes.

TFM

Ok, so software is supposed to ask for PlayCity (or know it's presence by using some configuration bytes).


IMPOTANT: Auto detection of hardware need to be aware of this, speaking of FutureOS, maybe SymbOS and other applications.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

PulkoMandy

Well, you can do everything in Albireo without using the NMI (using regular INT instead, or no interrupts at all and polling the status register). The test for Albireo does not need interrupts either, so you can safely detect both boards and then decide what to do with the interrupts.

TotO

#104

@Grim: Since years, I have forget that PlayCity's NMI not came directly from the CTC but it was an inverted signal from the CPLD...
So, I should reprogram the CPLD to protect itself against external signals. (fixing with a diode will be a pain in ass)

@Targhan: If you use the Albireo board to communicate with the PC and not to play with NMI, it will be not a problem.

By the way, the real question is about the Z80 CPU... How it will work when connected to two NMI sources??? (or two signals NMI come to it at the same time)
The NMI pin is not open-drain as the INT pin, because the computer only have to receive one Not Maskable Interrupt.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

PulkoMandy

I don't see a problem on the z80 side. There is an external pull-up which will make sure the pin stays high, unless one of the devices forces it to 0. There isn't anything special about the NMI or INT pin to handle that. The important thing is that devices driving the lines are only driving it low, and leave it floating when not in use. The pull-up will then do its job of raising the line high.


As I already mentionned, it is possible to vector NMIs, not using IM2 of course, but using other solutions like paging in different things at address 0x66 (the Multiface 2 pages in its internal ROM there, for example). And of course it's possible to mask/disable the NMIs on each device and use only one at a time, or, it is still possible to handle multiple ones, with some care in how the interrupt routine is written. In the case of Albireo, disabling its NMI output is possible, then interrupts from other devices can be checked and handled, then the Albireo one can be enabled again and it will trigger a new NMI if it has something new to say.



TotO

In this case, I will make a campain to update all the PlayCity boards.
But I remain skeptical about the fact of using more than one NMI.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

pelrun

Shared interrupt lines are nothing special - the handler just queries all the devices to find out which ones actually need attention when it's triggered. That actually requires that none of the devices are a special snowflake that assumes it's the only thing there and the interrupt is the only information it provides, which is pretty shortsighted.


The only thing different about an NMI compared to a normal maskable interrupt is that it's guaranteed to trigger the vector regardless of the state of the CPU - the DI/EI flag is ignored. That's it.

PulkoMandy

Actually, there is more to it, as Gerald already mentionned. On the z80, the INT signal is level triggered, but NMI is edge triggered. In simple cases, this doesn't matter, but imagine the following situations:


* One device triggers INT
* The z80 does an automatic DI and enters the interrupt handler code
* During the interrupt processing, another device triggers INT
* The z80 acknowledges the interrupt of the first device, and exits the interrupt handler (EI, RET)
* Because the second device is still holding INT low, immediately after the RET, the z80 enters the INT handler again (if using IM2, it goes to device 2 handler directly)
* The z80 can now process the interrupt from the second device


In the case of an NMI, it doesn't work this way. The NMI is "disabled" as long as the pin is held low.


* One device puts NMI low and holds it low
* The z80 enters the NMI handler
* Second device also pulls NMI low
* The z80 processes only the NMI from the first device
* The z80 exits the NMI routine, but the NMI line is still low because of device 2
* No NMIs can happen anymore!


This means the NMI handler must be carefully written to:
* Check ALL devices that could trigger an interrupt
* Disable the NMI on each device to make sure the NMI line goes up again (just acknowledging the interrupt is not enough, it must be locked at the "high" state until re-enabled by the CPU, providing a way to mask the NMI)
* Process all requests from the devices
* Finally, re-enable the NMI line of each device. If there is again an interrupt pending, we will enter the NMI handler again (before exiting it - we can't use the "EI/RET" trick of the regular INT here, where EI is effective only after RET is executed) - This means the NMI handler should also detect this condition and make sure to not overflow the stack by too many re-entries
* Do this in a loop until all devices are quiet again and there is no NMI to process anymore


Essentially, this emulates the behavior of INT in software.


There are other ways to handle this, for example the NMI handler could just increment a variable to signal that the NMI occured, then your main loop would check for that, do the actual processing and acknowledge each device.




And of course there is the case where you don't want to handle multiple NMIs at the same time. You first load something from Albireo (snapshot file, files from the USB, whatever), then you swithc Albireo interrupts off. Then, the program starts, and it uses the PlayCity after setting up its own handler. In this case there are no interrupt conflict problems, still the two devices have used the NMI at some point.

Fessor

#109
Z80 Family Interrupt Structure
Cant this be solved by Daisy-Chaining? IE1 of Albireo to IE0 of Playcity?

Or do we need something like a MX4 Mk.II with an Interruptcontroller like Intel 8259 to get a "real" Expansionport-system like ISA?

PulkoMandy

For normal interrupts, there is no problem.
For NMI, the z80 does not acknowledge the interrupt, so I'm not sure the daisy chaining would work.


An interrupt controller (or even just a priority encoder between different interrupt lines) would work, but may make things even more complex. Also I'm not sure it would mix well with the z80 (using IM2 for example).


These solutions are nice but they require moving away from the expansion port as designed by Amstrad (adding more signals, etc). It is then time to consider using a more standard bus, maybe ISA from PC, or S-100 from earlier machines starting with the Altair. This was already done in the form of the CPC-ISA :)

pelrun

Quote from: PulkoMandy on 10:09, 29 October 15
Actually, there is more to it, as Gerald already mentionned.


I didn't explain the steps, doesn't mean I don't know what they are :) I consider that a pretty standard handler design for that sort of interrupt hardware.

TotO

You really want to see the CPC working like a PC 8088?  :picard2:
Better to return to the original topic subject...
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

arnoldemu

Quote from: PulkoMandy on 10:09, 29 October 15
* One device puts NMI low and holds it low
Do not assume this. I expect devices to pulse NMI. (hold it low for a short time)

You already gave the reasons:
- no way for device to know NMI interrupt handler has been executed and completed
- no masking of NMI

So I think it's only safe for 1 device to issue NMI because then you know your code will not be interrupted.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

PulkoMandy

Well, Albireo at least uses level interrupts. As long as it holds the NMI low, no other device can re-enter the NMI handler. Only when the interrupt is acknowledged, the NMI goes high again and a new interrupt can be triggered. This provides a way to "lock" the NMI and make sure it doesn't get nested too early.

TFM

#115
IMHO we should use the NMI only if we really need it. For anything else the INT does just fine.  :)


Let me elaborate on this: The gain of the NMI it that it will happen immediately, so its usage is for very time critical things (rasters, FDC I/O, cyberwar). In case there would be more than one NMI sources 'firing' at one the routine would need to find out which one it is. So all the speed gain is lost, all the precision is lost.
:)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Grim

While developing software tinkering with NMIs and along the way, inevitably, some bugs happen (they always do), damaging or destroying one of your board: Premature end of development, beach-time aye! :)

awergh

I would like to order one to if im not too late.

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
  • 50 - awergh

Ast

As you can see, it's not too late... Thanks Pulko !
_____________________

Ast/iMP4CT. "By the power of Grayskull, i've the power"

http://amstradplus.forumforever.com/index.php
http://impdos.wikidot.com/
http://impdraw.wikidot.com/

All friends are welcome !

TFM

50 - that's a decent number for preorders!  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

PulkoMandy

The plan is to do a first batch of 5 boards (collector v0.9 edition), and if everything works fine on those, a second batch of 50 (or else, a second batch of 50 after fixing all the issues).


Progress report
After some difficulties with getting the packages (due to me getting only one tracking number when there were 4 packages), I now have all components for the first 5 boards (and some for the next 50 already). I'm still waiting for the main part, the CH376 USB controller, which I ordered from a different supplier.
This means I can start checking the board layout in real life and make sure all the footprints are correct and the chips will fit in place. Then, I can order the PCBs and start assembling them.

TFM

Dear community don't beat me up for this, but...


IMHO it would be a good idea to sell these 5 board on ebay (after they did their duty and are of no more use). That way the development would be funded and the producer would receive so kind of "compensation" for the development process.  ;)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Targhan

Well I have a better idea: why aren't the first guys being given their hardware are the one that actually PAY Pulko for his work?


Pulko, how do you want to be paid (Paypal? Cheque?)? I wouldn't want you to go bankrupt because of all this...
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

Ast

Quote from: Targhan on 22:39, 30 October 15
Well I have a better idea: why aren't the first guys being given their hardware are the one that actually PAY Pulko for his work?


Pulko, how do you want to be paid (Paypal? Cheque?)? I wouldn't want you to go bankrupt because of all this...
More if affinity ?
_____________________

Ast/iMP4CT. "By the power of Grayskull, i've the power"

http://amstradplus.forumforever.com/index.php
http://impdos.wikidot.com/
http://impdraw.wikidot.com/

All friends are welcome !

Powered by SMFPacks Menu Editor Mod