4 ms·

v6 on a Raspberry Pi RP2040

80 points by zdw 4y ago

msla 4y ago
In case anyone was wondering: > The de facto emulator for most old computers is Simh https://github.com/simh/simh https://github.com/simh/simh. The size and complexity of the individual machine apps is such that a direct port to a memory limited system is not feasible.
dboreham 4y ago
> DEC's view of the language to use was Basic!. This was at a time just prior to c appearing and it was believed that Fortran was not the language of the future. This isn't quite what happened. BASIC could be easily implemented in a few KB of assembler on a 8-bit/12-bit/16-bit computer. C could not. Fortran neither. Prior to the 32-bit/VAX generation compilers had to be split into several binaries - one per pass, or overlays depending on the OS, making their use painful and slow and not an option on the lower end systems. BASIC meanwhile worked just fine on those low end machines.
Koshkin 4y ago
The Pico is powerful enough to run Doom. https://www.raspberrypi.com/news/doom-comes-to-raspberry-pi-pico/ https://www.raspberrypi.com/news/doom-comes-to-raspberry-pi-...
smackeyacky 4y ago
That comment about how easy it is to trash a file system on those old unices... My first boss would look over our shoulders to make sure we ran sync before reboot but in an idiosyncratic way that I had forgotten about until now. The mantra was: # sync # sync # sync # reboot When she did it it was always typed quickly. The Pyramid we had did have some file system issues although we continued to do it on our Sun systems as well. Not sure why she asked us to do it three times. Was a habit for quite a few years.
- somesortofsystm 4y ago
  Bastard operator, checking in. Cut my teeth on paper, then tape, then disk. $ sync;sync;sync # three syncs in rapid succession is interpreted by the tape machine as a rewind command .. on card tray, shuffles cards to settle $ sync # one sync, just syncs to tape at current stream position
- HankB99 4y ago
  I found a bit of folklore on that https://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync https://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSyn...
  - smackeyacky 4y ago
    That is awesome. I don't think it was ever explained properly back then, so you finding this is fantastic to me. Cheers!
  - somesortofsystm 4y ago
    Its not quite accurate or good folklore though, because it misses the fact that "sync;sync;sync" is distinct from "sync <enter> sync <enter> sync <enter>" and the reason for that is that the machines (tape and otherwise) on the other end would interpret such fast contiguous syncs (as opposed to the human RNG) as instructions to, for example, rewind the tape .. or shuffle the card tray .. peripherals and resources which, alas, have fallen from our consciousnesses ..
  - kjs3 4y ago
    It was explained to me back in the stone age that one did 3 syncs because disks were slow enough that if you did one sync all the buffers might not be flushed before the reboot took hold. So do 3 syncs to make sure. Borking a filesystem wasn't fun. Not saying it's correct, and it's still a habit for me.
    - somesortofsystm 4y ago
      "One sync tells the system to flush all i/o buffers, the second one serves to ensure the buffers are sync'ed, and the third is useful in case slow-quitting processes meanwhile even still have things to flush before letting go of a node, and then of course .. ;reboot .. " Yeah, but it also means, if done in rapid succession (i.e. one shell cmd "sync;sync;sync", it can tell the machine on the other end of the i/o to do 'special' operations, such as rewind tape, settle card tray intake, etc. Long-forgotten aspects of operation which neverless fit in the 'class' of action, where data is settled and made safe.

80 points by zdw 4y ago

msla 4y ago

In case anyone was wondering: > The de facto emulator for most old computers is Simh https://github.com/simh/simh https://github.com/simh/simh. The size and complexity of the individual machine apps is such that a direct port to a memory limited system is not feasible.

dboreham 4y ago

> DEC's view of the language to use was Basic!. This was at a time just prior to c appearing and it was believed that Fortran was not the language of the future. This isn't quite what happened. BASIC could be easily implemented in a few KB of assembler on a 8-bit/12-bit/16-bit computer. C could not. Fortran neither. Prior to the 32-bit/VAX generation compilers had to be split into several binaries - one per pass, or overlays depending on the OS, making their use painful and slow and not an option on the lower end systems. BASIC meanwhile worked just fine on those low end machines.

Koshkin 4y ago

The Pico is powerful enough to run Doom. https://www.raspberrypi.com/news/doom-comes-to-raspberry-pi-pico/ https://www.raspberrypi.com/news/doom-comes-to-raspberry-pi-...

smackeyacky 4y ago

That comment about how easy it is to trash a file system on those old unices... My first boss would look over our shoulders to make sure we ran sync before reboot but in an idiosyncratic way that I had forgotten about until now. The mantra was: # sync # sync # sync # reboot When she did it it was always typed quickly. The Pyramid we had did have some file system issues although we continued to do it on our Sun systems as well. Not sure why she asked us to do it three times. Was a habit for quite a few years.

somesortofsystm 4y ago
Bastard operator, checking in. Cut my teeth on paper, then tape, then disk. $ sync;sync;sync # three syncs in rapid succession is interpreted by the tape machine as a rewind command .. on card tray, shuffles cards to settle $ sync # one sync, just syncs to tape at current stream position
HankB99 4y ago
I found a bit of folklore on that https://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync https://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSyn...
- smackeyacky 4y ago
  That is awesome. I don't think it was ever explained properly back then, so you finding this is fantastic to me. Cheers!
- somesortofsystm 4y ago
  Its not quite accurate or good folklore though, because it misses the fact that "sync;sync;sync" is distinct from "sync <enter> sync <enter> sync <enter>" and the reason for that is that the machines (tape and otherwise) on the other end would interpret such fast contiguous syncs (as opposed to the human RNG) as instructions to, for example, rewind the tape .. or shuffle the card tray .. peripherals and resources which, alas, have fallen from our consciousnesses ..
- kjs3 4y ago
  It was explained to me back in the stone age that one did 3 syncs because disks were slow enough that if you did one sync all the buffers might not be flushed before the reboot took hold. So do 3 syncs to make sure. Borking a filesystem wasn't fun. Not saying it's correct, and it's still a habit for me.
  - somesortofsystm 4y ago
    "One sync tells the system to flush all i/o buffers, the second one serves to ensure the buffers are sync'ed, and the third is useful in case slow-quitting processes meanwhile even still have things to flush before letting go of a node, and then of course .. ;reboot .. " Yeah, but it also means, if done in rapid succession (i.e. one shell cmd "sync;sync;sync", it can tell the machine on the other end of the i/o to do 'special' operations, such as rewind tape, settle card tray intake, etc. Long-forgotten aspects of operation which neverless fit in the 'class' of action, where data is settled and made safe.