What a fascinating and novel approach. See, this is what I truly miss about computing in the 80's and 90's. Limitation motivates innovation. I would very much be interested in how you take this idea forward. I'm very interested in ALL the things you're talking about, but if I had to prioritize, the small web project seems to be the most novel and interesting imho.
I've made several gopher browsers for 8 bit computers(including ZX Spectrum, MSX and Agon). It can be extended a bit and voila - you have a lot server software, you have desktop clients for all platforms, browser can be implemented even for really small computers.
A few thoughts: There is some value in targetting 40 columns. That would allow systems like the NABU or even MSX to use the same technology. Basically anything that runs on a TMS9x18 VDP. The more advanced 9938/9958 VDPs do support 80 columns, but only with 2 colors and no sprites. They would have to use the graphics mode and render text as graphics on the CPU. On the software level, it would be useful to have a 2 layer model right from the start. Separate the processing of data from the actual writing to the screen. If you separate the two and specify an API in between them, other people could implement the hardware dependent portion on other systems, while leaving the whole data processing/document parsing part as is. For the communication part, you might want to take a look at NHACP. That is a protocol that was developed by the NABU community to hook up the NABU to the internet. It has provisions for downloading files to the NABU from the internet, with a device in between of course. But the protocol is relatively simple, and is optimized for reducing the load on the client side.
Re don't make the client do layout / rely on sprites. are you not digging yourself into a hardware specific hole? if i can't or don't want to deal with images, this doesn't work. if my memory is such that I don't want to load, possibly useless images, or want to open them in a separate program, this makes it harder. and sprites are handled differently by different systems. and what happens if I access this on my commander x16 portable that has a tiny screen and so can't do 40 column text? Id be inclined to go with basic html, possibly simplify to make it easier to parse. it makes it more accessible because then you can serve up pages to 'normal' browsers. if i infer correctly what youre trying to do with the leaves, you could set it up as a double linked list. so the next previous page could be dynamically loaded. Im not sure if you could do that with a plain anchor link or whether you'd need to abuse it slightly. I suppose a client that doesn't have that anchor in memory could request it from the server?
For sure, I will be taking your feedback into consideration. I think it should be both possible and easy to offer up the data in a few different formats to best suit the system/client (e.g., 40col, 80col, and text-only). So in the case of working over a network, the client would simply need to indicate its format of preference, then expect that sent by the server. With regards to the sprite/image data, I do not plan to serve up directly, data in the image format used by the various systems. So the 32x32 pixel image chunks will likely need to be minimally processed upon receiving by the client. So that shouldn't result in any sort of hardware specific lock-in. Also, this is another area where I feel I should elaborate, regarding my primary focus. Ultimately, it comes down to creating a web/document experience on modern retro systems (i.e., x16, F256, MEGA65, x65, et.al.) which fully utilizes their capability. I would argue that BBSes are designed to use 100% of what older 8-bit systems could manage just as the modern web does its best to fully utilize modern CPUs and GPUs. So my design considerations here are to produce the optimal experience on platforms for which BBSes leave a lot on the table and the modern web is simply too much. If at all possible, I would like to devise a system which works and produces a good experience on vintage 8-bit systems as well as fully modern systems, however the target that I have in mind while designing and optimizing things are modern-retro systems like the ones I listed earlier in this comment.
@ModernRetroDev well fwiw I'm coming from a different angle, this popped up in my feed, presumably because I've been googling lightweight protocols because I'm trying to make a pi Pico into a computer. Again it's not really up to the modern web, and I can't really be arsed to get into all that anyway. Personally, I'd like some html 1 type thing. Preferably even easier to parse. But with an equivalent that can optionally be served. Plus, I know the Gemini protocol has has flak because it isn't very clear. Sticking closer to how the web used to operate, you can learn from the actual issues encountered. Bbss do escape codes so you should be able to what a Unix terminal can do. Considering what computing power early Unix had. So I don't think basic wrapping should be an issue. That then opens it up to more use cases. The ability to optionally serve up images just makes it much more useful. Another issue that occured to after my last message was character sets. If you want to make your site pretty (which is going to happen) with IBM box characters, or c64 graphic characters, it breaks for many other people. So then it's better to say I want a box then the client can render +-----+ | Box| +-----+ Or use graphics, or specialist characters. Your current plan makes assumption about character sizes also. If a font pixel is 8x8 pixels, it might work fine, what if it's 6x8? Then the graphics don't use enough space, and the opposite is even worse. I like the leaves thing. It opens up the possibility of infinite scrolling, (which I'm sure would actually be a feature in the alternative web) and allows dynamic interaction. A tick box could load a different next leaf. And I think compared to Gemini the no encryption thing is a plus. So I think it's got genuine 'broad' appeal outside of the retro community.
I love what you are doing! This concept of web pages/documents for retro machines I find really compelling: the restrictions make for interesting solutions while still aiming to get close to a modern interface (without all its complexity). - I would like to see an implementation of links (withing a "website"). - Are you going to implement TCP/IP and http? Or a more simple protocol? Maybe do a bit of research on that. - Maybe get the retro community involved in creating tooling for this or helping with the implementation? Regards, JeffreyH (as known within the X16 community)
Regarding internal/external document linking, that is absolutely something that I would like to do, I just haven't thought too deeply on the matter thus far. However, I think that as I have structured the concept to use leaves (which are little bits of content), this means that when links are finally implemented, it would be a natural target to use for that purpose (e.g., this link points to `somepage:leaf012`). This would allow us not only to jump to an appropriate document, but to even jump to the appropriate location within said content. With regards to communication over the network. I'll admit I haven't thought too deeply on it at this point, however I am leaning towards implementing this on top of TCP/IP. My thinking is, I really need to see how the performance is on this thing browsing through local documents/manuals before I go and make the situation even more complicated. If performance on a local document is bad, than it'll be even worse over the network. Admittedly, this is an area where I will have to put in more thought in the future. Finally, on the topic of retro community involvement. Yes, I would like to get help, input and feedback from the community. At this early formative stage, what I am most interested in, is feedback (I like this/I hate this) and also the various lessons learned and gotchas I've heard from people when communicating my idea. In my opinion, I haven't yet reached the minimum-viable-prototype for this particular project, which makes me very reluctant to ship it out as it is severely half-baked. However, I did feel that it was in good enough shape for me to show it off and see if others are interested. Oh and I should say, that if you want to continue this discussion in more detail, ping me in one of the X16 discord channels. I always post my videos in the `#self-promo`, so you can find my username there. Thanks for watching!
At the moment I'm most interested in the minimalist document format. I'd love to be able to view web/rss on 80's style computer hardware. I really dislike how inefficient modern information technology has become. Need the equivalent of a super-computer just to display simple text and images!
I'm glad that you found this project interesting as well! I do feel like things can be done better than they are currently. Furthermore, I think this concept (if done properly) could be a boon not only for older/weaker systems but also for modern and mobile systems. I'll be back with an update on this project before too long, however before then, I think I'd like to show off some of the other things I've been working on. Thanks for tuning in!
Regarding this smolweb like presentation, just a remark: For newspapers (printed ones) it is common to have text in columns not being wider than about 32 character, because of better readability. The same may be natural for mobile phones because of their screen width. So it would be great to have a format not fixed or oriented to a fixed screen size, but usable on all kinds of small devices - means, floating text, no hard cr/lf, where ist is not needed. Hard coding also makes the dokuments larger, because of additional formatting characters. Let the presentation be decided by the device, not the format. Regarding colors, different old machines may have totally different capabilities. The 16/32 bit Atari ST for example has nativly just a maximum of 16 colors, but only in 40 column character mode. Because of this it could be a good idea to have something like an optional grayscale mode. With that 16 shades of gray may be fully enough for little images, even if not colored. A big bunch of old machines may have no image capabilities at all, at least wihtout additional hardware. CP/M machines, PET, ZX81, ... Because of this I once was searching for a least common denominator, like the block graphics characters in different character sets. The Commodore ones, Sinclair, Tandy Coco for example have all these block graphics, for CP/M it would be a question of the used character set. Personally I find these cool and some kind of own art form. You can do many things with it, build things with it, like Lego blocks.
So I agree with being somewhat flexible on text width, by perhaps offering both 40 column and 80 column versions of the content. However, as I said in the video, I don't want to push the burden of laying out dynamic textual content of the document onto the client, as the client may be a creaky 6502 CPU. My thought is that the content creator would create the document in a free form format (something of a cross between markdown and LaTeX probably), then that content would be compiled into a static form. That static form is what would then be sent to the client on request. Regarding colors, I don't want to actually serve up text colors directly. Instead, I would want to serve up an intent or style instead (e.g., a bit of text might be a link, or have emphasis). If the server/document only communicates intent, then it can be handled appropriately on the client side. This allows for documents to be well rendered in light-mode, dark-mode, or other custom themes, not to mention on monochrome systems. The last issue is with images and realistically, the server is going to have to have a number of formats and options available for clients. One of those options could most certainly be, to not get the images. I should also say that this project is still very much in a formative stage and many of the aspects of this concept probably need to receive more contemplation and feedback. So I will continue to think on this, and I thank you for your feedback.
What kind of problem was this "compiler" going to solve? I see how it'd be a fun challenge compacting the essential functionality in as small a memory footprint as possible, but if it's forth, than forth it is 😊
Well, there's a few things I have in mind for this compiler project. First off, let me just say that all of these things are just hobby projects of mine... so if they seem fun to me for one reason or another, I have a tendency to just march in a direction and see what happens. Now I don't want to spoil my next video by dropping all the salient details here, but I will tell you that one aspect of this compiler project is that it is a heuristic exercise. However, that is far from the only reason as to why I am pursuing it. Here's to hoping you enjoy the story when I do get around to talking about it. Also, thanks for watching!
This is probably an unpopular opinion, but I think the 8x8 text cells of 8bit micros was inferior to non square fonts like VGA with true descenders. I spent countless hours staring at both a commodore 64 and a text mode. 80 column IBM PC and much as I love the commodore 64. The IBM PC text was just infinitely better.
Yes, meanwhile breaking it down into small transferable chunks. Also, I do think that inter and intra-document links are a must. So its a text file, with potentially embedded images and potentially hyperlinks of a sort. Admittedly, I need to do a bit more thinking about the finer details (lots of great feedback in the comments), but as I pointed out this is merely an early proof of concept at this point. It's always been my plan with this channel to talk about the development of my projects mostly in the present tense. Which is to say, I'm really showing things off here as early as am comfortable with doing so. While my inner perfectionist, wants me to wait till each thing is 100% done, I want to show of my thought process and all the little milestones along the way. So, here's to hoping people actually enjoy watching content in this form.
What a fascinating and novel approach. See, this is what I truly miss about computing in the 80's and 90's. Limitation motivates innovation. I would very much be interested in how you take this idea forward. I'm very interested in ALL the things you're talking about, but if I had to prioritize, the small web project seems to be the most novel and interesting imho.
Compiler shenanigans! And this small web project. Very interesting.
Awesome, duly noted!
I'm interested in hearing about all of it ..!
Game prototype project, compilers, and small web! All really fascinating topics ...
I've made several gopher browsers for 8 bit computers(including ZX Spectrum, MSX and Agon). It can be extended a bit and voila - you have a lot server software, you have desktop clients for all platforms, browser can be implemented even for really small computers.
A few thoughts:
There is some value in targetting 40 columns. That would allow systems like the NABU or even MSX to use the same technology. Basically anything that runs on a TMS9x18 VDP.
The more advanced 9938/9958 VDPs do support 80 columns, but only with 2 colors and no sprites. They would have to use the graphics mode and render text as graphics on the CPU.
On the software level, it would be useful to have a 2 layer model right from the start. Separate the processing of data from the actual writing to the screen. If you separate the two and specify an API in between them, other people could implement the hardware dependent portion on other systems, while leaving the whole data processing/document parsing part as is.
For the communication part, you might want to take a look at NHACP. That is a protocol that was developed by the NABU community to hook up the NABU to the internet. It has provisions for downloading files to the NABU from the internet, with a device in between of course. But the protocol is relatively simple, and is optimized for reducing the load on the client side.
Re don't make the client do layout / rely on sprites.
are you not digging yourself into a hardware specific hole?
if i can't or don't want to deal with images, this doesn't work. if my memory is such that I don't want to load, possibly useless images, or want to open them in a separate program, this makes it harder. and sprites are handled differently by different systems. and what happens if I access this on my commander x16 portable that has a tiny screen and so can't do 40 column text?
Id be inclined to go with basic html, possibly simplify to make it easier to parse. it makes it more accessible because then you can serve up pages to 'normal' browsers.
if i infer correctly what youre trying to do with the leaves, you could set it up as a double linked list. so the next previous page could be dynamically loaded.
Im not sure if you could do that with a plain anchor link or whether you'd need to abuse it slightly. I suppose a client that doesn't have that anchor in memory could request it from the server?
For sure, I will be taking your feedback into consideration. I think it should be both possible and easy to offer up the data in a few different formats to best suit the system/client (e.g., 40col, 80col, and text-only). So in the case of working over a network, the client would simply need to indicate its format of preference, then expect that sent by the server.
With regards to the sprite/image data, I do not plan to serve up directly, data in the image format used by the various systems. So the 32x32 pixel image chunks will likely need to be minimally processed upon receiving by the client. So that shouldn't result in any sort of hardware specific lock-in.
Also, this is another area where I feel I should elaborate, regarding my primary focus. Ultimately, it comes down to creating a web/document experience on modern retro systems (i.e., x16, F256, MEGA65, x65, et.al.) which fully utilizes their capability. I would argue that BBSes are designed to use 100% of what older 8-bit systems could manage just as the modern web does its best to fully utilize modern CPUs and GPUs. So my design considerations here are to produce the optimal experience on platforms for which BBSes leave a lot on the table and the modern web is simply too much.
If at all possible, I would like to devise a system which works and produces a good experience on vintage 8-bit systems as well as fully modern systems, however the target that I have in mind while designing and optimizing things are modern-retro systems like the ones I listed earlier in this comment.
@ModernRetroDev well fwiw I'm coming from a different angle, this popped up in my feed, presumably because I've been googling lightweight protocols because I'm trying to make a pi Pico into a computer.
Again it's not really up to the modern web, and I can't really be arsed to get into all that anyway.
Personally, I'd like some html 1 type thing. Preferably even easier to parse. But with an equivalent that can optionally be served. Plus, I know the Gemini protocol has has flak because it isn't very clear. Sticking closer to how the web used to operate, you can learn from the actual issues encountered.
Bbss do escape codes so you should be able to what a Unix terminal can do. Considering what computing power early Unix had. So I don't think basic wrapping should be an issue.
That then opens it up to more use cases. The ability to optionally serve up images just makes it much more useful.
Another issue that occured to after my last message was character sets. If you want to make your site pretty (which is going to happen) with IBM box characters, or c64 graphic characters, it breaks for many other people. So then it's better to say I want a box then the client can render
+-----+
| Box|
+-----+
Or use graphics, or specialist characters. Your current plan makes assumption about character sizes also. If a font pixel is 8x8 pixels, it might work fine, what if it's 6x8? Then the graphics don't use enough space, and the opposite is even worse.
I like the leaves thing. It opens up the possibility of infinite scrolling, (which I'm sure would actually be a feature in the alternative web) and allows dynamic interaction. A tick box could load a different next leaf. And I think compared to Gemini the no encryption thing is a plus. So I think it's got genuine 'broad' appeal outside of the retro community.
I love what you are doing! This concept of web pages/documents for retro machines I find really compelling: the restrictions make for interesting solutions while still aiming to get close to a modern interface (without all its complexity).
- I would like to see an implementation of links (withing a "website").
- Are you going to implement TCP/IP and http? Or a more simple protocol? Maybe do a bit of research on that.
- Maybe get the retro community involved in creating tooling for this or helping with the implementation?
Regards, JeffreyH (as known within the X16 community)
Regarding internal/external document linking, that is absolutely something that I would like to do, I just haven't thought too deeply on the matter thus far. However, I think that as I have structured the concept to use leaves (which are little bits of content), this means that when links are finally implemented, it would be a natural target to use for that purpose (e.g., this link points to `somepage:leaf012`). This would allow us not only to jump to an appropriate document, but to even jump to the appropriate location within said content.
With regards to communication over the network. I'll admit I haven't thought too deeply on it at this point, however I am leaning towards implementing this on top of TCP/IP. My thinking is, I really need to see how the performance is on this thing browsing through local documents/manuals before I go and make the situation even more complicated. If performance on a local document is bad, than it'll be even worse over the network. Admittedly, this is an area where I will have to put in more thought in the future.
Finally, on the topic of retro community involvement. Yes, I would like to get help, input and feedback from the community. At this early formative stage, what I am most interested in, is feedback (I like this/I hate this) and also the various lessons learned and gotchas I've heard from people when communicating my idea. In my opinion, I haven't yet reached the minimum-viable-prototype for this particular project, which makes me very reluctant to ship it out as it is severely half-baked. However, I did feel that it was in good enough shape for me to show it off and see if others are interested.
Oh and I should say, that if you want to continue this discussion in more detail, ping me in one of the X16 discord channels. I always post my videos in the `#self-promo`, so you can find my username there. Thanks for watching!
At the moment I'm most interested in the minimalist document format. I'd love to be able to view web/rss on 80's style computer hardware. I really dislike how inefficient modern information technology has become. Need the equivalent of a super-computer just to display simple text and images!
I'm glad that you found this project interesting as well! I do feel like things can be done better than they are currently. Furthermore, I think this concept (if done properly) could be a boon not only for older/weaker systems but also for modern and mobile systems. I'll be back with an update on this project before too long, however before then, I think I'd like to show off some of the other things I've been working on. Thanks for tuning in!
Regarding this smolweb like presentation, just a remark: For newspapers (printed ones) it is common to have text in columns not being wider than about 32 character, because of better readability. The same may be natural for mobile phones because of their screen width. So it would be great to have a format not fixed or oriented to a fixed screen size, but usable on all kinds of small devices - means, floating text, no hard cr/lf, where ist is not needed. Hard coding also makes the dokuments larger, because of additional formatting characters. Let the presentation be decided by the device, not the format.
Regarding colors, different old machines may have totally different capabilities. The 16/32 bit Atari ST for example has nativly just a maximum of 16 colors, but only in 40 column character mode. Because of this it could be a good idea to have something like an optional grayscale mode. With that 16 shades of gray may be fully enough for little images, even if not colored.
A big bunch of old machines may have no image capabilities at all, at least wihtout additional hardware. CP/M machines, PET, ZX81, ... Because of this I once was searching for a least common denominator, like the block graphics characters in different character sets. The Commodore ones, Sinclair, Tandy Coco for example have all these block graphics, for CP/M it would be a question of the used character set. Personally I find these cool and some kind of own art form. You can do many things with it, build things with it, like Lego blocks.
So I agree with being somewhat flexible on text width, by perhaps offering both 40 column and 80 column versions of the content. However, as I said in the video, I don't want to push the burden of laying out dynamic textual content of the document onto the client, as the client may be a creaky 6502 CPU. My thought is that the content creator would create the document in a free form format (something of a cross between markdown and LaTeX probably), then that content would be compiled into a static form. That static form is what would then be sent to the client on request.
Regarding colors, I don't want to actually serve up text colors directly. Instead, I would want to serve up an intent or style instead (e.g., a bit of text might be a link, or have emphasis). If the server/document only communicates intent, then it can be handled appropriately on the client side. This allows for documents to be well rendered in light-mode, dark-mode, or other custom themes, not to mention on monochrome systems.
The last issue is with images and realistically, the server is going to have to have a number of formats and options available for clients. One of those options could most certainly be, to not get the images. I should also say that this project is still very much in a formative stage and many of the aspects of this concept probably need to receive more contemplation and feedback. So I will continue to think on this, and I thank you for your feedback.
What kind of problem was this "compiler" going to solve? I see how it'd be a fun challenge compacting the essential functionality in as small a memory footprint as possible, but if it's forth, than forth it is 😊
Well, there's a few things I have in mind for this compiler project. First off, let me just say that all of these things are just hobby projects of mine... so if they seem fun to me for one reason or another, I have a tendency to just march in a direction and see what happens. Now I don't want to spoil my next video by dropping all the salient details here, but I will tell you that one aspect of this compiler project is that it is a heuristic exercise. However, that is far from the only reason as to why I am pursuing it. Here's to hoping you enjoy the story when I do get around to talking about it. Also, thanks for watching!
They’re all interesting to me. Compiler, web, game in that rank
Thanks for chiming in. That seems to be general sentiment. I think I'll aim to talk about my compiler project next time.
This is probably an unpopular opinion, but I think the 8x8 text cells of 8bit micros was inferior to non square fonts like VGA with true descenders. I spent countless hours staring at both a commodore 64 and a text mode. 80 column IBM PC and much as I love the commodore 64. The IBM PC text was just infinitely better.
So more like a specification for formatting a 'text file' with optional images?
(over the web, in a specialised browser)
Sounds pretty neat!
Reminds me of guidelines for sending plaintext email
Yes, meanwhile breaking it down into small transferable chunks. Also, I do think that inter and intra-document links are a must. So its a text file, with potentially embedded images and potentially hyperlinks of a sort. Admittedly, I need to do a bit more thinking about the finer details (lots of great feedback in the comments), but as I pointed out this is merely an early proof of concept at this point.
It's always been my plan with this channel to talk about the development of my projects mostly in the present tense. Which is to say, I'm really showing things off here as early as am comfortable with doing so. While my inner perfectionist, wants me to wait till each thing is 100% done, I want to show of my thought process and all the little milestones along the way. So, here's to hoping people actually enjoy watching content in this form.
Headshot snapper turtle
I would more be interested in compiler technics instead of games.
Great to hear. That's what I've been playing with most recently, so it's fresh on my mind.