Atari basic...no 'delete line' keyword?

[Rybags]

Supposedly the BBC interleaves CPU and graphics accesses, but it means the Ram needs sufficient speed to be running at 4 MHz effective.

On the other hand, the little Electron suffered in that they used a single 64k * 4 bit Ram giving 32K and used logic to do all Ram accesses over 2 cycles which somewhat crippled the machine.

[danwinslow]

Just as explanation, I am using Atari Basic as kind of a lowest common denominator on purpose. If I can get the I: handler to work smoothly with that, I figure that it ought to survive anything else.

[Rybags]

Atari Basic is fairly "unobtrusive" for the variables and work areas disregarding the program in memory itself. Memory usage is pretty well documented.

Most of the upper half of z-page including right near the top which is for the FP.

 

Non z-page is the syntax stack $480-$57F and the line buffer from $580-$5FF which is also used by FP.

 

One important note is that it's entirely possible for the line buffer to overflow into page 6 (up to $67F ?) - example there being lines entered using abbreviated forms which when LISTed to a disk file then exceed 128 characters.

 

Program in memory generally starts at MEMLO which defaults to $700 but will usually shift well upwards when a Dos is present.

Unlike many other Basics, no allocation takes place from the top of Ram downwards, mainly because the screen requirements are highly variable so it's just easier to keep strings/arrays/runtime stack contiguous with the program.

[danwinslow]

Good info. I've got no page 6 use. The handler installs itself at memlo and adjusts upward, with a DOSINI hook to handle reset. I've pared zpage usage down to 13 bytes, and it is fully saved/restored going from.to user calls. The VBI's are a little more problematic; I don't want to force a zpage copy/restore if I don't have to, so I'm hoping the zpage usage there is not detrimental...I can use a 'lazy' only as needed save/restore approach there if i have to, since there are so many different paths through the vbi and not all of them even need zpage ( for instance, if there's no packet available that needs processing ).

[Synthpopalooza]

My favorite thing about Atari BASIC, is that there is a function by which you can use string variables as a sort of block PEEK and POKE. This is in no small part because, unlike other BASICs which limit strings to 255 bytes, Atari BASIC allows for 32768 characters (or as much as your RAM will allow).

 

What you do is, you dim a variable, say S$(960) ... then mess with the variable name table so it points to screen memory. Then any operations done on S$ cause changes to the screen. In effect, you have a softsprite system, without using a byte of ML.

 

The string can be made to point to the font data, the PM data, or could itself contain ML code. I also love the ADR(S$) function which can be used as an address to call machine code stored in S$.

Edited February 17, 2015 by Synthpopalooza

[+therealbountybob]

How about:

#1 Load your BASIC program into Turbo basic then you have a del command.

OR

#2 Use the Atari User Toolkit from the Page 6 PD library

>>>

Lost for a few years, this fine set of utilities should be in every programmers disk box. Boot up the disk and you have a range of commands to use from Basic that will help with many programming tasks. There are ten commands of which the most useful are DIR which displays a disk directory without going to DOS; DEL will remove a single line or block of lines from a Basic program; REN instantly renumbers a program to any starting line and increment of your choice, you won't believe how quick it is!; CHANGE alters the name of any variable so if you have a program which you are trying to unpick you can identify a variable and give it a more meaningful name throughout the program; STRIP takes out REMs and reduces the size of your programs; LISTING prints out programs on an Epson compatible with all special characters shown; VAL coverts between Hex, Decimal and Binary; LVAR gives you a complete listing of all variables used in a program and where they occur. Overall an incredibly powerful set of programming utilities that every programmer will find a use for. Even if you only use one or two commands you will find your programming takes on a new ease and you won't have to sort through your library trying to find individual routines. Great stuff!

<<<

[Rybags]

Don't even Dim your strings that big... the memory is lost. Since you're relocating them anyway, change the length while you're at it. Making them as long as you want won't affect how much free Ram is left over.

[kenjennings]

Yes, what Rybags said. When BASIC executes the Dim S$(960) it allocates 960 bytes of memory to the string. Then when you change the string's starting address by changing the variable value table entry you lose/waste that space allocated by BASIC.

 

Instead, just use Dim S$(1), then change the STARP offset and size in the variable value table entry.

[ac.tomo]

One thing I have always loved about Atari BASIC is that you don't have to use EDIT to change a line. The full screen editor made up for a lot of other shortcomings.

 

True. This was always a bonus with the Atari, apparently Atari BASIC was 1 of the harder BASIC languages to understand back in the day.

[wesmond]

Bit of a bump, but I was searching for similar things today about deleting lines from within Basic, trying to debug some M/C in a magazine listing that the printing was nearly impossible to read. So disassembling it... I found myself in Mapping The Atari, addresses 136 and 137.

That pointed me to Antic August 1982... which includes a useful MC routine to delete lines with a call like z=usr(1536, first_line,last_line), which was what the magazine copied (uncredited... bit naughty!) - so I found the priting error.

 

Again, it's a "programmatic" method, although with a different approach to the POKE 842 trick. (The Antic issue is scanned on AtariMania)

 

I actually love the POKE 842 thing, for adding data. These days, I mostly program in Java, which can generate a new file of source code, compile dynamically load it and call that compiled version. The Atari, POKE 842 could (without compiling obviously) do similar self-modifying code, which as a programming method, I think is really cool for the time!

[+slx]

BBC BASIC sounds pretty cool for a retro BASIC. I still think Action! is da bomb though, as it's output is pretty reasonably tight/efficient 6502 machine code, and it is a structured high level language. Admittedly, it can be a bit obtuse using reals/floats in Action! with the toolkit. But it is available, and a lot of programming for the 8 bits never requires reals anyway.

 

 

BBC BASIC on the Atari and Action! on the Beeb would be quite a thing....

[bugbiter]

One thing I have always loved about Atari BASIC is that you don't have to use EDIT to change a line. The full screen editor made up for a lot of other shortcomings.

 

I realized the real value of the Atari OS 'Full screen editor' when I meddled with an apple ii for the first time. Even the c64 screen editor is more cumbersome than Atari's.

Were they the first to have it so convenient and straightforward?

[+Larry]

When I got an Apple II+, I could not believe how cumbersome the screen editor was. Even with the Beagle Bros replacement editor, it was not nearly so nice as the Atari. I always considered the C64 to be in the middle, but closer to being "user friendly" than the Apple by quite a bit. Never used a TRS model, so maybe someone else can comment. The A8 full-screen editor was definitely the best, I think.

 

-Larry