Possible futures for Basic XE/XL

[Alfred]

As suggested I'm creating this topic as base for discussion of what might be done regarding BASIC XE and/or BASIC XL. Action! I will leave out of this for now, because it's a different beast and there is already someone working on it (I think).

 

With the availability of some different 65816 options, as well as the plethora of cartridges and memory upgrades there will have to be some consolidation of expectations. Unless somebody really has too much time on their hands, there isn't going to be a version of each OSS product for every hardware combination out there. So we need to consider what's feasible.

 

Basic XE and Basic XL(+toolkit) are in my estimation essentially the same, with the exception of BXE being able to relocate its program code into the XE memory banks. In a 65816 system, is that relocation ability still useful ? I would have said no, because I wasn't aware that someone could have an 816 and not have any linear ram attached these days, until Kyle22 mentioned it. I'm not knowledgeable enough about the state of Atari hardware addons to know how you would do that, since as best I can think you would either have to have a Dataque T-816 without any of the SRAM cards or one of Mike H's Sweet16 cards. Neither of them were distributed in any quantity, but maybe I'm wrong.

 

So today we have Rapidus and there's Veronica. If there are other 65816 upgrades, well then mention them here and what they have besides the cpu, because those are the only two of which I am aware.

 

We have the source code for BXE and BXL. Things that could be done, in no particular order:

 

- update the code to 65816 opcodes, functionality stays the same

- relocate the 6502 code to run above the 64k line in pseudo-emulation mode (native, but all regs=8 bit)

- expand data/code size to exceed 64k. Probably easier to do with BXE given current Extended mode operation

- add Axlon compatibility and increase # banks able to be used

- make them work on an 800 with that upgrade whose name escapes me atm

 

From my point of view, in kind of order of difficulty, somewhat, would be:

 

- Increase # banks possible. Small change to syntax tables, addition of hardware scan and expanded bank table.

- move existing code above the 64k line. requires a loader to do the move, some interfacing to OS routines below the line

- change 6502 code to 65816. maybe two stages, first doing simple changes like STZ etc. 2nd pass to enable 16bit register usage

- final update to allow expanded memory use above the line where code/data can exceed 64K.

 

Veronica is a special case. I know nothing of how Veronica Basic was done. With it's limited memory, and bank swapping mechanism, I'm not sure what the best way to utilize it would be. At a guess I would say put the cartridge code into Veronica and leave the data in the Atari, but that leaves having to sync swaps for data access, and I have no idea how inefficient that might be.

 

Anyway, that's my thoughts for now.

Edited March 5, 2018 by Alfred

[Alfred]

My mistake, the source code to the Basic XL extensions doesn't seem to be on the source diskettes, so the discussion will perhaps be limited to Basic XE.

[phaeron]

Have you seen MultiBASIC? It's an '816 enhanced BASIC interpreter.

 

Veronica BASIC puts everything into Veronica -- interpreter, program code, and program data. Communication between the Atari and Veronica sides is awkward and slow, so the Atari side is only used for I/O. You have to do things differently than if the main CPU is a 65C816.

 

816 opcodes don't help as much as you might think. BASIC deals with a lot of byte values and REP/SEP sequences to switch between 8-bit and 16-bit eat both cycles and space. Using them can make the interpreter a bit more efficient but it's nothing compared to the gain from running the CPU at 14MHz or 21MHz. I looked at trying to optimize the math pack for 16-bit arithmetic but ran into problems with the standard floating point format having its mantissa bytes ordered backwards from what the 816 wants.

[Alfred]

No, I wasn't aware of that. I had a look at his page and I'm guessing it's based on Atari Basic and it has been updated with some new statements. I wonder if it's tied to his 65816 OS, I'll have to check it out.

 

Agreed about the usefulness of the 816 ops. Really the reason to go 816 is to get access to the extra memory. With hopefully not too many changes it should be possible to make the current code run above the 64k line and split code and data into separate banks. 64k of data is the real advantage, as it makes possible more advanced programs. Maybe a first pass would be to just enable the DBR to get the big data segment although I expect that to cause problems with things like the P/M graphics commands.

[phaeron]

MultiBASIC runs in 816 native mode, so it needs at least an 816-capable OS. Not sure if it will work with the few such OSes other than the author's OS.

 

I'm not sure it would be worth the trouble to change the data bank. A BASIC interpreter needs a lot of table access compared to how often it accesses the program and string/array tables, so for those it may be better just to use long addressing. The 65816 is quite limited with regard to data bank addressing, as opposed to the 8086 which has CS: and ES: overrides. If I tried to convert Altirra BASIC to 24-bit addressing I would have problems with cases where I had used (zp,X) as an alternative to (zp),Y with Y=0 and abs,Y when zp,Y was not available.

 

Compatibility is also something to watch out for. It turns out that merely hoisting the variable and string tables out of their standard locations is enough to break compatibility with a fair number of BASIC programs due to use of strings for USR() routines or P/M graphics. This is the main reason I found for programs being incompatible with Veronica BASIC. Having an extended BASIC is not that useful if you don't have software to run on it, and that is less likely if the software needs to be written as opposed to already existing.

[Alfred]

Well I was thinking more along the lines of putting all the runtime stuff above the line and leave the syntax tables down low. Move the DBR and just use all long absolute to for parsing/tokenizing. Sure there's going to be a performance penalty but I don't know that it will be too bad, because when you're typing in code, syntax speed isn't as big a deal as runtime speed.

 

As for USR, well BXE already has the copy mechanism for Extended mode, which is interesting because it must have a size limit that isn't mentioned in the manual. No 4K USR strings allowed I imagine.

 

Really maybe the biggest job will be getting it out of Mac/65. It uses a lot of locals all over the place using the same labels dozens of times and I'm not sure things like Mads permit that sort of label abuse as it were. It took me a long time to unroll the Action! Source and fix it to use the T816 assembler and produce the same binary image.

Edited March 6, 2018 by Alfred

[flashjazzcat]

MADS handles local labels without issue and regardless of 65C816 modifications, getting the source out of MAC/65 would probably be a good idea given the number of developers using cross assemblers these days. Having to detokenise MAC/65 source files on ATRs is enough to discourage me from even looking at the source code unless I have a specific objective in mind (in which case I would make the effort).

 

As for 65C816: I'm very new to it, but I already experienced what Avery is describing: SEP and REP and long addressing all over the place just to get anything done which traverses the entire address space. I had a situation where a driver needed access to its own bank (which was not known at compile time, so DBR was required), access the target buffer (which could reside in any bank, again not known at compile time), and access to registers and data in bank 0 (known at compile time). Not surprising execution speed wasn't as startling as I had hoped, even at 20MHz.

[Alfred]

As for 65C816: I'm very new to it, but I already experienced what Avery is describing: SEP and REP and long addressing all over the place just to get anything done which traverses the entire address space. I had a situation where a driver needed access to its own bank (which was not known at compile time, so DBR was required), access the target buffer (which could reside in any bank, again not known at compile time), and access to registers and data in bank 0 (known at compile time). Not surprising execution speed wasn't as startling as I had hoped, even at 20MHz.

 

Yes, trying to use wide registers when dealing with existing byte-level operands can easily get out of hand with SEP/REP. Since Kyle22 brought up the scenario of the user with an 816 and no >64k memory, I've been puzzling over what good (if any) would come from using an 816 BXE version, and I'm not coming up with many options. A few MVP/MVN's isn't really going to do anything. COP maybe might make for a nicer way of implementing the extensions into something that could live elsewhere, like in a ram bank rather than under the OS, but it's not really earth-shattering.

[JamesD]

The 816 would speed up clearing the screen, screen scrolls, and other memory moves.
It might speed up searching for variables, and searching for a line number (GOTO, GOSUB), but I'm only familiar with the internals of Microsoft BASICs so I can't be sure.
Other than that the SEP REP penalty for switching number of bits probably minimizes or negates any gains with the accumulator.
It might speed up some indexing since X and Y can be 16 bit while A can stay 8 bit. That saves slower references via the direct page and indexing is pretty much 16 bit anyway.
The larger stack and additional stack instructions might have an impact, but I'm guessing it would be minimal on the interpreter. That would have a bigger impact on stack based compiled languages.

On a Microsoft BASIC the 816 might help a few math library functions that loop a lot such a multiplication and division, but when I used 16 bit support on the 6803 it was a pretty small improvement even without the need for SEP/REP. Most of the places I took advantage of 16 bits required switching between 8 and 16 bits a lot so they wouldn't be of any use on the 816.

With the lower precision math of most 6502 versions, it would have even less impact even without SEP/REP.

There are some potential improvements that aren't speed related. Putting variables or code on their own 64K memory pages might let you have larger programs that deal with more data. It has some serious implications for programs that use PEEK and POKE though. Exactly which page of 64K do you want to PEEK from or POKE to? Code? Data? Hardware? You also have to deal with string constants in the code vs those in the variable RAM. And what about data the Antic needs to access? Backwards compatibility would definitely be an issue. This sounds like more of a language extension for dealing with arrays declared to be on a different memory page.

[flashjazzcat]

Here's a direct link to MultiBASIC, anyway:

 

http://drac030.krap.pl/en-mb-pliki.php

 

It allows use of extended linear RAM but does not currently require any. Although I don't use BASIC, Konrad's manuals always make interesting reading (likewise his 65C816 OS documentation on the same site). If I was intending to write BASIC programs on a 65C816 machine, no doubt I'd be giving this interpreter a try.

[Alfred]

Good stuff here.

 

With regards to backward compatibility, I'm not much concerned. If it works, great and if not, oh well. There are already programs I believe that don't work under BXL or BXE today because they jump into the Basic rom. The point of a new feature/language is to do something new. If you want to run something that only works with Atari Basic, well then you load Atari Basic. Some stuff only works with SpartaDos or only works with DOS 2.0 or MyDos. Nobody said oh well, SpartaDos is a dud because Disk Wizard doesn't work under it. Somebody writes a Disk Wizard that does work instead. I don't see too many people with 65816 upgrades saying, oh well both Drac's OS and Dataque's OS removed the cassette device, so they're useless, guess I'm stuck with 6502 only code.

Let's face it, there's essentially no market for this stuff. There's a few dozen/hundred users left, some/most (I have no idea) are content to play Star Raiders and could care less that there's an SDX 4.48 that can use an SD card as a disk device. I'm not writing a 65816 assembler or doing a 65816 DOS because I think there's a boatload of people dying to get their hands on it to play the Eidolon at 20MHz. I'm doing it because it's something I want, and if it happens to be useful to a few other people, that's nice, but it's not why I do it, and I doubt it's why others do what they do. It's a hobby, and it's fun compared to writing godda---d SRB code to handle stupid end-of-extent appendage processing during a channel program interrupt for z/OS. So if at some point I release a BXE for the 816 and Forem MPP doesn't work, I'm really not going to be too broken up about it. Ok, rant off.

 

So I read the first part of the MB manual and I see he's based it on TBXL. So right off there's some big differences, and I'm not even going to try to close the gap. I see he's putting some BXE stuff in and that's cool, but I have no intention of adding TBXL features to BXE. You want those, you go right ahead and do it, and have fun with it.

 

Pokes & peeks etc, I think would be best just special cased to say they only work in bank zero. All the hardware resides there, and off the top of my head I can't think why you would need to Poke >64K. If it was a string you could just direct assign the value to whichever byte you wanted. USR will be an odd one out. Might need to add a flag to that to say whether the target is above the line, not sure. BXE manual says ADR("string") will copy the string to main ram so you can only USR(ADR( within the same statement. Looking at the source I can't see that that is true. It just swaps in the bank with the string, looks up the address, pushes the params and JSR's in. Flag might not be needed, I'm having a hard time thinking at the keyboard of a case where you wouldn't know the 24bit address of the USR target before you passed control. If it's a literal string, you're already there processing the stmt and if it's an svar you can just check the value in the vvt. Maybe someone smarter than me about Basic can think about an edge case for that one.

 

Sure, faster screen clears etc. and it ought to be easy to do, since it's just a library kind of thing rather than a language change. For now I'm just collecting ideas and notes for the future, while I work on this other stuff.

Edited March 6, 2018 by Alfred

[phaeron]

MADS isn't actually very good for 65816, as at best it's a 6502 assembler that grudgingly does 65816 assembly. The two glaring omissions are: the inability to set the current bank, and the inability to set the default M/X mode without actually emitting code. The first one is a PITA when you are trying to assemble code above bank 0 as you have to manually add in the bank for any long references. The second is a dealbreaker if you like to use natural syntax. Even the REP/SEP tracking (opt t+) is broken, as it requires emitting REP/SEP to switch modes and if you do PLP or even REP #$21 it breaks. There's no support for LONGA/LONGI statements to change the assembly mode without emitting code. For Veronica BASIC and the placeholder Rapidus firmware I gave up and just assembled in opt c+t- mode with every instruction manually marked .b/.w/.l.

 

You definitely can make a BASIC interpreter faster with 65816 instructions, it's just not earth shattering when you have to work within the constraints of an existing BASIC interpreter that has to follow Atari BASIC conventions. 16-bit A is handy, except you have to keep switching back to 8-bit mode to read/write bytes. 16-bit X is even handier, but you can't do arithmetic on X/Y and the byte load/store problem is annoying there, too. Also costs you a cycle on every indexing operation. Stack operations are accessible from A only, which is solved by using D as a frame pointer but the setup is expensive. MVN/MVP are nice but the setup is too expensive for short copies. Oh, and you can't just run an existing interpreter in m8x8 native mode, it'll crash right after any TXS instruction. REP/SEP are slow, XBA is slow, COP is worthless compared to JSR/JSL.

 

Anyway, not to dissuade you from doing a 65816 enhanced interpreter, but hopefully knowing some headaches up front will save you some time. The biggest advantage would be being able to place the entire interpreter in bank 1+ and basically lift all code size limitations. A bit of long addressing is still easier than bank switching. And there's a lot you can do in 64K of code. I probably could have made Veronica BASIC a lot faster with the code space available but decided not to bother since the interpreter was already running an order of magnitude faster on Veronica than on the 6502.

 

Basic XE 5.1 does copy strings down from the statement table in extended memory into base memory. You have to do SET 15,1 to enable it, but it will happily do USR(ADR("..")) afterward:

    27724:225: 77 | A=0C X=8A Y=0C ( V   C) | A1ED: 71 8A             ADC ($8A),Y  ;$4021
    27724:225: 82 | A=0F X=8A Y=0C (      ) | A1EF: 85 FD             STA $FD
    27724:225: 85 | A=0F X=8A Y=0C (      ) | A1F1: AE C4 C0          LDX $C0C4
    27724:225: 89 | A=0F X=10 Y=0C (      ) | A1F4: C8                INY
    27724:225: 91 | A=0F X=10 Y=0D (      ) | A1F5: C4 FD             CPY $FD
    27724:225: 94 | A=0F X=10 Y=0D (N     ) | A1F7: B0 0B             BCS $A204
    27724:225: 96 | A=0F X=10 Y=0D (N     ) | A1F9: B1 8A             LDA ($8A),Y  ;$4022
    27724:225:101 | A=68 X=10 Y=0D (      ) | A1FB: 9D 80 05          STA $0580,X  ;$0590
    27724:225:106 | A=68 X=10 Y=0D (      ) | A1FE: E8                INX
    27724:225:108 | A=68 X=11 Y=0D (      ) | A1FF: 10 F3             BPL $A1F4
    27724:225:112 | A=68 X=11 Y=0D (      ) | A1F4: C8                INY
    27724:226:  0 | A=68 X=11 Y=0E (      ) | A1F5: C4 FD             CPY $FD
    27724:226:  3 | A=68 X=11 Y=0E (N     ) | A1F7: B0 0B             BCS $A204
    27724:226:  5 | A=68 X=11 Y=0E (N     ) | A1F9: B1 8A             LDA ($8A),Y  ;$4023
    27724:226: 10 | A=60 X=11 Y=0E (      ) | A1FB: 9D 80 05          STA $0580,X  ;$0591
    27724:226: 15 | A=60 X=11 Y=0E (      ) | A1FE: E8                INX
    27724:226: 17 | A=60 X=12 Y=0E (      ) | A1FF: 10 F3             BPL $A1F4
    27724:226: 21 | A=60 X=12 Y=0E (      ) | A1F4: C8                INY
    27724:226: 23 | A=60 X=12 Y=0F (      ) | A1F5: C4 FD             CPY $FD
...
      27724:240: 28 | A=00 X=01 Y=FF (      ) | AA30: 48                PHA
      27724:240: 32 | A=00 X=01 Y=FF (      ) | AA31: 30 03             BMI $AA36
      27724:240: 35 | A=00 X=01 Y=FF (      ) | AA33: 8C 01 D3          STY PORTB
      27724:240: 40 | A=00 X=01 Y=FF (      ) | AA36: 6C D4 00          JMP (FR0)
      27724:240: 47 | A=00 X=01 Y=FF (      ) | 0590: 68                PLA
      27724:240: 52 | A=00 X=01 Y=FF (    Z ) | 0591: 60                RTS

The max is a bit under 255 bytes since literal strings have to fit within a line.

 

[Alfred]

Thanks for that. USR must be more involved than I thought, because the XPUSR routine does no such thing. I guess I'd have to look at the parser to see how it handles that. I'm guessing it must set a few different tokens or something to indicate that extra processing needs to happen. The code comments say the string must be 128 bytes or less. Good to know.

[phaeron]

It's not in USR(), it happens in the processing of the string literal token ($0F). Instead of just pushing the address of the literal string onto the runtime stack, in EXTEND mode it copies the string to a local stack at $0590 and points the string entry there instead. Multiple strings in the same expression can be piled into this stack, but the stack is reset between expressions.

[flashjazzcat]

For Veronica BASIC and the placeholder Rapidus firmware I gave up and just assembled in opt c+t- mode with every instruction manually marked .b/.w/.l.

I eventually leaned heavily on .w and .l as well when writing the driver. Doesn't look so pretty.

[Alfred]

Apart from minor things like inserting MVP, there just isn't going to be enough of a benefit from 65816 instructions to justify the effort to rewrite an existing program. The only real reason to do so would be to gain access to the larger address space. To really make use of the 816 you need new code that doesn't use so many byte operands, or at least does so in a manner consistent with limited use of SEP/REP sequences.

 

That's why I think the best, and maybe easiest thing to do for BXE and even Action! is to unroll the code and move it above the line to get a 64k data space. That would really open up the possibilities for new programs, without making any other changes. For example you could write a DOS in Action! or even in say PL65 if you had 64k available for both the data and code portions of the program. Toss in 20MHz and that opens even more doors.

[luckybuck]

You guys rock, really! I see the first step of fruits out of the source codes. :-))) That is exactly, where I want to go. :-)))

 

Thank you so much! :-)

[Maury Markowitz]

As suggested I'm creating this topic as base for discussion of what might be done regarding BASIC XE and/or BASIC XL. Action! I will leave out of this for now, because it's a different beast and there is already someone working on it (I think).

Any pointers to this project?

 

I have some suggestions for Action! that i would love to play with if someone is working on this.

[Alfred]

Any pointers to this project?

 

I have some suggestions for Action! that i would love to play with if someone is working on this.

 

JAC! is the person you should be talking to about improvements to Action!.

[Alfred]

Kyle22's question about the 816 made me think of something. Tinkering with BXE it occurred to me that it could probably be made to run on an 800 with Axlon memory. The question is, since the Incgonito can run as an XL/XE is there any reason to have OSS binaries that run on a native 800 only if it has Axlon ram ?

Edited August 24, 2018 by Alfred

[_The Doctor__]

Yes, because how many 800's are decked out in that fashion... Axlon was the way to go with 800's for the longest time

[Kyle22]

It would be great to support both PortB or Axlon type RAM.

[Alfred]

Ok, so it might be useful to have OSS carts that can work on Axlon equipped 800 machines. I think I've come to the conclusion that there's no reason to program any code for the 65816 that could work on the 800, because it seems like, except for Kyle22, there isn't anybody who has either a 65816 or even a 65802 in their 800. There's no (as far as I can tell) commercial upgrade, and even though the 802 (I think) is a pin compatible chip, from another source it seems like you can't even buy them now, so there won't be anyone buying a 65802 or even 65C02 to stick in their 800.

 

It seems kind of sad to me, because I think my 1MB 800 ought to be good for something besides a big ramdisk. I guess it's best to just use it as big printer buffer or something with that project from Analog called Zucchini. So I"m thinking maybe instead of making an 800 version for say Basic XL, might be easier just make it work with the Incognito and run the 800 in XL mode. I expect at this late date there's probably more Incognito's in service than 288K or 1024K Axlon-type expansions.

 

Other thoughts on why new code that supports 800's with expansions should be created, rather than just sticking with the XL/XE series, anyone else has ? Am I missing some use that the 800 might have ?

Edited October 9, 2018 by Alfred

[Alfred]

I don't recall there being any response on the other threads, so I'll ask again here. Is there anybody who has a 65816 in an 800 ? Is it even possible. Kyle22 say he has a 65802 but he's the only one I've seen on here to make that claim. So I'm thinking there's no point in producing an 816 version of BASIC XE that will run on an 800, because that configuration just doesn't exist. So the options seem to be:

 

- BXE 6502 mode that works with Axlon or PortB memory expansions, and

- BXE 65816 code that works on either Rapidus, Antonia, or original T816's like mine with a static ram card

 

Now I only have 256K on my T816 and I don't think Chuck sold very many of his ram expansion cards. I have no idea how many of those little Sweet16 things Fte sold, but they didn't have any ram, so those would have to use banked ram for BXE. I suppose it would be possible to produce a 65816 version that simply treated the 24 bit memory as if it were XE banks, just 64K each rather than 16K, but that seems counter-productive.

 

First step will be to get the BXE code into another assembler, MAC/65 simply has no room to deal with it any longer. Six Forks is probably the only Atari assembler that can handle the volume of source code. Or else go cross-assembler. I'll have to see if BXE has some of the same code that Action! does that make using Six Forks troublesome. And I want that 65816 DOS, of which I have a good chunk already done from twenty-five years ago.

 

Edit: The code doesn't have any quirks in it, so I've started converting it to Six Forks.

Edited January 20, 2019 by Alfred

[luckybuck]

Hi Alfred!

 

Great you are back and still with us! :-)

 

Well, there is a guy in Poland, drac030, at least one(!), which uses the 65816 extensively:

http://drac030.krap.pl/en-main.php

 

Then, JAC! has made WUDSN:

http://www.wudsn.com/index.php/ide

highly(!) recommended...

So you can assemble even large projects in seconds. :-)

 

To my mind, yes, 65816 is rare, but only users like you are able to do such a job! Where do we have that again?

 

Pressing you both thumbs for going further.

 

P. S. ACTION! and BXE are developed from 2 different authors, far away from each other, but distributed by OSS...