"Sentoria" reader - now for unexpanded Vic
Moderator: Moderators
"Sentoria" reader - now for unexpanded Vic
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
----------------------------------------
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
----------------------------------------
Last edited by Victragic on Fri May 23, 2008 6:44 pm, edited 5 times in total.
3^4 is 81.0000001
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..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?
3^4 is 81.0000001
- Mike
- Herr VC
- Posts: 4849
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Well, hats off!
Nice idea utilising the redundancies of natural text.
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:
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
Nice idea utilising the redundancies of natural text.
I presume optimising the (currently linear) search, whether the character-pair already has been defined, would give the biggest speed-up.Victragic wrote:Any suggestions for improvements, or applications are most welcome
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
[...]
Cheers,
Michael
- Mike
- Herr VC
- Posts: 4849
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
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?
Greetings,
Michael
P.S.: I strongly vote for Sentoria to be included on Mega-Cart!
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?
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.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
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
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
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
3^4 is 81.0000001
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.
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.
Anders Carlsson
- Mike
- Herr VC
- Posts: 4849
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
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.
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.
I like E-booksMike wrote:P.S.: I strongly vote for Sentoria to be included on Mega-Cart!
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 !!!
Mega-Cart: the cartridge you plug in once and for all.
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
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
Last edited by Victragic on Tue May 20, 2008 5:40 am, edited 1 time in total.
3^4 is 81.0000001
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.
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.
Anders Carlsson
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/
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 5kral-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/
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!
3^4 is 81.0000001
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.
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.
Anders Carlsson
ThanksVictragic 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.
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.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.
Mega-Cart: the cartridge you plug in once and for all.