Hallo Spiro, > as always, I will not ask for the "why" and just go directly into the details. ;) In fact it was triggered by a Linux guru here at work who said that creating an OS was doable for one person. And I must say it is best a bit of fun. I certainly learned a lot about The BIOS, FAT and other disk related material. > Is it written in 8086/8088 assembler, or in a high-level language? Assembly. > Is the source available somewhere? ;) Not on Internet, yet. But you are free to send an email to get the stuff. I must warn you: although it is well documented (IMHO), it is still quite a lot of rough material with lots of try (and error) code. > I believe two formats, one "in memory format" (with tokens), and one "on disk format", > plain-text when storing the program externally, should give you more advantage. > You can use any editor externally, but you can also do any optimizations you like internally. > You can even change the in-memory-format as often as you like, as it will not affect the on > disk format. Great idea! It does mean we need a conversion the moment the program is loaded but I think the mentioned advantages out weight the loss of time. > You could "automagically" recognise CBM BASIC programs (start address... Hmm, I completely forgot about the start address and I even don't use it. So I wouldn't be compatible anyway. > You could also add a destination address for GOTO/GOSUBs, so you do not have to search the line targets over and over again. Another good idea! Hello Micha�, > For these reasons, I think FAT is much better filesystem. I agree. But the main reason for using this CBM-FS was that I wanted something that wasn't MSDOS related. Another reason: because of my work with the various C= drives I was more than familiar with it. That I switched to FAT now doesn't mean that I abandoned it. It is just a matter of two different files that handle all file access and a directive in the source that tells the compiler which one of the two to use. But its best purpose: it showed some people at my work to think a bit out of their well known box. Edit: I wrote the above yesterday. Your remark about the 254 bytes kept ringing a bell. When I checked things in the evening I found out why. I still use the link bytes but not in the sectors them self but in the BAM. In fact something like the FAT does. There was a very simple reason to do this. Now I can load a sector directly into memory. Otherwise I had to load the sector in memory first, strip the link bytes and copy the rest to the end of the already loaded part. That meant handling the data twice. And it would also mean I couldn't load more sectors in one go. For a drive these link bytes are no problem because the only thing that it will do with the loaded data is to send it to the connected computer. The moment that is done, the sector in memory is overwritten by a new one. One extra detail, I use two sets of link bytes: one set points forward, one points backwards. It enables one to search back in the chain, if needed. For floppies I use two bytes for each link, for hard disks four. That is enough for 128 GB. > You can do the same as the CBM-II 256: first 64 kB bank for the program, second for string variables, third for numeric variables, and fourth for arrays. I didn't know about this detail and I'll keep it in my mind. > Is there a garbage collection in the variable area? Very good question. So far none. But there is a simple reason for that: I still don't understand what garbage collection exactly does. In my understanding, if I understood Wikipedia correctly, the most less used variables are disposed. But in my opinion that is crazy. And AFAIK Pascal and C don't have garbage collection either. Why not if it is such a "good" tool? If someone is willing to explain in other words what garbage collection exactly does, what its benefits plus the assurance that it won't jeopardize any program, I might install it in time (in 10 years or so :) > Well then, don't forget things like DEL, REN, TYPE and so on - they are quite useful too ;-) I know, so I won't :) Marko:> guess on this group we would want to concentrate on the simpler CPUs with no MMU or virtual memory, that is, at most 8086 or 80286. :) That's exactly what I had in mind. For 386+ you have Linux, Minix and other OSes. The first comment I got when explaining that I was targeting the 8088: "but then you won't have multi-tasking, multi-user and no memory protection!". My God, at that time I didn't even know how a boot loader worked. For the moment I'm happy with my simple 8088 :) FYI: tomorrow we will go to Poland to spend Christmas there. And my parents-in-law don't have internet. So don't expect any replies from me for the time being. Which leaves me one thing to say: Merry Christmas and Happy New Year !!! Met vriendelijke groet, Ruud Baltissen De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617 The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. APG Groep N.V. is registered in the trade register of the Chamber of Commerce Limburg, The Netherlands, registration number: 14099617 Message was sent through the cbm-hackers mailing listReceived on 2016-12-21 08:00:03
Archive generated by hypermail 2.2.0.