flashjazzcat

One question: what is a 'cartridge based XEX'? You have an XEL-CF, so which cartridge are we talking about? If there's one present, disabling BASIC won't help much.

This is true of bootable ATRs, but the loader can disable BASIC independently of the PBI BIOS when launching an XEX (no reboot takes place). Regardless, all we needed to know is that BASIC is off in the loader, which it is. Therefore the loader is turning off BASIC before loading the XEX, so if it crashes or BASIC is not disabled, I have no idea why.

Yes that was clear from your initial post now I read it again. You mention the 'SIDE loader'; are you using a SIDE cartridge or an XEL-CF adapter? I would expect to see the 'XEL Loader' installed on a 1088XEL in the latter case.

Is BASIC disabled in the loader Options? This setting overrides what's in the firmware setup menu.

Given enough ROM and RAM and development time, anything is possible. Prior hardware hit a brick wall because deluxe implementation of basic functionality completely maxed out all resources.

The code which services your interrupt had spontaneously vanished when DOS switched extended banks. If you didn't actually run it, there should be no problem.

The 64K upgrade for the 600XL isn't too involved if you can make a few solder joints with wires. Topic here:

The 600XL has only 16K of system RAM. Hardly any disk-based software will work unless you upgrade it to 64K. I'm not sure about the SDrive menu; perhaps it positions the screen RAM beyond the 16K address space. Note there's no RAM under the BASIC ROM on a 16K 600XL.

Soft 80 column is built into the application. You can flip between 40 and 80 columns on the fly while editing.

TextPro was great and I used it for years (it's a derivative of 'SpeedScript'), but it writes directly to the display RAM so will not work with drivers. Mike Collins got in touch a few years ago talking about how he and Ronnie wanted to add stuff like 80 column support, but the architecture of the display code would have required a tremendous amount of redesign. TLW is basically a superset of TextPro (which was my favourite word processor for years on end), so unless TLW's use of the shadow RAM under the OS is a deal-breaker, it makes sense. It's much faster than TextPro and has the macros, disk management menu, etc.

There was a precursor (XEDIT), but it's 40 column. TLW works as a text editor and doesn't require SpartaDOS X or any external display drivers. The FastBASIC editor works nicely with 80 column drivers.

This is because the CAR environment variable does not describe a file on an on-line volume. Include the following in AUTOEXEC.BAT: SET CAR=E:CAR.SAV The message will go away, and you will be able to use DOS non-destructively (i.e. without losing your work in MAC/65).

This is a side-effect of timing-critical OSS address-bus banking code being patched to work with the SIDE data-bus banking scheme (bank switching inevitably consumes more machine cycles than on a cartridge which uses address-bus banking). Can't reproduce using some typed in assembly instructions, but perhaps @ebiguy can comment?

I can't speak for the author of the post, but I suspect 'compatibility' here may refer to built-in support for device configuration in the U1MB firmware. A forthcoming U1MB update allows setting of the Sophia 2 resolution and other feartures and PokeyMAX facilities from the firmware setup menu, via plug-in modules. These settings are therefore available with a press HELP+RESET, at any time. There are no known hardware incompatibilities between U1MB and Sophia and U1MB and IDE+, so - as said - I assume plugins are what's being referenced here.

Indeed. That's why I suggested >128K as a quick remedy to avoid having to edit CONFIG.SYS.

TBXL uses the 'shadow RAM' under the OS, so SDX MUST be using extended RAM. Without editing CONFIG.SYS, this requires MORE THAN 128K. Try a 320K or 1MB memory expansion and it should automatically work.

That may be so, but does it have a 'splash screen'? If not, then the OP appears to be using the newer firmware.

It does.

No, this isn't necessary and in fact it's inadvisable to boot SDX from the SIDE cart on an U1MB system. Disable SDX on the cart and enable or disable on U1MB as required.

Can you comment further on this?

The dot is a padding character, but is actually the character with code 125. It will never appear as the crooked arrow since it is internally redefined as said padding character.

CTRL+ESC, then the desired CTRL code. It's in the manual. There's also a control key mode which removes the need to escape the control characters at all.

Not really, I'm afraid. The system looks extremely unstable. It's unable to read the SD card and the partition editor is subject to crashes. It might require some deep investigation.

Of course not. It's crashed and everything has gone to Hell. There is no specific size limit for cards, but the thing must be addressable by 28-bits (whatever that limit is; 64GB will certainly work, etc).

If you want to put a >8K binary on CAR:, consider splitting it up into multiple files (say, '*.OVL', which is the convention I use, following SDX's own methods) and using a small stub loader to read them in.