BASIC for the CBM-II/8088

classic Classic list List threaded Threaded
65 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

BASIC for the CBM-II/8088

Baltissen, GJPAA (Ruud)

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
Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Michał Pleban
Baltissen, GJPAA (Ruud) wrote:

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

I understand that you are wrting this for a 8088 CPU? If so, how do you
access the screen data? Or do you just allow entering one line at a time
(like MS-DOS command line)?

> 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

The time needed to tokenize one line as the user is entering it is
neglible - you may spend 100 or 200 ms on it, but the user will not even
notice this delay as he is happily typing the next line. Whereas you
will save lots of time on execution, and that's what the user will notice.

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

Writing a BASIC compiler is quite a complicated affair. If you want to
have fun coding it in assembler, you may do it, but it will be lots of work.

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

The first solution that came to my mind is to store some kind of hash of
the variable name in place of the name itself. The hash will obviously
have a fixed length. However, you need to choose the hash length wisely
to make possible vairable name collisions unlilkely enough.

Also, Commodore BASIC does _not_ tokenize variable names in the program.
They are always stored verbatim, and you should do the same.

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

I would definitely advise against allocating a fixed length for strings.

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

If you are coding for the 8088, you really don't need to limit yourself
rigidly to the two or four 64 kB segments. 8088 has quite flexible
segment registers, so you can divide the memory more easily. What I
would do is to store the program text growing upwards from the bottom of
memory, and the variables growing downwards from the top of memory.

Regards,
Michau.

Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

MiaM
Den Thu, 05 Jul 2018 14:59:49 +0200 skrev Michał Pleban
<[hidden email]>:

> Baltissen, GJPAA (Ruud) wrote:
>
> > 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.
>
> I understand that you are wrting this for a 8088 CPU? If so, how do
> you access the screen data? Or do you just allow entering one line at
> a time (like MS-DOS command line)?
>
> > 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
>
> The time needed to tokenize one line as the user is entering it is
> neglible - you may spend 100 or 200 ms on it, but the user will not
> even notice this delay as he is happily typing the next line. Whereas
> you will save lots of time on execution, and that's what the user
> will notice.

+1

Not even the most complicated lines take any noticeable time to store.

> > 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.
>
> Writing a BASIC compiler is quite a complicated affair. If you want to
> have fun coding it in assembler, you may do it, but it will be lots
> of work.
>
> > Storing the variables. Again I don't know exactly how BASIC saves it
> > variables.

There are some stuff online about this. In short it has a table
(dynamically resized as needed) that contains a list of all variable
names, types and for floats and integers the actual values. For arrays
it instead points to where in the array area the variable is, and for
strings it points to where the string is stored.

If you have a linje like 10 A$="HELLO" then the pointer for A$ would
actually point into the stored program. But if you have a line like 20
B$="HEL"+"LO" then space will be allocated for the resultant string and
the pointer for B$ will point to that space. If B$ is shrunk the
existing length will be retained, while if B$ grows then a new space
will be allocated (maybe it deletes the old if it were the last stored
in the string space). This is the reason for the need of garbage
collection.

On VIC-20/C64 the pointers for these areas are somewhere around 43
(decimal) in zero page.

> > 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.
>
> The first solution that came to my mind is to store some kind of hash
> of the variable name in place of the name itself. The hash will
> obviously have a fixed length. However, you need to choose the hash
> length wisely to make possible vairable name collisions unlilkely
> enough.

Atari 8-bit basic has another aproach to this. It has a list of
variable namnes, which is used when entering and listing a program.
While running the program all variables are referenced by the type of
variable and a numer. This imposes a limit of the number of variables
of each type. Atari has iirc a limit of maybe 127 or 63 variables of
each type, or something similar. Imho not good to have that limit, but
with an 8088 it might be faster as you can chew data in 16-bit chunks.

Atari 8-bit basic is painfully slow, but that's not due to this being a
bad idea, rather due to other reasons.

Btw if you write your own basic, please let it be able to use integers
even in calculations, for speed reasons.

It seems like Microsoft Basic = CBM Basic were written to be able to
process mathematical problems and other thins like speed had a lower
priority.

I'd suggest that you read all about Basic at pagetable.com , there are
some really great articles.

> Also, Commodore BASIC does _not_ tokenize variable names in the
> program. They are always stored verbatim, and you should do the same.

True, the only thing that CBM Basic process when entering a line is
tokenize the reserved keywords and convert the lines line number to a
16 bit integer.

> > 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.
>
> I would definitely advise against allocating a fixed length for
> strings.

But maybe add the possibility of DIM'ing the lenght of a new string.

> > 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)
>
> If you are coding for the 8088, you really don't need to limit
> yourself rigidly to the two or four 64 kB segments. 8088 has quite
> flexible segment registers, so you can divide the memory more easily.
> What I would do is to store the program text growing upwards from the
> bottom of memory, and the variables growing downwards from the top of
> memory.

+1.

Btw maybe it would be a good idea to patch some existing basic instead?

And while we are at it, did you two ever consider my idea to make a
part of the ram remappable to $B0000 or $B8000 to be able to emulate a
PC display card?


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Michał Pleban
Mia Magnusson wrote:

> And while we are at it, did you two ever consider my idea to make a
> part of the ram remappable to $B0000 or $B8000 to be able to emulate a
> PC display card?

Yes, that's what I want to try for the next iteration of the card. I
will have some free time at the end of July so I want to prototype
something to see whether this is feasible.

Regards,
Michau.




Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Rhialto
In reply to this post by MiaM
On Thu 05 Jul 2018 at 16:34:55 +0200, Mia Magnusson wrote:

> > > Storing the variables. Again I don't know exactly how BASIC saves it
> > > variables.
>
> There are some stuff online about this. In short it has a table
> (dynamically resized as needed) that contains a list of all variable
> names, types and for floats and integers the actual values. For arrays
> it instead points to where in the array area the variable is, and for
> strings it points to where the string is stored.

Each (non-array) variable takes up a slot of 7 bytes. 2 of those are the
name. The 2 high bits of the name are set in various combinations to
indicate the type (AB, AB$, AB%).

See for instance at
https://archive.org/stream/transactor-anthology/anthology#page/n7/mode/2up

Variables are only ever added, never removed, so there is no garbage
collection for them, only for the values of strings.

> If you have a linje like 10 A$="HELLO" then the pointer for A$ would
> actually point into the stored program. But if you have a line like 20
> B$="HEL"+"LO" then space will be allocated for the resultant string and
> the pointer for B$ will point to that space. If B$ is shrunk the
> existing length will be retained, while if B$ grows then a new space
> will be allocated (maybe it deletes the old if it were the last stored
> in the string space). This is the reason for the need of garbage
> collection.
>
> On VIC-20/C64 the pointers for these areas are somewhere around 43
> (decimal) in zero page.
-Olaf.
--
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl      -- are condemned to reinvent it. Poorly.

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Rhialto
In reply to this post by Baltissen, GJPAA (Ruud)
On Thu 05 Jul 2018 at 12:26:51 +0000, Baltissen, GJPAA (Ruud) wrote:
> 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.

There is a table of 25 bytes, usually described as "screen line wrap (or
link) table". In the PET it is at $00E0 - $00F8. The 80-column version
uses this space for something else, since it doesn't combine lines. (Not
even when it has a window set with shorter lines).

https://archive.org/stream/transactor-anthology/anthology#page/n37/mode/2up

In the 64 it looks like it is $00D9 - $00F2 "Screen line link table".

https://archive.org/stream/transactor-anthology/anthology#page/n45/mode/2up

The table contains, for each of the 25 screen lines, the high byte of
the screen memory where it starts. The corresponding low byte is in
table in ROM somewhere.

If the screen line is a start line, the high bit is set. For a
continuation line, the high bit is clear.

list

10 for i = 217 to 242
20 printpeek(i);
30 next
ready.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx


run
 132  132  132  132  132  132  132  5  1
33  133  133  133  5  134  134  134  134
  134  134  134  135  135  135  135  135
  135
ready.


### commodore basic ###

 31743 bytes free

ready.
10 for i = 224 to 248
20 ?peek(i);
30 next
xxxxxxxxxxxxxcmkfjkjfkljkdhjghvhvhvhvhvh
vhvhvhjvhvhvhvhvhvhvhvhvjy
run
 128  128  128  128  128  128  128  129
 129  1  129  129  129  130  130  130  1
30  130  130  130  131  131  131  131  1
31
ready.

Hm, the table seems one byte too long :-) Possibly so that even the last
line has a pointer to where it ends, or something.

Also, on the VIC and 64, things probably go wrong if you try to relocate
the screen to $8000 or higher, since the trick with the high bit doesn't
work any more.

-Olaf.
--
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl      -- are condemned to reinvent it. Poorly.

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Spiro Trikaliotis
Hello,

* On Thu, Jul 05, 2018 at 09:38:25PM +0200 Rhialto wrote:
> On Thu 05 Jul 2018 at 12:26:51 +0000, Baltissen, GJPAA (Ruud) wrote:
> > 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.
>
> There is a table of 25 bytes, usually described as "screen line wrap (or
> link) table".

Perhaps, the most important part for Ruud is that BASIC does not know
about this at all. It is part of the KERNAL, more precisely, of the
editor.

Note, also, that the VIC20 can combine up to 4 lines. That's where the
limit 88 (= 4 * 22) for the maximum BASIC line length comes from.


Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Spiro Trikaliotis
In reply to this post by MiaM
Hello Mia,

* On Thu, Jul 05, 2018 at 04:34:55PM +0200 Mia Magnusson wrote:
> Den Thu, 05 Jul 2018 14:59:49 +0200 skrev Michał Pleban
> <[hidden email]>:
> > Baltissen, GJPAA (Ruud) wrote:

> > > Storing the variables. Again I don't know exactly how BASIC saves it
> > > variables.
>
> There are some stuff online about this. In short it has a table
> (dynamically resized as needed) that contains a list of all variable
> names, types and for floats and integers the actual values. For arrays
> it instead points to where in the array area the variable is, and for
> strings it points to where the string is stored.

For arrays, you are wrong. Array have their own area, and they start
after the variable area.

"Normal" variables all occupy 7 byte (even if they do not need all of
them), that's why you can proceed to the next one just by adding 7 to
the current address.

For arrays, this is not true anymore, they occupy exactly as many byte
as they need to.

>                                              If B$ is shrunk the
> existing length will be retained,

I think you are wrong: BASIC will allocate new space for a new variable,
even if it is smaller than the previous one. It will let the GC take
care of this later.

At least, that should be correct until BASIC2. I do not know about newer
ones (namely, 3.5, 7.0)

> while if B$ grows then a new space
> will be allocated (maybe it deletes the old if it were the last stored
> in the string space).

Your "maybe" part is wrong, again. It will not do this. It just lets the
GC handle it.

 
> On VIC-20/C64 the pointers for these areas are somewhere around 43
> (decimal) in zero page.

43/44: start of BASIC program
45/46: start of variable area (and, thus, end of program + 1)
47/48: start of array area (and, thus, end of variable area + 1)
...

 
> It seems like Microsoft Basic = CBM Basic were written to be able to
> process mathematical problems and other thins like speed had a lower
> priority.

Most probably, they had a space limitation. They wanted to make BASIC as
small as possible. That's why even the advanced FP routines were
optional in the original MS BASIC.

As the routines already existed, it was easier (program size wise) to
reuse the routines instead of generating their own integer routines.

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Steve Gray
In reply to this post by Baltissen, GJPAA (Ruud)
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)" <[hidden email]>
To: "[hidden email]" <[hidden email]>
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
 
 
 
 
 


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


Reply | Threaded
Open this post in threaded view
|

RE: BASIC for the CBM-II/8088

Baltissen, GJPAA (Ruud)
In reply to this post by Michał Pleban
Hallo Michał,


> If so, how do you access the screen data?

I don't read the screen actually, I read the table I mentioned later. At this moment I limit the length of a BASIC line to 80 chars and the end effect is more or less that I keep a copy of the screen memory in the memory handled by the 8088.


> Or do you just allow entering one line at a time (like MS-DOS command line)?

That is indeed what I do in my OS project. I just extended the idea.


> If you want to have fun coding it in assembler, you may do it, but it will be lots of work.

It sounds if I have other means to code it in. I know Linux is coded in C down to a very low level. So what could I do here? And assume it is loaded and started by the piece of code on the boot sector.
One question: what about the size of the compiled program?


> Also, Commodore BASIC does _not_ tokenize variable names in the program. They are always stored verbatim, and you should do the same.

But I need to make a look-up table that contains the value. Which means I have to use the name again to identify the entry. By using a code I save space. OK, not much, so I already have been thinking about skipping using this code thing. It also saves on needed code.

 
> I would definitely advise against allocating a fixed length for strings.

But that would mean I have to implement "garbage collection".


> What I would do is to store the program text growing upwards from the bottom of memory, and the variables growing downwards from the top of memory.

I certainly have a look at it.




Hallo Mia,


Thank you for you explanation!


> Btw if you write your own basic, please let it be able to use integers even in calculations, for speed reasons.

I already had the same idea.


> Btw maybe it would be a good idea to patch some existing basic instead?

I decided to start from scratch. A good idea? I don't know. FYI: the moment I come to code the actual BASIC commands, I'll use the source code of the C64/128 as guide.




Hallo Steve,

> I started my PC programming using GWBASIC then QuickBASIC and ...

Except possible direct screen accesses, I don't have any idea why they should not run under MS-DOS on the CBM-ii/8088.


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
Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Hans Liss
Hi Ruud,


On 2018-07-06 08:26, Baltissen, GJPAA (Ruud) wrote:
> Hallo Michał,
>  
>> I would definitely advise against allocating a fixed length for strings.
> But that would mean I have to implement "garbage collection".
>
>
>> What I would do is to store the program text growing upwards from the bottom of memory, and the variables growing downwards from the top of memory.
> I certainly have a look at it.
>

You could implement a simple heap memory manager. I found this very
clear explanation:
https://www2.cs.arizona.edu/~collberg/Teaching/553/2011/Handouts/Handout-6.pdf

/Hans

Reply | Threaded
Open this post in threaded view
|

RE: BASIC for the CBM-II/8088

Baltissen, GJPAA (Ruud)
Thank you !!!

> -----Original Message-----
> From: Hans Liss <[hidden email]>
> Sent: vrijdag 6 juli 2018 08:39
> To: [hidden email]
> Subject: Re: BASIC for the CBM-II/8088
>
> Hi Ruud,
>
>
> On 2018-07-06 08:26, Baltissen, GJPAA (Ruud) wrote:
> > Hallo Michał,
> >
> >> I would definitely advise against allocating a fixed length for strings.
> > But that would mean I have to implement "garbage collection".
> >
> >
> >> What I would do is to store the program text growing upwards from the
> bottom of memory, and the variables growing downwards from the top of
> memory.
> > I certainly have a look at it.
> >
>
> You could implement a simple heap memory manager. I found this very clear
> explanation:
> https://www2.cs.arizona.edu/~collberg/Teaching/553/2011/Handouts/Hand
> out-6.pdf
>
> /Hans
>

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
Reply | Threaded
Open this post in threaded view
|

RE: BASIC for the CBM-II/8088

Baltissen, GJPAA (Ruud)
In reply to this post by MiaM
Hallo Michał, Mia and others,

 
> And while we are at it, did you two ever consider my idea to make a part of
> the ram remappable to $B0000 or $B8000 to be able to emulate a PC display
> card?

Going through my sources I ran into a piece of code that handles clearing the screen. And I noticed it was writing directly into the screen memory, something that should not be done regarding the CBM-II. When I started coding this was one of the first pieces I wrote. And I wrote it with reason I just found out again. The next code:
 

        mov cx,80*25 ; 80 columns, 25 rows
.L100:
        mov ax,0E20h ; =  mov al,' '  +  mov ah,0Eh
        mov bx,7
        int 10h

        loop .L100


needs about 2 seconds to clear a screen; you see the cursor running over the screen. So unless someone has a better routine or another idea, I support this remap idea.


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
Reply | Threaded
Open this post in threaded view
|

RE: BASIC for the CBM-II/8088

Baltissen, GJPAA (Ruud)
Hallo allemaal,


Update:

> The next code:
> .....
> needs about 2 seconds to clear a screen;

As I said before, I learn something in the process as well.

I also found out that I used direct screen accesses for doing my own scrolling. Reading a character using INT 10h and writing it to the next or previous line would take even longer than 2 seconds IMHO. But having seen Michał's CBM-II in action, I knew I had something wrong. Studying some INT 10h documents I noticed some routines for scrolling. One could be even used to clear the screen according its documentation. And yes indeed, it works like a charm! It is less faster than the direct access method but better than I expected.


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
smf
Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

smf

scrolling and clearing can be done with the same int 10h call

Scroll up window AH=06h AL = lines to scroll (0 = clear, CH, CL, DH, DL are used),

BH = Background Color and Foreground color. BH = 43h, means that background color is red and foreground color is cyan. Refer the BIOS color attributes

CH = Upper row number, CL = Left column number, DH = Lower row number, DL = Right column number


Scroll down window AH=07h like above

It'll probably not be as fast as directly writing to the screen, but much faster than an int 10h loop

examples here:



On 06/07/2018 14:10, Baltissen, GJPAA (Ruud) wrote:
Hallo allemaal,


Update:

The next code:
.....
needs about 2 seconds to clear a screen; 
As I said before, I learn something in the process as well. 

I also found out that I used direct screen accesses for doing my own scrolling. Reading a character using INT 10h and writing it to the next or previous line would take even longer than 2 seconds IMHO. But having seen Michał's CBM-II in action, I knew I had something wrong. Studying some INT 10h documents I noticed some routines for scrolling. One could be even used to clear the screen according its documentation. And yes indeed, it works like a charm! It is less faster than the direct access method but better than I expected.


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
Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Michał Pleban
In reply to this post by Steve Gray
Steve Gray wrote:

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

Microsoft ported its MBASIC from CP/M to MS-DOS. It runs under MS-DOS
1.x and can be run in the original MS-DOS 1.25 environment for the card.
I tried it and it worked without any major problems.

Regards,
Michau.



Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Michał Pleban
In reply to this post by Baltissen, GJPAA (Ruud)
Baltissen, GJPAA (Ruud) wrote:

> Reading a character using INT 10h

Beware - INT 10,08 (read character from screen) is not supported on the
8088 card!

> Studying some INT 10h documents I noticed some routines for scrolling.

Fortunately, INT 10,06 and INT 10 07 are supported :-)

> One could be even used to clear the screen according its documentation.

Supported too ;-)

Regards,
Michau.

Reply | Threaded
Open this post in threaded view
|

RE: BASIC for the CBM-II/8088

Baltissen, GJPAA (Ruud)
Hallo Michał,


> Beware - INT 10,08 (read character from screen) is not supported on the 8088 card!

Strange, are you sure? You said you tried BASIC under DOS 1.25. I haven't run any BASIC under DOS the last 15 years so I'm not quite sure of it behavior anymore. But IIRC it behaves just like BASIC on any 8-bits Commodore (= Microsoft as well). If this BASIC is not using function 8 (indirectly through DOS), how does it keep track of changes?
Then what about other programs needing this function? (none comes to my mind right now)

IMHO every INT function that is supported by the original IBM BIOS and can be supported, should be supported by the BIOS of the 8088 card as well. Should be doable with the new card with its 64 KB EPROM.

A possible solution (for the moment ?) is reserving memory which serves as a copy of the screen. Every movement of the cursor and key input is stored here before being sent to the computer itself. So when an "Enter" is detected, the actual line is read from memory rather then being read form the screen using function 8. But I'm not happy about that.


Anyway: I also decided to limit the length of the BASIC lines to 80 chars. Which means no table needed to keep track of longer lines. If time proves we need longer lines, it is something that can be implemented later.


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
Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

Michał Pleban
Hello!

Baltissen, GJPAA (Ruud) wrote:

> Strange, are you sure?

Yes - I wrote the functions so I am pretty sure that I didn't write this
one ;-)

> You said you tried BASIC under DOS 1.25. I haven't run any BASIC under DOS the last 15 years so I'm not quite sure of it behavior anymore. But IIRC it behaves just like BASIC on any 8-bits Commodore (= Microsoft as well). If this BASIC is not using function 8 (indirectly through DOS), how does it keep track of changes?

You don't need to read anything from the screen to allow the user to
input lines of text. You just need a text buffer in memory where you
store the characters the user typed, and output them to the screen using
INT 10,0E. The buffer does not need to be limited to 80 characters.

You are probably thinking in terms of full-screen BASIC editor like on
Commodores. That's not how MS-DOS, MBASIC EDLIN and other CP/M era
programs handle text input; generally, they don't have full-screen
editors at all, they just allow entering one line at a time. When you go
into territory of full-screen editors, then you really need direct video
memory access because reading individual chars with INT 10 will be too
slow anyway.

> Then what about other programs needing this function? (none comes to my mind right now)

I haven't come up with any so far. If a program needs to read characters
from the screen, it generally accesses the video memory directly instead
of bothering with INT 10.

> IMHO every INT function that is supported by the original IBM BIOS and can be supported, should be supported by the BIOS of the 8088 card as well. Should be doable with the new card with its 64 KB EPROM.

The two main problems with "reading" characters from the screen is that
the screen is really on the 6509 side. That means that:

* The screen is in PETSCII; you would need to convert it back to IBM
which means you need another conversion table somewhere.

* There are 256 IBM characters but only 128 PETSCII characters so the
conversion IBM->PETSCII is lossy. Therefore, if you read back a
character, you will not always get back what you wrote.

All this can be done, but I focused my efforts on functions which were
really used by some software I tried.

> A possible solution (for the moment ?) is reserving memory which serves as a copy of the screen. Every movement of the cursor and key input is stored here before being sent to the computer itself. So when an "Enter" is detected, the actual line is read from memory rather then being read form the screen using function 8. But I'm not happy about that.

This can be done, but seems lots of effort to support a function that
nobody is using. I'd rather wait till me have the proper video memory
emulation on the card.

Regards,
Michau.

Reply | Threaded
Open this post in threaded view
|

Re: BASIC for the CBM-II/8088

MiaM
Re video emulation:

How much of the components of the B motherboard are socketed and how
much is soldered directly to the board? I've seen some pictures and it
seems like only the largest IC's are socketed.

Looking at the schematics, it would be really easy to add support for a
PC8 char rom and reuse the invert signal (MSB of screen ram data) to
support 256 instead of 128 characters.

It would not be that hard to add an additional of 2k ram as attribute
memory, although it would require a bit more effort. U25 74LS139
already decodes $C000-$DFFFF in 2k steps, where $D800-$DFFF isn't
useable as U24 74S138 already decodes that 2k block into 256 byte
blocks. $D000-$D7FF is already used for existing video ram. $C000-$C7FF
and $C800-$CFFF is free and either one of these could be used for
another 2k which could be used as attribute memory.

Of course this would only be visible by the 6509, but it would still
make it far easier, just copy 4k of data each time the screen needs
updating. Not sure if a 4k block copy (fixed addresses both for source
and destination, and requiring ,Y indirect addressing for either source
or destination) would be too slow to just do on each interrupt.


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

1234