4 ms·

It's possible, but it's just not the same thing. There are orders of magnitude more layers of abstraction in play. "Fullscreen a terminal" implies graphics -

It's possible, but it's just not the same thing. There are orders of magnitude more layers of abstraction in play. "Fullscreen a terminal" implies graphics - so X, toolkits, window managers, on top of kernel and userland etc. It would take you decades to wrap your head around all that; a little 6502 computer you can grok in a month. Quick, what stovepipe of software would let you type "PLOT 10, 10: DRAW 20, 20" to draw a line :)

GekkePrutser 6y ago
That's absolutely true. It was much simpler to start creating. Now you have a choice in platforms that can achieve the same with similar effort, but you have to start by picking and installing one, whereas those computers came with it. PS: You also used an Atari? I think it was DRAWTO there :)
- theamk 6y ago
  Have you seen Scratch [0]? It runs entirely in the web browser and you don't need to install it. It is designed for kids and it looks a bit goofy with all those drag-and-drop programming commands, but don't be fooled -- it is a pretty modern language, with flow control, variables, functions and all. At the same time it is great for "just start creating" things -- you start by drawing pictures, then you animate an object and the next thing you know you have a fun game :) [0] https://scratch.mit.edu/ https://scratch.mit.edu/
  - GekkePrutser 6y ago
    Never heard of it, looks cool. Thanks!
zepto 6y ago
Probably just an emulator if you want that to actually work. Yes, it does take decades to wrap one’s head around all that stuff, but you don’t have to in order to have a straightforward programming experience. Take this for example: https://docs.racket-lang.org/quick/ https://docs.racket-lang.org/quick/ Almost as simple, vastly better to learn. And it’s not like we understood how graphics worked, or how the basic interpreter was built in order to type those commands anyway. Even if some of us do now, most people who used those machines never understood them. I do agree with you in essence - I want that simplicity back, but I don’t miss actually using those machines. I wrote some quite complex software in BASIC, and have no desire to return to that. I want something with the immediacy and programmability of that era, but with modern capabilities and programming concepts.
- 7thaccount 6y ago
  Yeah, I basically want a machine with a fast CPU and lots of RAM that boots into something like LISP or Forth with a very minimal OS (SD card navigation, text editor, image and audio file player, simple graphics).
  - cturner 6y ago
    We have a group that has been playing with that concept, songseed.org/dinghy, including the notion of a ‘forth workstation’. Through this, I have found networking to be a significant design pressure on the rest of the system, inviting complexity. The comparison of retrobsd and litebsd in the pic32 paper talks about this. Another conclusion - if you want the platform to be relevant on high end hardware, you must use Windows or Linux as part of your foundation due to the gpu driver situation.
    - 7thaccount 6y ago
      It sounds like you've thought this through pretty well. Once you add in networking and a web browser, it might not be possible to avoid all that complexity.
      - cturner 6y ago
        I feel like I have only scratched the surface :) If you take interest in this, we hang out in #dinghy on freenode. We have bursts of activity, and then long periods of silence. But I do feel like the world is ripe for a revolution in a few directions here. -- Browser To your point that a conventional browser creates unavoidable complexity: I agree. It may be possible to disrupt that stack entirely, by creating something that developers would prefer to develop for. The new conversational interaction between whatsapp users and corporate chatbots (e.g. airline rebooking over whatsapp) shows developer and user appetite for non-HTTP internet activity. As does Slack, somewhat. This gopher-like 'Gemini' thing that has been popping up recently is interesting. On the Dinghy website, there is a proposal for an engine, /Limit/. It would be a Forth VM that would maintain an async connection back to a webserver-like server. Instead of having HTTP+HTML+CSS+Javascript, you would deliver sites as forth bytecode. This could be tighter yet more flexible than a web browser. An Everything-Is-A-X based overthrow of the current web browser model. /Limit/ could be simulated in a browser (using javascript and websockets) so that people who only had a browser could browse a Limit server without adding new software. Hypothesis: /Limit/ would have common purpose with alt-OS communities that do not have first-class browsers: Haiku, Plan9, Amiga, Suckless, people who run old SGIs for fun. Imagine if you could just recompile a C codebase, and change some headers, and get a full-featured browser-like thing running on these systems. -- Networking I am confident that there is a non-complex path through this problem. Hypothesis: interaction with the systems API should be purely asynchronous, and TCP interaction will look nothing like the Berkeley sockets API. Tanenbaum warns of the dangers of an async systems API (http://songseed.org/dinghy/tanenbaum.html http://songseed.org/dinghy/tanenbaum.html). But there is an occam-based OS, RMoX, that looks to be a demonstration of the async OS concept. I hit obstacles trying to evaluate/verify this. On the Dinghy website, there is a paper for "Drift". This proposes an async OS for the amd64 architecture. I noticed drafting problems in this paper earlier, will revise soon. The addition of io_uring to Linux may allow another approach: create an async API mezzanine on io_uring; regard this as your Bedrock, rather than the hardware itself. Once io_uring is mature, it may be possible to fork Linux in order to discard /all/ syscalls except io_uring. This kernel would have ongoing Linux driver support, but with a much smaller kernel surface area. -- Your requirements Regarding your stated requirements, 'SD card navigation, text editor, image and audio file player, simple graphics', you could build this on top of the Maximite architecture. But it would lack networking. Whereas the Dinghy concept goes beyond your stated requirements.
theamk 6y ago
Any system with Python (so any Linux system)? Here is a real-example, just tested on my Ubuntu PC: $ python3 Python 3.6.9 (default, Oct 8 2020, 12:12:24) [GCC 8.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from turtle import * >>> penup() >>> setposition(10, 10) >>> pendown() >>> setposition(100, 100) Not quite the same commands, but pretty close. And you have more modern things like "bgpic", "onclick" and entire Python library. https://docs.python.org/3/library/turtle.html https://docs.python.org/3/library/turtle.html
- GekkePrutser 6y ago
  True, Python is good for this, it also comes by default on mac!
- 7thaccount 6y ago
  Yeah, but you're missing the point the parent is making. On a C64, you boot into bare basic and can immediately start playing with sprites and lines and stuff. With a modern computer you have BIOS, 80 bazillion lines of Windows or Linux, your Python installation and about 90 layers in between. It's simply not possible to fully understand a modern computer. Just take a look at all the lines of code in Windows and Python that lets you play with turtle graphics (forget about the other million lines of other code I don't even know about). Then, compare that sum with the amount of code in the C64. See the difference? Sure a modern computer does a lot more, but it's also a black-hole/ accretion disk of bad design glued together.
  - theamk 6y ago
    Well, what is your goal? If you want to play with sprites and lines and stuff, use modern PC. It does the things that poor C64 never dreamed of, and if you want constraints, there are always things like "1k demos" which let one express their creativity while keeping the minimal amount of code around. if you want to understand stuff down to the metal, there is a whole embedded world out there. From the simple 8051 with a half-dozen registers to 32 bit ARMs where you can learn how to set up DMA transfers. (My favorite one is 8-bit AVR: the datasheet is small enough you can read it end to end, there are plenty of peripherals, but at the same time it is slow enough you have to occasionally solve "how to code this quickly" puzzle) I see no reason to mix those two, except because of nostalgia. Yes, in the past you had to be blacksmith and woodworker -- but those are gone. You can still mix those two, and the very first rasp you made still feels very special, but let's not pretend it was somehow better than the modern store-bought one.
zepto 6y ago
https://bbcmic.ro/ https://bbcmic.ro/ Is pretty close: https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE%202%5CnMOVE%20100%2C100%5CnDRAW%20200%2C200%22%7D https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE%...

GekkePrutser 6y ago

That's absolutely true. It was much simpler to start creating. Now you have a choice in platforms that can achieve the same with similar effort, but you have to start by picking and installing one, whereas those computers came with it. PS: You also used an Atari? I think it was DRAWTO there :)

theamk 6y ago
Have you seen Scratch [0]? It runs entirely in the web browser and you don't need to install it. It is designed for kids and it looks a bit goofy with all those drag-and-drop programming commands, but don't be fooled -- it is a pretty modern language, with flow control, variables, functions and all. At the same time it is great for "just start creating" things -- you start by drawing pictures, then you animate an object and the next thing you know you have a fun game :) [0] https://scratch.mit.edu/ https://scratch.mit.edu/
- GekkePrutser 6y ago
  Never heard of it, looks cool. Thanks!

zepto 6y ago

Probably just an emulator if you want that to actually work. Yes, it does take decades to wrap one’s head around all that stuff, but you don’t have to in order to have a straightforward programming experience. Take this for example: https://docs.racket-lang.org/quick/ https://docs.racket-lang.org/quick/ Almost as simple, vastly better to learn. And it’s not like we understood how graphics worked, or how the basic interpreter was built in order to type those commands anyway. Even if some of us do now, most people who used those machines never understood them. I do agree with you in essence - I want that simplicity back, but I don’t miss actually using those machines. I wrote some quite complex software in BASIC, and have no desire to return to that. I want something with the immediacy and programmability of that era, but with modern capabilities and programming concepts.

7thaccount 6y ago
Yeah, I basically want a machine with a fast CPU and lots of RAM that boots into something like LISP or Forth with a very minimal OS (SD card navigation, text editor, image and audio file player, simple graphics).
- cturner 6y ago
  We have a group that has been playing with that concept, songseed.org/dinghy, including the notion of a ‘forth workstation’. Through this, I have found networking to be a significant design pressure on the rest of the system, inviting complexity. The comparison of retrobsd and litebsd in the pic32 paper talks about this. Another conclusion - if you want the platform to be relevant on high end hardware, you must use Windows or Linux as part of your foundation due to the gpu driver situation.
  - 7thaccount 6y ago
    It sounds like you've thought this through pretty well. Once you add in networking and a web browser, it might not be possible to avoid all that complexity.
    - cturner 6y ago
      I feel like I have only scratched the surface :) If you take interest in this, we hang out in #dinghy on freenode. We have bursts of activity, and then long periods of silence. But I do feel like the world is ripe for a revolution in a few directions here. -- Browser To your point that a conventional browser creates unavoidable complexity: I agree. It may be possible to disrupt that stack entirely, by creating something that developers would prefer to develop for. The new conversational interaction between whatsapp users and corporate chatbots (e.g. airline rebooking over whatsapp) shows developer and user appetite for non-HTTP internet activity. As does Slack, somewhat. This gopher-like 'Gemini' thing that has been popping up recently is interesting. On the Dinghy website, there is a proposal for an engine, /Limit/. It would be a Forth VM that would maintain an async connection back to a webserver-like server. Instead of having HTTP+HTML+CSS+Javascript, you would deliver sites as forth bytecode. This could be tighter yet more flexible than a web browser. An Everything-Is-A-X based overthrow of the current web browser model. /Limit/ could be simulated in a browser (using javascript and websockets) so that people who only had a browser could browse a Limit server without adding new software. Hypothesis: /Limit/ would have common purpose with alt-OS communities that do not have first-class browsers: Haiku, Plan9, Amiga, Suckless, people who run old SGIs for fun. Imagine if you could just recompile a C codebase, and change some headers, and get a full-featured browser-like thing running on these systems. -- Networking I am confident that there is a non-complex path through this problem. Hypothesis: interaction with the systems API should be purely asynchronous, and TCP interaction will look nothing like the Berkeley sockets API. Tanenbaum warns of the dangers of an async systems API (http://songseed.org/dinghy/tanenbaum.html http://songseed.org/dinghy/tanenbaum.html). But there is an occam-based OS, RMoX, that looks to be a demonstration of the async OS concept. I hit obstacles trying to evaluate/verify this. On the Dinghy website, there is a paper for "Drift". This proposes an async OS for the amd64 architecture. I noticed drafting problems in this paper earlier, will revise soon. The addition of io_uring to Linux may allow another approach: create an async API mezzanine on io_uring; regard this as your Bedrock, rather than the hardware itself. Once io_uring is mature, it may be possible to fork Linux in order to discard /all/ syscalls except io_uring. This kernel would have ongoing Linux driver support, but with a much smaller kernel surface area. -- Your requirements Regarding your stated requirements, 'SD card navigation, text editor, image and audio file player, simple graphics', you could build this on top of the Maximite architecture. But it would lack networking. Whereas the Dinghy concept goes beyond your stated requirements.

theamk 6y ago

Any system with Python (so any Linux system)? Here is a real-example, just tested on my Ubuntu PC: $ python3 Python 3.6.9 (default, Oct 8 2020, 12:12:24) [GCC 8.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from turtle import * >>> penup() >>> setposition(10, 10) >>> pendown() >>> setposition(100, 100) Not quite the same commands, but pretty close. And you have more modern things like "bgpic", "onclick" and entire Python library. https://docs.python.org/3/library/turtle.html https://docs.python.org/3/library/turtle.html

GekkePrutser 6y ago
True, Python is good for this, it also comes by default on mac!
7thaccount 6y ago
Yeah, but you're missing the point the parent is making. On a C64, you boot into bare basic and can immediately start playing with sprites and lines and stuff. With a modern computer you have BIOS, 80 bazillion lines of Windows or Linux, your Python installation and about 90 layers in between. It's simply not possible to fully understand a modern computer. Just take a look at all the lines of code in Windows and Python that lets you play with turtle graphics (forget about the other million lines of other code I don't even know about). Then, compare that sum with the amount of code in the C64. See the difference? Sure a modern computer does a lot more, but it's also a black-hole/ accretion disk of bad design glued together.
- theamk 6y ago
  Well, what is your goal? If you want to play with sprites and lines and stuff, use modern PC. It does the things that poor C64 never dreamed of, and if you want constraints, there are always things like "1k demos" which let one express their creativity while keeping the minimal amount of code around. if you want to understand stuff down to the metal, there is a whole embedded world out there. From the simple 8051 with a half-dozen registers to 32 bit ARMs where you can learn how to set up DMA transfers. (My favorite one is 8-bit AVR: the datasheet is small enough you can read it end to end, there are plenty of peripherals, but at the same time it is slow enough you have to occasionally solve "how to code this quickly" puzzle) I see no reason to mix those two, except because of nostalgia. Yes, in the past you had to be blacksmith and woodworker -- but those are gone. You can still mix those two, and the very first rasp you made still feels very special, but let's not pretend it was somehow better than the modern store-bought one.

zepto 6y ago

https://bbcmic.ro/ https://bbcmic.ro/ Is pretty close: https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE%202%5CnMOVE%20100%2C100%5CnDRAW%20200%2C200%22%7D https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE%...