SPI Interface

Actually nothing was very fast on this processor. A single step of the LDIR instruction took 21 clock cycles to execute! (to move just a single byte)

A 6502 could actually do it in less time than that with the loop coded as separate instructions, but it had all kinds of 256-byte page limits because it had no 16-bit index registers.

Usually only OTIR had any use, and that was with peripheral chips that could be initialized by sending a sequence of bytes to the same output port. There were some chips like that. You could put the init sequence in a memory area, point to that, and send it to a port in one go.

But usually, interaction with I/O ports required testing bits, and branching until a "ready" bit got set, then reading a byte and store it, then again go back to the testing.

In that case the non-repeating variant INI and OTI could be of some use, but as you mention one often wanted to do some checksumming and it was not possible because INI would not leave the transferred byte in A.

To do actual block transfers from real peripherals with INIR, it would be possible to do a clever hardware design that inserted WAIT states when the CPU attempts to read a port before the data is ready, or to write it before it has been vacated. That would of course not be useful with a UART, but when the port actually is a transfer gate to another fast processor like a hard disk controller or video controller, it would be possible.

In reality it was not done very often, because in cases of a glitch in the I/O the entire system would hang.

I think what I had, was a FORTH library written in FORTH and somehow compiled to assembler.

I do remember that the assembler wasn't normal procedural assembler, more like 'this is what forth would do if forth was not interpreting'

I think this is it here:

Naturally I had to patch all the I/O to work with the clib I had built..

As you can see, what is there is not code, its PDF graphics of someone elses code...hahaha.

As you can see a typical forth 'function' is, in assembler, a list of pointers to other forth functions which are executed in turn. preceded by a pointer to a string which is the name of the forth function.

So although its all written in forth, its also written in assembler!

Anyway I tip my hat to Forth. impressive size reduction but a swine to actually use for large programs.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll

it costs nothing to have it on the chip, and very little to have it come out to some pins on the board, but rather a lot to put an actual D9 socket or D27 socket and cable to the case..

so no one actually bothers

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll

Yeah. I remember that. Every time I wanted to use it it was bleedin useless for the reasons specified.

I didnt do a lot of z80 assembler tho

8086 dropped that stuff entirely IN and OUT was all you had, either direct 8 bit or indirect using register contents.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll

I'll think you'll find there were 128 16bit index registers available to clued-up 6502 programmers. How many you could use depended on what other software you had to co-exist with.

;-)

ah yes, a processor I NEVER programmed.

I did a bit of work on 6809s once.

There was logic in that, thoiugh it was by then dog slow - we were well into 80286 by the time I did my last bit on that.

I have had a look at the ARM instruction set, and it is frankly amazing, how they did what they did with so little silicon.

Pure British engineering, as much as possible on a minimum budget.

And everything you need is there, although some of its is accessed in weird ways..

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll

Yes, IIRC that's a very similar structure, though the way it was coded differs quite a lot.

In the 6809 version the source that looked like assembler was very small indeed - certainly less than what is in your PDF.

Its been a long time since I looked at it but I'm pretty certain that the Forth source contained an assembler written in Forth. The Wikipedia article says that microForth was optimised for portability rather than performance, so something like I think I remember would be a neat way of achieving that.

Having a built-in assembler puts in on a similar footing to C, where porting it to a new system consists of:

- modifying the code generation phase

- feeding the compiler through itself

- moving the assembler source output to to target system and compiling it

- running the resulting C compiler

- repeating the above steps until you've got all the bugs out

I think that porting a Forth with an internal assembler would be very similar:

- modifying the Forth startup code

- modifying the lowest level 'machine' words

- moving the changed source to the target system and assembling the assembler parts

- running Forth, which completes startup by using its internal assembler to compile the words written in Forth assembler and starts to run.

- repeat the above steps until Forth runs successfully.

Yes, thoroughly agree - and its not only much easier to read than APL (IMO its nearest equivalent), but doesn't have the silliness of needing a special character set in the terminal.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

It's only inaccessible at bulk production time. Many of the pins in SoCs go through IO multiplexors so that an external pin can have 1,2,4 8 or more functions depending which internal functional blocks are selected to the IO pin. A pin may have SPI, I2C, DMA/IO handshaking or UART functionality. During debug the boot code will enable UART functionality for ease of connection. As the RTL matures UARTs are progressively disabled and more complex blocks enabled.

The UART code is left in the designs even if you cannot use it when the chip is mounted in its final guise. If it seems a silicon run has issues, you can mount samples on breakout connectors and re-enable the UART and debug the silicon features. The silicon real estate used by a UART inside your typical 100million transistor SoC is negligible. Also, having run all your timing closure code so your layout meets requirements, you don't want to change internals as you'd need to rerun all your verification code. Just don't select the UART function.

Qualcomm's Snapdragon family of processors, used in many popular mobile phones, have 16c750 UARTS (16550 with bigger FIFO) used for debugging and software bring-up. They just don't wire them up to a DB25 on the back of your Samsung Galaxy/HTC Desire/Nokia Lumia. They're still there in the silicon though.

That makes sense. Thanks for the explanation.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

They were not as easily usable as the HL/DE registers in the 8080 and additional IX/IY registers in the Z-80 because you could not simply increment them over the full 64K address range. That is what I mean with page limits.

I hated them. They seem to be such hard work with the lack of instructions, registers etc. compared to the Z80. If you were good you could make them sing but I never had the inclination to keep on with them at the time. Far too much like hard work especially when 68000s became common place.

That was what I didn't like the few times I had to write 6502 assembler, all the faffing about when you went over 255 in things.

The IX, IY registers had some real overhead in use. There was a prefix byte in the opcode to say it was IX or IY not HL or DE and then LD A,(IX) was actually LD A,(IX+0) i.e. there was always an offset byte even when it was zero. So that was 2 bytes longer than you needed.

LD A,(IX+0) takes 19 t-states LD A,(HL) takes 7 t-states

That was the problem with Z80, the slightly esoteric instructions often had enough overhead that more simple code was just as quick.

I last wrote Z80 assembler for money in 1992 and I had to look up the timing. I thought the numbers were burnt in my mind just like the 68k timings but getting older and really only writing C/C++ and Python these days means the fine details is slipping away!

I never found a use for IX and IY, apart from storing another register in em, but stack was near as good.

8086 I used all the registers at one time or another

Also on the 6809 IIRC.

I think the last time I worked on a z80 was 1984...

IBM PC came along and the call was for 8086 assembler.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll

If I can find my Zilog book I will look it up. Have not used it since 1992.

If this keeps up I'll have to post my disk drive driver for the TRS-80, complete with the test to see if a disk is really in the Shugart floppy drive. Yes I still have my original TRS-80 two of them and my Model IV. Ran LDOS on them. Can anyone say Android NIM?

Nope. 8086 generalized it to REP.

--
roger ivie 
rivie@ridgenet.net

*raises hand*

--
roger ivie 
rivie@ridgenet.net

Yes, that was a real disadvantage of nearly all "extra instructions". Only the relative jumps were useful.

I still have a small pocketbook with all instructions and timings... (also for the 68000 and the 8086)

I had a model I and used NEWDOS/80 2.0 (I think). Later CP/M 2.2 (with my own memory bank switching mod)

I was on an Agile course last week in Cambridge, all accept one attendee said they started off in the industry doing 6502 assembler (the other guy wasn't even born until 1983).

Not really surprising given that Cambridge is the home of Acorn and the

6502 based BBC Micro. But not forgetting Acorn also created ARM, and it's RISC instruction set was heavily influenced by the simplicity of the 6502.

---druck