UK Vintage Radio Repair and Restoration Discussion Forum

UK Vintage Radio Repair and Restoration Discussion Forum (https://www.vintage-radio.net/forum/index.php)
-   Vintage Computers (https://www.vintage-radio.net/forum/forumdisplay.php?f=16)
-   -   Multiprocessing SCMPII on MK14 (https://www.vintage-radio.net/forum/showthread.php?t=180590)

Mark1960 26th May 2021 9:11 pm

Multiprocessing SCMPII on MK14
 
4 Attachment(s)
I've been planning on trying this for quite some time now, I was going to lay out a board with three SCMPIIs but while looking for proto boards for another experiment I saw the type that buses DIP pins together and remembered that I had laid out a backplane board for RC2014 that would also support bussing 0.6" or 0.3" wide memory chips. There was quite some time spent peeling unwanted traces from the board but overall I think this is neater than doing it all in point to point wiring. Top side is ground plane so hopefully should also improve any bus transmission line effect.

The 74HCT109s control release of reset for the next SCMPII and also release reset on the second half of the 74HCT109 which then implements HALT to the CONT input of its SCMPII. This is then compatible with the SoC later version prom, where halt was intended to be used for single stepping.

On power up only U1 is running, when you press Go, this releases reset on U2 which then starts to run the SoC monitor, while U1 starts to execute code at the target address.

It seems to be working but so far only tested using the halt instruction at address 0000 in the SoC monitor. Each time Go is pressed the U1 halts and U2 starts running, so the display does not change until Go is pressed for U4.

The priority for NENIN and NENOUT is set up so the latest SCMPII running the monitor has the highest priority on the bus.

NENIN of U4 is currently connected to NENIN from the socket connected to the MK14, which is connected to 0v on the MK14. In the Nat semi documentation for multiprocessing the SCMPII this should be connected to NBREQ. It seems to be working OK but there may be some bus transactions aborted before completion due to timing of ripple though of the NENIN signal.

I'm thinking of adding some kind of look ahead to the NENIN/NENOUT chain, to support the ortonview using NENIN to kick the SCMPII off the bus, as there may be some delay in this NENIN ripple through to all SCMPIIs.

This is going to need more RAM than that available on the MK14 to try anything complicated, so I'll also add a four input AND gate to combine the four NADS lines to drive the NADS out from the socket. I had planned to put a 6264 RAM onto the prototype on the bottom right corner, but I think I'll do that on a separate board to give more space to experiment.

SiriusHardware 27th May 2021 5:31 pm

Re: Multiprocessing SCMPII on MK14
 
This is possibly the most hardcore thing I have ever seen tried with an MK14, original or replica. I think it's going to be quite niche, though, hands up how many of you have five working SC/MPs to play with? No, me neither.

Will be interesting to see when you get it fully functional with enough RAM for it to run with.

TonyDuell 27th May 2021 5:42 pm

Re: Multiprocessing SCMPII on MK14
 
I remember an article in a magazine when the MK14 was current where somebody had soldered 2 SC/MP's together, most pins connected, but fiddling with NENIN and NENOUT, and then put the pair of pgybacked ICs into an MK14.

I think it was 'Computing Today', I can try to find the issue on my bookshelf if anyone's interested.

Mark1960 27th May 2021 6:58 pm

Re: Multiprocessing SCMPII on MK14
 
Quote:

Originally Posted by TonyDuell (Post 1378368)
I remember an article in a magazine when the MK14 was current where somebody had soldered 2 SC/MP's together, most pins connected, but fiddling with NENIN and NENOUT, and then put the pair of pgybacked ICs into an MK14.

I think it was 'Computing Today', I can try to find the issue on my bookshelf if anyone's interested.

I have seen that one, I think he was using a switch to enable the second SCMP, unless I’m thinking of a different article.

I considered piggybacking the SCMPs, but putting them in sockets allows me to re-use them later. There are quite a few outputs that can not be bussed together.

Mark1960 27th May 2021 7:15 pm

Re: Multiprocessing SCMPII on MK14
 
Quote:

Originally Posted by SiriusHardware (Post 1378363)
This is possibly the most hardcore thing I have ever seen tried with an MK14, original or replica. I think it's going to be quite niche, though, hands up how many of you have five working SC/MPs to play with? No, me neither.

Will be interesting to see when you get it fully functional with enough RAM for it to run with.

This is probably going to go beyond the MK14, but plugging it into the MK14 replica gives me something to start running some tests and experimenting with bus control etc.

I’ll maybe just fill the bottom 2k with ram and add someway to bootstrap that ram in place of the SoC monitor, possibly by patching in an ft245. I had thought about using a 6264 and decoding NENIN and NENOUT to give each SCMP private memory but more shared memory is probably needed first.

I’m planning to connect an ortonview or a proto build of something similar to the MK14 vdu, then maybe game of life as a simple multiprocessing exercise.

julie_m 27th May 2021 8:00 pm

Re: Multiprocessing SCMPII on MK14
 
How about implementing something like the Acorn Tube?

Mark1960 27th May 2021 10:27 pm

Re: Multiprocessing SCMPII on MK14
 
Quote:

Originally Posted by julie_m (Post 1378405)
How about implementing something like the Acorn Tube?

I don’t think that would exercise the multiprocessor bus of the SCMP which is what I wanted to explore.

I would class the tube as limited loose coupled multiprocessing, two processors sharing data through a message passing system. Though from what I have seen of the BBC it was more a case of using the BBC as an intelligent terminal to a single processor running the workload.

Multiple SCMP on a shared data and address bus would be a close coupled multiprocessor, which should support multi threading.

Timbucus 28th May 2021 3:10 pm

Re: Multiprocessing SCMPII on MK14
 
2 Attachment(s)
This is awesome work - one of the things I always fancied trying since I discovered the articles on it having native Multiprocessing in the issue of Elektor:

https://www.americanradiohistory.com...or-1979-05.pdf

(it has a circuit for an RS232 for the SC/MP to do level matching to +/- 12v)

The article before the NIBL-E one is a full card to use BASIC on the Elector
SC/MP system - but, it contains a good description of the chip and its use as
a multiprocessor system.

I also found this which suggests that may have been done in reality by Mark Pepper with his BITD, the cpu has another socket soldered on the top - that is quite neat but only dual processor.

https://www.facebook.com/groups/sinc...6522057297457/

In case you can't see the article here are two of the Photo's:

Attachment 235018Attachment 235017

I love the idea of Life - loads of bits is a byte to keep semaphores for which chip is working on cell, next generation ready etc. You would also need an area for each chip to signal its complete. I have been outlining a single proc version using the non display bit to give next generation as I did with the Bright bit on my version for the Spectrum.

Mark1960 29th May 2021 1:23 am

Re: Multiprocessing SCMPII on MK14
 
I took some timing measurements from NBUSRQ to NADS before and after moving NENIN from 0v to NBUSRQ.

This was with 4.4336Mz clock.

NENIN = 0v
U1 NADS1 was 512ns

NENIN = NBUSRQ
U1 NADS1 was 1,408nS
U2 NADS2 was 944ns
U3 NADS3 was 956ns
U4 NADS4 was 508ns

Each of these measured with only the one SCMP active, so the time for each bus operation is dependent on its position in the NENIN/NENOUT chain. Probably a combination of asynchronous propagation delays, the clock frequency and timing relative to clock that NENIN is sampled.

Mark1960 29th May 2021 1:33 am

Re: Multiprocessing SCMPII on MK14
 
Note the step between these times is approx 2 x the clock period, so it seems the clock is divided by two before its used for driving the internal synchronous logic.

Next experiment is probably to increase the clock frequency. I tried 9 MHz but the monitor display was only correct for a few seconds. I’ll need to dig out the 8, 7 and 6 MHz crystals again. This is different date code SCMPII to the one I had running at 9 MHz.

Slothie 31st May 2021 6:50 pm

Re: Multiprocessing SCMPII on MK14
 
Nice to see an Issue IV being used in such a great experiment!

SiriusHardware 31st May 2021 7:19 pm

Re: Multiprocessing SCMPII on MK14
 
Quote:

Nice to see an Issue IV being used
(He means issue VI. It so happens that Mark actually does have an original issue IV, that's if I've got it right this time).

Slothie 31st May 2021 7:25 pm

Re: Multiprocessing SCMPII on MK14
 
Quote:

Originally Posted by SiriusHardware (Post 1379305)
Quote:

Nice to see an Issue IV being used
(He means issue VI. It so happens that Mark actually does have an original issue IV, that's if I've got it right this time).

Yes, my Roman numerals are not so great today :D

Mark1960 1st Jun 2021 8:25 pm

Re: Multiprocessing SCMPII on MK14
 
I had originally planned a simple look ahead circuit that would just kick all four scmps off the bus as quickly as possible if the NENIN to the first in the change was raised high, for example by the mk14 display.

From the results in #9, two of the scmps see a 450ns impact on bus cycle time and the last has a 900ns impact.

With a bit of guesswork it seems that the NENIN signal needs to be driven low less than 50ns after NBUSRQ is driven low to avoid extending the bus cycle time. Assuming the scmp decision point is 450 ns prior to the NADS activation. How much less than 50ns is going to depend on delays in the asynchronous logic internal to scmp that is generating NADS.

I’ll try adding the unused gates of the 74HCT04 between NBUSRQ and NENIN, to see how much it can stand before U4 bus cycle is extended.

Mark1960 14th Jun 2021 10:35 pm

Re: Multiprocessing SCMPII on MK14
 
1 Attachment(s)
I added 4 unused gates from NBUSRQ to NENIN of U4, measured on a scope this gave a 25-28uS delay. With the clock running at 4.4316MHz there was no additional delay from NBUSRQ to NADS.

With the clock increased to 6MHz there was an extra delay from NBUSRQ to NADS, as I guess the NBUSRQ is synchronous to the clock as is the sample time of NENIN to start the bus cycle and reducing the period of the clock does not leave enough allowance for the extra gate delay. This could also be a problem at 6MHz without the extra gates depending on internal delays of the 8060.

Attached pdf is an attempt to avoid ripple through delays of NENIN to NENOUT.

NBREQ of each 8060 is isolated and feeds into a NOR bistable latch, then the outputs combined to generate a global NBREQ which feeds the alternate input of each latch. This is then followed by a priority encoder to generate NENIN for each 8060.

The NOR gate bistable latches should detect if the NBREQ is active low before the global NBREQ is low. If the NBREQ is active after the global NBREQ the request will be ignored until all the existing requests have been completed.

With both latch inputs high, both outputs will be low, so the priority encoder using NOR gates will hold the NENIN of all four 8060s active low until a bus request is generated, then the 8060s without priority will have NENIN deactivated before they get far enough into the bus cycle to drive the bus. I'm hoping this might avoid delays in the allowed bus cycle compared to using a standard priority encoder. Also I don't have any priority encoders but I do have 74LS260s.

After a current set of bus requests have completed the global NBREQ will be deactivated, allowing the 8060s that were late generating NBREQ to reactivate the global NBREQ and take their turn at using the bus. I think the global NBREQ will be inactive for only three gate delays, but hopefully this is long enough for any 8060 with NBREQ active to be registered as requiring the bus.

I need to add extra RAM first before I try this priority encoder and see if I can get a demo of multiprocessing running.

SiriusHardware 15th Jun 2021 4:01 pm

Re: Multiprocessing SCMPII on MK14
 
We're still reading, Mark, it's just that I don't have the kit to play along and it's conceptually probably too awesome for me to be able to understand anyway. But looking forward to the outcome, nevertheless.

Mark1960 15th Jun 2021 5:24 pm

Re: Multiprocessing SCMPII on MK14
 
Software is probably going to be the hard part for me to make use of the multiprocessing with the limited instruction set and registers available. Also I’m still hand assembling which is going to slow even the simplest of tests. Any recommendations of an SCMP assembler to run on windows would be welcome.

I’m thinking something like a small operating system based on a process/thread table. The table would hold the registers and state for each thread and possibly flags to indicate if that thread is waiting on some other thread to complete. Possibly starting new threads instead of calling subroutines. For each thread the state would be similar to the way the MK14 saves the user registers in ram when it uses XPPC P3 to return to the monitor. Memory would be shared so any thread could run on any processor.

Slothie 15th Jun 2021 5:34 pm

Re: Multiprocessing SCMPII on MK14
 
Quote:

Originally Posted by Mark1960 (Post 1382853)
Any recommendations of an SCMP assembler to run on windows would be welcome.

I and Sirius have had good esperience using SBASM https://www.sbprojects.net/sbasm/
It works for a number of processor, and the SC/MP syntax is close to that used in the national documentation (although not identical). Its also free, which is a good price, and runs on Linux, Mac and Windows.

Timbucus 15th Jun 2021 9:16 pm

Re: Multiprocessing SCMPII on MK14
 
I second sbasm for SC/MP - it is what I use increasingly for other processors as well as it simplifies moving between them.

Mark1960 15th Jun 2021 10:10 pm

Re: Multiprocessing SCMPII on MK14
 
I’ll give SBASM a try, I’ve been using TASM for Z80 as thats used for ROMWBW, but I couldn’t find config files for the 8060 and it seems like it might be a wasted effort to try and create them if SBASM is already available.


All times are GMT +1. The time now is 1:13 pm.

Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.