Відео

I agree with @wChris_. What I had read until now is about the operations being simple. So I think you are on the right path with your add sub mult and div operations. The += must not be in the low level. But of course if fine on the high level. All math operations must be in the form dest = var_or_constant_1 operation var_or_constant_2 (en.wikipedia.org/wiki/Three-address_code) Maybe the println should not be a primitive on the IR. You can have a generic 'call' primitive to call funcions on your standard library. On my project I use a concept like of the asmsub on prog8, you can take a look. And maybe you should not have 'if' and 'loop' control flow on it. But labels and conditional 'goto' primitives. So not this : if a = b #do this elif #do this end if ... You will have : v1 := a = b ifnot v1 goto else_label # do this (if block) goto endiflabel :elselabel # do this (else block) :endiflabel

I already promised one of the other viewers that I would open source the code at some point, probably with an MIT license. Right now though, it's in such rough shape it would be embarrassing to share. Also, seeing as how I had to break up this video into effectively two parts, posting up the code as it is now, would effectively amount to giving away a huge spoiler with regards to the next part. That said, I'm really glad to hear that you are enjoying this project! Hearing that from other people certainly makes me feel like making these videos is well worth my time. Thanks!

@@ModernRetroDev Hey, don't believe for a second you should be embarrassed by your code, dude. It is a work in progress, it is a foundation for what you are building and, probably most important, it is working. Yeah, it may be rough around the edges, maybe you have some "creative" work-arounds here and there, but hey, you got to solve the problem first and then refactor. You should be proud: you're building something people are interested in and are keen to contribute, even if it's just a comment here and there. And yeah, I agree about the spoiler part, I think I would rather wait for the revel, at this point!

C# is an odd one in that you can make .NET compile it for you on the fly using the Roslyn APIs. You can for examples take a C# text file, convert it to an in-memory binary on the fly and execute it on the spot. No emulation required.

I'm not going to lie. I totally had to search the internet for the term "orchestrator for docker containers". Unfortunately, that is way outside of my expertise and also, not really within the umbrella of topics that would fit within this channel. That said, I do hope that you'll enjoy some of the things I talk about here. Thanks for watching!

Docker?... noooooooo....

These are some great comments questions and I think I might have some great answers as well. First off, I am far from the first person to attempt a modern language for retro computers. There's another guy who is active in the X16 community who is way farther along on one and it is awesome by the way (take a look at this: prog8.readthedocs.io/en/stable/ ). If you just want to get started dipping your toe into X16 development, Prog8, is a great place to start. Regarding LLVM... that is actually one of the paradigms I was thinking of as I contemplated how best to approach this task. I think fundamentally it has a great design which enables supporting multiple higher level languages. I suspect it is less prone to regressions as a result of this design as well. Regarding the potential of using LLVM framework within my project. While this could be possible, I suspect the framework would be so big that this would prevent me from ever being able to make a compiler which could run natively on a 6502 system. Also, there is another cool project which directly leverages LLVM to compile C code for 6502 targets (see: llvm-mos.org/wiki/Welcome ). So that's another similar and fun project.

I would not recommend LLVM. It's extremely heavy-weight. If this is your full time job, then it's a no brainer, spending several months learning LLVM and getting productive is fine, and you'll want to stand on the shoulders of giants. The company you're working for likely would settle for nothing less. For hobby stuff, ain't nobody got time for that. Keep it simple.

@@OneWingedShark I just a video in writing a FOrTH interpreter in Zig. Which doesn’t compile words to assembly as that’s a hassle in a memory managed environment. But it’s a fun language.

@@CallousCoder -- I "cheated" with my implementation in Ada: a variant-record that contains either a list of words or else an access-to-procedure [with the 'VM' as an IN OUT parameter], then wrote all the core words in that form, compile, and let the Ada compiler handle generating the machine-code for me.

@ aah I had a similar thought to inline words and compile a new binary (didn’t do it) but that’s a similar approach I guess. I miss the old days where you could just do self modifying code without a lot of OS memory management hassle. Memory protection is so overrated 😉🤣😜 I actually hope to have some more time and do this on the PiPico or a bare metal RiscV that will actually generate binary code to jump to and execute and not just reinterpret.

​@@CallousCoder Maybe they're similar approaches. The word "reinterpret" makes me a bit unsure. The technique I was describing is essentially: TYPE Operation is not null access procedure( Object : in out VM ); -- VM: the Forth stacks, collectively, plus the dictionary [populated w/ core on init]. Procedure ADD ( Object : in out VM ) is Begin Push( Pop(Object) + Pop(Object) ); End ADD; Since it's native Ada, the compiler generates the binary for the procedure and the VM's initialization associates that with the dictionary entry for "ADD" - because the Forth is meant to run on the same machine I'm compiling for, the access to the procedure _is_ the "chunk of machine-code" to execute - and so I can "hijack" the compiler's codegen so I never _have_ to touch assembly by-hand. But, you're right that sometimes the OS steps on your toes inconveniently.

Regarding code style: thus far I have been focusing on the low-level language interface. Earlier versions of my compiler (prior to my making of this video) did infer the actual types on either side of mathematical operations, however as I described in the video, this was proving to be error prone and was removed from the low-level implementation in favor of being fully explicit. Both this and the other stylistic comment are likely more relevant for the higher-level interface. To be honest, I haven't thought too much yet about what that higher level interface should look like, but once the lower-level parts are more complete I will start contemplating on the matter. Regarding C as a compilation target. I think that's a great idea, and was already something that I was considering, but not so that I can compile for 6502 systems. Rather so that I can easily compile code from this novel language onto fully modern Linux/Windows/OSX systems. Also, I am already using cc65 in this project as I am feeding the assembly I generate into its assembler.

@@ModernRetroDev As far as syntax decisions go and using type inference, I took inspiration in my own language from QBasic. You can use a statement to guide the compiler towards a "natural" default. Maybe it sounds silly to take inspiration from such a language, but it was an idea ahead of its time as far as clarifying type inference for the users. If you're using a lot of floating point types it can be annoying to constantly type whatever typename you use for it, so for my language I can use a directive and just #default type=float32 and for all the code after it and until a new directive is encountered every variable that uses type inference will just start with the assumption that it's floating point. Obvious incompatible types will either cause errors or the user will have to explicitly type the variable. That way you could just assign a value to a variable and if it can be converted by the compiler or interpreted as floating point the compiler does it.

I've been constantly working to improve my production quality, but I am still very new at producing videos and as such, I still have a lot of room for improvement. In fact, for this video I switched over to a new camera than I was using before. Due to my lack of familiarity with the new camera, I ended up routing the microphone input directly through my computer instead of through the camera. So it might have been that, it might have been improper gain levels. Or perhaps overly aggressive noise suppression algorithm. Beyond that I do audio compression and normalization steps as well. Long story short, making the audio within a video sound decent is a bit of work, not particularly straightforward, and I am inexperienced in this area. I'll try and do better with the audio next time, but as with everything, I'm teaching myself this stuff and learning as I go. Audio quality aside, I do hope you enjoyed the video.

Very interesting. Thanks for sharing that book recommendation, but good golly is it expensive. That reminds me of being back in college and buying from the campus bookstore.

@@ModernRetroDev Wow, you are right. The prices for the new book are ridiculous! But luckily on ebay the edition from 1986 is offered for ~20$.

I don't agree. Write a simple recursive decent parser by hand. It won't take long and will have much better error handling than a compiler compiler's generated garbage. Besides, the hard part about a compiler is not the parser. It is type checking. And the dragon book basically has just a handful of high level paragraphs on type checking and spends almost the entire rest of the book on parsing, which is so easy you can write software to do it for you. Waste of money unless you're really interested in parsing.

So I am planning to post my source code on Github at some point (once it is in a less horrible state), but at the moment its in a pretty rough state. Regarding resources that I find useful... its mostly stuff on the 65XX assembly front, as I very comfortable with programming in general, just new to assembly. That said, let me share a few of those. First off, I printed up a page with this on it: mimuma.pl/opcodes/opcodesA4_final.png (this is great for reference). Next, I've been reading through the book "Programming the 65816" by David Eyes. This is a good book which goes into incredible detail about these processors, but is not a particularly fun or easy read. Most recently I got a copy of the brand new book "6502 for beginners" by John Dale. While I haven't yet finished reading this book (only a couple of chapters in). It's a very easy read, does a great job of explaining/showing the various memory loading/indexing operations. So far, I would give this book a very strong recommendation. Finally, the first book I started reading on the topic of retro computing was "Retro Game Dev (C64 Edition)" by Derek Morris. While I don't think I'd recommend that book for learning assembly. I suppose I can credit the book with me more getting interested in developing for retro systems.

Thanks! Glad to hear that I might be on the right track.

Like I was saying, there are some really fun and rewarding things about learning to write code in assembly. For me this was one of those cases. Also, I'm really glad to hear that other people found this to be interesting as well. This makes me think that perhaps my plan to cover projects a bit in breadth and a bit in depth, is a good one. Thanks for watching!

@ModernRetroDev As someone who does similar projects (just more long form videos), I just do what I want. Usually people stick round. Certain projects do get more views (compilers especially haha). Just hard sometimes to get engagement like comments!

This is how we always approached multiplication within CPUs that had no multiply instruction. Even on 8086 I would use it because often it was faster than the MUL instruction.

@CallousCoder I recall at uni memorising a fancy way to divide things as div is slow. Tbh I assume you could do same trick here to div/8+div/2 if div ever comes up

@@hughdavenport1 Yes div (in integers) is exactly the same shift right and subtract

The two discord servers that I am most active on, are the ones for the Foenix Retro Systsms (c256foenix.com/) and the one for the Commander X16 (www.commanderx16.com/). Both of these webpages have a links to their respective discord servers near the bottom of the page. If these modern retro systems seem interesting to you, then please drop by and join the servers. Both of these communities are super awesome, and there are tons of people working on all sorts of things. Not to mention, working on these systems is a blast. Thanks for watching!

Thank you! Yeah, I wouldn't mind eventually releasing the compiler as an open source code... probably under an MIT license. However, I'd like to get a bit further along before I do that as the code is pretty messy at this point as a result of the project itself being a learning exercise.

Sorry for being so slow to respond! but I did finally get around to posting up a video about my compiler project. Also, just as you were saying, I do think you are right that people do just get better at this sort of thing over time. I already feel like I am able to produce way better videos than I was just one month ago. Regarding C... I love writing code in C and I do it all the time. That said, if you are writing it to target a 6502 machine, you have to write in a very deliberate way to get the best performance out of your code (for example: github.com/ilmenit/CC65-Advanced-Optimizations ). There are other reasons as well, but you can see the whole explanation for this within my latest video.

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!

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!

(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.

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.

Thanks for chiming in. That seems to be general sentiment. I think I'll aim to talk about my compiler project next time.

Awesome, duly noted!

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.

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!

Great to hear. That's what I've been playing with most recently, so it's fresh on my mind.

I'm afraid I'm not. This was my first video. That said, thanks for watching!