Re: BASIC for the CBM-II/8088

From: Steve Gray <*sjgray_at_rogers.com*> Date: Thu, 5 Jul 2018 21:05:49 +0000 (UTC) Message-ID: <1916711255.3390119.1530824749081@mail.yahoo.com> · sjgray_at_rogers.com

I started my PC programming using GWBASIC then QuickBASIC and finally moving to Microsoft BASIC Professional Development System before VisualBASIC was finally released. It would be amazing if some of those old BASIC's would run on the 8088 board!
Steve

      From: "Baltissen, GJPAA (Ruud)" <ruud.baltissen@apg.nl>
 To: "cbm-hackers@musoftware.de" <cbm-hackers@musoftware.de> 
 Sent: Thursday, July 5, 2018 8:27 AM
 Subject: BASIC for the CBM-II/8088

Hallo allemaal,       I have three software projects at hand: - adding a 6809 module to MP-ASM, my Multi-Processor Assembler. - CBM-DOS, my own OS written from scratch, to be run on a PC and the CBM-II/8088 - CBM-BASIC    This is about the last one, a BASIC written in asm for the CBM-II/8088 and PC. Why? I wanted something better than MS-DOS 1.25 but a very smart guy on this list crossed my plans. Now I'm doing it for the fun mainly and to learn from the process. But I could use some ideas or other input.    So far I wrote what you can call the editor: the part that handles cursor movements, prints the typed chars on the screen and reads the line where the cursor is when "Enter" is pressed. On the C64 a BASIC line can be spread over at least two lines. I still haven't found out how the C64 knows that the current screen line is part of a bigger BASIC line. (I think) I have found a solution to handle this by creating a table that save the starting and ending screen line of every BASIC line. But comment on this and other ideas are welcome.    I know the original Commodore BASIC saves the lines in memory using tokens to replace the original text. I have been thinking about to skip this step. The disadvantages are that: - I will need more memory to save the lines, but not that much more IMHO - I will loose speed because the program line needs to be checked first at run time So I will most probably choose for the token solution as well in the future: at the moment I save the lines as text to be able to test the editor etc. Another option is to compile the program completely and to run the resulting executable. The main disadvantage: I'll need memory to store it. Storing it on and running it from disk is an option but when this disk is a floppy disk then I have my doubts: speed. Again comment on this and other ideas are welcome.    Storing the variables. Again I don't know exactly how BASIC saves it variables. What I do know is that BASIC shortens a given variable to only two characters. It simply means that Commodore BASIC sees the variables BYTE1 and BYTE2 as one and the same variable. I only found out my self yeeeears ago after a lot of frustration. But what is a reasonable length then? What ever length I will choose, I'll give every variable its own code. I'm not sure at this moment how it will look like. But this code is going to be stored in the tokenised instead of the original name as Commodore BASIC does. This will make the program shorter. And how much memory should be reserved for a variable? The length of a byte, integer or real is known. The length of a string can vary. Choosing a fixed length has the advantage that we don't have a need for garbage collection (I think). But the disadvantage id that we probably will need more memory. And again comment on this and other ideas are welcome.    Where to store everything? First we need to know whether we are dealing with a 128 KB or better. When the machine is started, BASIC and another needed file is stored in the first 64 KB. My idea is to store the variables on a 128 KB machine in the rest of the memory of the first segment, about 32 KB. Or maybe the other way around? (but I don't think so) The program will be stored in the second segment. Having a 256 KB machine or better I will use at least a segment for the variables and the program. Using more segments will create other problems of its own due to segment crossing but that is something for the future. For the last time: comment on this and other ideas are welcome.       Met vriendelijke groet / With kind regards, Ruud Baltissen    www.Baltissen.org

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