50 Hz interrupt generator module

[Steve Cousins]

As far as I'm aware there isn't a 'standard' 50 Hz interrupt source in the RCBus world. We have the Z80 CTC but these are now difficult to get hold of and are not part of typical RCBus systems.

In an attempt to fill the gap I've created SC737.

[Alan Cox]

Nice. That's a useful gap filler.

I'd have probably chosen a 74HC4060 8)

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/c99071f2-4c3a-4316-9a99-a75f3135ac6dn%40googlegroups.com.

[Wayne Warthen]

Excellent Steve!

I have been doing some initial testing/cleanup for the new RomWBW release and was lamenting my inability to test with a simple timer interrupt.  I will definitely add support to RomWBW.

Thanks, Wayne

[Steve Cousins]

Thanks Alan

Yes, I considered the 4060 but I don't use it in any of my other projects, so using here would mean yet another component to stock and manage. Using the 393 is not as efficient but I already use them in several kits. Design is always a compromise :)

[Steve Cousins]

Here is my simple test code

                    0001  ; Interrupt module (SC737) test for SCM
                    0002  
8000:               0003  CODE        .EQU  0x8000        ;Program code starts here
8100:               0004  DATA        .EQU  0x8100        ;Data in RAM starts here
000F:               0005  Port:       .EQU  0x0F          ;Interrupt controller port
                    0006  
                    0007              .PROC Z80           ;Assemble Z80 code
                    0008  
                    0009              .ORG  CODE          ;Start of code
                    0010  
                    0011  
                    0012  ; Main program sets up 50 Hz interrupt
                    0013  
8000: 3E 07         0014  Start:      LD   A,7            ;Jump table entry 7 (mode 1 int)
8002: 11 10 80      0015              LD   DE,Int         ;Address of Interrupt handler
8005: 0E 09         0016              LD   C,9            ;API 9 = Claim jump table entry
8007: F7            0017              RST  $30            ;Claim mode 1 interrupt
8008: ED 56         0018              IM   1              ;Set mode 1 interrupt
800A: FB            0019              EI                  ;Enable interrupts
800B: 3E 80         0020              LD   A,0x80
800D: D3 0F         0021              OUT  (Port),A       ;Enable 50Hz interrupt
800F: C9            0022              RET
                    0023  
                    0024  
                    0025  ; Interrupt handler (mode 1)
                    0026  
8010: F5            0027  Int:        PUSH AF
8011: DB 0F         0028              IN   A,(Port)       ;Bit 7 low if interrupt
8013: 17            0029              RLA                 ;  is being requested
8014: 30 04         0030              JR   NC,Int50Hz     ;Interrupt requested
8016: F1            0031              POP  AF             ;  so go handle it
8017: FB            0032              EI
8018: ED 4D         0033              RETI
                    0034  
801A: D5            0035  Int50Hz:    PUSH DE
801B: AF            0036              XOR  A
801C: D3 0F         0037              OUT  (Port),A       ;Clear interrupt
801E: 3D            0038              DEC  A
801F: D3 0F         0039              OUT  (Port),A       ;Reenable interrupt
8021: ED 5B 00 81   0040              LD   DE,(Count)
8025: 13            0041              INC  DE             ;Increment counter
8026: ED 53 00 81   0042              LD   (Count),DE
802A: D1            0043              POP  DE
802B: F1            0044              POP  AF
802C: FB            0045              EI
802D: ED 4D         0046              RETI
                    0047  
                    0048              .ORG  DATA          ;Start of data in RAM
                    0049  
8100: 00 00         0050  Count:      .DW   0             ;Interrupt counter
                    0051  
                    0052  
 

[Alan Cox]

Added to EmulatorKit (option '-5')

Will take a look at adding it to the Fuzix int source detection when I have a bit more time

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/fad9ffd8-5431-4c56-b127-3606fc21b8d9n%40googlegroups.com.

[Steve Cousins]

Wow, that was quick

[Wayne Warthen]

On Thu, Jan 29, 2026 at 10:41 AM Alan Cox <etched...@gmail.com> wrote:

Added to EmulatorKit (option '-5')

Nice.  This should allow me to add support to RomWBW prior to getting the hardware.

-Wayne 

[Pellatonian]

Would substituting a 3.93216 mhz oscillator give a 60 hz interrupt?

[Steve Cousins]

Yes, a 3.93216 MHz crystal would give a 60 Hz interrupt. You may need to use different load capacitors to match the crystal.

During testing I tried running the module with a 7.3728 MHz crystal and got the expected 112.5 Hz interrupt.

[Harry Speer]

Please forgive my ignorance but  (1) Would 50 Hz be used in Europe and 60 Hz in the USA ??   (2)   I have heard of maintaining a "ticker" for a CPU + OS to do time-sharing to multiple programs and / or multiple users ??   and   (3)   How is this ticker useful, especially if you have a WatchDog Timer from the Power-Supervisor Chip,  and  also if you already have an RTC Chip with CR2032 Battery Backup for a Real-Time-Clock ?? 

   

  I'm sorry to be so "thick" but I am having trouble seeing how this "ticker" would be wanted with all-of-the-above other timers ??  Timing how long it takes to do ..... ??
HSS

[Alan Cox]

1. Not necessarily. Historically the interrupts on many machines were either generated by interesting circuitry off the mains input so was grid HZ, or was tied to the usual video scanning rate and generated by the video card. That of course was in turn is tied to the grid HZ in order to avoid flicker from lighting and so on. There's no specific reason though. The TRS80 for example uses something like 40Hz regardless of location, other machines used various fixed rates. The moment you have onboard video though there are advantages to having a frame rate timer tied to your video scanning.

2. That's one use yes

3. Power supervisor watchdogs generally don't provide an interval interrupt.

The RTC selected from the RC2014 (and coming from Retrobrew) is both incredibly slow to read and provides no interrupt. You can ask it for the time but you can't ask it to wake you up. That makes it no use for multi-tasking where a program might be in a busy loop and need to be task switched. There are RTCs that can provide time interval interrupts but the one used by that card unfortunately doesn't do so.

There are three different bits of time going on here

1. The ability to ask the time and date (RTC board)

2. The ability to get a regular interrupting event (Z80CTC, TMS9918 video, 50Hz card, and a few other odder devices)

3. The ability to do fine grained accurate timing of events (Z80 CTC)

#1 alone gets you time stamping on files in CP/M 3 and is fine for that job

#2 gets you multi-tasking and is really useful also for stuff like games

#3 lets you do things like fancy sound generation, industrial control type things, localised time bases and so on most of which are not that relevant to the RCbus machines.

Alan

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/e34dabb2-7d23-45ce-8992-69d5c36d7909n%40googlegroups.com.

[Wayne Warthen]

To add a practical example to Alan's thorough reply, RomWBW will use a system tick to pace the output of audio files when played with the TUNE application.  The common .pt2 and .pt3 audio files want to have 50Hz pacing and play back much better when a 50Hz timer is available.

Thanks, Wayne

[Wayne Warthen]

Just wanted to post a quick follow-up that support for the SC737 Interrupt Generator Module has been implemented and tested on RomWBW.  Works very nicely.

This support is in the current RomWBW Beta Release v3.6.0 available on the RomWBW Releases Page.  The module is enabled with the config setting SCTIMENABLE.

Thanks, Wayne

[Steve Cousins]

Excellent. Thanks Wayne.

[Jaap van Ganswijk]

50 Hz makes me think of the 220V we have here in the Netherlands. The frequency of the 220V signal is very precize (over time), because clocks needed to rely on it. A processor has a crystal or resonator to make it run and you can derive a sense of time from that but it's not real-time. Therefore you need a Real Time Controller (RTC) but that also depends on it's own crystal or resonator or whatever and isn't real real-time. Another source is the internet where there are real time sources, Microsoft provides one. We also used the DCF-77 broadcast from Germany, like most home weather stations do now, but sometimes they are hard to receive and that isn't a big problem as long as they are received at least some of the time correctly. BTW, you shouldn't use RTC-signals to control task-switching etc.

Hey Cousins, I think I bought one or more of your PCB's. Thanks for doing all that work, almost started doing it myself.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/013e8706-3e44-4d2d-b26a-fdb6c3de5675n%40googlegroups.com.

[Bill McMullen]

BTW, you shouldn't use RTC-signals to control task-switching etc.

Perhaps there's a language issue that needs clarification.  I spent MANY YEARS working on large plant-wide REAL-TIME process control systems.  In that context, there is priority-based task switching in order to try complete critical tasks within specified time constraints i.e. a one second PID loop.

Systems such as MP/M use TIME-SLICING so that multiple cpu-bound users get access to some machine cycles on a rotating basis.  MP/M uses a 50Hz or 60Hz clock signal (i.e. tick) to control this task switching.  Obviously this needs some kind of reliable signal generator like the SC737 card.

Both of the above dispatch algorithms are based on multi-tasking systems rather than typical single-task systems like CP/M.  A Time-Of-Day (TOD) clock could also be used by a scheduler for things like once-a-day reporting, time & date stamping etc.  Adding to the confusion, TOD clocks are sometimes called Real Time Clocks (RTC) in datasheets and some can also produce square waves at select frequencies which might be appropriate for time-slicing.

[Jaap van Ganswijk]

We seem to live in different worlds...

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/e4fbb1ce-d64c-4a87-9c31-5cec4b5c98ban%40googlegroups.com.

[Tom Storey]

I am not so sure that 50Hz (or 60Hz) is maintained so people can run their clocks accurately. There are greater operational reasons for doing that, and by maintaining the grid as close as possible to a nominal frequency it just happens to become a relatively stable timing source to cheaply implement a clock.

As the frequency drops below nominal this indicates there is more demand than supply, and as it rises above nominal it means there is more supply than demand. Keeping the frequency as close to nominal as possile means that supply and demand are being equally matched, and this is quite critical for the operation of the network more than anything else.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/CADNzunw2vbFCmf6bNYV8cVXkCdxqTUuctdf%3D%3D3%2B79%3DLpkqcpBQ%40mail.gmail.com.

[Alan Cox]

On Wed, 4 Mar 2026 at 13:53, Tom Storey <t...@snnap.net> wrote:

I am not so sure that 50Hz (or 60Hz) is maintained so people can run their clocks accurately. There are greater operational reasons for doing that, and by maintaining the grid as close as possible to a nominal frequency it just happens to become a relatively stable timing source to cheaply implement a clock.

It isn't. However in much of the world not only is it stable but the energy suppliers actually slightly adjust the demand/supply balance deliberately to get the correct number of cycles a day if it wanders off slightly due to usage patterns.

Alan

[Tom Storey]

I did a little investigation into this kind of thing some years ago when I built a clock entirely out of transistors, and used the AC frequency as the time base. I wanted to see how good or bad the grid frequency would be over longer periods of time, and whether it would constantly lose/gain time. I only managed to reliably capture just under 2 weeks of data, but it seemed to be enough to get a bit of a picture.

https://ornotblog.blogspot.com/2017/05/clock-build-log-2-time-module.html

Short story is that it can run fast or slow by tens of seconds for days at a time, but in the end it will probably balance out just fine. I've had the clock running for several years and bar the occasional power outage it has remained pretty true - much as expected. :-)

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/CAK9X0%2Buq5EmZv8KDHJxFnR9gOKXSyVg6%2B0ek4R4ZC%3DMzhBkBSw%40mail.gmail.com.

[7alken]

ya, this "slightly adjust the demand/supply balance deliberately" means also activating big outside industrial "energy wasters", basically resistive heating elements with fans to burn peaks mostly from unstable solar farms (part  of theirs cost optimizations when negative price on realtime energy exchange occurs) during peak sun activity; as far as I understand, this (heating here) positive feedback is sometimes called "turbo";  back in 2010, here were built big solar farms with guaranteed subsidized prices for generated energy for decades, around 100bn CZK sucked from state steadily (still in progress)... also small PV installations have "grid following inverters" but large one try to use "grid forming inverters" (fanatics are discussing more  or less weird miracles) which tries  in some segments to generate/maintain also that mandatory pure-sinus frequency, but its semiconductor (SiC) limited thing only, nothing to compare with big rotational generators at outputs of coal/gas/nuclear power plants ... so "base load" level may be unstable and "noised" by peaks from network if not stabilized even by this drastic turbo way... you can imagine your computer PSU is weak, has no big electrolytes at output and your chips have no blocking capacitors ... this kind of beauty for power/signal integrity;
P.

[Interocitor Steve]

Hello Steve C,

I was looking at the schematic of your new 50Hz board.  I do not understand where the 50Hz comes from.  I see the 3.2768 MHz oscilator divided by 16, 16, 2nd then 2.  That give 3,276,800 / 16 /16 / 2 = 6400 Hz.  What am I overlooking?

Cheers.  It has been a while.

[Mark Durham]

I think each chip - i.e. U5 and U6 does a divide by 256. With two 4-bit counters in each chip, each half is doing a divide by 16 which gives you 3276800 / 16 / 16 / 16 / 16 = 50Hz. But then again. I've got more gaps than neurons these days.....

[Steve Cousins]

Mark is spot on.

[Dennis Burke]

Steve,

 I'm responding to your e-mail concerning the 68000 MCU on the RCBus since I can't reply to that directly.

    I’m aware of this 68000 effort and I think it’s pretty functional. I haven’t seen any other 16-bit MCU on the RCBus.

    There is a useful degree of interoperability in the 68000 design but an Achilles heel of the RCBus vis-à-vis 16-bit support is the byte/word behavior isn’t well defined.

    I get it that different MCU’s implement that their way and homogenizing it isn’t practical given the minimal real-estate of an RCBus card.

    Which is why I was doing an FPGA based design. I can implement whatever executable engine I want and drop it onto the RCBus. An 8086 acting like a 68000 on the bus is trivial.

    It's hard for me, or probably anyone, to say how much interest there would be in something like this.

    Regards,

    Dennis

  

[Alan Cox]

I did 68008 and 80C188 boards to avoid the problem. Also as it could use existing memory boards. The performance impact for 8086 isn't bad as it has asynchronous memory handling and internal instruction fetch queues.

The only true non 68k board 16bit I know of otherwise is the TMS9900 which of course just does everything in words.

Someone probably does need to add the byte lanes as used into the rcbus doc so there's some kind of standard. Even if it's just a 68k appendix for now.

I also found 16bit data almost impossible to route on 2 layers with the pins assigned.

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/2a75908c-2c27-4c64-a5fc-2bdc69722104n%40googlegroups.com.