Jump to content

Photo

OSS-D-Day part 3-Integer Basic & source code now in PD

OSS Integer Basic source code

50 replies to this topic

#26 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 14,315 posts
  • Location:United Kingdom

Posted Thu Sep 22, 2016 10:04 AM

Give it 24 and/or 32-bit ints and it would really kick ass.

#27 Alfred OFFLINE  

Alfred

    Moonsweeper

  • 414 posts
  • Location:Elmwood, Ontario

Posted Thu Sep 22, 2016 10:18 AM

Yes, I figure if they used six bytes for FP, then using say four for an integer version would be be both fast and useful.



#28 ricortes OFFLINE  

ricortes

    Dragonstomper

  • 632 posts

Posted Thu Sep 22, 2016 10:21 AM

You can't forget FP is part of the OS, so it is there if you really need it that badly. Long(s) would be nice to have of course.

#29 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Thu Sep 22, 2016 10:23 AM

flashjazzcat

You got it: take for example Carol Shaw's Calculator from 1979:

Color.jpg



#30 MrFish ONLINE  

MrFish

  • 5,350 posts

Posted Thu Sep 22, 2016 10:35 AM

Try building the cartridge with listing enabled, you'll get full source code in one file, without unused parts that may still be left on the disk.

 

Yes, definitely; some of the files may not even be part of the compilation. I was initially just looking for some possible command to control the display mode of numbers.



#31 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Thu Sep 22, 2016 10:38 AM

As I have done with the MAC/65 assembley source on the wiki.

 

But the really fun starts, when we interbreed... best of all carts in one. Like a SpartaDOS cart (64K) for BASIC, which has allin one plus runtime and compiler... ;-)

 

Let the good times roll... ;-)



#32 Larry OFFLINE  

Larry

    River Patroller

  • 4,083 posts
  • Location:U.S. -- Midwest

Posted Thu Sep 22, 2016 12:21 PM

To each his own, but I suspect there are several folks here that could gin up a little (USR) routine to do larger integers, if you really needed something like that occasionally.  I'm thrilled to have this addition to our Basic arsenal.

 

-Larry



#33 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Thu Sep 22, 2016 12:26 PM

Larry, that is all I will say. The Atari computer is seen as a game computer, but more and more proof came out, it wasn't. It was just hold behind. The machine could have done it. It doesn't mean, you are forced to used it. So with the open source everybody can now build his/her favourite OS and language. That is all. :-)



#34 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 14,315 posts
  • Location:United Kingdom

Posted Thu Sep 22, 2016 12:31 PM

It's not that we're not thrilled - far from it - but RAM and disk space are so huge now that we often find ourselves dealing with big integer values. Sure you can write machine code which adds or compares two 32-bit values, but using USR calls as part of the logic of your BASIC program is rather kludgy at best. For that matter, I have no real intention of writing a program in any dialect of BASIC at any point in the future, but if I did, I'd sure appreciate something very fast which could handle long INTs. Perhaps few others have such requirements, though. I rarely if ever need FP, but frequently need long integers. And no part of the FP package was of any use once the integers got wider than 16 bits. 32-bit ASCII/INT and INT/ASCII conversion isn't difficult and the "ideal" BASIC could have its own code on-board. 24/32-bit math is a bit more bloated (unless you use loops, which slows things little), but it's still way lighter than FP.



#35 ricortes OFFLINE  

ricortes

    Dragonstomper

  • 632 posts

Posted Fri Sep 23, 2016 10:28 AM

IMHO: Like much of what goes on here, we celebrate a lot of [would'a, should'a, could'a] in retrospect. Back when 300 BAUD was the norm, Atari BASIC was fast enough. Matter of fact, I think it was "Smart 1030" that set the standard for a lot of telecommunication programs that came after it was in BASIC. It would have been nice to have a fast BASIC back in the day just so we would have had more people contributing to the form and function of our programs. *BUT* like everything else, this was an OSS product and while the prices of their products was in line with everything else at the time, not a lot of people would have bought it. About the time this was available, there were several compilers for BASIC available. IIRC, somewhere after AMODEM 4.2 a lot of telecommunication were compiled BASIC programs.

#36 Larry OFFLINE  

Larry

    River Patroller

  • 4,083 posts
  • Location:U.S. -- Midwest

Posted Fri Sep 23, 2016 1:26 PM

Yes, I need to run some benchmarks to see how much faster it is than other variants..  And I agree, there would not have been much of a market for this product. But still very neat to have it appear out of the blue.

 

-Larry



#37 FifthPlayer OFFLINE  

FifthPlayer

    Moonsweeper

  • 425 posts

Posted Sat Sep 24, 2016 10:09 AM

Yes, I need to run some benchmarks to see how much faster it is than other variants..  And I agree, there would not have been much of a market for this product. But still very neat to have it appear out of the blue.

 

-Larry

 

It's just really odd they took on this project in the first place, given that there really wouldn't have been a big market for it.  It seems almost as if they did the project because it's a cool thing technically, rather than whether there's a business case for it. If OSS were thinking business-savvy, they would have ported Mac/65 and especially Action! to the C64 and Apple II.

 

Is this a completed project, or is it a work-in-progress with bugs and missing features?  Can you really use it to write workable programs?



#38 tschak909 ONLINE  

tschak909

    River Patroller

  • 3,082 posts
  • Location:USA

Posted Mon Sep 26, 2016 3:06 PM

From the tests I've been able to do, it IS indeed BASIC XE, sans floating point. All the features are there, and boy howdy is it fast!

 

As for the comment ricortes made about AMODEM 4.2... I knew Jim Steinbrecher, the guy who wrote ATARI MODEM, who ran his Atari-centric business SECTOR ONE all the way until 1990. AMODEM 4.2 was the last official version of the code, which ran in BASIC, and had its core terminal routines written in stringified machine code. Pretty much any version AFTER this, was not an official AMODEM version, but there were TONS of them, some that I had, and remember very clearly:

 

AMODEM PLUS 5.2 and AMODEM PLUS 5.6, were compiled variations that were compiled with the Monarch ABC compiler, the big innovation was the scrolling status bar, simple autodial (1983)

AMODEM PLUS 1.0 - a weird branch, that had built in wargames dialer, and PBX scanning features, identified by a sort of pie logo in ATASCII graphics, when being viewed (BASIC) (1983)

AMODEM 6.0, 6.1, 6.2, 6.3 - (BASIC) - support for dialing through other PSTN networks (MCI, etc.), autodial directory, etc. (1984)

AMODEM 7.0, 7.1, 7.2 - (1985) , lots of autodial features, print functionality, etc. It really pushed the limits of a size of an Atari BASIC program.

 

-Thom



#39 Larry OFFLINE  

Larry

    River Patroller

  • 4,083 posts
  • Location:U.S. -- Midwest

Posted Wed Sep 28, 2016 9:24 AM

I did run some benchmarks with the Sieve:

 

Rev C Basic 16086 jiffies

Altirra 8071

Integer Basic 4876

Basic XE 7308

TBXL 7009

ABC Compiler 3101

TBXL Compiler 1496

XL14 Accelerator (7 MHz) with TBXL Compiler 381

XL14 Accelerator (14 MHz with TBXL Compiler 190

XL14 Accelerator (14 MHz) with Integer Basic 622

 

I also noticed that the tokens are not compatible with the other Atari Basics.  You must LIST and ENTER a program that is SAVED in regular Atari Basic. Sort of like Basic A+, the forerunner of BXL/BXE.

I also noticed that this was written by Steven Lawrow (the Mac/65 author).  Didn't notice that earlier.

 

-Larry



#40 Larry OFFLINE  

Larry

    River Patroller

  • 4,083 posts
  • Location:U.S. -- Midwest

Posted Wed Oct 18, 2017 6:16 AM

Work-arounds?

 

I tried to think of some work-arounds for the 16-bit limitation of Integer Basic, but so far nothing has worked.  I was interested in using IB on one of the Basic programs that calculates checksums for the OS roms. Here are some benchmarks of different Basics and Compilers calculating the checksum for the XLOS:

 

Atari Basic © 213 seconds

Basic XL 127 seconds

ABC compiler 27 seconds (!)

 

Since ABC has work-arounds for floating point using 3-byte integer internal representation, it is quite easy to get around the 65535 limit. (See the ABC manual pages 8-12 if interested.)  Because these checksum programs basically just add integers, ABC can really shine -- nearly 8 times faster than Atari Basic  Basic XL is equally fast with or without the FAST command. That is quite interesting to me since BXL usually is very similar to Atari Basic in benchmarks except when using FAST on programs that benefit from that.

 

Anyone had any thoughts on work-arounds for the Integer Basic limitation?

 

-Larry



#41 dmsc ONLINE  

dmsc

    Moonsweeper

  • 473 posts
  • Location:Viņa del Mar, Chile

Posted Wed Oct 18, 2017 11:05 AM

Hi!,
 

Work-arounds?
 
I tried to think of some work-arounds for the 16-bit limitation of Integer Basic, but so far nothing has worked.  I was interested in using IB on one of the Basic programs that calculates checksums for the OS roms. Here are some benchmarks of different Basics and Compilers calculating the checksum for the XLOS:
 
Atari Basic © 213 seconds
Basic XL 127 seconds
ABC compiler 27 seconds (!)
 
Since ABC has work-arounds for floating point using 3-byte integer internal representation, it is quite easy to get around the 65535 limit. (See the ABC manual pages 8-12 if interested.)  Because these checksum programs basically just add integers, ABC can really shine -- nearly 8 times faster than Atari Basic  Basic XL is equally fast with or without the FAST command. That is quite interesting to me since BXL usually is very similar to Atari Basic in benchmarks except when using FAST on programs that benefit from that.
 
Anyone had any thoughts on work-arounds for the Integer Basic limitation?
 
-Larry


You can use my FastBasic IDE (editor and compiler), download at https://github.com/d...tbasic/releases .
The sieve benchmark completes in 1329 jiffies (NTSC, screen on), so it's faster than compiler TB-XL.

Also, you can mix integer with FP variables, and produce an Atari executable.

You only need the ATR image, the other binaries are for cross-compiling.

Daniel.

#42 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Wed Oct 18, 2017 1:46 PM

@Larry: I have some doubts to compare compiled basic code. If you go this way, you should compile Turbo-BASIC Xl, too and then compare again. As far as I remember, without compiling, Integer Basic from Stephen D. Lawrow is the fastest from the 80's. It was, without compiling, so fast, that is was very close to even compiled basic code! Therefore, I suggest, to compare basic interpreter on their own and those with a compiler as a 2nd kind. Nevertheless, you are welcome to put all results in one table, of course.

 

@dmsc: WOW! Great job! Thank you. :-)))) Do you mind, I publish your work here:

https://atariwiki.or....jsp?page=Basic

too? To my mind, you really deserve it! :-)))

 

@all: I have a dream, that one day, we have a BASIC for Atari 8 bit, which can do everything, is super fast, with compiler, linker and so on, in an 128 KiB cartridge like SpartaDOS?

Have already published this idea here:

http://atariage.com/...ic#entry3668423



#43 dmsc ONLINE  

dmsc

    Moonsweeper

  • 473 posts
  • Location:Viņa del Mar, Chile

Posted Wed Oct 18, 2017 3:09 PM

Hi!
 

@dmsc: WOW! Great job! Thank you. :-)))) Do you mind, I publish your work here:
https://atariwiki.or....jsp?page=Basic
too? To my mind, you really deserve it! :-)))


Not a problem, just link to the github page https://github.com/d...tbasic/releasesand perhaps to the atariage thread.

#44 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Wed Oct 18, 2017 4:50 PM

Hi dmsc,

 

Houston, we have a problem, FastBasic, the name, is alredy used by Tom Hunt (CTH):

https://atariwiki.or...?page=FastBasic

any suggestions?

 

My 1st draft:

https://atariwiki.or...=DMSC-FastBasic


Edited by luckybuck, Wed Oct 18, 2017 5:17 PM.


#45 dmsc ONLINE  

dmsc

    Moonsweeper

  • 473 posts
  • Location:Viņa del Mar, Chile

Posted Wed Oct 18, 2017 6:16 PM

Hi!
 

Hi dmsc,
 
Houston, we have a problem, FastBasic, the name, is alredy used by Tom Hunt (CTH):
https://atariwiki.or...?page=FastBasic
any suggestions?
 
My 1st draft:
https://atariwiki.or...=DMSC-FastBasic


Thanks, looks good.

I know that the name was already taken, but I really like it, so DMSC-FastBasic should be ok. Or perhaps "FastBasic 2017" ;)

#46 Mathy ONLINE  

Mathy

    River Patroller

  • 2,859 posts
  • Location:Heerlen, NL

Posted Wed Oct 18, 2017 6:39 PM

Hello guys

 

Why not DMSC-BASIC?  DMSC-FastBasic is way to long.  That'll get shortened to FastBasic after a while.  And "FastBasic 2017" will confuse people since a) some people will drop "2017" and b) others don't know that there already is a FastBASIC.

 

Sincerely

 

Mathy



#47 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Wed Oct 18, 2017 6:46 PM

Thanks Mathy, fully agree, further, FastBasic 2017 would assume to the user, that Tom Hunt's Basic is further developed. If one day, I find time to write Calculator 2.0, it will still be © by Carol Show. For example TurboBASIC XL and enhanced TBXL...

#48 dmsc ONLINE  

dmsc

    Moonsweeper

  • 473 posts
  • Location:Viņa del Mar, Chile

Posted Wed Oct 18, 2017 8:44 PM

Hi!

Thanks Mathy, fully agree, further, FastBasic 2017 would assume to the user, that Tom Hunt's Basic is further developed. If one day, I find time to write Calculator 2.0, it will still be © by Carol Show. For example TurboBASIC XL and enhanced TBXL...


that happens when using common names :)

Well, if I ever change the name it would be to something that abbreviates to "FB", so perhaps "FBasic", "FlashBasic", "FleetBasic", "ForwardBasic" ...

#49 Larry OFFLINE  

Larry

    River Patroller

  • 4,083 posts
  • Location:U.S. -- Midwest

Posted Thu Oct 19, 2017 6:29 AM

@dmsc-

Yes, I need to try your very nice Fast Basic.  I thought I might have some conversion issues, so I put it off until another day.  But I'm sure that once I get used to any differences, I'll like it very much.

 

@luckybuck-

You're right, but I wanted something that I knew should agree with the embedded stock OS checksum, and TBXL/compiler and Basic XE replace the math pack, right?  That's why I chose BXL, and also since ABC has it own internal  integer-only routines, that seemed like a reasonable comparison.  But today I checked TBXL and it gave a highly respectable value of 67 sec. (with a bad checksum message).  And I also tried the compiler, but it gives compiler errors, so it is omitted.  The only issue that I had with ABC was that I knew that I could not use a constant of 65536 or larger.  But the fix is very simple -- change the constant to a variable, SUM=32768 + 32768.  Then it compiled on the first attempt. 

 

-Larry



#50 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • Topic Starter
  • 957 posts

Posted Thu Oct 19, 2017 9:57 AM

@Larry: TBXL and Basic XE doesn't change the math pack, please see picture below:

XE.jpg

If you have trouble with TBXL, please try the NTSC-Version out of here:

https://atariwiki.or...IC XL-ATRImages

 







Also tagged with one or more of these keywords: OSS, Integer Basic, source code

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users