Denial

Hi, all!

As promised, I've packed the ML routines used in the Easter present into this small text viewer.

It runs with a least an +8K RAM expander. However, as the whole text file is read into RAM, a bigger expansion might be necessary for larger texts. +24K allow for 512 lines (and are required to read the interview).

BROWSE consists of a ML library, which does line-based ASCII text output on the high resolution screen provided by MINIGRAFIK. This library is 'scripted' by a BASIC program:
Download *.d64, and source.

The variable S=10240 defines the start of a jump table into 5 different routines:

SYSS,<adr>,<nr>

prints an ASCII string of 40 characters at <adr> to screen line <nr>.

SYSS+3,<nr>

inverts screen line <nr>. Within BROWSE, this is used to highlight the banner in the bottom line.

SYSS+6,<top>,<bottom>
SYSS+9,<top>,<bottom>

scroll the screen between screen lines <top>, and <bottom>. '+6' scrolls up, '+9' scrolls down. This is much faster than reprinting the whole screen, but the newly appearing line still must be printed with the first SYSS command above.

SYSS+12,<adr>,<nr>

This routine does the main work: it reads in the file with logical number <nr> into a memory buffer beginning at <adr>, formatted to 40 characters per line. The printable characters from 32 to 126 and the two codes 9 (TAB) and 10 (LF) are recognized; everything else is ignored. TABs are 8 characters wide.

Greetings,

Michael

Well done! Thanks Mike, I think a lot of apps will be developed from this engine.

orion70 wrote:I think a lot of apps will be developed from this engine.

something from papersoft ?

Very useful routines, thanks Mike.

nbla000 wrote:

orion70 wrote:I think a lot of apps will be developed from this engine.

something from papersoft ?

nbla000 wrote:Very useful routines, thanks Mike.

Maybe for a 40 column version of SD2browse?

Mike wrote:

nbla000 wrote:Very useful routines, thanks Mike.

Maybe for a 40 column version of SD2browse?

I'm working on new .D41 and .DNP files support for CBM-FileBrowser at the moment so I may check your idea btw 22 columns are enough since file name are max 16 chrs length,

nbla000 wrote:I'm working on new .D41 and .DNP files support for CBM-FileBrowser at the moment so I may check your idea btw 22 columns are enough since file name are max 16 chrs length,

... however, a "normal" directory display also includes the block count, and file type (and possibly the write protect '<'), i.e. possibly up to 30 columns, when the block count exceeds 999:
If you are honest, the current display of sd2browse is more like shoe-horned into the standard 22 column layout of the VIC.

I've never heard of .D41 files?

How about using this for a Vic-20 diskmag?

Nice work again, Mike! I've been putting your ML 40 column text printing routine to use a lot recently.

Wilson wrote:How about using this for a Vic-20 diskmag?

Together with a friend I once published a diskmag with Acorn computers as central theme (and running on RISC OS). That was around 1995 to 1998, and it was scheduled roughly bi-monthly. We had developed an own viewer program, and used an own document format with compressed text, and image data. Effectively the display of the viewer could compare to early web browsers, only it couldn't fetch data over the web.

...

Turned out, that even though we had some people that semi-regularily offered articles, most work was done by us two. I found it quite sad, that even though we knew the "circulation" was wide up in the hundreds only so few readers participated with ideas.

IMO, diskmags had their time when still not everyone could get access to the web, and indeed we used the web a lot, filtered out some relevant information, and often were the first ones to spread news when the next issue was presented at a meeting - because we included information we just found the day before, and made a quick edit in the night before the meeting.

Nice work again, Mike! I've been putting your ML 40 column text printing routine to use a lot recently.

I'm quite happy, that these routines find their use also in other contexts.

1. I confess, they're really geared to fast output, at the expense of being slightly "user-unfriendly" because of their focus on whole lines. But with the source at hand it shouldn't be too difficult to include some more flexibility in that regard. The most difficult thing to implement here would be the printing of a single character at left, and right end of the string, as here the old background must be taken into consideration.

2. Another approach is simply to keep a "shadow" line with the original text bytes, maybe even a complete shadow text screen - and then write whole lines even though parts at the left- and right-hand side haven't changed. Easier to implement, and not really much slower. That is, how the load/save dialog in MINIPAINT displays file name, and device number.

Only if there is graphics to the left, and right of the text string, it is really necessary to implement point 1.

Boray wrote:I've never heard of .D41 files?

From what I've found, a simple renaming of *.d64 files, to fit those into the naming scheme of *.d71, and *.d81 files.

Yes, the results of a diskmag might be harder to appreciate these days. I enjoy reading some of the C64 mags like Vandalism from time to time as it incorporates graphics, music, and news together so nicely. I figure something like that for the Vic-20 might promote more music and graphics to be made. Whether anyone would bother to read it is another thing.

Mike wrote:I confess, they're really geared to fast output, at the expense of being slightly "user-unfriendly"

And I must confess that I did nothing to get around the limitations in my usage.

Mike wrote:. Another approach is simply to keep a "shadow" line with the original text bytes, maybe even a complete shadow text screen - and then write whole lines even though parts at the left- and right-hand side haven't changed. Easier to implement, and not really much slower. That is, how the load/save dialog in MINIPAINT displays file name, and device number.

Ahh, an interesting solution.

Wilson wrote:Yes, the results of a diskmag might be harder to appreciate these days. I enjoy reading some of the C64 mags like Vandalism from time to time as it incorporates graphics, music, and news together so nicely.

We did this in our diskmag quite the same, and also could for example start other programs from within the mag, which then would multitask together with the magazine engine on the desktop.

Also, the music player was just another application launched with a sound tracker file as parameter.

What I wanted to point out was, the magazine of course didn't literally assemble itself; it needed to be constructed like a game, tool, or another program. Even if it was more work design-wise rather than coding-wise.

From this point of view, I really appreciate the work put into such a magazine. But my own motivation to start out again on such a project is very much limited, given my personal experience stated above. And ...

I figure something like that for the Vic-20 might promote more music and graphics to be made.

... that can also be promoted by other means, for example with a good game, or programming tool, which stretches the VIC capabilities slightly further than one would otherwise expect.

Mike wrote:Another approach is simply to keep a "shadow" line with the original text bytes, maybe even a complete shadow text screen - [...]

Ahh, an interesting solution.

Only not too obvious.

Boray wrote:I've never heard of .D41 files?

It is a standard .d64 file with the .d41 extension.

Point taken.

Anyway, I shall eagerly wait to see what others will produce with this fine extension to the increasingly impressive MINIGRAFIK.