Frnak McKenney wrote:> Ah, I miss Das Blinkenlights... <grin!>I remember the strange feeling with the first home brew computer I built that did not have a blinking light and switches console. I was convinced that it would never be able to run or debug anything. The feeling went away soon enough. I could still key in the boot code on a pdp11 with my eye's closed. Regards, w.. -- Walter Banks Byte Craft Limited http://www.bytecraft.com
Pipelined 6502/z80 with cache and 16x clock multiplier
Started by ●December 19, 2010
Reply by ●January 12, 20112011-01-12
Reply by ●January 12, 20112011-01-12
In article <4D2DC656.B2A7942F@bytecraft.com>, Walter Banks <walter@bytecraft.com> wrote:>Frnak McKenney wrote: > >> Ah, I miss Das Blinkenlights... <grin!> > >I remember the strange feeling with the first home >brew computer I built that did not have a blinking light >and switches console. I was convinced that it would >never be able to run or debug anything.That would depend on how hard it was to get access to the initial peripherals! I once had a Fortran compiler for testing that had no I/O support. No input, no output and no file access. I did check that it used Fortran 77 DO-loop semantics and told the salesman it was useless. When I had explained why, he then asked "Other than that, what did you think of it?" I suspect that being faced with a peripheral-free CPU would be very comparable :-) Regards, Nick Maclaren.
Reply by ●January 12, 20112011-01-12
In article <nf3108-g6d1.ln1@ntp6.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:>> >> I once had a Fortran compiler for testing that had no I/O support. >> No input, no output and no file access. I did check that it used > >So how were you supposed to feed in data?God alone knows.>> Fortran 77 DO-loop semantics and told the salesman it was useless. >> When I had explained why, he then asked "Other than that, what did >> you think of it?" > >I'm trying to think how the developers of said compiler could ever tell >that it was actually doing anything?Dunno, but I know how I did - being a mad hacker from way back, as you know :-) I used a ternary output mechanism: it stopped normally, it crashed horribly, or it looped forever.>Did they always run it from the debugger and manually inspected the >current data structures?What debugger? :-)>> I suspect that being faced with a peripheral-free CPU would be very >> comparable :-) > >Yeah...your (hw) debugger is the only possible tool?But, without any peripherals, how do you connect it? :-) Regards, Nick Maclaren.
Reply by ●January 12, 20112011-01-12
nmm1@cam.ac.uk wrote:> In article<4D2DC656.B2A7942F@bytecraft.com>, > Walter Banks<walter@bytecraft.com> wrote: >> Frnak McKenney wrote: >> >>> Ah, I miss Das Blinkenlights...<grin!> >> >> I remember the strange feeling with the first home >> brew computer I built that did not have a blinking light >> and switches console. I was convinced that it would >> never be able to run or debug anything. > > That would depend on how hard it was to get access to the initial > peripherals! > > I once had a Fortran compiler for testing that had no I/O support. > No input, no output and no file access. I did check that it usedSo how were you supposed to feed in data? In the form of program declarations, similar to BASIC's DATA statements?> Fortran 77 DO-loop semantics and told the salesman it was useless. > When I had explained why, he then asked "Other than that, what did > you think of it?"I'm trying to think how the developers of said compiler could ever tell that it was actually doing anything? Did they always run it from the debugger and manually inspected the current data structures?> > I suspect that being faced with a peripheral-free CPU would be very > comparable :-)Yeah...your (hw) debugger is the only possible tool? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
Reply by ●January 12, 20112011-01-12
In article <aVlXo.32847$My1.1809@newsfe16.iad>, EricP <ThatWouldBeTelling@thevillage.com> wrote:>Terje Mathisen wrote: >>> >>> I once had a Fortran compiler for testing that had no I/O support. >>> No input, no output and no file access. I did check that it used >> >> So how were you supposed to feed in data? > >You call subroutines not written in Fortran.Nice try, but no banana. It used a C-incompatible calling sequence, and there was no assembler. I baulked at creating object decks using the available tools - such as ed and cat - especially with no specification. I said "useless" and I meant just that! That's what I told the salesdroid, too. Regards, Nick Maclaren.
Reply by ●January 12, 20112011-01-12
In article <897a0e6d-2d0b-46f6-990e-6be61d0fe3f4@f2g2000vby.googlegroups.com>, Robert Myers <rbmyersusa@gmail.com> wrote:>> >> I suspect that being faced with a peripheral-free CPU would be very >> comparable :-) >> >I'm not certain as to what you are claiming. > >In a microcomputer environment, so long as you had access to the BIOS >and could call an assembly language routine (or even a machine >language routine, if necessary), then what the language did or did not >support didn't matter. What the BIOS and/or OS supported did (and >still does).And what does the BIOS do with no peripherals? Contemplate its own magnificence? Seriously. Frank McKenney was talking about a generation of systems before you could assume that everything comes with a more-or-less functional run-time executive (which is what a BIOS is). What I was talking about was the sort of embedded system where the BIOS IS the application, and how you start loading it. Think hearing aids, not PCs in a box. Regards, Nick Maclaren.
Reply by ●January 12, 20112011-01-12
Terje Mathisen wrote:> nmm1@cam.ac.uk wrote: >> >> I once had a Fortran compiler for testing that had no I/O support. >> No input, no output and no file access. I did check that it used > > So how were you supposed to feed in data?You call subroutines not written in Fortran. Eric
Reply by ●January 12, 20112011-01-12
On Jan 12, 10:23=A0am, n...@cam.ac.uk wrote:> In article <4D2DC656.B2A79...@bytecraft.com>, > Walter Banks =A0<wal...@bytecraft.com> wrote: > > >Frnak McKenney wrote: > > >> Ah, I miss Das Blinkenlights... <grin!> > > >I remember the strange feeling with the first home > >brew computer I built that did not have a blinking light > >and switches console. I was convinced that it would > >never be able to run or debug anything. > > That would depend on how hard it was to get access to the initial > peripherals! > > I once had a Fortran compiler for testing that had no I/O support. > No input, no output and no file access. =A0I did check that it used > Fortran 77 DO-loop semantics and told the salesman it was useless. > When I had explained why, he then asked "Other than that, what did > you think of it?" > > I suspect that being faced with a peripheral-free CPU would be very > comparable :-) >I'm not certain as to what you are claiming. In a microcomputer environment, so long as you had access to the BIOS and could call an assembly language routine (or even a machine language routine, if necessary), then what the language did or did not support didn't matter. What the BIOS and/or OS supported did (and still does). I faced a number of odd situations using Fortran in microprocessor environments in which the compiler did not support the necessary I/O correctly. I eventually stopped using native Fortran I/O so that I could use my own uniform interface on different platforms. All I had to change was my own I/O library. Saying that the language does not natively support the necessary I/O is different from having a peripheral-free CPU. Hard [to get access to peripherals, in this case] and impossible are not the same. That's the essence of non-trivial engineering. Robert.
Reply by ●January 12, 20112011-01-12
nmm1@cam.ac.uk wrote:> In article <aVlXo.32847$My1.1809@newsfe16.iad>, > EricP <ThatWouldBeTelling@thevillage.com> wrote: >> Terje Mathisen wrote: >>>> I once had a Fortran compiler for testing that had no I/O support. >>>> No input, no output and no file access. I did check that it used >>> So how were you supposed to feed in data? >> You call subroutines not written in Fortran. > > Nice try, but no banana. It used a C-incompatible calling sequence, > and there was no assembler. I baulked at creating object decks > using the available tools - such as ed and cat - especially with > no specification. > > I said "useless" and I meant just that! That's what I told the > salesdroid, too.Ah... well... sometimes the world is out to get you! Eric
Reply by ●January 12, 20112011-01-12
In article <almarsoft.5881524279275810439@aioe.org>, ulf@fake.atmel.com says...> > On Wed, 12 Jan 2011 09:08:49 +0200, upsidedown@downunder.com wrote: > > On Wed, 12 Jan 2011 01:36:53 +0100, Ulf Samuelsson > > <ulf@fake.atmel.com> wrote: > > > > >On Tue, 11 Jan 2011 21:21:48 +0100, Morten Reistad > <first@last.name> > > >wrote: > > >> Modern, well designed servers don't have many problems. You have > to > > >> do the occasional upgrade and reboot as part of meintenence, but > > >> the MTBF of single servers are around 5 years. More, if you > > >> go for redundancy everywhere and hot-swap parts. > > > > > > > > >> OS crashes in Linux, BSD etc from LTS releases that happen > > >> except for hardware issues are also very rare. > > > > > > > > >> -- mrr > > > > > >IIRC, a VAX/VMS machine in Sweden has been running for > 20 years. > > > > That must have been the uptime for an entire VAX cluster. Individual > > machines could have been booted several times, but at least one > > machine has been running all the time. > > > > To upgrade the OS on the VAX cluster, take one machine off the > > cluster, upgrade that machine to the next version and then join the > > cluster. Repeat for the other machines. > > > > In the cluster the machines could have OS version separated by one > > step, thus several cycles of this rolling updates had to be made, > if a > > large number of versions is needed to upgrade at once. > > No, it was a single machine controlling something related > to the railroad. Today, you would probably have used an > embedded system.I remember about 30 years two DEC engineers[1] went to Norway and the railroad ran on a dual PDP-11/70 system, where the code was wrong so did not run in failsafe, so needed both systems running. Field Service had to guess which part to change shut down the whole network to try a change then bring the whole lot back up. They went to fix so serial driven colour graphics systems, for mimic displays and had to cross marshalling yards, go up the stairs in a signalling tower, past the banks of Victorian relays still working after 100 years, but the embedded systems running the graphics were needing fixing after less than 3 months. [1] When I worked at the division of DEC in UK and got the stories from the engineers who went to Norway. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
