"Outline specification for the BBC MICROCOMPUTER system"

[jgharston]

There's nonorthongonal and there's nonorthongonal. To me the Z80 is very othoganal. Especially as Zilog used sensible mnemonics and syntax instead of the Intel strangeness.

You can do:
LD any_8bit_register, any_8bit_register
LD any_8bit_register, immediate
LD any_8bit_register, (HL)
LD (HL), any_8bit_register
LD A,(any_16bit_register)
LD (any_16bit_register),A
any_aul_operation A, any_8bit_register
any_rotation any_8bit_register
ADD/ADC/SBC HL,any_16bit_register
PUSH any_16bit_register
POP any_16bit_register
etc.

and the opcodes are formed very orthogonally, %01dddsss is LD ddd,sss %10uuusss is ALU A,sss %01ddd101 is LD sss,n etc.

[1024MAK]

CP/M stuff...

Where do you get the impression that there was any kind of graphical support in CP/M?
Each manufacturer supplied a bespoke version of CP/M for their hardware...

Also, I read Mr Zaks z80 book (the opposite of the 6502 one I used to use) and he mentioned that the z80 loop instructions are slower and surprisingly not even more code efficient than a plain 6502 indexed loop: perhaps there are some counter examples he skipped...

At which clock speeds? The two CPUs use very different internal circuitry, so you cannot compare the two CPUs when run at the same clock speed.

Which of these two CPUs is best very much depends on what application you are writing and how good a machine code programmer you are. Ever since the 1980s people have been comparing and arguing about which is best. I'm still waiting for a clear overall winner. But in reality there will never be one, as they are both about the same in overall performance for general computing. In some applications one or the other has a slight advantage, but that's about it.

And on that note, I should say that a CPU war here will not be welcome.

Mark

[Coeus]

I had thought CP/M had a BIOS/API

It did, but AFAIK the BIOS only provided very basic features indeed, for example:

• Write a character to the screen
• Read a character from the keyboard
• Write a character to the printer port
• Read a sector from disc
• Write a sector to disk

There really wasn't much beyond that. I did not see any standardisation of how the cursor was moved around the screen even, though there may have been fewer differents sets of codes than there were machines, perhaps by copying the control code sequences from terminals used on mainframe/mini computers. So definitely no graphics, definitely no advances I/O capabilities etc.

CP/M had it's advantages, probably the biggest of which was its ubiquity. In the usual fashion of these things the first barely adequate solution that gets a hold often builds enough momentum that later, better solutions fail to displace it. From an assembly language programmer's perspective having a fixed starting address for user programs and having the command interpreter re-loadable from disk in case you overwrite it, thus giving more of the RAM to the program you are writing are definite advantages. From a user's perspective the tendency to simply reset when an error occured, and thus discard your work, and tortoise-slow floppy disk performance were not good features. The whole design philosophy of transient programs petty much assumes disks are available. It would be tortuos to use from tape which presumably explains why RM, when marketing a Z80 machine for schools, had it run a ROM basic when running from tape and only ran CP/M on disk-based or network-based machines.

If you want to get an idea of what a Z80-based machine capable of running CP/M with some similar characteristics to the BBC micro could be like then check out the RM 480Z, and the 380Z, its predescessor.

To me the BBC micro was walking in an interesting middle ground. I didn't assume you would have the money to buy disks and resorted to ROM to hold the software that needed to be loaded quickly but at the same time had a clean separation between BASIC interpreter and OS so other languages could be run too. At the same time it didn't indulge in the extreme cost engineering that Sinclair was so good at, at the cost of performance, of course.

to me the z80 always looks like a confused complicated non-orthagonal cpu

JGH pointed out that the 8bit operations are very regular. Yes, the register pairs have specific roles - one of them is for (HL), i.e. the contents of the memory whose address in in HL, to act like any eight bit register. LDIR, with it's specific use of three of the register pairs it a bit of special case.

On the 6502 the two index registers X and Y are not exactly equivalent, either. Look at the indirect-indexed and indexed-indirect addressing modes where you can write:

Code: Select all

LDA (02,X)

or

Code: Select all

LDA (02),Y

but not the other way round, i.e. if you want the index to happen first then you have to use X, if you want the indirection to happen first you have to use Y.

I have never written a project the size of a BASIC interpreter on either processor but I did learn assembly language on the Z80 first and then the 6502. On the Z80 ytou can keep more in registers as there are more of them, but then you need more of them because many instructions work on only a register value (or (HL)). On the 6502, you have page zero which is like half-way house - quicker to access than the rest of memory, usuable as an operand in most instuctions, but slower than a real register. These things make it hard to draw any conclusions about performance. Empirical wisdom seems to be that you need to clock a Z80 about twice as fast as a 6502 for the same general performance, but then the parts generally available were suitable for clocking twice as fast - the 6502A is 2Mhz and the Z80A is 4Mhz. There were plenty of successful machines using both and there were certainly other factors that influences the performance and other characteristics of the machine other than the choice of processor.

[Coeus]

It exists. OSWORD &7F. The DFS translates that to whatever hardware frobbing the hardware needs regardless of what that hardware is, the programmer just sees OSWORD &7F. As with the entire Acorn philosphy. Hardware specifics are hidden behind APIs, and as long as you behave yourself and use the APIs everything works.

Well that does offer sector-level access to the disk but it really is a thin wrapper around the 8271, i.e. it takes away the need to know the address at which the registers appear or writing your own NMI routine but you're still using the 8271 command set and subject to the 8271 way of doing things. I was thinking of something just a fraction higher level that would be easier for those using non-8271 hardware to implement.

[Deleted User 9295]

I had thought CP/M had a BIOS/API (I know it didn't really hide graphics differences)

The graphics, sound, input/output etc. facilities are just as important (probably more so) than the simplistic system management provided by the CP/M BIOS, so that doesn't really help. It would still have needed common hardware and associated firmware to be developed first, for the various manufacturers to adopt, to achieve an acceptable degree of compatibility. I wonder if you were actually around in 1981, because some of your suggestions don't seem very realistic in the context of that era.

I had thought a machine compiler (perfect memory) would cope better a shortage of orthagonality than a human who must remember that one instruction can do something when another can't (even if desirable).

Hardly any software was 'machine compiled' for the 6502 and Z80! We are talking about a time when virtually all system programming was in hand-crafted assembler, because that was usually essential for performance and code size reasons. CPUs of the day were designed with that in mind.

The 6502 seems elegant to me, the z80 doesn't somehow: However I've never had to program a z80. I am guessing you prefer the z80 then

It's not really a case of "preference" but of experience. I've never programmed a 6502, or a 16032, or a 68000, or an ARM - and I've never had the urge to! The first microprocessor I ever programmed was the Intel 4004 (or possibly the similar 4040), a 4-bit CPU. Later I purchased an 8080 development board as a kit, which I turned into a complete 'computer' by adding a keyboard and a minimal VDU based on TTL chips (photo below); this was at a time when home computers didn't really exist. From then I worked my way through the 'Intel-family' of CPUs: the Z80, 8086/8088, 80386 etc. up to the IA-32 and x64 processors of today.



Richard.

[B3_B3_B3]

... I wonder if you were actually around in 1981, because some of your suggestions don't seem very realistic in the context of that era.
....

I was...in still in school... I think I got a BBC (with OS 0.1) around time of the 1st issue of the Micro User. Deathwatch was a very good game for a type-in....
All I know about CP/M is that the complaint seemed to be that it was meant to be a standard OS for different computers but different versions of some applications (eg of WordStar) were often required to cope with different graphics hardware on each make so a bit flawed.

[danielj]

All I know about CP/M is that the complaint seemed to be that it was meant to be a standard OS for different computers but different versions of some applications (eg of WordStar) were often required to cope with different graphics hardware on each make so a bit flawed.

Not sure who was complaining about CP/M... It was a standard OS. Z80 programs written for CP/M would run on it happily on any Z80 computer assuming there was enough memory. If they needed complex displays (i.e. more than single line input/output), then invariably they would need the escape sequences to control the screen or printer altered. At the time CP/M was written, people would consider output as something that was hugely variable (LPR, CON, TTY etc), it wasn't the OS's responsibility to format things appropriately or even know about the display hardware, just chuck what the software told it to at the relevant output stream and then let the hardware on the end of that output stream work out what to do with what it received.

Many programs you would buy would allow you to enter the relevant escape sequences to drive the output hardware (screen/printer) attached to the processor you were running it on. Turbo Pascal springs to mind.

I've been happily able to run software from here: http://www.classiccmp.org/cpmarchives/ on a BBC with a Torch Z80 Coprocessor running CP/N (a CP/M alike) without having to make any changes at all.

d.

[Deleted User 9295]

but different versions of some applications (eg of WordStar) were often required to cope with different graphics hardware on each make so a bit flawed.

I don't think you can blame CP/M for being "flawed" for that reason; when it was introduced home computers didn't really 'do' graphics, they were text-based machines. Even when graphics-capable displays became common and well-defined OS interfaces were available (such as the BBC Micro's VDU drivers) application programs often accessed the screen memory directly for reasons of speed and/or to achieve effects not supported by the drivers. That remained true throughout the MS-DOS era, when at least there was some hardware standardisation (CGA, EGA, VGA etc.) because of all the IBM-PC clones.

It wasn't really until the advent of Windows, and the proliferation of different display resolutions and bit depths, that driving the graphics display via standardised APIs became the norm. From Windows 95 onwards (if not before) the physical screen memory wasn't even mapped into the process's address space, making direct pokes difficult or impossible. Now we have GPUs, with the graphics memory often not being directly accessible by the main CPU at all, and highly-abstracted interfaces like DirectX or OpenGL.

Richard.

[paulb]

I had thought a machine compiler (perfect memory) would cope better a shortage of orthagonality than a human who must remember that one instruction can do something when another can't (even if desirable).

Hardly any software was 'machine compiled' for the 6502 and Z80! We are talking about a time when virtually all system programming was in hand-crafted assembler, because that was usually essential for performance and code size reasons. CPUs of the day were designed with that in mind.

Systems programming on larger machines had surely moved on to higher-level languages, though. And aside from orthogonal instruction sets being nicer for assembly language programmers, the reason for companies like DEC to migrate from the VAX architecture to MIPS and eventually Alpha had a lot to do with making it easier for compilers to target the hardware. It would seem that the 68000, which was already around in 1980 and became quite affordable in the following years, was designed to facilitate the use of high-level languages.

[BigEd]

Somewhat parenthetically, the Z80 and 6502 designs were already fairly old when they were adopted for the 8 bit home computer revolution. The problem with chip designs is that they get harder as you add complexity, and each time you do that, you find problems you've not had to tackle before. It's always a learning experience and there are almost always delays. Here's a timeline of the 68000 life story:

A 68000 CHRONOLOGY:
1975: design study of advanced microprocessor commences.
1976: design solidifies; 32-bit registers and address pointers adopted.
1977: availability of 68000 is promised for 1978.
1978 - 1979: continual promises that the 68000 will be available "real soon now"
1979: Motorola sees first silicon for the 68000.
Feb 1980: 4MHz 68000 available as part of $2000 demo board.
Nov 1980: first sale of 8MHz 68000 across the counter.
Jun 1982: 12.5MHz 68000 available across the counter.
Aug 1982: 8-bit data bus version of 68000 sees first silicon and - gasp! - works!
1983: virtual-memory version (68010) developed.
1983: Hitachi shrinks mask set to 2.7 micron design rules and becomes second source for 12.5MHz 68000s.
Sep 1983: floating point math chip support for 12MHz 68000 arrives - the Nat Semi 16081 (engineering samples only).
Feb 1984: Motorola anxiously awaits impending 68020 first silicon.

That's from the lively and not necessarily accurate newsletter DTACK Grounded, at
http://www.easy68k.com/paulrsm/dg/dg29.htm

[1024MAK]

And of course it should be said that apparently both the 6502 and the Z80 primary markets were expected to be embedded systems and such like rather than as general purpose CPUs for computers.

Mark

[Coeus]

I had thought a machine compiler (perfect memory) would cope better a shortage of orthagonality than a human who must remember that one instruction can do something when another can't (even if desirable).

Hardly any software was 'machine compiled' for the 6502 and Z80! We are talking about a time when virtually all system programming was in hand-crafted assembler, because that was usually essential for performance and code size reasons. CPUs of the day were designed with that in mind.

It is interesting to look at the implementation of high-level languages on the BBC. BASIC is interpreted. BCPL and Pascal are both compiled to an intermediate code (CINTCODE for BCPL, BL-code for Pascal) for reasons of compactness. Forth is interpreted, though some of the nucleus words are implemented as native code.

Part of the difficulty here is that the high level languages tend to use data types that are not native to an 8bit processor, for example 16 or 32 bit integers, floating point numbers or strings If you compiled such a language to native code it would become just a series of subroutine calls to manipulate values of those types interpersed with branch instructions. Given the memory contraints of typical 8bit microprocessor it makes more sense to represent those subroutine calls as single byte opcodes for a virtual machine with the other part of the definition of such a virtual machine, i.e. virtual registers, virtual stack, etc. completing the picture. So, as an example I could write suboutine to add two 32bit integers and set out as a calling convention that the first number is stored in zero page at 00-03, the second at 04-07 and the result is returned to 00-03. The intermediate code version of this would be to give this an opcode (01, for example) and designate 00-04 as forming a virtual 32bit integer accumulator and 04-07 as a virtual 'B' register.

Returning to CP/M it seems Gary Kildall, who wrote CP/M, also wrote a compiler (in FORTRAN) for a language called PL/M specifcally designed to be able to be compiled to 8bit processor code. He then went on to write early versions of CP/M in it. It is interesting to note, though, that CP/M 2.2 was written in native assembler and you can draw your own conclusions from that.

[Coeus]

Systems programming on larger machines had surely moved on to higher-level languages, though. And aside from orthogonal instruction sets being nicer for assembly language programmers, the reason for companies like DEC to migrate from the VAX architecture to MIPS and eventually Alpha had a lot to do with making it easier for compilers to target the hardware. It would seem that the 68000, which was already around in 1980 and became quite affordable in the following years, was designed to facilitate the use of high-level languages.

And that suitability would be one reason compilers for 68000-based Unix workstations didn't have any of the nonsense PC compilers had of differnt memory models to cope with how to handle the segmented architecture of the 8086 family.

Hmmm, I had thought a machine compiler (perfect memory) would cope better a shortage of orthagonality than a human who must remember that one instruction can do something when another can't...

Notwithstanding the comments about how few compilers targetted 8bit microprocessors, when microprocessors got to the point where they were reasonable targets for the high level languages used on larger computers the compiler writers would be aiming to keep their compilers portable so they'd prefer not to spend too much time tuning up the code generation for a particularly quirky processor.

And of course it should be said that apparently both the 6502 and the Z80 primary markets were expected to be embedded systems and such like rather than as general purpose CPUs for computers.

You remind me of "computer studies" at school and talk of processors having a multiply instruction and I was thinking "none of microprocessors I know has such a thing". That course was oriented towards mainframe computing and home micros were a new thing and probably a bit of a surpise to many.

Somewhat parenthetically, the Z80 and 6502 designs were already fairly old when they were adopted for the 8 bit home computer revolution.

Old, enough, presumably, that they had become a commodity. No-one was going to pay to include a leading-edge microprocessor in a home computer, at least not at that time.

[Deleted User 9295]

Given the memory contraints of typical 8bit microprocessor it makes more sense to represent those subroutine calls as single byte opcodes for a virtual machine

Indeed, and not just for 8-bit CPUs either. Consider how many of the popular programming languages today use a compact byte code executed by some kind of VM, for example Java, Python and the .NET suite. Even though memory size is not the limitation it was, memory bandwidth still is so reducing the size of the code so more will fit in an on-chip cache is valuable.

a language called PL/M specifcally designed to be able to be compiled to 8bit processor code.

Worth noting that this was a cut-down version of PL/1.

CP/M 2.2 was written in native assembler and you can draw your own conclusions from that.

Early versions of Windows too; even Windows 95 had a significant amount of assembler code. Only with Windows NT did it transition to being mostly coded in a high-level language.

Richard.

[davidb]

And that suitability would be one reason compilers for 68000-based Unix workstations didn't have any of the nonsense PC compilers had of differnt memory models to cope with how to handle the segmented architecture of the 8086 family.

As an aside, I should mention the current article by Jimmy Maher on The Digital Antiquarian site.

You remind me of "computer studies" at school and talk of processors having a multiply instruction and I was thinking "none of microprocessors I know has such a thing". That course was oriented towards mainframe computing and home micros were a new thing and probably a bit of a surpise to many.

These days, even 8-bit processors have multiply instructions, as I discovered when I looked at the Atmel ATmega168 a few years ago.

[firthmj]

Early versions of Windows too; even Windows 95 had a significant amount of assembler code. Only with Windows NT did it transition to being mostly coded in a high-level language.

Richard.

One notable difference between Windows and sensible other operating systems is that Windows from 1.0 through to Millennium Edition exclusively targeted the X86 processor family.

Unixes were designed to be portable, which probably explains why they were written in high level languages before Windows was.

Windows NT was itself originally aimed at portability - I believe Windows NT 3.5 was available on PowerPC and Alpha as well as X86. This probably explains NT being written in a high level language too.

I will refrain from any comments about the relative stability of Windows 9x, Unix and Windows NT!

[B3_B3_B3]

As well as compilers making P-code there was also Woz's approach of a pretend processor (Sweet<N> where N was 16 for the one Woz made for Apple Integer Basic*), Whose pretend instructions could be easily mixed with native 6502. Unfortunately, there appears to be no Sweet32 .

* http://www.6502.org/source/interpreters/sweet16.htm

Where do you get the impression that there was any kind of graphical support in CP/M?

EDIT I just remembered a criticism of CP/M that different versions of an application were required for different CP/M machines: I think it may have mentioned/or I thought it implied graphics hardware as a reason.

to me the z80 always looks like a confused complicated non-orthagonal cpu

JGH pointed out that the 8bit operations are very regular. Yes, the register pairs have specific roles - one of them is for (HL), i.e. the contents of the memory whose address in in HL, to act like any eight bit register. LDIR, with it's specific use of three of the register pairs it a bit of special case.
On the 6502 the two index registers X and Y are not exactly equivalent, either. Look at the indirect-indexed and indexed-indirect addressing modes where you can write:

Yes, I know about the difference in Y and X on a 6502 but that seems a reasonable easy to remember compromise. The comparison I remember was that 1Mhz EDIT 6809 (NOT 6502) outperforms 3.5Mhz z80 END_EDIT I definitely remember but the 2Mhz BBC being reported as faster than a 3.5Mhz spectrum . The criticism of a z80 I remembered is that addressing modes do not necessarily apply very consistently across instructions.

But I didn;t mean to cause massive thread drift by an aside: perhaps mods could split thread perhaps (and lock the z80 vs 6502 child thread).

Also, I read Mr Zaks z80 book (the opposite of the 6502 one I used to use) and he mentioned that the z80 loop instructions are slower and surprisingly not even more code efficient than a plain 6502 indexed loop: perhaps there are some counter examples he skipped...

At which clock speeds? The two CPUs use very different internal circuitry, so you cannot compare the two CPUs when run at the same clock speed.

Yes I know, that: as far as I remember the comparison took all that into account (otherwise I would have remembered it as an unfair comparison).
The mention of 6502 vs z80 was kind of an aside: perhaps it could be split into its own thread.

[B3_B3_B3]

Meanwhile, back on thread:

but different versions of some applications (eg of WordStar) were often required ..

I don't think you can blame CP/M for being "flawed" for that reason.

But was adding a graphics display interface and some interfacing ports with a common BASIC to an agreed standard (even if had to be accessed via a new API/via common addresses) really so difficult for the established CP/M manufacturers when Acorn managed it?
Was the lack of experience with the SAA5050 (which Acorn already had) the camel that broke their collective backs? Did they just not want to collaborate?
Or did they just think the potential return was not worth the effort? (I would bet on that )
Or as was suggested earlier was the fact that CP/M is disk based unhelpful.

About teletext: why does it differ slighty from Ascii in the range 32-127decimal?

[Coeus]

I will refrain from any comments about the relative stability of Windows 9x, Unix and Windows NT!

From my experience:

• The Unixes were very stable - they just didn't crash.
• NT was basically stable once you had a stable set of drivers.
• The Windows versions that ran on top of DOS were notably unstable.

Regarding the difference between NT (and I thinking 3.5 owards) and the the Unixes I am not sure if it has anything to do with the quality of the code or the processes around it - it might simply be that while the Unix core was portable, by the time it was turned into a commercial OS it was supported on a narrow range of hardware supplied by the same company as the OS so the drivers were tested on that hardware by that same company. With NT, there was a wider range of hardware - graphics cards in particular seemed to have dodgy drivers. That said, Linux is very stable and that runs on a very wide range of processors and on PCs with a variety of graphics cards too.

The really big gap was between those two and the DOS-based Windows. In the area I worked in at the time we abandoned DOS-based Windows and ran NT instead on most desktops resulting in much less frustration. There was the odd application that wouldn't run on NT so we kept one PC running whatever the current DOS-based Windows was which people could connect to with VNC to run the vagrant applications.

[Coeus]

But was adding a graphics display interface and some interfacing ports with a common BASIC to an agreed standard (even if had to be accessed via a new API/via common addresses) really so difficult for the established CP/M manufacturers when Acorn managed it?

So Research Machine was already a supplier of Z80-based machines which, if equipped with a disk drive, could run CP/M and which also had, at least if you bought the option, graphics capability. They apparently said implementing the specification was too expensive. I don't know if they were referring to the development cost or the cost of assembly once designed but clearly if there is more than one compatible design each gets a smaller share of the eventual market and yet each still costs as much to develeop as one single design would.

Did they just not want to collaborate?

For companies to collaborate in a market they also compete in they have to be convinced that the collaboration will create demand and thus expand that market so there is still plenty for all involved. Or to spin that in a negative way that no one party is able to lock consumers in so fairure to collaborate and ensure compatibility as consumers, concerned about the lack of interopability, would simply buy nothing at all and cause the market to dry up.

About teletext: why does it differ slighty from Ascii in the range 32-127decimal?

At the time it was common practice to use only a 7 bit character set as parity was often used on communication lines. That meant if one needed specific characters for a particular system it was normal to find some little used characters, or characters that served a similar function, from the ASCII set and replace them with your new ones. The practice even got standardised by ISO with the intention that if your goal was to make the character set suitable for a particular language or country, for example by including a particular currency symbol, everyone who made such a subsitution made a the same one and could thus exchange files.

8 bit character sets which could each usually cope with more than one language came later and then finally, unicode which we pretty much take for granted these days. While we are looking back with the benefit of hindsight another glaring error was to adopt 16 bit unicode characters. No doubt it was intended to trade the extra storage requirement for typical English text for havinga fixed number of bits per character and thus be able to index into strings as one would an array, and as one did with 8 bit characters sets. It didn't work that way in the end, though, as the number of unicode code points has exceeded 65536 so now 16bit unicode systems will actually work with UTF-16 which has the worst possibly characteristics - wasted space for simple English text and variable-length characters.

[B3_B3_B3]

About teletext: why does it differ slighty from Ascii in the range 32-127decimal?

At the time it was common practice to use only a 7 bit character set as parity was often used on communication lines. That meant if one needed specific characters for a particular system it was normal to find some little used characters, or characters that served a similar function, from the ASCII set and replace them with your new ones.....

But some were actually just moved so BBC BASIC remapped them 'back' to match ascii:

from http://www.bbcbasic.co.uk/bbcwin/manual/bbcwinh.html

As with the BBC Micro, the codes for # (hash) £ (pound) and _ (underscore) are 'shuffled' so as to display as expected, rather than using the Videotex codes. To force use of the standard Videotex codes (such as would be required for displaying a Teletext page) set bit 7 of the stored characters, i.e. add 128 to their normal ASCII values.

It seems a bit strange for teletext to support them but at a different code from plain ascii.

[1024MAK]

You have to keep in mind that there was NO FULLY STANDARD character set at the time. Yes ASCII was used by some computers, but not by all (ZX80, ZX81, various Commodore computers all used different character sets - PETSCII).

The teletext character set was designed for use with teletext TV transmissions - teletext was a British design. While ASCII is an American attempt at a "standard". So it is not that surprising that there are differences.

Mark

[jgharston]

But some were actually just moved so BBC BASIC remapped them 'back' to match ascii:

No it doesn't, the VDU driver does.

Why do I have to keep saying this? BASIC knows ABSOLUTELY NOTHING about the I/O system, it merely solely just only sends output to the operating system for the operating system to do whatever the hell the operating system choses to do with it. BASIC knows and cares ABSOLUTELY NOTHING about what the operating system does with it.

[Deleted User 9295]

It seems a bit strange for teletext to support them but at a different code from plain ascii.

But that's not what happened. The only character to exist in both the ASCII and Teletext character sets, but at different code points, is hash (#). The other characters you refer to are not present in both: grave accent (`) and underscore (_) are in ASCII but not in Teletext; pound (£) and wide-bar (—) are in Teletext but not in ASCII.

Nor is there anything "strange" about allocating the pound sign to code &23, because this is the standard code for that symbol in the ISO-7-UK character set. Since Teletext was (at that stage at least) a specifically UK system it is not at all surprising that it chose to use a character encoding based on ISO-7-UK.

Richard.

[B3_B3_B3]

Why do I have to keep saying this? BASIC knows ABSOLUTELY NOTHING about the I/O system, it merely solely just only sends output to the operating system for the operating system to do whatever the hell the operating system choses to do with it. BASIC knows and cares ABSOLUTELY NOTHING about what the operating system does with it.

Sorry, I do actually know that is true for an actual BBC: but the BBC BASIC site I quoted covers BBC BASIC for other machines so I thoughtlessly typed BBC BASIC without further explanation However expect Mr Richard Russell simply writes a 'mini-MOS' of VDU drivers etc for each machine he ports to rather than delving within his interpreter code.

Interesting about the teletext codes.
Is there a reason so many other symbols differ from ascii in teletext character-codes eg I don't remember seeing fractions on Ceefax pages (but maybe I missed them/remember wrong...)?

[1024MAK]

Do you remember the half pence?

And the other fractions were sometimes in in recipe pages.

Mark

[Deleted User 9295]

Do you remember the half pence?

Ahem, I think you mean "halfpenny" (pronounced ha'penny)

Richard.

[B3_B3_B3]

Do you remember the half penny?

And the other fractions were sometimes in in recipe pages.....

I remember those 1/2p coins but not seeing fractions on Ceefax (I don't think looked/looked closely at recipes ).
]

[alk0v]

Hello, guys. I'm writing an article about the history of the appearance of BBC Micro and trying to find information about what prototypes were proposed for the competition from Sinclair and Tangerine. Does anybody has information about this?

[jonb]

Just a footnote about CP/M as I am a fan of it

• There was no standardised disk format (such as there was for DOS) and this meant that software providers had to produce different distributions of their code (the code itself largely unchanged; only the disk format was different). Naturally this cost them.
• There was a standardised graphical API for CP/M called GSX: http://www.seasip.info/Cpm/gsx.html. It did come rather late to the party, though.
• CP/M rocks because it is quite easy for a single person to understand (even one as thick as me!). I've even written device drivers for it. Of course, it helps that I can speak in pidgin Z80, whereas 6502 is just so much gobbledygook to me. For example, I know how to say "Where is the bar / toilet / hotel?" in Z80.