Anyone modify Basic XE to use more than 128K

[peteym5]

I had been wondering if anyone modified Basic XE to use more than 128K for computers that have larger memory upgrades? Since some people have Atari computers with as much as 1024K, it would be interesting to have Basic XE make use of extra banks of RAM for the programs.

 

 

[+Larry]

It's a very good idea, but there is an issue that (IMO) reduces its usefulness. In BXE extended mode, string/array space is in the main memory and the program is in extended memory. So that means you could have a huge program, but still no more space for large arrays (especially string arrays). Someone probably could hack some type of a memory device to go into extended memory, but that would certainly pose added complications. I've written several programs over the years where I could really have benefited from more string/array space, but never have come close to running out of actual program memory.

 

A possible alternative might be Drac030's Multi Basic. He has mentioned possible future modification to allow use of linear memory (if you are using a 65816 with linear memory and his 65816 OS). Since MBI is very much like TBXL, that would be very powerful. With an accelerator, it would be a killer BASIC.

 

-Larry

[+MrFish]

I was just coming in here to post the same thing. No benefit of having extra code space, it's the data space that's needed. In fact in a lot of instances, you can make better use of the extended RAM by using a RAM-Disk, or have your own MLS to manage storing and retrieving your data from extended RAM.

 

I was considering writing my font converter in BXE at one point and ended up trashing the idea because of the way extended RAM is handled.

Edited November 9, 2015 by MrFish

[Rybags]

A Ramdisk would be almost as fast as having direct string storage, just the way you go about handling the programming would be a bit different.

Most/all of them allow Note/Point don't they?

[+Larry]

A Ramdisk would be almost as fast as having direct string storage, just the way you go about handling the programming would be a bit different.

Most/all of them allow Note/Point don't they?

 

Hi Gary-

So you would write ramdisk file(s) that you could update with new/altered records using the Note/Point? Sounds like that might work pretty well.

-Larry

[JamesD]

I won't go so far as to say there's no use for more program space without more space for data, but what is the point of a massive program that can't access more variable storage?

The Plus/4 actually let you use around 56K for BASIC program code but it's BASIC is slower than the C64's since it has to switch the ROM in and out.
Banking variables in and out is going to be even slower.

The CoCo 3 had a program called BIG BASIC that let you use 512K but you manually selected banks for different groups of variables or code. I guess it worked and it avoids the complexity and slowdown that would be required to automatically switch banks, but it's definitely not transparent to the programmer.

Something else to consider is that on the 6502, you are still stuck with a limited stack size so there is a limited call depth even if you eliminate the code and data limits.
Using the 65816 would solve a lot of problems and you could throw in some optimizations.

[peteym5]

You could also write short ML routines that access values, data, and strings in the extended memory banks. That would be much faster than using DOS and RAMDISK. If I was going to hack the EXTEND feature in Basic XE, maybe just have it go as large as 128K for the program, and maybe use the rest for DATA. Would need to disassemble the Basic XE ROM and find all the writes to PORTB. Is it using a table or just doing bit manipulation for that register.

[+Larry]

IIRC, one of the U.S. mags had an ML program that let you use the extended memory in Atari Basic. It might be a good starting point. I'll search for it. I want to say it was Compute!, but not sure.

 

-Larry

 

Edit: I think this may be the Article that I remembered:

 

http://www.atarimagazines.com/v4n7/memorymanagement.html

 

or more likely this one from Analog #62, July, 1988. PDF is way too long to post, and should be at Atarimania.

[+MrFish]

Here's the routine that I use. It's from Compute magazine. The limit is 64KB extended. Access (Extended RAM)

 

JAC found what he considered a small potential problem in the bank switching code, and provided an amended routine, which you can find further down the thread.

 

I've used the routine as is for years and never had any data corruption or other problems. So use as you choose.

[charliecron]

Would need to disassemble the Basic XE ROM and find all the writes to PORTB. Is it using a table or just doing bit manipulation for that register.

AAH HAA!

 

Your a cartridge hacking copyright violator!

[Rybags]

Basic uses it's own stack, I don't think the 6502 small stack creates problems in that regard.

Yes, the banking action can slow operations down somewhat. But we're talking Basic so it wasn't exactly fast to begin with anyway.

Buffering data would help. If you do an entire 128 byte record operation from main memory to the banked window in one hit the overhead reduces enormously.

[peteym5]

Here's the routine that I use. It's from Compute magazine. The limit is 64KB extended. Access (Extended RAM)

 

JAC found what he considered a small potential problem in the bank switching code, and provided an amended routine, which you can find further down the thread.

 

I've used the routine as is for years and never had any data corruption or other problems. So use as you choose.

I actaully had that routine myself many years ago. It moves to and from extended RAM, and think it could peek and poke as well. I think I did a modified version that could work with 256K, 320K, 576K extended RAMS.

[+MrFish]

I actaully had that routine myself many years ago. It moves to and from extended RAM, and think it could peek and poke as well. I think I did a modified version that could work with 256K, 320K, 576K extended RAMS.

 

Yeah, it's pretty handy. If you ever dig up that routine, I'd be interested in checking it out.

[peteym5]

I lost it, but those things are not too hard to make using assembly. Ones I made copy to and from the bank switch window, but cannot copy from one bank to another, or move to/from the main RAM inside $4000 to $7FFF. Its a simple memory move with a bank setting at the start and end.

 

I originally wanted to do a room by room adventure game many years ago using extended memory. But I managed to set up screens using procedural subroutines and managed to compact the information to draw rooms to about 100 bytes that instruct a ML program how to draw a screen.