David_P

Atari's 810s and 1050s have a 6507 (pared down 6502.

Sophia is a year or two out due to limited supplies of the necessary chip, unfortunately.

So, is next up shrinking BCalc or SpeedCalc to a 8K ROM as well, to have a system with selectable built-in word processor or spreadsheet?

Because this will not be a cart - it will be a multi-ROM that permits the user to choose Atari BASIC, SpeedScript, or two other 8K ROMs. But really, if someone wants to ROM-ify TLW, they should reach out to ask @flashjazzcat

Can the self-modifying elements (for memory copying) be re-written to use ZP locations / ZP indexing instead? It would reduce the RAM footprint, and perhaps simplify the conversion since those routines could then remain in ROM. As well, are the $1F00 elements still necessary once converted to a cart? Stealing DOSVEC for init when you've got the cart init vector; checking memory footprint to see if the program is already loaded... are those needed once the program is moved to ROM?

I like the apology in the source code, where the author acknowledges that he probably should have used a label instead of an absolute address - where the program toggles one bit in the char set to make non-printing spaces visible / invisible. (Search for ONOFF)

Source code is available at https://www.atariarchives.org/speedscript/. As I recall, it uses a custom charset, so there are memory usage considerations; it may take a bit more effort than just recompiling, setting INIT and RUN addresses and calculating the checksum. Just did about a 30 second scan of the source code. As written, it assumes that the available memory is above the program; converting it to run from the Left Cart memory area will require some degree of review. There is a custom character set, and a boot loader stub. The boot loader is likely not needed if it's converted into a ROM image. It is probably in the art of the possible to convert it to a ROM image without too much effort (famous last words).

It's a link to Twitter. What browser are you running?

FujiNet spotted in the wild:

If you change the FP for a XL/XE OS, you also need to either recalculate the ROM checksum or remove the routine that checks the checksum. Hacking the OS ROM lets you replace the default character set, speed up key delay, reverse OPTION for BASIC on boot, add additional functions... lots of fun (and lots of ways to make things crash in rather spectacular ways).

For the 600xl / 800xl, a 27128 can replace the OS ROM. The FPP is in the XL/XE OS, same memory locations as the 400/800.

Upgraded computers may not run properly, though.

Bob Puff's UNARC: https://www.mathyvannisselroy.nl/special stuff.htm If you have hardware to run SDX, there's a decent ARC in there too.

I have one of the 2013 edition - highly recommended.

I admire your discipline. If I were testing and booted MULE, I wouldn't be able to resume work until I was First Founder (as a human).

Not saying I have too many Atari 800xls. But...

You may also want to look at the SpartaDOS X ongoing development work; they have a very detailed programming guide. http://sdx.atari8.info/index.php http://sdx.atari8.info/sdx_files/4.49/SDX449_Programming_Guide_EN.pdf

Ah! I was looking only at CIO; lots more under the hood with SIO calls. So if I understand correctly, each CreatorID can have up to 256 apps, each with 256 Keys. Thank you!

Is there possibility to add local storage on the Fujinet itself, at 127.0.0.1? Context: Applications can be loaded from literally anywhere in the world, but there may be configuration information that would be useful to save locally (and we definitely don't want to accidentally hammer the original version halfway around the world, where someone accidentally enabled WRITE permissions on their TNFS server). If a program was able to save its config information to, say, 127.0.0.1/CONFIG/APPNAME/CONFIG.SYS or something similar, there's no need to worry about DOSes and their peculiarities for reading and writing that info. As a secondary benefit, this might simplify porting programs between different systems, as there would be no need to adapt the config routines between platforms. Just a random thought for a Wednesday night...

There are the original MIOs sold by ICD and those produced by @MetalGuy. At the time of the MIO release, the only other PBI devices out were RAM expansions for the 600XL. Even now, there are not many other PBI devices available: there's the Black Box; Supra HD; BTL HD; various versions of the IDE Plus; the Yorkie 256K expansion; a 320K RAM expansion... As they were all pretty much designed as stand-alone devices, in the absence of the 1090 or any other official Atari devices, each pretty much took control of the bus for its own purposes, regardless of the Atari standards.

Given that most PBI devices hog the bus, that's not a surprise or disappointment.

How many great innovations only exist because someone wanted to show up their boss?

I have in my basement a pretty good (though unused for 15+ years) Tandy green composite monitor. When my XE light gun died, I peeled off the label and stuck it on the monitor, to give me an Atari XE System monitor

Is there a pass through for other PBI devices (I have two different IDE Plus adapters and a MIO in my collection)?

MIO RAM is accessed 256 bytes at a time through $D6XX, set through $D1E0 (A15-A8) and $D1E2 (A19-A16). See http://websites.umich.edu/~archive/atari/8bit/Info/Hardware/mioman.txt chapter 5.