Spartados X and Spreadsheets

[+DrVenkman]

4 minutes ago, Lord Thag said:

Still... I miss Syncalc. It's a much better program.

Absolutely no doubt.

 

Realistically thought, the ATR version(s) from @DjayBee’s cracks thread (search the forum) and the ATX versions from the 8-bit Software Preservation Initiative do seem to work. I loaded up ATX versions on my SDrive-MAX and the ATR versions via the Loader in my Incognito, with a data disk ATR mounted as D2: and it didn’t lock up when booted and run - I could access the menus and so on.  So too does Visicalc. I actually tried that this morning during a break from work - took a couple minutes to grab a manual from Atarimania to see how to format a blank working disk ATR on my CF Card in the Incognito and use it to save files, then quit the program, booted it again and loaded up test file. So it works.

 

So at least there’s a way to use these programs, just not from an SDX command line. 

[Lord Thag]

1 minute ago, DrVenkman said:

Absolutely no doubt.

 

Realistically thought, the ATR version(s) from @DjayBee’s cracks thread (search the forum) and the ATX versions from the 8-bit Software Preservation Initiative do seem to work. I loaded up ATX versions on my SDrive-MAX and the ATR versions via the Loader in my Incognito, with a data disk ATR mounted as D2: and it didn’t lock up when booted and run - I could access the menus and so on.  So too does Visicalc. I actually tried that this morning during a break from work - took a couple minutes to grab a manual from Atarimania to see how to format a blank working disk ATR on my CF Card in the Incognito and use it to save files, then quit the program, booted it again and loaded up test file. So it works.

 

So at least there’s a way to use these programs, just not from an SDX command line. 

Oh, yeah, I've never doubted that. I've used them before from .atr files as well, and they do work fine... just not in Spartados X, which was the goal of this thread. Having to constantly juggle booting to Syncalc, then jumping back to Sparta to write, program etc is not ideal (obviously).

I was hoping that there were some tricks I had missed to get them to cooperate, but sadly, it seems like this won't be the case without a patch... which is sadly beyond my ability atm.

Still, SpeedCalc was a find, and it does seem to work, so that's something!

[Alfred]

Yes, the .atx SynCalc (1985) from the Atari Wiki seems to work. None of the file versions appear to work. I looked at one and the init segment has a bunch of junk copying from $2000 to $20,X and vice versa. Didn't look like it actually did any i/o but I didn't trace into it very far either, so I don't know if it's just some code to bypass the original copy protection or what. I haven't found a VisCalc file version that works either. It would be easiest to start with a file version of whatever programs are available, since it's easier to disassemble that than a disk. Or maybe it would be easier to just write something from scratch, I mean it's a glorified calculator. I guess it would really depend on the macro language (whatever you call it) that these things have, how powerful it is, as to how hard it would be to clone say SynCalc. Too bad the VisiCalc source isn't available as a text file or something, there doesn't seem to be a tool to extract it from the Apple Dos disk format.

 

So a working binary file version of either SynCalc or Visicalc would be a good place to start, if there is such a thing.

 

Edit: SynCalc checks $FC82 (I think) for $A2. Not obvious why, it just changes some screen colours if it finds it. My stock XL OS Rom fails the test, so I'm not sure what it's looking for, Omnimon or something ?

Edited May 20, 2020 by Alfred

[Lord Thag]

2 hours ago, Alfred said:

Yes, the .atx SynCalc (1985) from the Atari Wiki seems to work. None of the file versions appear to work. I looked at one and the init segment has a bunch of junk copying from $2000 to $20,X and vice versa. Didn't look like it actually did any i/o but I didn't trace into it very far either, so I don't know if it's just some code to bypass the original copy protection or what. I haven't found a VisCalc file version that works either. It would be easiest to start with a file version of whatever programs are available, since it's easier to disassemble that than a disk. Or maybe it would be easier to just write something from scratch, I mean it's a glorified calculator. I guess it would really depend on the macro language (whatever you call it) that these things have, how powerful it is, as to how hard it would be to clone say SynCalc. Too bad the VisiCalc source isn't available as a text file or something, there doesn't seem to be a tool to extract it from the Apple Dos disk format.

 

So a working binary file version of either SynCalc or Visicalc would be a good place to start, if there is such a thing.

 

Edit: SynCalc checks $FC82 (I think) for $A2. Not obvious why, it just changes some screen colours if it finds it. My stock XL OS Rom fails the test, so I'm not sure what it's looking for, Omnimon or something ?

There is also this thread which has a bunch of file/xex versions of various sheets I tried for anyone interested.

Yeah, it's a real shame that the source to Syncalc was lost, as the dev donated it to the public domain. He had no idea there was still interest, and sadly, disposed of the disks.

However, I've had some luck with the Apple II Visicalc sources. I found a way to extract and convert the files to PC text format. Seems to be a straight disassembly, without a lot of comments. I'm attaching the code below in case someone wants to look at it.

Edit: I should add there are also some 'DVU' files, which apparently are an Apple II 'development Utility File'. If anyone wants those, I'll post them as well. I believe they are application specific.

VISICALC_DISASSEMBLY.zip

Edited May 20, 2020 by Lord Thag
Updated info

[+DjayBee]

4 hours ago, Alfred said:

Yes, the .atx SynCalc (1985) from the Atari Wiki seems to work.

Here are working ATRs of two releases of the 1985 version: SynCalc (1985)(Synapse Software)(US)(Side A)[cr CSS].atr SynCalc (1985)(Synapse Software)(US)[a][!][cr CSS].atr

I don't know the difference between them. Both are taken from original disks by a8preservation.com

 

4 hours ago, Alfred said:

None of the file versions appear to work. I looked at one and the init segment has a bunch of junk copying from $2000 to $20,X and vice versa.

As I wrote above: SynCalc's loader loads a big data block in one rush and finally jumps somewhere into it. This block includes the patched DOS 2.0 I was referring to.

Therefore it makes a lot of sense that the (non-working) file version must move data to various places in RAM.

 

The only copy protection "in code" is a check for a weak sector which is defeated with a one byte change.

The bigger deal is that the disk has many tracks with more than 18 sectors of which most are used. The crack therefore needs an ED disk to contain all these sectors. This is only implicitly checked by loading lots of duplicate sectors which must contain the correct data.

The sectors are linked together in a way distantly related to DOS2's sector linking.

Edited May 20, 2020 by DjayBee

[drac030]

On 5/19/2020 at 6:12 AM, Lord Thag said:

Syncalc seems the best candidate to port. Not only is it a great program, it runs fine under sparta until you do anything with file IO, which according to Jon/flashcatjazz, it leaves a DLI running during file IO which Sparta overwrites when using BANKED RAM

So what about trying to run it in USE OSRAM mode (instead of USE BANKED)? Does it help?

[Alfred]

Well I spent a chunk of the night reading the SynCalc manual since the dog wouldn't let me go to sleep. It seems like it might be easier to just redo SynCalc from scratch than spend a whole lot of time puzzling out a disassembly of something.

[+David_P]

ANALOG 63 has the source code for B-Calc.  Move it to MEMTOP, use $4000-7FFF for data, permit paging, store in 16K sheets within a larger "book", and you can have a 64K spreadsheet (with 2 byte cell references) where a 48K/64K machine can access one sheet at a time, but enhanced memory machines can have the whole thing resident in memory.  Plus there's space in RAM to grow the program to add more functions.

[Alfred]

Issue 63 eh ? I'll have a look.

[Lord Thag]

9 hours ago, drac030 said:

So what about trying to run it in USE OSRAM mode (instead of USE BANKED)? Does it help?

I tried that, my copy still did not work. I'm going to fool around with it more this evening and see though.

 

3 hours ago, David_P said:

ANALOG 63 has the source code for B-Calc.  Move it to MEMTOP, use $4000-7FFF for data, permit paging, store in 16K sheets within a larger "book", and you can have a 64K spreadsheet (with 2 byte cell references) where a 48K/64K machine can access one sheet at a time, but enhanced memory machines can have the whole thing resident in memory.  Plus there's space in RAM to grow the program to add more functions.

Very interesting! That sounds like it's very doable. I'd totally forgotten this was even in Analog, but now that you mention it, I do have a vague recollection. With the source code, this should be the easiest thing to port by FAR. Nice!

[Lord Thag]

Here's the BASIC/ML source code for B-Calc, courtesy of Atarimagazines.com. I've exported it into a text file for anyone interested in tweaking it:

 

B-Calc ML Source Code.txt

[+CharlieChaplin]

21 hours ago, Lord Thag said:

Yes, see this thread. You have to use the .xex version. It'll run just fine, but any disk io crashes the system.
 

I mentioned this in my second post. Like Syncalc, it does indeed run fine, but also like Syncalc, saving/loading does not work. In this case, it throws up an error 130 (non-existent device). Otherwise it does work. This and Syncalc seem to be the only versions that partially run under Sparta 4.x.
 

Yep. SDX doesn't recognize the disk format to even read it. Anyone have an .xex of this one to test?

 

It's a K - Bootdisk, which means an XEX put onto an ATR as small as possible. K indicates Ken Siders, one may use UnmakeATR or ATRUtil by Ken Siders to extract the XEX again. Afaik, sourcecode for Bcalc is available one one of the Analog diskettes (most of the time sourcecode for BBK programs was available)...

 

EDIT: Found the Mac65 sourcecode for B-Calc on Analog diskette 88-08a...

 

Bcalc.xex

ANA8808A.zip

[drac030]

On 5/20/2020 at 8:32 PM, Lord Thag said:

I tried that, my copy still did not work.

I tried and it works in the OSRAM mode, but the copy I have, while executing the SAVE function, ignores the filename I have typed (it just saves the file as ".SC"). I have not investigated it further, I guess it may possibly be just a bad crack. Additionally the executable is packed, so it is not easily fixable.

[Lord Thag]

6 hours ago, drac030 said:

I tried and it works in the OSRAM mode, but the copy I have, while executing the SAVE function, ignores the filename I have typed (it just saves the file as ".SC"). I have not investigated it further, I guess it may possibly be just a bad crack. Additionally the executable is packed, so it is not easily fixable.

Interesting. I'll try some other versions. The one I used did not work when switching to OSRAM.

[drac030]

I think the version I am speaking about is this one

Here is the config.sys I used:

 

USE OSRAM
DEVICE SPARTA OSRAM
DEVICE SIO
DEVICE IDEPTIME
SET PROMPT=$L$P>
SET DAYTIME=2
SET PAGER=LESS;/C;

The IDEPTIME is IDE+ clock driver, you may want to replace this with the driver for the clock you are using. Also, the SynCalc binary is to be started with X.

 

[Alfred]

Well I haven't found any file version of SynCalc that works. So I'm going to assume there isn't one, and that the best Syncalc version we have to go on is the 1985 atr version, because it's supposed to be bug-free.

 

I looked briefly at VisiCalc, the file version I have, and it doesn't work either. It includes a DOS 2.0 as well, but where it seems to fall down is after it issues a call to see if there's an R: device. I don't have an 850 manual at hand so I don't know what command $21 does, but based on the code in VisiCalc I'm assuming it's strobing the 850 to make it download its handler. I don't get why it's probing for an R: device. Anyway it looks like it falls apart after that call.

 

The 1985 Syncalc, looks like the check at $FC82 is to see if it's an 800. After that it probes $C000 to see if there's RAM there. Wasn't there some upgrade for the 800 that gave you a 4K block of ram at $C000 ? Anyway, Syncalc appears to use it if you have that. If it fails the 800 check, then it looks to see if you have any PORTB ram and from there it looks like it loads the rest of itself. If there was 130XE type memory, it appears to load the remaining sectors into the extended ram although I haven't confirmed that yet. That could be an issue for SDX users who USE BANKED. The copying of $2000 to $20 appears to be cribbed from the original disk (that's what it does) but I guess the cracker either missed something or there's a transcription error because the file versions don't work while the ATR does. Next will be to look at unwinding the loader, see how nasty it is.

[BillC]

1 hour ago, Alfred said:

Wasn't there some upgrade for the 800 that gave you a 4K block of ram at $C000 ?

For vintage hardware the Mosaic 64K RAM board gives 4 switchable 4K banks accessible at C000 to CFFF, I have one in a 400.

 

For modern hardware tf_hh makes a 48/52K PCB with socket for additional OS:

 

[+DjayBee]

4 hours ago, Alfred said:

The 1985 Syncalc, looks like the check at $FC82 is to see if it's an 800. After that it probes $C000 to see if there's RAM there. Wasn't there some upgrade for the 800 that gave you a 4K block of ram at $C000 ? Anyway, Syncalc appears to use it if you have that. If it fails the 800 check, then it looks to see if you have any PORTB ram and from there it looks like it loads the rest of itself. If there was 130XE type memory, it appears to load the remaining sectors into the extended ram although I haven't confirmed that yet.

Yes, it does. Look there, I will write more later today :

 

[Alfred]

Well that’s good news, it’s already cracked. I was running some loops of the state machine tonight thinking I didn’t want to figure it all out. Good stuff.

[_The Doctor__]

cracked doesn't mean you can use it with spartados or a hard drive though... cracked seems to just mean being able to copy and load/run from a standard floppy disk drive....   although some can be run from image slots in that fashion (myide or black box) not MIO, AVG, or SIDE, unless ATR mounted but then there are other issues...

 

[Alfred]

True, but getting the basic program code available would be perhaps the largest task. Once that's done, anybody can write a sector copier to build a binary from the true data sectors. Worst case, you could probably piece the file together using DiskRX. Just need to decide which version to extract, I'd probably use the 130XE version and then just add some extra code to handle the Axlon case, and ignore the 52K version. Just need to run the loader through to get the list of sectors required.

[Alfred]

Looking at the cracked disk, I'm a bit confused. It doesn't look any different than the original disk, it still runs the big ole state machine. So where is the change where you're changing sector numbers to point to the "new" duplicate sectors ? Why not just dump the state machine altogether and just run a simple loader that walks the linked chain ?

[+DjayBee]

59 minutes ago, Alfred said:

It doesn't look any different than the original disk

I always try to be least intrusive to the original.

 

In this particular case it already was a big effort to trace down how the linkage works. The loader must be written in something compiled to p-code or similar which is very difficult to trace.

 

1 hour ago, Alfred said:

Why not just dump the state machine altogether and just run a simple loader that walks the linked chain ?

It might well be that the loader does more than just piece together all the loaded parts and this "more" would then miss if you only extract the final loaded memory block(s) to create a XEX.

 

The crack loads all sectors sequentially compared to the original loader which does "wild circles" around each track. It does not touch the contents of the sectors which are loaded to seemingly random RAM-locations.

Using the obfuscated loading address contained in each sector it should be possible I could have sorted them for sequential memory locations. Both out of lazyness and also to keep it closer to the original disk, I decide against this.

IIRC the number of bytes taken from each sector varies. I did not analyze this during the crack and do not remember if I observed anything useful.

 

Using the attached documentation and sources (SYNLIST.BAS) it shouldn't be too hard to track and dump the target address of each sector in RAM. It is calculated by EORing the first 2 bytes of the linkage block with the target address of the sector read before (or $44FF for the very first sector).

For a sophisticated coder (which I am not), doing this is probably an easy job.

 

Synapse21Tools-101.atr README-from-ATR.txt Crack-Info.zip

[Alfred]

Yes, it did occur to me after I posted that you might have left the state machine in place due to not knowing if it did anything extra. I'm a bit puzzled by you saying the crack reorders the sector loading order. The first block loaded is at $30D5 for I think $22 sectors. I'm assuming this is the bulk of the state machine/loader for a version. Since the sectors are calculated by the tables at $32FA etc. with the various goofy routines ( all that $00,X/$01,X stuff) how were you able to change the ordering without working out the full sectoring list ? I suspect you're right that the state machine does more, because the self-modfying code where in one call it's JSR $E453 to read a sector and in the next it's some other random JSR, it could be that those other calls do something useful. Or not. Probably the only way to know for sure is to just run the damn thing and catch every call, but that's a lot of tracing. I was thinking it might be just faster to dump the memory at the point where loading is complete and use that as a binary.

[Alfred]

Actually I think we're getting lost in the weeds here. If the object is to have DOS loadable spreadsheet, I'm not sure SynCalc is going to lend itself to that. It doesn't appear to load a DOS 2.0 and it's code starts down around $070F and runs up to at least the $A100 range and that's just from a few minutes of looking around. I'm wondering if this thing is written in something like Forth or a compilable BASIC because it's just so ...busy. JSR is like every 5th instruction. Uses all sorts of zero page, down low 1-3, $BX-$Dx, just jumps all over the place. It's doing a lot of work for no apparent reason that I can see so far anyway.