UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 3rd May 2021, 8:15 pm   #1
Michael Haardt
Triode
 
Join Date: May 2021
Location: Titz, Germany.
Posts: 17
Default New SC/MP II system

Hello,

this looks like the place for remaining SC/MP users. I can't say for how long I wanted to build a system with this CPU and finally got to do it:

http://www.moria.de/tech/scmp/cpuscmp/

I recovered programs from the Elektor data records ESS-002 and ESS-004 and wrote some test programs to verify hardware operation. I believe I have all published articles to possibly recover all programs from ESS-001, although those are mostly for use with Elbug and HEXIO. I have kitbug working, built from original source and with a fix for the set 8th bit bug when it echoes input plus modified for 600/1200 baud (2/4 MHz). I did not yet attempt to build and run NIBL.

The bus control used may be useful in case you want to build a CPU card for an S100 or ECB system.

Have fun!

Michael
Michael Haardt is offline   Reply With Quote
Old 3rd May 2021, 9:16 pm   #2
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,110
Default Re: New SC/MP II system

Welcome Michael to the last bastion of the SC/MP clan - the problem with other processor users like the Z80 and 6502 is they think the arguments they started in the playground were relevant. They missed the winner - the SC/MP which quietly got on with running the world around them and taking their money in most slot machines

Fascinating article and it makes use of Slothies parallel idea of an Arduino to blast software in directly via DMA - I did not see mention of supporting SMP which of course is a major feature of the processor but, I assume that is possible with some tweaks to add multiple CPU cards to an NDR rack.

I have to ask where did you get the ESS records that is a lovely find - I have a lot of Elektor and quite a bit of software is mentioned as supplied on them!
Timbucus is offline   Reply With Quote
Old 3rd May 2021, 10:52 pm   #3
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 689
Default Re: New SC/MP II system

Hi Michael, and welcome to the crazy group that still plays with the scmp.

I think we might argue that the MK14 was more popular, if by that we mean more numerous and not most preferred. The elektor machine was probably developed much further into a more usable machine.

I like the idea to use the ‘395 as address latch, I have a few 74LS395 and 74F395 in my collection from a different project. The tristate output could be useful too.

I don’t think there is any additional logic required for halt if interrupts are used, just the latch with the output to drive CONT input. If an interrupt is generated I think the next instruction will still be fetched and the NADS cycle will then clear the latch.
Mark1960 is offline   Reply With Quote
Old 4th May 2021, 4:41 pm   #4
Michael Haardt
Triode
 
Join Date: May 2021
Location: Titz, Germany.
Posts: 17
Default Re: New SC/MP II system

I got ESS-002 and ESS-004 as MP3 files from the web, but unfortunately I lost the URL. The physical records are probably unobtainium.

I converted the MP3 files to WAV, hoping for the best, and then used the rtty software to convert FSK back to a byte stream (rtty contains a UART decoder), saved all continuous byte streams and ended up with lots of tiny files from noise and a few large chunks from the actual tracks. I stripped off the framing with a small program and the CRCs were fine. There is a bug in Elbug: The check sum is the addition of all data bytes in the record. Due to a bug in Elbug the carry flag is reset at the beginning of a record instead of before each data byte addition, so it is folded back into the sum. I am still organizing things, which is why I did not release any software so far, but after 40 years I guess there is no need to hurry.

I got kitbug sorted out, as a bunch of images is on the net for various baud rates and CPU speeds, but NIBL is still a mess: I have two NIBLE binaries that are slightly different in just a few bytes, one NIBL binary without serial functions and one with them, plus source I can assemble to the latter. Guessing, there were NIBL bugfixes that probably explain the byte differences. Funnily NIBL uses the same GECO and PUTC function as kitbug, but with the MSB bug in GECO fixed.

The NDR Klein Computer (NKC) offers DMA, but has no bus arbitration and expects the CPU to coordinate DMA accesses: No SMP. It largest strength is the modularity: Pull the Z80 or 68008 CPU card, plug in the SC/MP card and you have a new computer. Anybody who wants one can download Gerbers and have it manufactured:

http://www.nkc-wiki.de/index.php?title=Hauptseite

The biggest problem is probably the language: All German, as it was featured in a German TV series in the eighties.

It is news to me that the SC/MP would ignore CONT in case of an interrupt, but I did not pay such close attention to the possibility of halting it really.

Michael
Michael Haardt is offline   Reply With Quote
Old 5th May 2021, 3:52 pm   #5
audiokit
Triode
 
Join Date: Jan 2021
Location: Hulst, Netherlands.
Posts: 17
Default Re: New SC/MP II system

Hallo Michael,

Welcome in joining the group of enthousiasts that want to keep the sc/mp alive. And alive means working in a computer system.
You really contributed in a posititve way by giving new ideas and a fresh view. I will surely use some of them in my future designs.
The designs of elektor (elektuur in Dutch) were popular in Germany and the Netherlands. I don't know if it had a lot of followers in the UK where SC/MP allready had a group of followers with the MK14.
Most of the ideas you mentioned can be built on the existing boards I have. The speaker with LM386 and the LED connected to Flag-2 are 2 examples of easy extensions which will improve our knowledge of programming the SC/MP.

I hope you will become a frequent contributor with new ideas which doesn't mean that the older people present (I am one of them) don't come up with new ideas. Saying that meas I assume you are a younger person but of course I could be completely wrong
audiokit is offline   Reply With Quote
Old 5th May 2021, 4:10 pm   #6
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,535
Default Re: New SC/MP II system

The first programmable device or system I ever programmed was the Elektor (as it is known in the UK) simple SC/MP system with DIP switches for address and data input and LEDs for address display and data display. It belonged to a friend who had started to build it at about the same time as I ordered my MK14.

As we now know, Science of Cambridge (later Sinclair) were very bad at delivering systems on time so I think I had to wait many months, and in the meantime I used that little Elektor system to become more familiar with the SC/MP. I know that the Elektor system was eventually expanded into a fairly serious system but my friend never took his further than that initial stage.

Over here in the UK we especially like the Elektor / Elektuur style of PCB artwork which is good enough to put on the wall because it looks so good.

There are quite a few of us here who own original MK14s, or replica MK14s, or in some cases both.
SiriusHardware is offline   Reply With Quote
Old 5th May 2021, 4:51 pm   #7
Michael Haardt
Triode
 
Join Date: May 2021
Location: Titz, Germany.
Posts: 17
Default Re: New SC/MP II system

The speaker originated in the Elektor design. I just improved it using a LM386 to avoid the disadvantage of the original design that did not drive the speaker in both directions. It would be quite cool to use PWM to create a fading sine tone, just for hack value. Besides I wanted to run the Elektor programs playing christmas songs. I recreated their source code, which showed bugs in the published listing. In general the published listings appear to contain a number of bugs, but the binary allows to figure out what the source should have been. Guessing, back then source code was not transferred electronically.

I just got NIBL (not NIBLE) running. The sources I have contain a number of changes compared to the Dr. Dobbs article, which look like bugfixes to me, and mention further possible bugfixes. I can build NIBL from this source and get the binary I fetched from the net (the one that lacks the serial functions). Looking through all the changes will probably take some time.

So far I settled on 600 (SC/MP II 2 MHz) and 1200 (SC/MP II 4 MHz) baud for both kitbug and NIBL. The SC/MP already misses characters to abort a listing occasionally, so going faster is probably asking too much. Which speeds do you use?

The cross assembler asl recently got new features to natively understand the integer literal syntax used by the original SC/MP assembler and I made a small awk script to convert the rest, so it is possible to assemble original sources with minimal to no changes.

Does anybody know anything on FBASIC? It looks like there is only a binary and I don't even know what it uses as console.

Michael
Michael Haardt is offline   Reply With Quote
Old 5th May 2021, 8:32 pm   #8
audiokit
Triode
 
Join Date: Jan 2021
Location: Hulst, Netherlands.
Posts: 17
Default Re: New SC/MP II system

Hello Michael, thank you for the clear response and I see you have a lot of plans for the future.
I run my 600 on 4Mhz and never had a character missing up to now. Make sure it is exactly 4Mhz and not the 4 and a bit (don't remember exactly) that MK14 is using.
fbasic is running too on one of my SC/MP's it is a floating point interpreter and is very close to the PET basic without the graphics. You can find all statements and the HEX on Ronald Dekker's DOS4ever page. I did not dig into this interpreter in detail so cannot tell you al lot about it.

Last edited by audiokit; 5th May 2021 at 8:55 pm.
audiokit is offline   Reply With Quote
Old 6th May 2021, 8:50 pm   #9
Michael Haardt
Triode
 
Join Date: May 2021
Location: Titz, Germany.
Posts: 17
Default Re: New SC/MP II system

I tried 600 baud at 2 MHz and kitbug does not always recognize the CR to stop showing memory contents. It looks like it just samples sense-b, so that may fail at either speed, because lower speeds need more time to output characters.

I am aware of the relationship between clock and the speed constants in the code. It took me a while to figure that out and I checked the serial timing with a logic analyzer. The published table I found late is perfect for 1200 baud at 4 MHz. I used a crystal oscillator to avoid the slight frequency offset non-matched crystals have.

Today I stumbled upon a surprise: Is the SC/MP little or big endian? I don't see any 16 bit operations, so it may be neither, but the original SC/MP assembler stores word (.dbyte) in big endian. Is there a reason?

I found the link for at least one ESS record in my notes:

https://mahlzeit.it/No-Artist/Elekto...-Service/90524

Regarding the Elektor RAMIO SC/MP board with LEDs and DIP switches: In 1983/1984 I made a PCB and built the same thing as my first computer, but being unable to obtain a SC/MP I used a Z80. That was fun indeed, but I never met anybody who knew that system.

Michael
Michael Haardt is offline   Reply With Quote
Old 15th May 2021, 7:35 pm   #10
Michael Haardt
Triode
 
Join Date: May 2021
Location: Titz, Germany.
Posts: 17
Default Re: New SC/MP II system

Here are kitbug and the programs from the ESS-002 and ESS-004 records:

http://www.moria.de/tech/scmp/software/

The NIBL source is not yet fully restored. The version available on the net contained many OCR problems and was hacked a lot for assembling with asl. I proof read it against the listing, fixed what I found and removed almost all asl changes in favor of a small front end conversion script. I will release it when that is done.

Michael
Michael Haardt is offline   Reply With Quote
Old 25th May 2021, 6:09 pm   #11
Michael Haardt
Triode
 
Join Date: May 2021
Location: Titz, Germany.
Posts: 17
Default Re: New SC/MP II system

I am currently working on a boot ROM, which involves copying program images larger than 4 KB from the boot ROM to RAM. At that point I can use RAM for variables, if I have to, but it makes everything easier if I don't need RAM variables. My naive attempt at memory copy with 16 bit pointers is slow as hell. p1 is the source, p2 the destination and p3 the length:

copyloop1:
ld (p1) ; copy from source to destination
st (p2)

ccl ; 16 bit increment of p1
xpal p1
adi 1
xpal p1
xpah p1
adi 0
xpah p1

ccl ; 16 bit increment of p2
xpal p2
adi 1
xpal p2
xpah p2
adi 0
xpah p2

scl ; 16 bit decrement of p3
xpal p3
cai 1
xpal p3
xpah p3
cai 0
xpah p3

xpal p3 ; jump if p3 is not zero
xae
lde
xpal p3
lde
jnz copyloop1
xpah p3
xae
lde
xpah p3
lde
jnz copyloop1

Apart from unrolling the loop, what else could I do? Pointers are best stored in pointer registers, I guess. ild only does 12 bit arithmetic and does not set carry. The length could benefit from being stored in a variable addressed through p3. It's still clumsy and I guess someone figured out way better code for memcpy(). Suggestions are welcome!

Michael
Michael Haardt is offline   Reply With Quote
Old 25th May 2021, 6:40 pm   #12
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,110
Default Re: New SC/MP II system

Just quickly would it not be quicker to use the Extension register as a fixed offset from 256 byte pages - it can be used on both pointers and then only change the High Bytes to move through pages?

In my SCRUMPI serial bootstrap I use a fixed page endpoint (rather than like you creating a general COPY) but, you could make that part of a pointer... PUTCHAR is the serial transmit in this instance of a similar approach

Code:
	LDI	/PUTCHR-1
	XPAH	P3
	LDI	#PUTCHR-1&255
	XPAL	P3

REPEAT:
	LDI	/MESSAGE-1
	XPAH	P2
	LDI	#MESSAGE-1&255
	XPAL	P2

LOOP:	
	LD	@1(P2)
	XPPC	P3
	LD	-1(P2)
	XRI	#0x04		;Is it EOT
	JNZ	LOOP
Timbucus is offline   Reply With Quote
Old 25th May 2021, 9:06 pm   #13
Michael Haardt
Triode
 
Join Date: May 2021
Location: Titz, Germany.
Posts: 17
Default Re: New SC/MP II system

I need to copy the same memory area twice, once second stage loader + code from the boot ROM to high RAM, then after disabling the boot ROM only the code back to low RAM. The code position relative to 256 byte pages will change unless I pad the boot loader to a full 256 byte page and copy the full loader in the first stage as well to maintain the position. A 256 byte page copy function may indeed be easier than a byte wise copy function.

Your code is awesome, because a generic map function walks a string, using the function pointer in P3 for each character.

I guess it is best to accept the 12-bit pages and just never have data crossing them.

Michael
Michael Haardt is offline   Reply With Quote
Old 25th May 2021, 9:24 pm   #14
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 689
Default Re: New SC/MP II system

Use auto increment and then test the low byte of each pointer for zero, if its zero test the high byte, low nibble for zero, then increment the high nibble. It would add more code but its only executed once in every 256 bytes.

Also use load with auto increment for the counter, but take the 2s complement at the start of the loop. Exclusive or with FF for each byte and load with auto increment to add one.

I tried writing an example but copying and pasting on the ipad is too painfull.
Mark1960 is offline   Reply With Quote
Old 26th May 2021, 7:11 pm   #15
Michael Haardt
Triode
 
Join Date: May 2021
Location: Titz, Germany.
Posts: 17
Default Re: New SC/MP II system

I tried to fix up the pointer register 12 bit overflow, but did not save much runtime, because checking the pointer registers is almost as bad as a 16 bit increment. I don't quite get what you suggest for the counter. My problem is that I cannot easily load a byte from P to A: xpal, xae, lde, xpal, lde just takes too long.

Copying aligned 256 byte pages can be made quite efficient, but the code looks strange, because I have to copy 255 bytes with auto increment, then 1 byte without and perform a 16 bit pointer increment. Otherwise the 12 bit restriction hits again. Only using a 256 byte page counter saves a little bit, but the code is not pretty, just fast. Well, say not as slow. I could still unroll the loop, but I am amazed the first attempt works at all.

copyloop1:
ccl
ldi 1
copypage1:
xae
ld @1(p1) ; copy from source to destination
st @1(p2)
lde
adi 1
jnz copypage1
ld 1(p1) ; copy last byte of page
st 1(p2)

ccl ; 16 bit increment of p1
xpal p1
adi 1
xpal p1
xpah p1
adi 0
xpah p1

ccl ; 16 bit increment of p2
xpal p2
adi 1
xpal p2
xpah p2
adi 0
xpah p2

ld @-1(p3) ; decrement p3
xpal p3
xae
lde
xpal p3
lde
jnz copyloop1

I guess I should accept it is a memory machine and put the length in memory, pointing p3 to the workspace.

Michael
Michael Haardt is offline   Reply With Quote
Old 26th May 2021, 8:45 pm   #16
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 689
Default Re: New SC/MP II system

This is my attempt, definitely uses more code.

This is untested so may have multiple errors.

Code:
xpal p3		; 2s complement of p3
xri 0xFF
xpal p3
xpah p3
xri 0xFF
xpah p3
ld @1(p3)

copyloop:
ld @1(p1)
st @1(p2)

ld @1(p3)	; Increment p3
xpal p3
jnz loop1
xpal p3
xpah p3
xae
ldi 0x0F
ane
jnz loop2
ldi 0x10
ade
jz end
xpah p3
jmp loop3

loop2:
xae
xpah p3
jmp loop3

loop1:
xpal p3
loop3:

xpal p1		; check for p1 page boundry crossed
jnz loop4
xpal p1
xpah p1
xae
ldi 0x0F
ane
jnz loop5

ldi 0x10
ade
xpah p1
jmp loop6

loop5:
xae
xpah p1

loop4:
xpal p1
loop6:

xpal p2		; check for p2 page boundry crossed
jnz loop7
xpal p2
xpah p2
xae
ldi 0x0F
ane
jnz loop9

ldi 0x10
ade
xpah p2
jmp copyloop

loop9:
xae
xpah p2

loop7:
xpal p2
jmp copyloop

end:
Mark1960 is offline   Reply With Quote
Old 30th May 2021, 9:15 pm   #17
Michael Haardt
Triode
 
Join Date: May 2021
Location: Titz, Germany.
Posts: 17
Default Re: New SC/MP II system

Pretty smart, but those jumps to get the exchanges right are hard to follow. I like how you use E to save the value. I never had so much trouble with forks in the data flow as I do on SC/MP.

But in the end the core loop does not look faster to me. I unrolled the loop of the 256 byte copy and now the speed is good enough for me:

Code:
copyloop1:
  ccl
  ldi 2
copypage1:
  xae
  ld @1(p1)     ; copy from source to destination
  st @1(p2)
  ld @1(p1)     ; copy from source to destination
  st @1(p2)
  lde
  adi 2
  jnz copypage1
  ld 1(p1)      ; copy next to last byte of page
  st 1(p2)
  ld 2(p1)      ; copy last byte of page
  st 2(p2)
 
  ccl           ; 16 bit increment of p1
  xpal p1
  adi 1
  xpal p1
  xpah p1
  adi 0
  xpah p1

  ccl           ; 16 bit increment of p2
  xpal p2
  adi 1
  xpal p2
  xpah p2
  adi 0
  xpah p2

  ld @-1(p3)    ; decrement p3
  xpal p3
  xae
  lde
  xpal p3
  lde
  jnz copyloop1
I should be on a good way with my boot ROM now, thanks a lot!

Michael
Michael Haardt is offline   Reply With Quote
Old 31st May 2021, 12:45 am   #18
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 689
Default Re: New SC/MP II system

At least you remembered the ccl, I missed a few in my attempt.

I had almost forgotten how awkward it can be to do anything with the SCMP instruction set. I found my old programming reference leaflet and kept thinking it must be missing a few pages, but nope, that all it had.
Mark1960 is offline   Reply With Quote
Old 31st May 2021, 8:52 am   #19
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,110
Default Re: New SC/MP II system

But of course that minimal approach is what makes it now something fun and challenging...
Timbucus is offline   Reply With Quote
Old 31st May 2021, 5:47 pm   #20
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,104
Default Re: New SC/MP II system

I think one of the reasons National ported Tiny BASIC to SC/MP and came up with NIBL so early was that programming the SC/MP for large applications was so complex, and the intended use of the SC/MP for industrial control made the page-structured BASIC code approach more attractive to customers wanting to control hardware. Without a seperate minicomputer and cross-assembler, creating large programs on a SC/MP system is problematic. and some applications wouldn't warrant the purchase of a seperate minicomputer. NIBL enabled the deveopment system hardware to be somewhat interactive in itself.
Slothie is offline   Reply With Quote
Reply

Thread Tools



All times are GMT. The time now is 2:19 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


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