WIP: VICdesk office suite

[orion70]

(Spin-off from this post).

As per Mike's suggestion, I put in this post all the ideas and the code of a long-forgotten project: a complete office suite for the VIC-20, inspired by C64's Magic Desk I. As you can see from the linked advert, the suite sported several applications, including a word processor, a calculator, a database, a digital clock, disk file management, etc.

My original idea was to closely follow the bigger cousin's footprints, trying to re-create the environment from scratch and make it as close a possible to the C64's:

C64


Early VIC-20 attempt


Then, two factors intervened:
1- I got aware of Mike's Minigrafik tool and its incredible potential (hi-res graphics, 40-column text handling); and
2- Mike and I produced a tiny word processor which we think is better than C64's , and is more or less ready to be used with MG's 40 columns (still to be implemented, but the 22 col version works flawlessly).

So, here I am to open a thread calling for anyone who wants to collaborate in this project. My programming skills are limited and I'd really be glad if someone would join Mike's ability in filling this gap for VIC's software.

To start with the right step, Mike provided me with a pointer routine, and I elaborated an hi-res image as a proof of concept of the main desktop screen:



Better than the C64's, isn't it?

Download the disk HERE. Unzip, load and run "BOOT"; then just move the pointer around with the joystick.
I will also double-check the 22-column word processor, and post it in the next few days.

[Wilson]

Neat! I messed around with Magic Desk a while ago. It's pretty fun. A Vic-20 version is a great initiative. What needs to be done yet? My coding skills are not particularly good, but I'd love to help in any way I can.

[Kweepa]

Looks like a cool project.

I think I prefer your original PETSCII to the new MG screen. They are both awesome in their own way, but the PETSCII has a purity that is lost in the MG.

Seems a bit odd to have an image of a computer for the word processing app... particularly a computer more modern than the VIC.

[orion70]

Neat! I messed around with Magic Desk a while ago. It's pretty fun. A Vic-20 version is a great initiative. What needs to be done yet? My coding skills are not particularly good, but I'd love to help in any way I can.

Thanks! Mike and I have been programming the word processor, and I have drafts of the database and a disk directory read/display routine. The original PETSCII version already had a calculator and the wall clock, too.
I will post all the finished and unfinished programs on friday (they're at my workplace, but now I'm at home with a bad flu ).

Looks like a cool project.

I think I prefer your original PETSCII to the new MG screen. They are both awesome in their own way, but the PETSCII has a purity that is lost in the MG.

Seems a bit odd to have an image of a computer for the word processing app... particularly a computer more modern than the VIC.

Of course, I agree the PETSCII version is somehow "more VICish". But the applications will make full use of the hi-res graphics and 40-column text provided by Minigrafik, so this project will probably fall into the "doesn't seem to be a VIC program" category. The hi-res desk probably fits better .
As for the objects on it, well, it was quite a random choice, just to show what can be done - there are plenty of other possibilities, including top (non-perspective) views, or even multi-colour instead of hi-res.

But I'm also open to the PETSCII option. .

[Mike]

Seems a bit odd to have an image of a computer for the word processing app... particularly a computer more modern than the VIC.

That tool is supposed to start up the built-in Amiga emulation.

What needs to be done yet? My coding skills are not particularly good, but I'd love to help in any way I can.

As Alessandro wrote, the text editor was about half-way being ported to 40 columns. Edits on a single line can be done quite easily with the string operators in BASIC, but line insertions/deletions need ML support. Also the DIMed string array holding the text should be replaced by the memory buffer like the routines in MG BROWSE use for storage - mainly to avoid lengthy garbage collections. That'd also require another two extra routines to copy between a BASIC string and that buffer.

For the directory display in 40 columns I could reuse the display of MINIPAINT. Directory management (delete/rename/reorder/copy/...) of course needs some more work, and would be specific to CBM DOS drives - 1541, 157x and 1581 - for the more delicate tasks.

The database is supposed to use REL files. I have posted a routine in the thread 'ROM call and other tricks' which can read in a record string of up to 255 characters up to the final CR without hiccuping on commas, colons, and the like.

The clock display can reuse the routine I once posted to put TI$ into the border. Here the output then should be directly written to the screen bitmap.

The calculator shouldn't be too difficult to program with all basic arithmetics, and percent automatic - unless it is supposed to adhere to operator precedences.

And, of course, the current pointer display routine is just a prototype - the final version will be flicker-free.

they're at my workplace, but now I'm at home with a bad flu

Ouch! Get well soon!

Michael

[Wilson]

Sounds like it's mostly a matter of rounding up all this code then.

As Alessandro wrote, the text editor was about half-way being ported to 40 columns. Edits on a single line can be done quite easily with the string operators in BASIC, but line insertions/deletions need ML support. Also the DIMed string array holding the text should be replaced by the memory buffer like the routines in MG BROWSE use for storage - mainly to avoid lengthy garbage collections. That'd also require another two extra routines to copy between a BASIC string and that buffer.

Let me make sure I understand this. Whenever the user changes line, the new line is copied to a BASIC string variable?
Also, how are line insertions/deletions to be handled? Just a big mem copy 256 bytes up or down?

The database is supposed to use REL files. I have posted a routine in the thread 'ROM call and other tricks' which can read in a record string of up to 255 characters up to the final CR without hiccuping on commas, colons, and the like.

I'll check that out. What sort of information would the database store?

The calculator shouldn't be too difficult to program with all basic arithmetics, and percent automatic - unless it is supposed to adhere to operator precedences.

Hmm, that sounds like a job for BASIC, which I am rather useless with.

I'm at home with a bad flu

Sorry to hear. Get well soon!

[Mike]

Sounds like it's mostly a matter of rounding up all this code then.

Not really. There's still enough to be done, coding-wise.

Let me make sure I understand this. Whenever the user changes line, the new line is copied to a BASIC string variable?

The current line, where the cursor resides, is handled within a BASIC string. When the cursor is moved to the preceding or following line, the string is copied into the memory buffer, and replaced by the new current line.

Also, how are line insertions/deletions to be handled? Just a big mem copy 256 bytes up or down?

That can be handled slightly more efficient.

The editor uses the buffer-gap method: All text above the current line resides at the start of the text buffer. All text below the current line is separated by a gap, so its end is aligned to the text buffer end:

Code: Select all

buffer start: +-------------------------+
              |                         |
              | text above current line |
              |                         |
              +-------------------------+
              | current line            |
              +-------------------------+
              |/////////////////////////|
              |/////////////////////////|
              |////// buffer gap ///////|
              |/////////////////////////|
              |/////////////////////////|
              +-------------------------+
              |                         |
              | text below current line |
              |                         |
  buffer end: +-------------------------+

The irrelevant buffer gap contents are omitted from screen display. That way, regardless whether what type of line operation is performed (insertion, deletion, change of current line), only one screen line needs to be copied.

I'll check that out. What sort of information would the database store?

A variable number of (named) fields, each with a given number of maximum allowed characters per field, up to a total maximum allowed record length of 255 bytes/record (including field and record separators).

The calculator shouldn't be too difficult to program with all basic arithmetics, and percent automatic - unless it is supposed to adhere to operator precedences.

Hmm, that sounds like a job for BASIC, which I am rather useless with.

A calculator in ML with operator precedences would even be better!

[orion70]

Thank you guys. I feel better now, and being back at work I can post some files .

Sounds like it's mostly a matter of rounding up all this code then.

Not really. There's still enough to be done, coding-wise.

Agree. Here's what's been done for now:

- Desktops with joystick-driven pointer, in green and blue background versions. They include: loading routine for external routines (all of them except word are still to be done, and of course we can put whatever we want on the desk ); a calculator app and a disk read routine found in magazine type-ins.

Hmm, that sounds like a job for BASIC, which I am rather useless with.

A calculator in ML with operator precedences would even be better!

If the calc and disk read routines look naive, it's because they ARE naive, and you ML gurus should really modify them .

- VICWord, an almost complete word processor with the features previously described by Mike, more or less ready to be adapted for the 40-column MG environment.



That's almost all for now: the database I was working on is still another mod of an Italian magazine type-in, but I don't feel it's good to be adapted for the 40 columns, so I dropped it.

Download everything in a small zip file HERE.

I'll check that out. What sort of information would the database store?

A variable number of (named) fields, each with a given number of maximum allowed characters per field, up to a total maximum allowed record length of 255 bytes/record (including field and record separators).

Is this a to-do for the future database, or was there already a draft of it Mike? Sorry, I can't remember, too much time passed..

As a final note, I should add my general point of view regarding this project:
- All that's been done until now can be changed to any extent.
- I would point more towards a hi-res integrated environment for the fully expanded VIC with a disk drive, rather than a "cheaper" PETSCII product: we have new know-how, let's use it!
- Graphically, the office suite should be coherent, e.g. all blue text and graphics on white background (or vice-versa), for better readability and professional look .
- It should include at least a word processor, a general purpose database (from recipes to books, disks, phone directory, etc.) , a disk handling routine, the calculator, the wall clock, and a graph creation program (2D and 3D bars, cake graphs, cartesian... I'm working on a MG version of it). The "VICmoney" prg is an optional - I don't have clear ideas of what to put in it .
- The PETSCII desktop with the simple calculator and wall clock could be re-used for a subsequent scaled-down version of the suite, like for 8/16K VICs (simpler external apps), more appealing to the purists.

[orion70]

Just adding fuel to the fire :
HERE's a working 3D bars mini-program, inspired by Mike's demo. It allows 2 to 14 3D bars displayed, at any maximum Y (to be specified before entering data). Load and run Minigrafik (included in the D64) before the 3D program.

Code: Select all

10 printchr$(147)
20 input"bars (2-14)";b:ifb<2orb>14then10
30 dimz(b)
40 input"max y value";my
50 print:print"now input values.":print
60 forr=0tob-1
70 print"value#"r+1:inputz(r)
80 ifz(r)>mythenprint"too high!":goto70
90 nextr
100 forr=0tob-1
110 z(r)=int((175*z(r))/my)
120 nextr
130 @on:@clr
140 y=191:z=175:s=25:gosub200
150 q=int(132/b)
160 y=188:forx=6to138stepq:x1=int(x/q):ifx1>bthenx1=b
170 z=z(x1):gosub260:next
180 geta$:ifa$=""then180
190 @return:end
200 @1,0,yto147,y:@1,147,yto159,y-12
210 fort=0tozsteps
220 @1,0,y-tto12,y-t-12:@1,12,y-t-12to159,y-t-12
230 next
240 @1,0,yto0,y-z:@1,12,y-12to12,y-z-12:@1,159,y-12to159,y-z-12
250 return
260 ifz=0thenreturn
270 ifz<2then300
280 fort=1to8:@0,x+t,y-1tox+t,y-z+1:next
290 fort=1to5:@0,x+t+9,y-t-1tox+t+9,y-t-z+1:next
300 fort=1to5:@0,x+t+1,y-t-ztox+t+8,y-t-z:next
310 @1,x,ytox+9,y:@1,x+9,ytox+15,y-6
320 @1,x,ytox,y-z:@1,x+9,ytox+9,y-z:@1,x+15,y-6tox+15,y-z-6
330 @1,x,y-ztox+9,y-z:@1,x+9,y-ztox+15,y-z-6
340 @1,x,y-ztox+6,y-z-6:@1,x+6,y-z-6tox+15,y-z-6
350 return

[Mike]

That's almost all for now: the database I was working on is still another mod of an Italian magazine type-in, but I don't feel it's good to be adapted for the 40 columns, so I dropped it. [...] Is this a to-do for the future database, or was there already a draft of it Mike? Sorry, I can't remember, too much time passed ...

I rather was quoting some perceived minimal spec of a database - of course for the VICdesk application that could be specialised to hold contact data or address fields to print on a letter envelope. I didn't remember you already tried out that type-in program. Did you post it with a link somewhere here in Denial?

Here's a working 3D bars mini-program:

Some suggestions:

The program could easily infer the maximum bar size from all positive numbers entered, instead of requiring the user to enter it beforehand:

Code: Select all

10 M=0
11 FOR T=1 TO N
12 PRINT "BAR #";MID$(STR$(T),2);
13 INPUT B(T):IF B(T)<0 THEN PRINT "ONLY POSITIVE NUMBERS, OR ZERO, PLEASE!":GOTO 12
14 IFM<B(T)THENM=B(T)
15 NEXT

... this is not a complete program, but only serves to show the idea: in line 14, M is adjusted to a higher number as soon as an input of a bar size is greater than it. At the end, M contains the size of the highest bar. And then, all bar sizes are normalised to whatever pixel size intended ... that need not necessarily be 175, it could rather be 100 instead.

It is not quite clear to me why you disallow the display of zero-height bars in line 260. The original routine can cope with that, and simply displays a "flat" parallelogram which is supposed to lie in the base plane (consequentially the bar height is "measured" between the middle of the base pixel row and the middle of the top pixel row, BTW).

[orion70]

I rather was quoting some perceived minimal spec of a database - of course for the VICdesk application that could be specialised to hold contact data or address fields to print on a letter envelope. I didn't remember you already tried out that type-in program. Did you post it with a link somewhere here in Denial?

Nope, I'll post it next week, but I don't feel it's a very good one. Maybe parts of it can be of use.

The program could easily infer the maximum bar size from all positive numbers entered, instead of requiring the user to enter it beforehand:

Thanks! Being from Italy, I tend to produce spaghetti-code .

It is not quite clear to me why you disallow the display of zero-height bars in line 260. The original routine can cope with that, and simply displays a "flat" parallelogram which is supposed to lie in the base plane (consequentially the bar height is "measured" between the middle of the base pixel row and the middle of the top pixel row, BTW).

It was only a matter of aesthetics .

[Mike]

The program could easily infer the maximum bar size from all positive numbers entered, instead of requiring the user to enter it beforehand:

Thanks! Being from Italy, I tend to produce spaghetti-code.

My pleasure!

Though, I'll take a look into the bar display routine, so their width can also be changed. That will allow a more evenly display (not just some 3 or 4 "lonely" bars around because of a big spacing between them ...)

It was only a matter of aesthetics.

<fx=shrug></fx>
I don't see what could appear wrong about that. If, for example, you calculate the bar height H by normalising and rounding:

Code: Select all

H=INT(100*value/max_value+0.5)

... H can range from 0 to 100, including both end-values. Especially intermediate results of 'value/max_value' between 0 and strictly less than 0.5 are rounded down to 0 - yet I see no good reason to make that bar disappear. If I were a bare user of this office suite, that would have earned you a bug report.

[Mike]

Though, I'll take a look into the bar display routine, so their width can also be changed. That will allow a more evenly display (not just some 3 or 4 "lonely" bars around because of a big spacing between them ...)

Here we go:

Code: Select all

10 PRINT"{CLR}3D BAR CHART":PRINT
11 INPUT"BARS(2..14)";N:IFN<2ORN>14THEN11
12 DIMZ(N-1):M=0
13 FORT=0TON-1
14 PRINT"VALUE #";MID$(STR$(T+1),2);:INPUTZ(T)
15 IFZ(T)<0THENPRINT"ONLY VALUES >=0!":GOTO14
16 IFM<Z(T)THENM=Z(T)
17 NEXT:IFM=0THENM=1
18 :
19 W=3*141/(4*N-1):V=(141-W)/(N-1)
20 :
21 @ON:@CLR
22 Y=191:Z=175:S=25:GOSUB33
23 Y=188
24 FORS=0TON-1
25 X1=INT(V*S+6.5)
26 X2=INT(V*(S+3/4)+6.5)
27 Z=INT(175*Z(S)/M+0.5)
28 GOSUB40
29 NEXT
30 GETA$:IFA$=""THEN30
31 @RETURN:END
32 :
33 @1,0,YTO147,Y:@1,147,YTO159,Y-12
34 FORT=0TOZSTEPS
35 @1,0,Y-TTO12,Y-T-12:@1,12,Y-T-12TO159,Y-T-12
36 NEXT
37 @1,0,YTO0,Y-Z:@1,12,Y-12TO12,Y-Z-12:@1,159,Y-12TO159,Y-Z-12
38 RETURN
39 :
40 IFZ<2THEN43
41 FORX=X1+1TOX2-1:@0,X,Y-1TOX,Y-Z+1:NEXT
42 FORT=1TO5:@0,X2+T,Y-T-1TOX2+T,Y-T-Z+1:NEXT
43 FORT=1TO5:@0,X1+1+T,Y-T-ZTOX2-1+T,Y-T-Z:NEXT
44 @1,X1,YTOX2,Y:@1,X2,YTOX2+6,Y-6
45 @1,X1,YTOX1,Y-Z:@1,X2,YTOX2,Y-Z:@1,X2+6,Y-6TOX2+6,Y-Z-6
46 @1,X1,Y-ZTOX2,Y-Z:@1,X2,Y-ZTOX2+6,Y-Z-6
47 @1,X1,Y-ZTOX1+6,Y-Z-6:@1,X1+6,Y-Z-6TOX2+6,Y-Z-6
48 RETURN
49 :
50 REM ** 3D BAR CHART V3.1 WRITTEN 2011-01-08 BY M. KIRCHER

Lines 40 to 48 contain the changed bar drawing routine. Instead of a fixed width, and the left X co-ordinate of the front facet, X1 and X2 (left and right) are supplied instead. The variables W and V control width and spacing of the bars, so the gap between two bars is 1/3 of the bar width, yet all bars together span the whole screen width.

In the *.d64, first run 'MINIGRAFIK', then '3D BAR CHART'.

Greetings,

Michael

[Wilson]

Ahhhh, so much activity!

The editor uses the buffer-gap method: All text above the current line resides at the start of the text buffer. All text below the current line is seperated by a gap, so its end is aligned to the text buffer end:

Okay, thanks for explaining that. That's a much better way.

A calculator in ML with operator precedences would even be better!

With liberal usage of KERNAL routines I trust? It's worth a shot. Do you think the memory usage would be comparable to a BASIC version?

- I would point more towards a hi-res integrated environment for the fully expanded VIC with a disk drive, rather than a "cheaper" PETSCII product: we have new know-how, let's use it!

I agree, but I must admit I prefer the look of the color PETSCII interface... If it weren't for that darn cursor.
Is anyone working on any particular program for this suite? I assume not, but I figure it is good to ask so we don't have four people making the same thing?

[folkoh]

I elaborated an hi-res image as a proof of concept of the main desktop screen:



Better than the C64's, isn't it?

Great stuff! I find the PETSCII-Version charming, but why not going for something much better in 2011? The only thing that worries me a bit is the strange PC-ish machine on the desktop instead of a proudly presented VIC...

Keep on the good work!

Greetings,

Folko