"Sentoria" reader - now for unexpanded Vic

Victragic · Post by **Victragic** » Mon May 19, 2008 5:25 am

Hi all,

Display 50 columns by 28 rows of text on a Vic..

http://www.adam.com.au/grichards/SENTORIA.d64

****************************************
EDIT : I've included a program "READER" on the disk, which works on an unexpanded Vic. It will display 46x22 text, due to memory restrictions. I have added in a simple Menu to change colours, turn the (crude) word-wrap off/on, and change the filename from 'readme.txt' to another name.

I had to remove the nice indexing, and compress the characters to 3.5 bytes per character to get it to fit in - but it does, just..

It is not possible to go back to the menu, as that code is over-written by character memory. However, there is still about 1K left for 'menu' purposes - perhaps a file selector is possible?

I need to learn more about working with disk files, I may need some help shortly..

****************************************

Running the program "Sentoria SYS8192" on a machine with 8k+ will prompt you to enter a name for a text file, and display it on the Vic screen using 50 columns by 28 rows.

It works best with text - English at least, I haven't tried other languages, and the special characters for Euro languages aren't included, so it would likely have strange results.

Press any key to move to the next page - sorry at this point I've just made it freeze when it gets to the last word (which for the default README.TXT is 'it!"')

The reader loads in the text 1 byte at a time, to save memory.

Further possibilities I have ideas for include

- ability to highlight words in different colours without clash, as screen is in 8x8 format (not implemented yet)

- possibility for graphics to be combined with text in a split-screen situation, eg for graphic adventures? (I'll work on a working demo of this if anyone is interested)

- Text entry method

The downside, (which of course there must be) is 1) the low-resolution characters, 2) the fact that it is slow, and 3) the possibility to crash it.. oh, and the fact it does take memory, making it only useful for expanded machines.

If the screen turns to black with red characters, then the program has run out of memory to display the text characters...

The font probably needs some work too.

Any suggestions for improvements, or applications are most welcome..

Cheers
-Glen

Log:
----------------------------------------
19/5/2008 11pm Fixed word wrap
----------------------------------------
20/5/2008 9am Included screen correction for NTSC
----------------------------------------
20/5/2008 8pm Cranked up the speed about 300%
----------------------------------------
21/5/2008 11am Implemented 'TAB' character
Prompt for filename to be read
Basic line now - just 'Run'
Eliminate chars > ASCII 127
Included DASM source code on .d64 image
----------------------------------------
21/5/2008 11pm Now opens file to read, rather than load
Simplified text-wrap & screen display method
----------------------------------------
24/5/2008 10am READER - textfile reader for unexpanded Vic
Added simple but crude menu function
----------------------------------------

orion70 · Post by **orion70** » Mon May 19, 2008 5:56 am

Nice work! Quite well readable, too.

In VICE emulator, at the end of the text a series of a thru z letters appear, then some random chars. Is that normal?

It works also with Italian text, if you change all the accents (e.g. é, è -> e'):

Can't wait to have it with on-screen text entry/edit.

Victragic · Post by **Victragic** » Mon May 19, 2008 6:10 am

orion70 wrote:Nice work! Quite well readable, too.

In VICE emulator, at the end of the text a series of a thru z letters appear, then some random chars. Is that normal?

That is my sloppy demo

- if you try to load a txt file larger than the available memory, it doesn't recognise the end of the memory.. the reader keeps going until it comes across the character #$FF, which obviously isn't there..

Mike · Post by **Mike** » Mon May 19, 2008 9:21 am

Well, hats off!

Nice idea utilising the redundancies of natural text.

Victragic wrote:Any suggestions for improvements, or applications are most welcome

I presume optimising the (currently linear) search, whether the character-pair already has been defined, would give the biggest speed-up.

You might try inserting the character pairs into a natural binary tree, as follows:

Four bytes for each entry:

Byte 0: first byte of pair
Byte 1: second byte of pair
Byte 2: index of branch to lower values (i.e. 'AA' < 'AB')
Byte 3: index of branch to higher values (i.e. 'GH' > 'FH')

I'd put these four bytes on separate 256 byte pages, so that access to them is easily done with the same index, without complicated address-calculations, the tree-walk would look roughly like this:

Code: Select all

 LDA #1            ; 0 index of empty branch, o.k. because we also use char 0 as 'two spaces'.
.walk
 TAX
 SEC
 LDA current_1     ; compare current pair with entry in tree, second character first
 SBC byte_1,X
 LDA current_0
 SBC byte_0,X
 BEQ found_it
 BCS to_higher
 LDA lower,X
 BNE walk          ; tight loop!
 ; empty branch found,
 ; now insert new pair at next free slot, if possible, and link into tree
 [...]

.to_higher
 LDA higher,X
 BNE walk
 [...]

This program is great for including the instructions for a game, program, etc. onto the same disc. An accompanying *.txt file to a *.d64 could easily be lost.

Cheers,

Michael

Mike · Post by **Mike** » Mon May 19, 2008 11:45 pm

Sentoria can be useful for displayed columns of numbers, i.e. log data of measuring equipment.

Finally, I think even a text-mode web-browser could be feasible!

In generating the char pair bitmap: if you duplicate the source bitmaps into the higher nibble of the byte, you don't need to shift 4 times; masking out suffices. Does Sentoria use this method?

Code: Select all

 SEC
 LDA current_1     ; compare current pair with entry in tree, second character first
 SBC byte_1,X
 LDA current_0
 SBC byte_0,X
 BEQ found_it

I found out, these lines are not quite that simple, but still: Here's a new matching routine for Sentoria. It should quite well be possible to generate a screenfull of text within 1 second.

Greetings,

Michael

P.S.: I strongly vote for Sentoria to be included on Mega-Cart!

Code: Select all

 ; ** Initialise tree
.Init
 LDA #0
 TAX
.Init_00
 STA lower,X     ; only necessary to init the pointers,
 STA higher,X    ; byte_0, and byte_1 are guaranteed to
 INX             ; contain valid values, when read.
 BNE Init_00
 LDA #1          ; empty tree
 STA free
 RTS

 ; ** Search for matching character pair, return index in X
.Search
 LDA current_1   ; first check for double space
 CMP #32
 BNE Search_00
 LDA current_0
 CMP #32
 BEQ Search_02
.Search_00
 LDA free
 CMP #1
 BEQ Search_03
 JSR Tree        ; a match exits with Z=1, therefore
 CPX #0          ; do explicit comparison
 BNE Search_01
 NOP             ; replace with appropiate error handling.
                 ; if we end up here, no matching character
                 ; pair was found, and there's no more place
                 ; to insert the current one in the tree.
                 ; for now this is simply ignored.
.Search_01
 RTS
.Search_02
 LDX #0          ; index for double space (no error!)
 RTS
.Search_03
 JSR Insert
 LDX #1          ; first pair always inserted at position 1
 RTS

 ; ** Traverse tree
.Tree
 LDA #1
.Tree_00
 TAX
 LDA current_1   ; first check for equality, needs to be
 CMP byte_1,X    ; done, since the subtraction below might
 BNE Tree_01     ; give Z=1, even though there is no match!
 LDA current_0
 CMP byte_0,X
 BEQ Tree_02
.Tree_01
 SEC             ; no match,
 LDA current_1   ; chained subtraction for comparison
 SBC byte_1,X    ; gives CS for current >= entry,
 LDA current_0   ;       CC for current <  entry
 SBC byte_0,X
 BCS Tree_03     ; N.B. equality for CS already ruled out!
 LDA lower,X
 BNE Tree_00
 JSR Insert      ; didn't find a match, so insert, and ...
 TYA             ; ... return new index in Y, or 0 for tree full
 STA lower,X     ; now link into tree, full tree writes 0 (o.k.)
 TAX             ; return matching index, or 0 for error, in X   
.Tree_02
 RTS             ; Beware Z=1 also in case there's a match!
.Tree_03
 LDA higher,X
 BNE Tree_00
 JSR Insert
 TYA
 STA higher,X
 TAX
 RTS

 ; ** Duh
.Insert
 LDY free
 BEQ Insert_00   ; do nothing, if tree is full, and return Y=0
 INC free
 LDA current_0
 STA byte_0,Y
 LDA current_1
 STA byte_1,Y
.Insert_00
 RTS

Victragic · Post by **Victragic** » Tue May 20, 2008 12:39 am

Thanks Mike,

that's exactly the kind of feedback I was hoping for.

I was aware the left nyble of each character definition wasn't being used, so duplicating it is probably a sensible use for the 'spare' 4 bits..

I will implement those enhancements hopefully tonight, and post the results!

Cheers
-Glen

carlsson · Post by **carlsson** » Tue May 20, 2008 2:18 am

Cool! I yet haven't checked it out, so what I'm writing below are speculations based on your descriptions.

The character generator still is only 2K as you generare 256 characters 8x8 pixels and reuse those where possible? In that case, you would need to swap the pointer to the character memory if you want to use one half of screen with graphics (another 2K) and one half with text. However you need to find room for at least 350 bytes screen matrix (700 bytes if you want 50x28 with twice the "resolution"). Probably it is doable as long as you keep the main driver in expansion RAM.

Also remember that by printing reversed characters, you can get 25 columns of normal (double width) characters from the ROM.

Mike · Post by **Mike** » Tue May 20, 2008 3:02 am

The char map needs 700 bytes, as Sentoria packs two half-wide characters into one normal 8x8 char. Using 8x16 chars would impede the reusability of the resulting char quadrupels.

Putting that char map into ZP space is more or less out of the question, IMHO.

my random thoughts: So to split screen graphics in the top:

text at $1000, also character definitions at $1000, 2048-700 bytes available: 1348 bytes = 168 characters (beginning with char #88) -> 12 chars horizontally, 14 chars vertically. FITS.

Which gives a 96x112 pixel bitmap at top. You set colour RAM to background left and right to the (centered) bitmap.

Raster IRQ at line 112, switch character definitions to $1800.

Do Sentoria display for the bottom of the screen.

nbla000 · Post by **nbla000** » Tue May 20, 2008 3:49 am

Mike wrote:P.S.: I strongly vote for Sentoria to be included on Mega-Cart!

I like E-books

I think that for a Mega-Cart inclusion a sort of disk reader/selector for text/seq files is required so you may read any text file...

Btw i need to remove something, maybe a game but not Frogger '07 of course...

Great work Glen !!!

Victragic · Post by **Victragic** » Tue May 20, 2008 4:24 am

Having implemented Mike's indexing, and fixing a ghastly bit of (my!) coding that located the start of character memory for 'building' new characters, it now updates a page in about 1 second..

All suggestions taken on board, and definitely the plan is for it to read 'chunks' from a file on disk, rather than trying to use a whole file in memory.

Cheers
-Glen

carlsson · Post by **carlsson** » Tue May 20, 2008 5:08 am

My opinion is that a tool like this (and the Develop20 also for that matter) suits better on an upcoming Denial Compilation Disk. I have already vaguely mentioned the idea to NBLA000 and think it sounds like a great idea. Downloadable D64 image and someone generates real floppy disks with a snazzy cover to sell for a low rate to Denial members and other interested parties. Net gross goes to the Denial site.

Multicarts should mainly consists of cartridge games/tools and then sprinkled with a few of the best old and new games released on other media.

ral-clan · Post by **ral-clan** » Tue May 20, 2008 5:17 am

Wow! If someone could port the freeware open source Infocom interpreter "FROTZ" to the VIC-20, with a 40+ column display like this it would be an amazing accomplishment. Imagine ZORK and any other Infocom text adventure running on the VIC-20!

http://frotz.homeunix.org/frotz/

Victragic · Post by **Victragic** » Tue May 20, 2008 7:00 am

ral-clan wrote:If someone could port the freeware open source Infocom interpreter "FROTZ" to the VIC-20, with a 40+ column display like this it would be an amazing accomplishment. Imagine ZORK and any other Infocom text adventure running on the VIC-20!

http://frotz.homeunix.org/frotz/

At the moment I'm trying to speed it up, but if speed of display is not a problem (eg 4 seconds to display a screen), then it would be feasible to fit Sentoria into approx 5k

Display Mem 700 bytes
Char definition min 336 bytes (using 7 bytes per 2 chars, for 96 chars)
'Key' for chars 512 bytes
Character memory 2048 bytes
Program Code approx 1300 bytes (I guess) once text input built in

+ Some memory for loading text into before it is displayed.

40K Vic - 5K, 35K to run a Z-machine? Is that possible? I don't know how much memory it takes, my understanding is 64K is pretty close to the limit.. I'd like to see it too though!

carlsson · Post by **carlsson** » Tue May 20, 2008 7:57 am

There is a Z-Machine for the Oric Atmos 48K which however only handles V3. I saw there is one for the ZX Spectrum, but I didn't look if it runs on a 48K or requires a 128K model. Does Zork on the C64 contain a Z-Machine or were those adventures hand made? It probably isn't impossible, only very hard. From what I understand, Scott Adams' adventures also use a common parser.
In case many of these adventures are optimized for 40 or 80 columns, couldn't Sentoria easily be adapted to only display 40 columns as well? I know there already are plenty of such programs, but they seem to use a fully bitmapped display, taking much more memory than this approach does. On the other hand, in case of many unique combinations of two letters, it is not so fun to get ?OUT OF MEMORY when you try to print something on screen.

A completely different application that comes to my mind is VIC-Tracker by Daniel Kahlin. The current version runs on a 22 column screen and has to make a few sacrifices to readability. It would be possible to expand the display to e.g. 26 columns, but your approach to display anything from 40 to 50 columns on screen using repeated patterns would be great. Half the screen is fixed and half contains well defined combinations of letters and numbers.

nbla000 · Post by **nbla000** » Tue May 20, 2008 9:41 am

Victragic wrote:All suggestions taken on board, and definitely the plan is for it to read 'chunks' from a file on disk, rather than trying to use a whole file in memory.

Thanks

carlsson wrote:My opinion is that a tool like this (and the Develop20 also for that matter) suits better on an upcoming Denial Compilation Disk. I have already vaguely mentioned the idea to NBLA000 and think it sounds like a great idea.

I like your idea Anders, we may put the new Orion70's game too btw to include a text disk file reader to the MegaCart is not too bad.