How do you stop the helium leaking out, or have you managed to replace the laser with a semiconductor variety? I've heard stories of 'rejuvenating' HeNe lasers by leaving them in a helium-rich atmosphere for a while (so some helium leaks back in) but I've never been sure if they are genuine.RobC wrote:Several of us on here have working systems although they are quite temperamental!
It's still using the original laser as far as I know.Richard Russell wrote:How do you stop the helium leaking out, or have you managed to replace the laser with a semiconductor variety? I've heard stories of 'rejuvenating' HeNe lasers by leaving them in a helium-rich atmosphere for a while (so some helium leaks back in) but I've never been sure if they are genuine.
Ooo, did it use those thin characters to get higher-colour modes? Eg:RobC wrote:The Domesday system uses mode 1 mainly and even has its own font for mode 2:
http://www.beebmaster.co.uk/Domesday/DFont2.html
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_I think you're jolly lucky that it's still working. I've found a reference to rejuvenating HeNe lasers in the American Journal of Physics (although only the abstract is available to read online) so it seems it's not a myth.RobC wrote:It's still using the original laser as far as I know.
Yes, it definitely did, but only under certain circumstances (when more colours needed, I suppose). This is something I remember seeing when I used one at school, and I remember being impressed by what I saw as "game author's" technique in a serious application. Also, the normal-width character set was subtly altered (eg, no slash through zeros).jgharston wrote:Ooo, did it use those thin characters to get higher-colour modes?
Where's the Like button when you need it?!jms2 wrote:(eg, no slash through zeros).
Just to be clear, I wasn't doubting you. Have to admit that this isn't something I was aware of but I'm happy to take your word for it.Richard Russell wrote:I think you're jolly lucky that it's still working. I've found a reference to rejuvenating HeNe lasers in the American Journal of Physics (although only the abstract is available to read online) so it seems it's not a myth.
The link I posted earlier shows the differences in the mode 1 fonts and says that the thin mode 2 font was used to display charts (where the extra colours are useful).jms2 wrote:Yes, it definitely did, but only under certain circumstances (when more colours needed, I suppose). This is something I remember seeing when I used one at school, and I remember being impressed by what I saw as "game author's" technique in a serious application. Also, the normal-width character set was subtly altered (eg, no slash through zeros).jgharston wrote:Ooo, did it use those thin characters to get higher-colour modes?
I never thought you were; I did a Google search for my own interest. I know that Helium can leak through glass (slowly) and eventually this alters the mixture enough to stop the laser working. I expect keeping the machine switched off and in a cool environment helps to extend its life.RobC wrote:I wasn't doubting you.
I always assumed the player used a solid-state laser, the switch-over from tube to solid-state was 1984 - https://en.wikipedia.org/wiki/Laserdisc ... technologyRichard Russell wrote:How do you stop the helium leaking out, or have you managed to replace the laser with a semiconductor variety? I've heard stories of 'rejuvenating' HeNe lasers by leaving them in a helium-rich atmosphere for a while (so some helium leaks back in) but I've never been sure if they are genuine.RobC wrote:Several of us on here have working systems although they are quite temperamental!
I can't say I'm 100% sure, no. I thought all Philips LaserVision players used HeNe lasers; if they switched to semiconductor lasers at some point I wasn't aware of it, although since CD players were around by 1986 the technology must have been available. Hopefully you're right, which might give them a longer life - until a mechanical failure anyway.IanS wrote:Are you sure the Domesday player was a tube?
From what references I can find it looks as though the transition to semiconductor lasers was happening concurrently with the Domesday Project, which makes it hard to be sure one way or the other. I note that the HeNe lasers gave better video performance, which perhaps might have been a factor in this case. If anybody here with a working setup dares to take the top of the player I think it should be fairly obvious. If there's a gas laser it will be quite a large item, with a high-voltage feed, I would expect - and probably with a warning sticker.Richard Russell wrote:I don't know about the Philips machines.
I would agree with you - if I were to guess on the basis of that photo I'd say it's most probably a semiconductor laser. If so, it worries me somewhat - given the nature of the video material - that (if Wikipedia is to be believed) picture quality may have suffered as a result.danielj wrote:Doesn't look like there's a big old tube in there?
Good to know for sure. I expect my recollection was of the Laservision players available at the start of the project, which would have been when they still used HeNe lasers. Sadly it doesn't eliminate laser aging as a cause of failure, and rejuvenation wouldn't be an option! But at least it shouldn't deteriorate whilst switched off.RobC wrote:"A Solid State laser emits a diverging laser beam"...
By coincidence Computerphile on YouTube put-up a video about the Domesday system at the weekend (the title is clickbait) and it looks like both the hardware and laserdiscs (the edges of one of discs shown appears to be 'rotting' away) are becoming a problem. They also show some other laserdiscs that were produced for the system that I was never aware of.Richard Russell wrote: The information provided by schools included both photographs and text, and my recollection is that the textual content was displayed in MODE 7. But I can't be certain, and the only way of ascertaining for sure (in the absence of evidence from screen shots) would be to run up a working system - and I'm not sure there are any left (keeping the Helium-Neon lasers going was a real problem). It may be that the Camileon emulation would be another way of finding out, but I don't think that is available now either.
Interesting video but look at the comments! If I ever needed convincing that my refusal to give recorded interviews was justified....algenon_iii wrote:By coincidence Computerphile on YouTube put-up a video about the Domesday system at the weekend
I never (well, almost never) read the comments on the ones I do for Computerphile -- not worth the aggroRichard Russell wrote:Interesting video but look at the comments! If I ever needed convincing that my refusal to give recorded interviews was justified.....algenon_iii wrote:By coincidence Computerphile on YouTube put-up a video about the Domesday system at the weekend
I found a quote from Chris Curry in an article in Your Computer (October 1981, lightly edited):Richard Russell wrote:I know no more than what can be deduced from that Acorn document, i.e. that Super BASIC was an "enlarged version of ATOM BASIC very similar in power to Microsoft, and with some extensions". So it definitely wasn't what was "shipped with every Atom", but you'd have to ask Sophie to what extent BBC BASIC was developed from it, or from scratch.hoglet wrote: Was Atom Super-BASIC not actually an early version of what became BBC Basic?
Or is it just another name for the Basic that shipped on ROM with every Acorn Atom?
It's not even clear to me whether Super BASIC was ever an available product or just something that Sophie was working on at the time the BBC proposal was prepared. So it could be that it morphed into BBC BASIC before even being completed.
Nearby, from the June/July issue, there's an article by Martin Hayman "BBC's Proton Project and the Nuclear Family"Before the BBC contract arrived Sophie at Acorn was writing a development of the Atom Basic which would have brought it more into line with languages such as Pascal and Comal. In the end, however, the BBC contract forced them to move back towards a Basic compatible with Microsoft.
“We have ended up with a compromise that doesn’t actually lose the features of Sophie's original ideas. We are confident that the Basic we are using for the BBC is as good as anyone can make it. It covers all of the Microsoft and all the good points of Sophie's original Basic. It meets just about everyone’s criteria of what they need out of Basic. It meets Microsoft 5; it does what Comal does; it is a structured Basic; it’s fast and it has upward-compatibility from the Atom Basic.
Controversy is still surging back and forth over the BBC's decision to put Acorn into the front-line by choosing an adaptation of its forthcoming Proton model as the "standard" micro for the 1982 series, Hands-on micros. Yet, as Your Computer has found, the programme makers are not daunted by the doubters and backbiters from the ranks of the microcomputer professionals and are pushing ahead with their initiative to popularise computing by putting it into every home.
Does anyone know whether the draft specification which was supposed to be "available on request" for BBC BASIC mentioned here exists anywhere anymore?The BBC is investigating the possibility of
supporting a version of BASIC which is not implemented
yet on any single machine but which would be as
compatible as possible with existing practice and
could be made available within the public domain to
any manufacturer willing to implement it. The specification
in draft form is available on request. Meanwhile, you will
see that the most desirable 'fallback' is specified below.
"MOS/BASIC joystick support" was provided from the beginning, using ADVAL (documented in the User Guide as being suitable for "games paddle" or "joy-stick" control). ADVAL(0) receives digital inputs (e.g. from 'fire buttons') and ADVAL(1) to ADVAL(3) analogue inputs (typically three joystick 'axes').B3_B3_B3 wrote:could have allowed MOS/BASIC Joystick support.....
The BBC would never have accepted that. The serial port was essential for 'professional' use and was one of the BBC's 'red lines' along with things like providing a broadcast-compatible baseband video output.Also, without RS423 port perhaps serial UART IC could have been dropped from main board
This is the way the Atom had worked - you could use the machine in a basic state, or start plugging extra things in to gain more functionality, the pads already existing on the PCB. Econet was implemented as a plug in module by the time of the Master. Hindsight is, as ever, 20-20 with these things. At the time people make good and bad decisions about the way to do things in light of their current experience and/or requirements that are laid out before them. Lots of these observations seem to come from looking at the Beeb through the lens of the home-user, not the educational establishments etc that were actually the main consumers here.B3_B3_B3 wrote: Would an extra internal '1Mhz' style Bus interface and IDC header for the Disc Interface have avoided needing disc interface specific ICs on main board, saving purchasing cost / giving smaller main board/ allowing design to be deferred/changed to 1770 later? Similarly for the econet section of board.
Also, it could be easier to attach a daughterboard to an IDC header than solder new chips to the motherboard.
Most of the extra interfaces you say are typically unused are not present on the Model A, though this is only by omitting the components from the PCB - the space to fit them is still there.B3_B3_B3 wrote:I always wondered about the bbc B's excessive amount of built-in ports (and thus unnecessary added cost for unused circuitry) e.g. many were unused on mine (disc and printer were eventually used):
For a personal printer, they were. I still remember going to a computer centre where we setting up equipment to capture screen dumps from a terminal - we attached a computer to the printer port and wasted much time because the technical guy at the centre concerned was adamant about the baud rate, strt & stop bits etc. Only when I fetched the protocol analyser and discovered what settings where really in use did we make any progress. You don't get that hassle with a centronics I/F. On the other hand the centronics I/F has limited cable length - you can't so easily sent to a printer in another room or even at the end of a modem.B3_B3_B3 wrote:Also, I thought Centronics printers of the time were viewed as less hassle to setup than serial....
I think this another question in the category of "Why was the BBC not better optimised for playing games" to which the answer is "that was not the focus of its design". For the TV series one would be much more likely to demonstrate controlling robotics via the joystick, hence the choice of an analogue one, capable of proportional control rather than Atari-style. It was nevertheless common practice to connect game-playing hoysticks to the analogue port and once you did that the OS support for a joystick would work fine.B3_B3_B3 wrote:An agreed(officially suggested) way of wiring Atari joysticks to user port pins could have allowed MOS/BASIC Joystick support.....
It may be a co-incidence but at the time I remember the BBC micro having much more reliable tape loading than some of the other machines of the time and it occurs to me this might be specifically because it uses a proper UART for the tape interface.B3_B3_B3 wrote:Also, without RS423 port perhaps serial UART IC could have been dropped from main board* and the cassette bit-banged like on Electron (but I suppose they were probably in a hurry_). *but moved to optional Econet daughterboard/section.
I think there is a clear design philosophy with the BBC micro to keep things neat by having things inside the single case and to me this is very much preferable to the mess of interconnected boxes that might otherwise have been. On the other hand, given that there was no room inside the case of 5 1/4" disc drives and therefore an external enclosure was needed, and given the later trend for having a power supply inside the case with the disk drives, it would have been a neater design to mount the floppy disc controller hardware on a PCB inside the enclosure with the drives and have that box then connect back to the BBC 1Mhz bus. It would also have been good to define an OSWORD interface for reading/writing raw sectors from the disk and formatting discs that wasn't tied to a specific FDC and didn't extend to doing trickery with the hardware, so that the choice of FDC would be up to whoever was supplying the DFS ROM to go with the disks. But hindsight is wonderful thing.B3_B3_B3 wrote:Would an extra internal '1Mhz' style Bus interface and IDC header for the Disc Interface have avoided needing disc interface specific ICs on main board, saving purchasing cost / giving smaller main board/ allowing design to be deferred/changed to 1770 later? Similarly for the econet section of board.
Also, it could be easier to attach a daughterboard to an IDC header than solder new chips to the motherboard.
Sorry, I meant that each daughter board would neatly fit somewhere inside the BBC case (which would have a smaller main PCB use due to said daughterboards....). So still tidy.Coeus wrote:.....Most of the extra interfaces you say are typically unused are not present on the Model A, though this is only by omitting the components from the PCB - the space to fit them is still there.
.....
I think there is a clear design philosophy with the BBC micro to keep things neat by having things inside the single case and to me this is very much preferable to the mess of interconnected boxes that might otherwise have been.....
Sorry, I was suggesting abandoning the built-in ADC for a (more replaceble) external one on a general purpose IO port as explained above: so was merely suggesting a way that joysticks could have been officially supported by Acorn.Richard Russell wrote: "MOS/BASIC joystick support" was provided from the beginning, using ADVAL (documented in the User Guide as being suitable for "games paddle" or "joy-stick" control). ADVAL(0) receives digital inputs (e.g. from 'fire buttons') and ADVAL(1) to ADVAL(3) analogue inputs (typically three joystick 'axes').....
I just meant that it was an option: I presumed affordability would have had some affect on the series popularity. Hence I wondered at the amount of built-in ports....Richard Russell wrote: The BBC would never have accepted that (no RS423). The serial port was essential for 'professional' use and was one of the BBC's 'red lines' along with things like providing a broadcast-compatible baseband video output.
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.Coeus wrote:It would also have been good to define an OSWORD interface for reading/writing raw sectors from the disk and formatting discs that wasn't tied to a specific FDC and didn't extend to doing trickery with the hardware, so that the choice of FDC would be up to whoever was supplying the DFS ROM to go with the disks.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_The degree of compatibility required could only have been achieved using identical circuitry and identical firmware (we're not talking about a utopia where all application software operates through well defined APIs) so somebody would still have needed to design the guts of the machine before farming it out to different companies to apply their 'branding' (enclosure, keyboard etc.). I can't think of any commercial or economic model that could have achieved that, certainly not in the timescale.B3_B3_B3 wrote:it would almost have seem to have made more sense to specify a new subset of CP/M (ie with compatible graphics/screen)...
The Newbrain, which everybody assumed would become the BBC Micro, was a Z80 machine.z80 focus looks like the BBC may have originally thought that too?
Non-orthogonal, yes (all 8080-derived CPUs have been, even to the present day with the 64-bit x86 architecture to a degree), but you say that as though it is a bad thing. My view is that with limited chip resources, and most software being hand-coded in assembler, being non-orthogonal had an advantage because you get a more flexible instruction set for a given gate count and op-code space (for example the auto-repeated instructions such as CPIR, LDIR etc. were only possible because of dedicating the BC register pair to 'count', the DE register pair to 'destination' and the HL register pair to 'source').to me the z80 always looks like a confused complicated non-orthagonal cpu
B3_B3_B3 wrote:it would almost have seem to have made more sense to specify a new subset of CP/M (ie with compatible graphics/screen)...
I had thought CP/M had a BIOS/API (I know it didn't really hide graphics differences), so perhaps same graphics hardware, perhaps same analog/user interface port hardware but I thought CP/M would allow a lot of commonality: so if manufacturer made a new graphic and interface port daughterboard/ main board they could have had a slice of BBC computer profit.... It seems perhaps CP/M was less impressive than I thought and so it was not worth the BBC commissioning an independent company to design a common BBC CP/M graphics standard and experimental interfaces (ADC /digital IO user port) circuit/board/standard? I had (mistakenly it seems) assumed that updating a CP/M computer's graphics circuitry and adding some common interface ports would be less work than building a BBC B from scratch whilst allowing any manufacturer who wanted a slice of the pie to have some. I suppose the CP/M manufacturers didn't think the pie was a big enough. I wonder if it was the computers in schools in the 80's subsidy that multiplied the pie size....Replying, Richard Russell wrote:The degree of compatibility required could only have been achieved using identical circuitry and identical firmware (we're not talking about a utopia where all application software operates through well defined APIs) so somebody would still have needed to design the guts of the machine before farming it out to different companies to apply their 'branding' (enclosure, keyboard etc.). I can't think of any commercial or economic model that could have achieved that, certainly not in the timescale.
to me the z80 always looks like a confused complicated non-orthagonal cpu
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 (even if desirable). 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...Replying, Richard Russell wrote: [Non-orthogonal, yes (all 8080-derived CPUs have been, even to the present day with the 64-bit x86 architecture to a degree), but you say that as though it is a bad thing. My view is that with limited chip resources, and most software being hand-coded in assembler, being non-orthogonal had an advantage because you get a more flexible instruction set for a given gate count and op-code space (for example the auto-repeated instructions such as CPIR, LDIR etc. were only possible because of dedicating the BC register pair to 'count', the DE register pair to 'destination' and the HL register pair to 'source').