|
Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment. |
|
Thread Tools |
16th Jul 2020, 10:28 am | #101 |
Octode
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
|
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 |
16th Jul 2020, 11:03 am | #102 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,553
|
Re: SC/MP timing and microcode information
Quote:
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". |
|
28th Jul 2020, 10:03 pm | #103 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
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 |
29th Jul 2020, 11:31 am | #104 |
Octode
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
|
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 |
29th Jul 2020, 1:38 pm | #105 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
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. |
1st Aug 2020, 3:53 pm | #106 |
Octode
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
|
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 I'm not sure how useful an instruction it is! D |
1st Aug 2020, 4:21 pm | #107 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
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... |
2nd Aug 2020, 1:10 pm | #108 |
Octode
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
|
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 |
3rd Aug 2020, 8:18 am | #109 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
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. |
3rd Aug 2020, 10:42 am | #110 |
Octode
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
|
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. |
3rd Aug 2020, 11:48 am | #111 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
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) ? |
3rd Aug 2020, 1:39 pm | #112 |
Octode
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
|
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 |
3rd Aug 2020, 9:12 pm | #113 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,363
|
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.
|
4th Aug 2020, 11:31 am | #114 |
Octode
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
|
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: |
4th Aug 2020, 12:26 pm | #115 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: SC/MP timing and microcode information
And I thought I went for devious and obscure methods
|
6th Aug 2020, 1:29 pm | #116 |
Octode
Join Date: Nov 2004
Location: Hebden Bridge, West Yorkshire, UK.
Posts: 1,885
|
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 |
6th Aug 2020, 7:39 pm | #117 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,294
|
Re: SC/MP timing and microcode information
|
8th Aug 2020, 1:37 am | #118 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
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? |
8th Aug 2020, 8:22 am | #119 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: SC/MP timing and microcode information
Quote:
|
|
8th Aug 2020, 9:44 am | #120 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,553
|
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.
|