"Excel" for the CPC - SYMCALC spreadsheet application

[Prodatron]

In 2008 I started an engine for a spreadsheet application, but due to another (stupid) hobby these routines collected dust for many many years.
Now finally I restarted the work on this spreadsheet application for SymbOS again, which is currently called "SymCalc" (not sure about the final name).
SymCalc should provide all usual functions of a more or less modern spreadsheet application. Memory and display/format handling is nearly finished now (only date/time stuff is missing), GUI stuff is mostly finished as well (like navigating, marking cells etc.).
The next big step is implementing formula handling. Yes, the most important stuff of course.
The plan is to have a full automatic recalculation of cells in any direction which wasn't usual for 80ies spreadsheet applications.
SymCell is already able to handle a field of 64x125 cells with a maximum amount of 1024 used cells. Maybe this can be extended to 64x250 and 2048 used cells, but let's see.
Currently the bottom line on the screen shots is a dummy one. The right part will be implemented. But currently I am not sure, if multiple sheets within the same file will be possible in the future, using references between sheets.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

[Gryzor]

Ok, this is seriously impressive and ambitious! 

Can you explain the bit about calculation in any direction? I didn't know it was a limitation back in the day, but why was it so?

[St-BeidE(DE/GB)]

Prodatron,  you are insane... 
I run into trouble,  next time I give students a guest lecture. How to explain, the CPC is from the 80s ? 

Steven

[McArti0]

Handle the SLK (sylk) format as it is in Multiplan under CPM as well as in the new Excel

[Prodatron]

Can you explain the bit about calculation in any direction? I didn't know it was a limitation back in the day, but why was it so?

This is what I saw at least in VisiCalc (Apple 2) and Mastercalc (CPC).

The recalculation usually starts at A1, then A2, A3 etc, then B1, B2, B3 and so on.
You could change the setting, that it does first A1,B1,C1 etc. then A2,B2,C2 and so on.

Usually this is fine, but when you have some chained references, which are hopping forward and backward, it won't update the sheet correctly automatically. In this case you could trigger an additional recalculation process manually. And if you have multiple references which are going in the wrong direction, you have to do this multiple times. Of course this is not the normal way how you create a table, so in most cases this was not an issue.

[Gryzor]

Can you explain the bit about calculation in any direction? I didn't know it was a limitation back in the day, but why was it so?

This is what I saw at least in VisiCalc (Apple 2) and Mastercalc (CPC).

The recalculation usually starts at A1, then A2, A3 etc, then B1, B2, B3 and so on.
You could change the setting, that it does first A1,B1,C1 etc. then A2,B2,C2 and so on.

Usually this is fine, but when you have some chained references, which are hopping forward and backward, it won't update the sheet correctly automatically. In this case you could trigger an additional recalculation process manually. And if you have multiple references which are going in the wrong direction, you have to do this multiple times. Of course this is not the normal way how you create a table, so in most cases this was not an issue.

Interesting. I can see how it can be an issue when you first think of it ("oh, how will we scan the table to update stuff?") but... It's not like you don't already have a matrix of what values are dependent on other values so that you can do it in an arbitrary way?

[Prodatron]

So you suggest to generate something like pathes, which define, in which order the cells have to be recalculated as soon as something has been updated. You check, if a cell is included in such a path, and when you find it, you follow the remaining part of the path and update all mentioned cells in the correct order. This would result in a very fast and always correct recalculation. As soon as you change references inside a formula you have to regenerate one of these pathes.

My current approach was to find all affected cells in realtime again and again after each update, but maybe this will become slow when having a lot of cells. Then you could at least cache the recalculation order.

Anyway that is an interesting problem

[Gryzor]

I was thinking more along the lines of your own solution (which, if I understand it correctly, does include creating some paths on the fly). But I see no need to do it realtime; you could just run it when a cell is changed?

[Prodatron]

Yes, you are right, only when a cell is changed. I just wonder, if changing a cell could take a while as soon as you have a few hundrets of them, and it always has to generate the whole path again. In this case pre-generated pathes could be a solution. Then only changing formulas would take some time, but some additional memory for storing the pathes will be required as well.

[Gryzor]

On one hand, the grid is comparatively small so you can run through it rather quickly. On the other hand, I guess it's going to introduce *some* delay when it runs, but hey, I wouldn't be bothered by it if I had a fully graphical spreadsheet on my z80 😁 Especially if there was an option to run it manually when needed.

[Prodatron]

Handle the SLK (sylk) format as it is in Multiplan under CPM as well as in the new Excel

Thanks for the hint! Phew let's see!
https://en.wikipedia.org/wiki/Symbolic_Link_(SYLK)
Maybe a basic SLK import/export function can be done when there is enough time.

[m_dr_m]

Slick and Sick. @Overflow will be able to start coding on CPC again!

[menegator]

Woah. Just woah!

[norecess464]

Awesome. It really looks like Microsoft Excel !! Plus, multi-sheets. Congrats !

[Prodatron]

Formula calculation is now implemented including cell references.
Here you can see some of the current existing features of SymCalc:




Main Todo:
- automatic recalculation
- cell copy and moving, while considering absolute and relative cell references

[abalore]

Looks amazing. What are the hardware requirements?

[HAL6128]

A CRTC & GA GPU hardware accelerator 

Just kidding... I assume at least a 256 kB (or more) memory expansion.

[Prodatron]

Looks amazing. What are the hardware requirements?

All you need is RAM.
Like for all larger applications a minimum of 192KB ram is required, if not much more else is running at the same time.
Of course a mouse would be nice as well

[BSC]

Formula calculation is now implemented including cell references.
Here you can see some of the current existing features of SymCalc:




Main Todo:
- automatic recalculation
- cell copy and moving, while considering absolute and relative cell references

Alter, krass! 

I also love the awesome music that is part of the prog ;-) 

Seriously, this is mind-blowing... 

[zhulien]

Personally I found i rarely had so many columns but more rows. Perhaps if it cannot be user defined column numbers and whatever rows fit, a couple of alternatives could be provided? E.g. 8, 16, 32, 64 columns and rows expanding as appropriate?

64x125
32x250
16x500
8x1000

That would allow a lot more rows for people who like their spreadsheets to be databases.

Then you could perhaps have an upload to Google docs via a proxy server.

[Prodatron]

Personally I found i rarely had so many columns but more rows. Perhaps if it cannot be user defined column numbers and whatever rows fit, a couple of alternatives could be provided? E.g. 8, 16, 32, 64 columns and rows expanding as appropriate?

64x125
32x250
16x500
8x1000

That would allow a lot more rows for people who like their spreadsheets to be databases.

Then you could perhaps have an upload to Google docs via a proxy server.

Currently it is around 64 columns x 126 rows (see screenshot, cell range display at the left upper side).

You cannot view this attachment.

I guess it will be extended to around 64x250 at the end.
SymCalc wont support more than 64 colums, as currently I am thinking about using the upper 2 bits for accessing additional sheets (up to 4, which should be enough, see status bar at the bottom).
Same for rows, around 250 will be the maximum. It is more easy to stay with 8bit in this case.
Currently the total amount of used cells is 1024, I will try to increase this to 2048.
There is one limitation: The SymbOS GUI can't display more than 252 ACTIVE cells at the same time in the visible area. For this I have to add a smart algorithm, which checks, what area is currently visible and what not, so it can remove or re-define old/new controls for the GUI.

[zhulien]

Currently it is around 64 columns x 126 rows (see screenshot, cell range display at the left upper side).

You cannot view this attachment.

I guess it will be extended to around 64x250 at the end.
SymCalc wont support more than 64 colums, as currently I am thinking about using the upper 2 bits for accessing additional sheets (up to 4, which should be enough, see status bar at the bottom).
Same for rows, around 250 will be the maximum. It is more easy to stay with 8bit in this case.
Currently the total amount of used cells is 1024, I will try to increase this to 2048.
There is one limitation: The SymbOS GUI can't display more than 252 ACTIVE cells at the same time in the visible area. For this I have to add a smart algorithm, which checks, what area is currently visible and what not, so it can remove or re-define old/new controls for the GUI.

The 252 cell limitation is interesting if you ever increase screen resolution and allow for maximizing.  Symcalc looks awesome though same with your video if it.

[Prodatron]

The 252 cell limitation is interesting if you ever increase screen resolution and allow for maximizing.  Symcalc looks awesome though same with your video if it.

Well spotted
Here is how it looks on a Spectrum Next at a screen resolution of 640x256:

You cannot view this attachment.

But even in this resolution it will be hard to display around 250 active cells at the same time (you will have to shrink the width of the columns).

[Prodatron]

Handle the SLK (sylk) format as it is in Multiplan under CPM as well as in the new Excel

I just did some tries with SYLK in LibreOffice, and it looks really easy to implement. LibreOffice just ignores all the formatting stuff, which makes it very easy.
So yes, this is on the TODO list now, thanks for the hint/idea!

[Prodatron]

The plan is to have a full automatic recalculation of cells in any direction which wasn't usual for 80ies spreadsheet applications.

Interesting. I can see how it can be an issue when you first think of it ("oh, how will we scan the table to update stuff?") but... It's not like you don't already have a matrix of what values are dependent on other values so that you can do it in an arbitrary way?

I finished the auto recalculation today, and it seems to work quite nice!
I combined 10 cells in a very random way (some are below, some are above) as a chain, each of these cells were dependant on one other one.
When changing the value of the first cell in the chain, it takes not much more than one frame (around 21000 microseconds) to find and fully recalculate all other 9 cells (of course without updating the display).
I think it is still possible to do some optimizations, but now it already works better and faster than in most (early?) 80ies spreadsheet applications.