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.

Closed Thread
 
Thread Tools
Old 16th Jul 2020, 10:28 am   #101
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
Default Re: SC/MP timing and microcode information

Interesting Mark, I'll have a look on my set up when I get the chance. I added a simple clock divider as an extra option so I can divide the clock down easily so it should be possible to see how much the signals move in relation to the clock as it slows down - and try to work out how they are clocked out and hopefully in.

I did test nADS and it doesn't require a pull-up as far as I could tell so I suspect its just slow - maybe it's loaded up on the mk14?

Did you use xin or xout as the clock?

D
dominicbeesley is offline  
Old 16th Jul 2020, 11:03 am   #102
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: SC/MP timing and microcode information

Quote:
Originally Posted by Karen O View Post
I'm sure there are better Mk14 VDU experts than I, so please say if I've got all this wrong.
No, you're both doing just fine so far.

There is no...

"Can I have the buses?"
"Wait a second..."
"Yes, now you can have the buses"

...conversation that goes on as far as I can see. It's just

"Move over. I'm taking the buses".
SiriusHardware is online now  
Old 28th Jul 2020, 10:03 pm   #103
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: SC/MP timing and microcode information

I've had something of an insight regarding PC-relative addressing which I think Dom would find useful. There are two circumstances: jump instructions and indexed instructions. In the former case, a displacement of zero corresponds to the first byte of the next instruction hence 90FE (JMP -2(P0)) will form the classic infinite loop.

For indexed instructions, a zero displacement corresponds to the operand field. Hence C800 (ST 0(P0)) actually over-writes the operand! So to answer a longstanding question yes, this is a STI (store immediate) instruction!

My emulator gets all this right because the PC (Pointer 0) is pointing at the operand when the displacement is added. Consequently, a zero displacement behaves as described for indexed instructions.

And jumps work because of the PC PRE-INCREMENT before instruction fetch.

I hope this is interesting for to our resident clone emulator
Karen O is offline  
Old 29th Jul 2020, 11:31 am   #104
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
Default Re: SC/MP timing and microcode information

Thanks Karen, I'm guessing you tried this on a real chip? I'll check my verilog implementation - I think it will work as you describe but I will need to check if I specifically disallowed it or, less likely, I may be incrementing P0 before the store happens but I don't think that is happening. I've been a bit slow recently as I messed up my Xilinx and Altera installations when I upgraded my Laptop

D
dominicbeesley is offline  
Old 29th Jul 2020, 1:38 pm   #105
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: SC/MP timing and microcode information

No real chip involved - all determined by inference

I think it's common knowledge that 90FE is the SC/MP infinite loop (?)

I looked at the Mk14 SCIOS code for examples of indexed PC-relative addressing.
Karen O is offline  
Old 1st Aug 2020, 3:53 pm   #106
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
Default Re: SC/MP timing and microcode information

I can confirm that STI (C8 00) works as expected. I tried the following in NIBL:
Code:
@#1F00=#C4
@#1F01=#23
@#1F02=#C8
@#1F03=#0
@#1F04=#3F
LINK #1F00
Attached is the trace.

I'm not sure how useful an instruction it is!

D
Attached Thumbnails
Click image for larger version

Name:	temp.jpg
Views:	51
Size:	43.4 KB
ID:	212378  
dominicbeesley is offline  
Old 1st Aug 2020, 4:21 pm   #107
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: SC/MP timing and microcode information

Actually Dom, I looked at this because I realised a limitation of my SC/MP assembler that I wrote for my NIBL machine. When using pointers 1, 2 or 3 the displacement for indexed instructions is most often an offset into a block that the pointer is basing. With PC-relative addressing it's much more useful that the assembler calculate the displacement in the same way as for jump distances. Then you can just say things like 'LD VAR' where VAR is a storage location (hopefully) within 128 bytes of the instruction.

I'll get onto that fix...
Karen O is offline  
Old 2nd Aug 2020, 1:10 pm   #108
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
Default Re: SC/MP timing and microcode information

Ah, I've just realised that the C8 00 instruction isn't really a STI its a ST 0(P0) which is not quite the same. A real(?) STI would be CC xx which unfortunately I didn't check. That would be a slightly more useful instruction if it works as it would store in the operand byte but with fewer cycles than a normal pointer relative store.

Unfortunately the logic analyser is otherwise engaged at the moment. If I can track down the bugs in my other project I'll try out a CC instruction and see if that works.

D
dominicbeesley is offline  
Old 3rd Aug 2020, 8:18 am   #109
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: SC/MP timing and microcode information

I think you're getting into areas of semantics there, Dom.

Is an instruction defined by its effect or its method?

I think most programmers would only concern themselves with the effect.
Karen O is offline  
Old 3rd Aug 2020, 10:42 am   #110
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
Default Re: SC/MP timing and microcode information

I suppose I'm more concerned with how it does it rather than just the effect the "I" instructions on the datasheet (with opcodes of the form "11xxx100") work differently (and have fewer cycles - an artifact a programmer will be interested in!) than the others.

Another aspect that would be useful to a programmer would be for an STI the second opcode byte would possibly be ignored in terms of forming the address.

consider the "C8" case:

[code]
LDI 04
ST 0(PC)
[code]

If this were executed twice from RAM on the second pass it would actually do a ST 4(PC)...possibly not what was wanted though with some byzantine thinking it might be possible to make use of it?

If CC works then the immediate value might be overwritten but ignored in forming the address so I think the distinction is very much valid.
dominicbeesley is offline  
Old 3rd Aug 2020, 11:48 am   #111
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: SC/MP timing and microcode information

I take your point.

If execution is from RAM then the displacement gets modified so that the next invocation stores to somewhere else.

If execution is from ROM then the operand field can't be written to anyway.

Perhaps we can devise a contest for the most obscure use of ST n(0) ?
Karen O is offline  
Old 3rd Aug 2020, 1:39 pm   #112
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
Default Re: SC/MP timing and microcode information

Code:
  LDI #8		//opcode for NOP
  ST  0(P0)
  ..			// 8 bytes worth of stuff
  XPPC P3		// this will be overwritten with nop on subsequent passes but will be preserved on first pass
  ...			// other stuff to do on subsequent passes
Something like the above?
dominicbeesley is offline  
Old 3rd Aug 2020, 9:12 pm   #113
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: SC/MP timing and microcode information

Oh that is clever - I was just looking at my minimum RS232 receive for the SCRUMPI to see if I could eliminate the use of P3 and auto increment by storing the receive byte offset and updating it this way instead of in that Pointer register. In RAM it is a useful combined variable and write within a 256 byte block. So buffer processing etc reducing the use of a Pointer register springs to mind.
Timbucus is offline  
Old 4th Aug 2020, 11:31 am   #114
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
Default Re: SC/MP timing and microcode information

Maybe something like: (not tested just top of my head - I'm no SC/MP expert)

Code:
READBUF:
  LDI #BUF-(STX+1)  ; point at start of buffer in offset byte
LP:
  .. do serial stuff ..
STX:
  ST 0(P0)    ; store
  JZ EXIT  ; terminate on zero received - probably not what you want?
  ILD STX+1  ;increment offset
  XRI #BUFEND-(STX+1)  ; check for end of buffer
  JNZ LP  
EXIT:
  ..exit..

BUF:
  .RES 30
BUFEND:
dominicbeesley is offline  
Old 4th Aug 2020, 12:26 pm   #115
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: SC/MP timing and microcode information

And I thought I went for devious and obscure methods
Karen O is offline  
Old 6th Aug 2020, 1:29 pm   #116
dominicbeesley
Octode
 
dominicbeesley's Avatar
 
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
Default Re: SC/MP timing and microcode information

Everyone likes a bit of self modifying code! Makes debugging such a joy!

It's actually fairly common on 6502 games where you can really speed up memory copying and graphics by using an indexed mode but fankle with the instruction to move between 256 byte pages.

I guess it's less useful on the SC/MP with its auto-incrementing pointers?

D
dominicbeesley is offline  
Old 6th Aug 2020, 7:39 pm   #117
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
Default Re: SC/MP timing and microcode information

Quote:
Originally Posted by dominicbeesley View Post
Everyone likes a bit of self modifying code! Makes debugging such a joy!
D
Not just self modifying code, but a self modifying instruction
Mark1960 is offline  
Old 8th Aug 2020, 1:37 am   #118
Karen O
Rest in Peace
 
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
Default Re: SC/MP timing and microcode information

On this thread and the Mk14 VDU thread we were speculating whether the SC/MP NENIN input responds immediately or whether the SC/MP completes its current cycle before relinquishing.

I think I can say with confidence that it relinquishes immediately, probably via asynchronous logic so there's not even a clock delay. I think the SC/MP gets straight off the bus but takes note if it has been knocked back part-way through a cycle. It will try again when the buses subsequently become free again, perhaps multiple times. There must be a point in each memory cycle when the SC/MP deems 'mission accomplished' and ceases retries.

Do people concur with this analysis?
Karen O is offline  
Old 8th Aug 2020, 8:22 am   #119
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: SC/MP timing and microcode information

Quote:
Originally Posted by Karen O View Post
On this thread and the Mk14 VDU thread we were speculating whether the SC/MP NENIN input responds immediately or whether the SC/MP completes its current cycle before relinquishing.

I think I can say with confidence that it relinquishes immediately, probably via asynchronous logic so there's not even a clock delay. I think the SC/MP gets straight off the bus but takes note if it has been knocked back part-way through a cycle. It will try again when the buses subsequently become free again, perhaps multiple times. There must be a point in each memory cycle when the SC/MP deems 'mission accomplished' and ceases retries.

Do people concur with this analysis?
Now my inner sadist wants to stick a 555 on NENIN and see how it copes running a program.....
Slothie is offline  
Old 8th Aug 2020, 9:44 am   #120
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: SC/MP timing and microcode information

That's basically what the VDU already does to the SC/MP, continually kicks it off the buses while it is rendering from the RAM. Think of it as a very complicated 555.
SiriusHardware is online now  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 11:20 am.


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 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.