Hello, thank you for this wonderfull forum !
Do you know the GameBoy Book Reader (
http://www.mqp.com/fun/index.html ), a tool for transforming .txt file to .gb file (open source software) ? It's amazing and useful, no ?
I would like the same tool, but txt2nes file.
This tool of my dream exists ? if not, do you think it would be easy to adapt GameBoy Book Reader to make NES Book Reader ? (I dont program cuputer, it's why I ask the question)
It would be straightforward to write a .txt reader for the NES, but why? Book reader is intended for use where you can't use a PC, and the NES isn't nearly as portable as a Game Boy.
In fact, I have a portable DVD player with a nes emulator in it. I can play nes game on it. And I want to transform it in e-bbok reader .
This DVD player with NES emulator is the PDVD 8088 (see into google)
Sorry, what mean "It would be straightforward to write a .txt reader for the NES", I dont understand, english is not my native language.
define straightforward
What else did you not understand?
ok, it's mean it can be easy to make a such tool, it's that ? A txt2nes software (or html2nes, why not) would be realy great to use with the PDVD 8088 !
I'm very interesting by utilities in .nes (calendar, calculator, text player, dictionary, etc...) for my PDVD
francois wrote:
ok, it's mean it can be easy to make a such tool, it's that ?
Yes, it would be easy to code such a tool.
Quote:
A txt2nes software (or html2nes, why not) would be realy great to use with the PDVD 8088 !
I don't know how much text you'd be able to put in a standard cart. Maybe some dictionary compression can be used to maximize the space. The HTML thing is interesting... a simple (very simple!) HTML interpreter for the NES would be fun to have... well, I'm not up for a task like this right now.
Quote:
I'm very interesting by utilities in .nes (calendar, calculator, text player, dictionary, etc...) for my PDVD
Don't those chinese computers that are clones of the NES come with this kind of software? Maybe there are dumps of those... they probably require a keyboard and may not be 100% compatible with an actual NES, though.
I made a text viewer on NES once a long time ago, for this amusing crazy story someone wrote. I had to reformat it manually to 30 column though, which means there's a lot of hyphens and line breaks. I would've released it, but it's just another of one of my old progs that only runs on NESticle.
A variable-width font rendered into CHR-RAM, with the formatting etc. handled automatically would be a lot nicer.
There's a web browser that almost works on NES:
http://www.sics.se/~adam/contiki/apps/webbrowser.html
I imagine that should work as an HTML viewer. It's written in C and compiles with cc65, but I think the "conio" library for the NES needs to be finished or rewritten.
The biggest obstacle I see to implementing a full-screen variable-width text reader is the bankswitching. In order to fill the screen with variable-width text even in monochrome, you're going to need to use both pattern tables, and if you plan on scrolling the text (as opposed to just rewriting it), you're going to have to rewrite the background base address (
$2000.4) twice per frame in order to see both pattern tables. This means you're going to have to either hit sprite 0 and waste time waiting on the second CHR bankswitch, or you'll need a board with both a scanline IRQ and CHR RAM. The only common board like this is TGROM (e.g.
Mega Man 4), and even that's not all that common.
But if you'd accept a reader with only pageup/pagedown (not lineup/linedown), then it would only need sprite 0 at a constant position, and it would be easy to make a text reader with plain-old UOROM (mapper 2), which just about everything supports.
And are we going to need support for non-US-ASCII codepages such as latin-1, etc.?
font data
as seen on tv
If it was possible to have this kind of tool, it would be great ! In the gameboy world they have such tool (txt2gb and html reader with hyperlink etc...)
Gameboy is such different than NES ? Do you thionk it's difficult to adapt this kind of program (it's only text and sting, and I think GB is 8 bit too)
I have very little dream :
1) You have a text
2) With a soft on Windows, you import the text.
3) Eventualy, you can select chapter and title for menu.
4) You clic on a button, and you have a .nes file.
5) on your NES console , you can read the text, scroll with up and down, turn page with right and left, and have a menu with chapters.
If I have a source code in NES langage of a simple book of that kind, I think I can make a tool to transform a txt in nes file in Windows.
I don't find informations about text display in the NES documentation. How to developpe something to display text and scroll and turn page on NES? Please, help me, it very important for me .
Stuck with fixed width font, it is very easy to write text on the NES' screen.
Load each letter in pattern table and write the corresponding tile number on name tables.
If you arrange the letters in pattern table in maneer they matches ASCI definition, you just have to copy the text data to the nametable and go to the next row when a return character is encountered.
Code:
|Fixed width fonts in a 30 |
|column window aren't nearly as|
|easy to read as variable width|
|fonts. If your DVD player's |
|NES emulator supports |
|the right mappers, then I |
|see no reason to compromise |
|functionality, especially when|
|a variable width font could |
|look this good: |
As usual, your lowercase t's are still ugly, looking far too much like z's.
I actually though Tetanus on Drugs had an unimplemented "Drug Quiz" feature after misreading the quit option.
Dwedit wrote:
As usual, your lowercase t's are still ugly, looking far too much like z's.
It's called the half-uncial 't'. Well at least it's
not a cross Quote:
I actually though Tetanus on Drugs had an unimplemented "Drug Quiz" feature after misreading the quit option.
Hmmm...
Exodus for NES had multiple choice questions about the story of Moses. Thanks for the suggestion for M4, if I ever get to it
I like a lot fixed fonts myself. When a lot of "i" and "l" are on the same word, it does make reading easier.
However, what makes really difficult to read is misplacen line retuns.
Such as :
Code:
Hello, how are
you ? What did you
do last holliday ?
Some fan made translation patches combine il, ll, and li into one 8x8 block, which doesn't looks as ugly as other letter combinations in a single 8x8 block.
If using variable width font why not justify the text? I will look great. I don't think variable width fonts by themselves improve readability much. All books have justified text, so why not he NES book reader? =)
Seriously, how hard do you think it would be? We'd have to calculate the size of the words to then calculate the empty space in the line. The tricky part would be to distribute the empty space evenly between the words. If the page scrolls a line at a time it wouldn't be hard at all to implement this, it wouldn't even feel slow. Rendering the fonts to CHR-RAM would still be the slowest thing.
Justification can look more clunky on a tile-based device such as the NES, as when laying out a book you have much more control over exactly how much spacing you add, whereas with a fixed with charset, you can only space in multiples of 8 pixels.
Of course, you can always render the text to a character map, but that's a whole different boat. This is what you'd have to do to use variable width fonts anyway, for the most part (although I'm sure there are various shortcuts one could take that wouldn't compromise the final result).
I find that, for reading text on smaller, tile-based devices, fixed-width and left-justified is my preference. Although depending on how much text you want to be able to have onscreen at once, you might even consider a 1x2 tile charset (8x16 pixels). I wouldn't go 2x2 (8x16 px) as that would severely diminish the amount of text on screen.
I think 8x16 fonts are very nice. Variable width fonts and justification surelly need rendering to the pattern tables, that's why I said "If using variable width font", or else justification would look pretty bad.
Well, variable width fonts still have fixed height, so they're still vertically aligned to the background grid. This means the fonts can be placed with horizontal pixel precision just by shifting them left or right and merging the bytes. Not a very complicted procedure.
If a simple justification algorithm that only affects white spaces was used it wouldn't make things much more complicated. A more complicated one, that also distributes the empty space between the letters of the words would be more complicated, but still doable.
Wariable width is definitly hardly reasonable for the NES. Maybe on a demo that only show text, but it would be slow. In an actual game, even in a RPG that show a lot of text, it would be a real sacrifice in tiles. Displaying the whole alphabet with both small letters and caps, with all special characters and all can sacrifice up to 80 tiles.
Doing 3 lines of variables width fonts makes 3x28 = 84 tiles.
So yeah, it is do-able, but only for 3 or 4 lines.
I'd prefer have fixed letters, but with 8x16 tiles, allowing taller letters. That sacrifices MUCH more tiles, unless you're in a text only menu or if you use a MMC5 (quick reference to Just Breed hehe). Most SNES and GBC games uses 8x16 tiles for letters.
Bregalad wrote:
Wariable width is definitly hardly reasonable for the NES. Maybe on a demo that only show text, but it would be slow. In an actual game, even in a RPG that show a lot of text, it would be a real sacrifice in tiles.
Man, we're talking about a TXT viewer here, of course it's just text. Don't loose the track.
If you scroll one line at a time that would be 32 tiles. If we agree that a reasonable ammount of bytes to upload to CHR-RAM in one frame is 256 (ok, maybe not reasonable, but surelly possible in a TXT READER), 16 tiles could be updated. So 2 frames would be needed to upload the tiles, and I believe that 2 full frames are enough to build those tiles through shifting and AND'ing.
So you'd get a 30 lines per frame text scroller. I don't think that's slow for a text reader at all. In 1 second you can scroll through a full page, that's enough.
Quote:
Displaying the whole alphabet with both small letters and caps, with all special characters and all can sacrifice up to 80 tiles.
Doing 3 lines of variables width fonts makes 3x28 = 84 tiles.
So yeah, it is do-able, but only for 3 or 4 lines.
Not if you keep the actual fonts stored in PRG-ROM, so you have all the CHR-RAM free for rendering. Plus, we can force a 1-bit mode, as all we need is black and white. Just by forcing the 1-bit mode we double the ammount of avaliable tiles. Split the screen in the middle (switch to the other pattern table) and you have 1024 tiles to draw black and white stuff on. It's more than you need for a full screen.
Since the whole screen uses only 960 tiles you even have some free tiles to use with something other than text. 64 if you use them as 1-bit or 32 if you use them as regular 4-color tiles. More than that actually, since we would not be rendering text to the leftmost and to the rightmost columns.
Quote:
I'd prefer have fixed letters, but with 8x16 tiles, allowing taller letters. That sacrifices MUCH more tiles, unless you're in a text only menu or if you use a MMC5 (quick reference to Just Breed hehe). Most SNES and GBC games uses 8x16 tiles for letters.
Many games switch to a CHR bank that contains mostly letters when the text part of the screen is on.
EDIT: I even got the math wrong. If using 1-bit mode 256 bytes would be enough to represent a full 32-tile column. So we could scroll 60 lines in a second! 2 screens in a second, you can't get any faster than that! Of course, provided you can compute the 32 tiles in 1 frame. I think it's possible. Didn't change the post itself 'cause I'm feeling lazy right now. =)
I think with a palette like :
$0f, $20, $0f, $20
$0f, $0f, $20, $20
And write attribs like :
$00, $00, $00, $00, $55, $55, $55, $55
$00, $00, $00, $00, $55, $55, $55, $55
You could write 1-bit data for the first half of the screen on the first bitplane, and the 1-bit data for the second half of the screen on the second bitplane. Is that what you said ?
Anyway... txt is supposed to be always viewed in a fixed fond. This fixes most problems I think.
Yeah, instead of using 2 bits of a tile to represent 1 pixel, we have each bit represent 1 pixel. The NES only makes that easier, as the format it uses for tiles has one plane separated from the other. Some consoles with 4bpp tiles have the 2 bits of a pixel packed in the same byte, wich makes it difficult to make 1bpp graphics.
But as you said, all you need in order to use this technique in the NES is to have 2 different palettes, one arranged to display black whenever bit 0 is clear (colors 00 and 10) and white when it is set (colors 01 and 11), and onother one arranged to display black whenever bit 1 is clear (colors 00 and 01) and white when it is set (colors 10 and 11). Then depending on the palette used you have one image represented by the first bits and another one represented by the second bits.
I'd rather split the screen always horizontally, in 4 areas, like this:
1. pattern table 0, palette 0
2. pattern table 0, palette 1
3. pattern table 1, palette 0
4. pattern table 1, palette 1
And the last area is shorter, leaving some tiles for use in an interface or something.
Since the program would be more like a book reader, I think justification is a nice feature. And maybe some simple HTML-like tags could be used to format the text. Stuff such as bold, italic, underlined, and even aligning options like centered, left, right and justified. The hardest thing to implement here would be the "bold" option, in my opinion, as it would most likely require a separate font, or simulation, by drawing the letter twice dislocated by 1 pixel, but that may look ugly. Guess the same happens with italic.
tokumaru wrote:
Bregalad wrote:
Wariable width is definitly hardly reasonable for the NES. Maybe on a demo that only show text, but it would be slow. In an actual game, even in a RPG that show a lot of text, it would be a real sacrifice in tiles.
Man, we're talking about a TXT viewer here, of course it's just text. Don't loose the track.
If you scroll one line at a time that would be 32 tiles. If we agree that a reasonable ammount of bytes to upload to CHR-RAM in one frame is 256 (ok, maybe not reasonable, but surelly possible in a TXT READER), 16 tiles could be updated. So 2 frames would be needed to upload the tiles, and I believe that 2 full frames are enough to build those tiles through shifting and AND'ing.
Problem is that in order to get more than 16 lines, you'd need to use more than one 4 KB bank of CHR RAM (256x128 pixels times 1 bit per pixel / 8 bits per byte = 4096 bytes), and you'd need to synchronize to the raster and bankswitch at specific scanlines. In fact, you'd have to switch twice: once at the end of a VRAM page and again 128 lines down at the end of the next page. Unless you want to sit in a loop and burn 14400 cycles that could otherwise be used for rendering text, you need two events that can be triggered on separate scanlines. As there is only one sprite 0 hit, and the 9 sprites on one scanline bit is complicated to use given bugs in the PPU's sprite evaluation logic, the most obvious way to do this is with MMC3 or some other board with an IRQ, but mappers with an IRQ also tend to use CHR ROM.
Quote:
EDIT: I even got the math wrong. If using 1-bit mode 256 bytes would be enough to represent a full 32-tile column.
Correct. The VWF engine that I'm working on does just this.
Quote:
So we could scroll 60 lines in a second! 2 screens in a second, you can't get any faster than that! Of course, provided you can compute the 32 tiles in 1 frame. I think it's possible.
Even when sitting in a loop to find the (highly variable) times to bankswitch? Or were you planning on showing only a 16-line-tall window to use only 4 KB of CHR RAM?
I'd suggest making page-down and page-up the scrolling primitives, allowing the time to bankswitch to become much more predictable.
Yeah, I didn't think about the case when you have to switch twice. A static screen would need only 1 switch, but in this case, the reader does scroll.
I know that the 9 sprites in one scanline flag should not be trusted, but isn't there a specific situation it was verified to work? I know it behaves differently depending on the sprites you use and all, but there must be one specific setup that is verified to work, otherwise we should just stop naming the damn flag and consider it an unused/unknown bit...
Hey, I'm not working on this. At least not right now, I'm just seeing the possibilities. It's fun. Maybe I will give it a shot some time, but I'm already working on too many projects now.
You're right. PAGE UP and PAGE DOWN would work ok.
tokumaru wrote:
I know that the 9 sprites in one scanline flag should not be trusted, but isn't there a specific situation it was verified to work?
It has to do with the entry following the 8th entry. As I understand it, a 9th sprite in that entry or in a multiple of 4 entries after that. But then it's still a female dog to set up properly.
Quote:
Hey, I'm not working on this. At least not right now, I'm just seeing the possibilities. It's fun. Maybe I will give it a shot some time, but I'm already working on too many projects now.
But I am working on it. In fact, I have been looking into so-called "huffword" text compression for this project, which tokenizes the text and then entropy codes the token stream.
Quote:
You're right. PAGE UP and PAGE DOWN would work ok.
I need verification of the scrolling requirements from the original poster before we can assume this for sure.
tepples wrote:
But I am working on it. In fact, I have been looking into so-called "huffword" text compression for this project, which tokenizes the text and then entropy codes the token stream.
Cool! I thought about the "tokenizing" part, but not the huffman part. It may end up using a lot of memory, huh? Is the avaliable memory enough?
Quote:
I need verification of the scrolling requirements from the original poster before we can assume this for sure.
Well, since you'll be needing a lot of memory to hold all the text you might as well pick MMC3 as a mapper and "split" the screen twice.
How about good old fashioned pucrunch?
Dwedit wrote:
How about good old fashioned pucrunch?
Pucrunch is just an LZ77 coder. (What Pasi Ojala calls "RLE" is just an alternate encoding of LZ77 matches at distance 1.) How well does pucrunch do with random access to a given 1 KB of data within a file? And how much efficiency does it gain vs. the loss in speed from a bit-oriented format?
Tokenization has the benefit of easy random access.
As for memory, "canonical" Huffman codes are comparatively cheap to represent, and bit->token decoding and token->character decoding can probably be done in separate banks.
I've only skimmed this thread, but had an idea that might help with handling proportional font rendering. If this is being used on a handheld device, you could display everything rotated 90 degrees, so that you view the screen in a vertical orientation like a page. This would make each byte of tile data a vertical strip rather than horizontal, eliminating all the bit shifting when rendering a proportional font. Maybe this has already been discussed.
Very intersting discussion. I didn't think it was so complicated to developpe a simple text reader in NES. I thought that the NES language was a kind of Basic, like on the old TV-computer of the 80's (I had a Thomson Mo5...).
I think a vertical orientation could be a good solution too.
A simple BASIC-style reader with a fixed-width font (i.e. 8x8 pixels per character) is easy. One with proportional fonts pushes the NES hardware since it requires so much bitmap storage. If I can figure something out, I'm going to try a quick implementation.
blargg: You might not want to duplicate the work I've already done.
This is what I have so far.
I got an almost full-screen bitmap display technique working on my NES using an MMC1 (to provide a second nametable). I ran into a snag near the end of implementation that reduced the active area by 8 pixels, due to not being able to scroll to X=256. I didn't have any 8-pixel-high TrueType fonts for my Mac, so I threw together some random images to use as a test:
That's how it would look on an emulator that didn't do any aspect ratio correction or pixel expansion, which I'm assuming will be the case for a handheld device.
nes_bitmap.nes
The timing is fairly loose, the above is just a general demo that the idea would work.
The pixels are stored in VRAM in a nearly unbroken fashion. The image is rotated 90 degrees clockwise, so you must turn the screen 90 degrees counter-clockwise. If it's a handheld, this puts the joypad at the bottom where you can use it to change pages. Using this orientation, the source image is mapped to VRAM as follows, with VRAM locations specifies as addr.bit:
Code:
col 0 ... 127 128 ... 239
row ----------------------------------------
0 0.0 1.0 ... 127.0 4096.0 ... 4207.0
1 0.1 1.1 ... 127.1 4096.1 ... 4207.1
2 0.2 1.2 ... 127.2 4096.2 ... 4207.2
3 0.3 1.3 ... 127.3 4096.3 ... 4207.3
4 0.4 1.4 ... 127.4 4096.4 ... 4207.4
5 0.5 1.5 ... 127.5 4096.5 ... 4207.5
6 0.6 1.6 ... 127.6 4096.6 ... 4207.6
7 0.7 1.7 ... 127.7 4096.7 ... 4207.7
8 128.0 129.0 ... 255.0 4224.0 ... 4335.0
9 128.1 129.1 ... 255.1 4224.1 ... 4335.1
10 128.2 129.2 ... 255.2 4224.2 ... 4335.2
11 128.3 129.3 ... 255.3 4224.3 ... 4335.3
12 128.4 129.4 ... 255.4 4224.4 ... 4335.4
13 128.5 129.5 ... 255.5 4224.5 ... 4335.5
14 128.6 129.6 ... 255.6 4224.6 ... 4335.6
15 128.7 129.7 ... 255.7 4224.7 ... 4335.7
...
255 3968.7 ... 4095.7 8064.7 ... 8176.7
My main aim was to make the VRAM format easy to render an 8-pixel high proportional font to. With the above layout, the only special case is when a character crosses the boundary near the middle of the screen (columns 127 and 128). When building the bitmap, the VRAM address only needs to be reloaded twice per line.
The first 8 palette entries are set as follows: black, white, black, white, black, black, white, white. This allows the attribute bits to select which of the two 8x8 images to use in a character. I filled the nametables with the following tile indicies (now using the normal NES screen orientation), where x was a junk value:
Code:
248 240 ... 8 0 - 240 232 ... 8 0 x
248 240 ... 8 0 - 240 232 ... 8 0 x
249 241 ... 9 1 - 241 233 ... 9 1 x
249 241 ... 9 1 - 241 233 ... 9 1 x
...
255 247 ... 15 7 - 247 239 ... 15 7 x
255 247 ... 15 7 - 247 239 ... 15 7 x
248 240 ... 8 0 - 240 232 ... 8 0 x
248 240 ... 8 0 - 240 232 ... 8 0 x
...
253 245 ... 13 5 - 245 237 ... 13 5 x
253 245 ... 13 5 - 245 237 ... 13 5 x
I enabled vertical mirroring and filled the left screen's attribute table with $00 and the right with $55. In the NMI handler, I toggle the horizontal scroll every 8 rows between 0 and 248. This causes odd rows to use palette #0 and even rows to use palette #1. Just before scanline 128, I switch the background pattern table address to $1000 by writing to PPU $2000. Then the above process repeats as before, using the second pattern table.
The code could be simplified to just change the pattern table address in the middle of the screen and use an attribute table that alternated between palettes #0 and #1 each pair of rows, but this would complicate the VRAM layout. If the original was 01234567, where each number represents 8 bytes of data, this scrambled layout would be 01324576. It would complicate rendering fonts. I haven't written any font rendering yet, so the complication might be simple to deal with. This would solve the problem with horizontal scrolling and eliminate the need a special mapper beyond having CHR RAM. If the font data could be rendered to a temporary 256-byte buffer, then copied to VRAM, this would work fine, but would that slow it down too much? I need to see how slow font rendering is.
Any ideas of working around the scroll problem? Or about what font rendering will entail?
The device's resolution is 640x480 according to this page:
http://www.yaka88.com/Product/PDVD-8088.html
I tried the alternate version that only needs to switch pattern tables in the middle of the screen and I think it'll work better. It gives the full 240x256 image and requires only one timed PPU write in the middle of the frame.
nes_bitmap2.nes
It'd be simpler to render the font into a 240-byte temporary buffer than try to write it to VRAM using either way. Copying 32 of these 240-byte buffers to VRAM using a fully unrolled loop would take 240x32x8 clocks per byte = 61440 CPU clocks = ~1/30 second and use only 1.5K of the ROM. So the only advantage of the original layout is that it might shave 1/30 second off changing pages, which is insignificant compared to what the font rendering and decompression time will likely be.
As for font rendering, if there was only one font available, the text could be pre-wrapped by the encoder/compressor program, freeing the reader from handling that. I'm going to try a quick text rendering implementation and see if it's really slow.
UPDATE: Text rendering and wrapping turned out to be plenty fast; it can flip through about 4 pages of text per second. This version lets you read the GNU General Public License by pressing A to go to the next page (13 pages in all). The source text isn't preprocessed in any way, and the reader wraps lines during rendering.
nes_book.nes
This is what it might look like on a device which expanded the NES image to 640x480 using bilinear filtering:
I think I can turn on the left-hand 8 pixel PPU blanking and smoothly scroll text up the screen without any delays (won't know for sure until I try it).
The only requirement of this is CHR RAM (and that seems pretty hard to get around). When the display is enabled, you lose about 50% of the CPU time, but you can otherwise run code that polls the joypad, plays sound, etc. And this
has been developed on my NES, even though it'd be pretty impractical to turn your TV on its side.
UPDATE 2: Now it smoothly scrolls each page. I think plain switching is fine, but this looks cool (this is just a fun hack, after all).
nes_book_scrolling.nes
I have tested the nes_bitmap2.nes file. On my emulator the picture is like your, but on my PDVD it give me that :
What about nes_book and nes_scrolling_book? Do you know how compatible the NES emulator is in general? As in, name some games that work properly on it.
I have tested
nes_book : black screen with nothing else
nes_scrolling_book : The PDVD can't launch it at all...
This product is sell with around 300 NES games on a disk. Exemple of games:
1942, 1943, Adventure Island, Bomber man, Super Mario, Tetris, Arkanoid, burger time, Donkey 1 to 3, Exerion, Golf, millipede,othello, pacman, popeye, tennis, iron fighter, majiang 2, china chess, king knight, puzzle, mickey, buggy pop, pyramid, mteal gear, card game, maze, circus, star gate, pacland, baseball, elevator, gunsmoke,route, sasa, lunar ball, gambling, gradius, binary land, arabian, dhexbian.... and more.
I have downloaded some games and demo on internet to test it with my usb key on the PDVD and it's ok.
Game furnished with the PDVD are on a VCD. There is a VCD menu to choose games. On windows, when I open the VCD with explorer I have that :
Games are in this folder :
You can see that game have a .bin extension, I suppose it's for VCD system. I have copied a file on my hard drive, rename the extension with .nes and try to open it with emulator (jnes and nesten) and it doesn't work (can't open).
Informations given by Nesten :
But I can play .nes game and demo downloaded on internet (and nesdev).
Does it even run Zelda or Metroid, or other games with no vrom?
I suspect the problem may be due to the fact that you aren't disabling rendering on powerup. The demo runs in my emulator on powerup, as well as on a frontloader, but upon performing a soft reset in my emulator (or a top-loader or Famicom) it gets completely garbled.
My reader will not require rotating the screen. Once it is working, it should work on any emulator that can handle mappers similar to UNROM (
see list). At least 1943 and Gunsmoke appear to be listed.
What I'm dying to know here is how you guys plan on setting up your progs to allow for the loading of txt files. From what I'm seeing, the text has to be hardcoded into the .nes file, right? Exactly how useful would that be?
Hey heres a wicked idea for a possible application, a monthly or quarterly nes homebrew news/fanzine published in nes format. I realise the internet is a much more viable and useful publishing medium, but i would happily download and read such a zine for the pure novelty and coolness of it.
Anyone else have any ideas on how this could be used if they release the source?
I'm guessing someone could always make a program that injects one or more text files into a 512k NES ROM image using a PC program.
tepples: I changed it to use the DMC IRQ for the mid-frame pattern table switch. Now it doesn't have any wait loops, so it uses very little CPU time. The variability of the DMC IRQ is compensated for by repeating the 16 rows above the switch in the bottom of the second pattern table, allowing the switch to occur anywhere between scanlines 112 and 128.
nes_book_scrolling2.nes
Quietust: This is just a tech demo, not a complete program. I've added the standard init code now and used my devcart's special test-at-reset and test-at-powerup functions to ensure it's not depending on the devcart environment. Any other peripheral issues I must know about?
As for the font's compact nature, it was something I made for a Tandy 102-based word processor a while back, aimed at fitting as much text on screen as possible. It might be better to use a less-tight font.
Quote:
What I'm dying to know here is how you guys plan on setting up your progs to allow for the loading of txt files. From what I'm seeing, the text has to be hardcoded into the .nes file, right? Exactly how useful would that be?
If the device has a filesystem and allows reading of text files directly, there's no need for this NES-based reader. If not, there's no way the NES program could access the filesystem without writing custom software for the device, and if you're doing that, you might as well write a native text reader. If it doesn't read text files, just use a PC program to package the text with the NES ROM and then pretend that .nes files are .txt files on the device.
francois: Have you verified that the NES games included with the device aren't modified or "trained" to work with around emulator limitations?
I have tested nes_book_scrolling2.nes, PDVD can't launch it... (when I select the game, just a black screen a fraction of second, and come back to the file selector of the PDVD. At least with nes_bitmap I hade something wrong, but something))
I have tested Zelda 1 and Metroid, it's working great. I take these two games here :
http://www.theoldcomputer.com/Libarary' ... ummary.htm .
blargg wrote:
francois: Have you verified that the NES games included with the device aren't modified or "trained" to work with around emulator limitations?
My device play regular rom, I can take a rom on internet and play it on my PDVD. But I can't take a file on the VCD I have with the PDVD for playing on my computer, like I explain in my last post. So I don't think there is emulator limitation.
My PDVD doesn't give me information about the emulator. I know the "brain" Chip is a Sunplus SPHE 8281A. The file system doesn't show long file name, I don't know if it's important for you.
Perhaps there is .nes file for testing configuration or extract the name of the emulator or take other informations for testing ?
How many bytes is the ROM file on the VCD for, say, the original Super Mario Bros.?
Two files, 32768 and 8192 bytes, with a third file describing the mapper: separate files for PRG and CHR ROM, much as seen in Pasofami
One file, 40960 bytes: PRG and CHR ROM concatenated or CHR and PRG ROM concatenated
One file, 40976 bytes: More than likely a 16-byte header, PRG, and CHR, in that order, and more than likely in the format initially defined by the iNES emulator
The last demo (nes_book_scrolling2) displays sideways in FCEU for me with some text cut off.
Tepples, in the VCD, .nes file seem to be encapsulated into .BIN file, so I can't know about version like that.
But, I have downloaded a Mario bros .nes file of 40 976 byte and it's work. (" likely a 16-byte header, PRG, and CHR, in that order, and more than likely in the format initially defined by the iNES emulator")
Morever, I have tested this file :
http://nesdev.com/scroll.zip ( a croll demo with source ) . It doesn't work on my device.
I hope it can help.
I'm guessing that means Battletoads also doesn't work?
Dwedit wrote:
I'm guessing that means Battletoads also doesn't work?
Very good! Anyway, francois have you run Blargg's series of NES test roms on your device? That might give us an idea of what works and what does not on that emulator.
Like I explain, all the test .nes file of Blargg work on my PC emulator, but no one work on my device.
I have tested maybe 50 rom from this site :
http://www.theoldcomputer.com , and all games that I have tested work.
I have just tested Battletoads (what a great game !), it's working.
Worst case is that it uses the MD5 hash of the ROM to enable a trainer. I'll see if I can make a simple test ROM that should display at least something.
Does it run
Tetramino?
I have tested tetramino.
On my PC emulator, only the ntsc version work (other there is your message "... make for ntsc console only...")
On my device, the two files do "Region coding failed..." (your message)
Which means your emulator's timing is way off from that of a real NES. The timing of Tetramino's region detection was adjusted for Nintendulator 0.950, which is known to behave like an NES in 99.44% of cases. We may have to approach this not as an NES programming project but as a really-bad-famiclone programming project.
It's a famiclone, a bad one I don't know, emulators are free, so why take a bad one ?
Today nobody has a NES consol at home. But some people have PC, Linux or Apple emulators, mobile phone, DVD player, GP2X, PS2, etc...
If the emulator of the PDVD is a very bad one and if the text viewer can work on it , it's mean it can work on all system, no ?
francois wrote:
It's a famiclone, a bad one I don't know, emulators are free, so why take a bad one ?
Well, even if they based their emulator on some open-source one from the net, porting it to other platforms may not be a trivial task.
Quote:
If the emulator of the PDVD is a very bad one and if the text viewer can work on it , it's mean it can work on all system, no ?
Not really. In this case, "bad" could mean "forgiving", meaning it will let go on things that the real system wouldn't (bad timing, for example). So, the fact that you have a "good" emulator does not mean it will run all the stuff that runs on the "bad" emulator, simply because they are different enough for one to be called "good" and the other one "bad". And "different" is practically the opposite of "compatible".
francois wrote:
Today nobody has a NES consol at home.
That's not exactly true. Pretty soon, I will own 6 systems that can play NES/FC games. 3 original NESes, 2 Yobo Famiclones (1 is 60 pin, and one is 72 pin), and I will soon be the owner of the original famicom. So yeah, a lot of people have NES consoles.
Celius wrote:
So yeah, a lot of people have NES consoles.
Somebody have a lot of NES consoles.
So, it seem normal that an emulator play with one simple chipset can't be 100% compatible with all the parameters, variable, etc... of the NES langage. For me, it's a miracle that this device can play all the nes rom game that I find on the net.
I hope that it's possible to do this usefull tool. Thank you for all
Other than DVD-Video and famiclone, what does this device play? Does it play JPEG, BMP, GIF, PNG, MPEG-1, VCD, or anything else?
The PDVD can read every kind of media : Support CD DVD-R/-RW/+R/+RW, files from usb, sound in MP3 and WMA, CD-audio, video in DivX 3, 4, 5, 6 , XdivX, WMA, BivX, images in JPEG, VCD and SVCD, CDG (karaoke).
(this gem cost around 200$, I love it !)
spec. from the factory (Aude technology) :
¡¤Driving active matrix 8¡± inch Diagonal Wide-screen TFT LCD Monitor for big screen excitement
¡¤6 IN 1, DVD, TV tuner, FM Radio, Game, USB, MPEG4
¡¤Analog TV receive 3 system, directly support PAL/ NTSC/ SECAM
¡¤FM receive (76MHZ~109MHZ), FM output, wireless link to car audio.
¡¤Support MPEG4 file, DIVX4.X, or DIVX 5.X
¡¤Support 8 bit NES Game disc playing. Down load 8 bit game file (*.NES), put it into CE-R or USB disc.
¡¤Optical digital output for DTS & Dolby Digital AC-3 video
¡¤Built-in audio of 5.1 sound channels out
¡¤Virtual Surround Sound ( V. S. S ) output.
¡¤Rechargeable Li-ion battery
--------------------------------------------------------------------------------
¡¤New Functions:
Play DVD, MPEG4, VCD, SVCD, CVD, VCD, CD, JPEG,MP3, DVD+ R, DVD ¨CR, DVD-RW, DVD+ RW,CD-R, CD-RW
Support MPEG4 Home theater video Platform(680 x 480 resolution)lution)
Full functions, Slim size remoter for easy operations and convenience
Built-in Stereo speakers for great sound just about anywhere
Normal (4:3)/ Wide (16:9)/Zoom Screen Selector lets you adjust the picture size. /16£º9/ZOOM
--------------------------------------------------------------------------------
¡¤Audio:
Optical output for DTS ® and AC-3® Dolby Digital ® Surround Sound allows for amazing home theater sound quality
Virtual Surround Sound for theater-like experience
96KHZ/24-bit Audio D/A converter for enhanced system flexibility digital audio out
On-Screen Menu lcons to help guide operation
--------------------------------------------------------------------------------
¡¤Video:
Horizontal definition 500 lines, image resolution: 640 X480 X RGB pixels
27MHz/10-bit Digital video-out (optical) for enhanced system flexibility
Still picture display (I/P/B) freezes an image to allow for precise picture quality adjustment
Auto switching Field/Frame still for added versatility.
Frame advance (Forward & Reverse) for incredible control
--------------------------------------------------------------------------------
¡¤Operating Instructions:
Twin laser for DVD/CD Playback
Chapter Preview, Standard remote control
Hi-Speed Smooth Motion Scan: 5 Speed up to 100 Speed allows crystal clear scan quality while locating desired locations on a disc
On-Screen Menu Icons to help guide operation
Using high CPU, full-functions Chinese/English language control
Automation saving for screen
Standard Audio & Video line output, connect to TV or any audio amplifier
Signal system: PAL/NTSC/SECAM , easy system shift
Rechargeable battery, about 120--180 minutes of Playback with included battery pack
--------------------------------------------------------------------------------
¡¤Standard Accessories£º
Audio/ Video Cables
CATV Cable
Remote Control
AC/DC adaptor
Car power adaptor
Rechargeable Battery Pack
Headphone
Game Handle
Installation package
User¡¯s manual
--------------------------------------------------------------------------------
¡¤Specifications:
Signal system: PAL/ BG/DK/ I, NTSC/M, SECAM/BG/DK/L, AUTO
Video format: DVD: format, Horizontal definition more than 500 line, image resolution: 640 X480 X RGB pixels
TV Frequency: VHF: 48.25~423.25MHZ, UHF: 431.25~855.25MHZ
FM Frequency: 76MHZ~108MHZ
Power Source: AC Input 100~240V, 50Hz/60Hz Output DC 13.8V
Power consumption: <12W
Dimensions (LX W X H): 225 X 165 X 46 mm
Weight: 0.93 KG
Wait... the device OFFICIALY plays NES games downloaded more or less ILEGALLY on the NES ? That's a nonsense ! Or... is that device sold by Sony ?
No one said it was official. Those chinese pirates do all kind of crap. They are the pirate kings. I'm not surprised they put so much in this one device.
Wow, they are really strong !!!
I wouldn't be able to make a device emulating NES games myself, even if the NES is most probably the device I know the more about. It is a shame that they're called pirates, its kind of true for the real industry tough.
If it supports JPEG slide shows, then an easier way to do e-book would be to make a program that converts HTML using a CSS paged media format into a CBZ file. (A
CBZ file is a PKZIP archive containing JPEG images, and
CSS @media projection is similar to @media handheld or @media tv but without scrolling.)
I would have prefered a NES text viewver, with possibility to have an index and other tool. And I like funny things.
Thank you to have tried.
I'm back on the task of making a real-NES text viewer, without any special accommodation for faulty emulators built into DVD players (sorry francois) and without screen rotation (because among Nintendo hardware, only the VS Unisystem has the capability of rotating the screen, and that's too rare). But I'm having a little trouble optimizing the rendering code. Even when I shift glyph patterns with an unrolled loop based on Duff's device, I can't always get one 56-character line of text to render in one frame, and that's a hard thing to deal with if I have to use sprite 0 for bankswitching. Is anybody interested in looking at my code to see what's going wrong?
EDIT:
Latest code |
Screenshot
I had a go at the code and made a lot of changes (and enjoyed using ca65). Here it is, including a ROM built from it:
blargg_vwf_003.zip
I sped the glyph rendering up somewhat. The original's image appeared after 29 frames, and after my changes it appeared after 21 frames, so it's at least 28% faster. I was hoping for more speed, but the bit shifting really costs a lot. I ended up writing 8 separate render loops for each of the bit alignments. I was able to come up with lots of bit shifting tricks to make most of them pretty quick. One difference is that is clears to the right of a glyph, so you can't draw text from right-to-left, for example. This simplified the code and eliminated the need to clear the entire line in advance.
After that worked, I switched to using the sprite overflow flag ($2002.5) instead of sprite #0 hit, allowing removal of the borders. Then I put the sprite overflow polling loop in an IRQ handler and had it fire mid-screen using the DMC. With these changes, display is all being done via interrupts, allowing the mainline code to do anything without having to manage the pattern switch mid-screen.
I added a flag to have the NMI routine blit a line of text/graphics to the screen during vblank and changed the text rendering to draw the lines as they are complete, so you see them appear one at a time on screen. One line appears per frame, so the bottleneck there is vblank time (though I guess you could end the frame early to get more vram access time).
I couldn't help changing the code style a bit and putting the bitmap screen handling in a separate module, since it's logically distinct from the variable-width font rendering. You could use the bitmap screen module to do graphics or text using your own font routines. Also you can specify the foreground and background colors in X and Y when initializing the bitmap screen.
I tested it on my NES to get the overflow flag timing fine-tuned. I hope this new sprite overflow timing is used instead of sprite #0 hit, because it would finally justify enabling sprite overflow calculation in my emulator (Bee 52 is the only thing I've found to use it). In any case, use whatever of my changes you like and toss the rest. The changes are orthogonal so you should be able to pick and choose without mich difficulty.
blargg wrote:
I tested it on my NES to get the overflow flag timing fine-tuned.
How fine-tuned?
It works in my emu... I have the sprite overflow flag set up to be as described on the wiki. If it is off by one or two cycles, would the display distort? or is it more of a loose timing mechanism just so you can get around the right area?
I'm glad to see something finally testing the overflow flag. I wasn't sure my implimentation was working because I didn't really have anything to test it on (I don't think Bee52 really strains it that much). Seeing this working was kind of a load off =)
Very impressive, btw
Quote:
It works in my emu... I have the sprite overflow flag set up to be as described on the wiki. If it is off by one or two cycles, would the display distort? or is it more of a loose timing mechanism just so you can get around the right area?
Probably not very fine-tuned because I made a quick fix just after I posted it that made it much less critical. I'll have to write a test ROM for sprite overflow sometime (including the crazy behavior documented on the wiki). Start a new thread if you want to discuss it further or encourage me to write a test.
blargg wrote:
I had a go at the code and made a lot of changes (and enjoyed using ca65). Here it is, including a ROM built from it:
blargg_vwf_003.zipWow thanks.
Quote:
I sped the glyph rendering up somewhat. The original's image appeared after 29 frames, and after my changes it appeared after 21 frames, so it's at least 28% faster.
I'll take a look.
Quote:
One difference is that is clears to the right of a glyph, so you can't draw text from right-to-left, for example.
Ouch. There goes the internationalization. If my code can't write in Hebrew or Arabic, then the terrorists have already won
Quote:
After that worked, I switched to using the sprite overflow flag ($2002.5) instead of sprite #0 hit, allowing removal of the borders. Then I put the sprite overflow polling loop in an IRQ handler and had it fire mid-screen using the DMC.
There goes the ability to play music while reading text
Quote:
I added a flag to have the NMI routine blit a line of text/graphics to the screen during vblank and changed the text rendering to draw the lines as they are complete, so you see them appear one at a time on screen.
Figures.
Quote:
so the bottleneck there is vblank time
As long as it draws faster than one can read...
Quote:
I couldn't help changing the code style a bit and putting the bitmap screen handling in a separate module, since it's logically distinct from the variable-width font rendering.
Thanks for the refactoring ideas.
Quote:
I tested it on my NES to get the overflow flag timing fine-tuned. I hope this new sprite overflow timing is used instead of sprite #0 hit
Compatibility with NES is of primary importance, but compatibility with other existing emulators is also important (to avoid harassment from people who don't have the right kind of computer or right kind of OS to run Nintendulator).
Quote:
because it would finally justify enabling sprite overflow calculation in my emulator (Bee 52 is the only thing I've found to use it).
I'm guessing it's not commonly used because it may trigger prematurely if four or more game characters (each 16 pixels wide) wander onto the same line.
Quote:
In any case, use whatever of my changes you like
I'll take that as a license.
Quote:
The changes are orthogonal so you should be able to pick and choose without mich difficulty.
Cherry picking is fun
Just tried it on my CopyNES, and it looks nice. No timing glitches are evident, and all of the text is readable (except for the top ~6 scanlines which aren't visible on my TV tuner, and the top 8-10 and left 8-10 which aren't visible on my composite monitor).
Quote:
There goes the ability to play music while reading text.
DMC-less music will play fine (though you might need to let the IRQ and NMI handlers know which channels it should enable, since it current writes $1F and $0F to $4015).
Quote:
Compatibility with NES is of primary importance, but compatibility with other existing emulators is also important (to avoid harassment from people who don't have the right kind of computer or right kind of OS to run Nintendulator).
You could always switch back to the sprite #0 hit and poll for that in the IRQ handler, if sprite max isn't handled properly by common emulators. I put 9 sprites in a row to be sure it wasn't relying on the pathological behavior when the sprite after the 8th doesn't trip the overflow. Surely Nestopia handles the sprite overflow flag properly.
I forgot to mention that I flipped the source font data vertically to allow using a decrementing index to save 2*8 clocks for each glyph rendered.
I'm now writing some scripts so I can use ca65 as easily as my other assembler (hit F4 to run source from current window on NES). If only I could find the cause of the :+ feature being broken (I fixed some problem with I think :- a while back on my source tree).
How about just using MMC3? Then you don't need polling loops, and get DMC.
Dwedit wrote:
How about just using MMC3? Then you don't need polling loops, and get DMC.
On which board?
- TGROM: Only three games games used it, namely Mega Man 4, Mega Man 6, and Ninja Crusaders.
- TQROM: Only 128 KB of PRG ROM, limiting the maximum length of a book.
Anyway, I adapted blargg's version of putTile with the following changes:
Remove 'eor' instructions (+6 cycles/character)
- Replaced eor @temp/rol a with lda @temp/rol a/and #
- Extra and instruction slowed it down by 2 cycles per row for 3 out of 8 cases.
Restore OR semantics (+32 cycles/character)
- Required "Remove 'eor' instructions"
- Extra 'ora' instruction slowed it down by 4 cycles per row.
Unflip tile data (+6 cycles/character)
- Replaced inx/dey with dex/dey
- Replaced txa with txa/adc #7/tax/adc #1
- Now x counts down from x+7 to x+0
Prepare for page alignment reads (+4 cycles/character)
- Required "Unflip tile data"
- Replaced txa/adc #7/tax/adc #1 with stx @temp/txa/adc #7/tax/ldx @temp
Page align reads (-7 cycles/character)
- Required "Unflip tile data"
- Replaced adc #7 with ora #%111
- Removed -1, -2, -3, etc. from lineImgBuf accesses
- Reclaim 1 cycle per row from garbage reads in 7 out of 8 cases
Skip spaces
- In vwfPuts, skip calling putTile for character #32
Net effect: +41 cycles/character, or roughly +2 frames. I countered that slowdown by modifying vwfPuts to skip drawing character 32 (space). And now for the same text, I get 23 frames in Nintendulator, compared to 31 frames for 0.02.
Quote:
* TGROM: Only three games games used it, namely Mega Man 4, Mega Man 6, and Ninja Crusaders.
I have the idea that more japaneese games uses TGROM, but I cannot have any exemples in my mind.
I'm taking a bit of a break from ascii->pixels and pixels->video signal to determine the representation of text as a bitstream. Obviously, a straight 8-bit-per-character encoding is right out, as gzip compresses text at 3:1. But plain old Lempel-Ziv compression doesn't work well because there isn't much RAM inside an NES to hold the ring buffer (for LZ77) or dynamic dictionary (for LZ78). Does anybody know what kind of compression was used for answers and questions in Rare's
Jeopardy! games?
If you can figure out what the heck
this file represents, you win an e-cookie.
tepples wrote:
If you can figure out what the heck
this file represents, you win an e-cookie.
It seems to be a list of the distinct words that appear in some text and how many times they appeared. Ordered by number of occurrences and character codes... That's what it seems to me... what is that?
tokumaru wrote:
tepples wrote:
It seems to be a list of the distinct words that appear in some text and how many times they appeared. Ordered by number of occurrences and character codes
Correct so far: it's a frequency table. For full credit, what is "some text"?
Quote:
... That's what it seems to me... what is that?
One thing you can do with a frequency table
tepples wrote:
Correct so far: it's a frequency table. For full credit, what is "some text"?
Well, there are a lot of "Pinocchio"'s in there (464). I'm not really familiar with Pinocchio, but must be some story about him/it. Maybe THE story, but I don't really know how much was written about him/it.
Quote:
Yeah, I know, you can assign shorter codes to the more frequent words. How exactly do you plan on coding the text? Building a dictionary with all the words and assigning codes to them based on how frequent they are? That may work well... Do you have any results yet?
Hell, with only 4127 distinct words, even if you assigned fixed-sized codes you'd get a decent compression ratio, I guess.
Compression is cool! =D
EDIT: Do I get an e-cookie now? =)
Bregalad wrote:
What's an e-cookie ???
I have no idea, but a promise is a promise! =D
tokumaru wrote:
tepples wrote:
Correct so far: it's a frequency table. For full credit, what is "some text"?
I'm not really familiar with Pinocchio, but must be some story about him/it. Maybe THE story
Translation of the original novel by Carlo Collodi without any Disney interference.
Wikipedia tells more.
Quote:
Quote:
Yeah, I know, you can assign shorter codes to the more frequent words. How exactly do you plan on coding the text? Building a dictionary with all the words and assigning codes to them based on how frequent they are?
That's how Huffman coding is normally supposed to work. I may use a second Huffman code on the letters.
Quote:
That may work well... Do you have any results yet?
Hell, with only 4127 distinct words, even if you assigned fixed-sized codes you'd get a decent compression ratio, I guess.
That's what I saw. For
The Adventures of Pinocchio, the dictionary file is roughly 32 KB uncompressed after I take out a lot of the debugging info. Then coding 50051 words with 12 bits per word gives 73 KB or so. The total is 95 KB, compared to gzip's 78 KB.
For a novel about the rehabilitation of a handicapped boy by two of his friends in a Yorkshire garden, which has 98755 words, 5351 distinct, and a 45 KB dictionary. At 12.5 bits/word the wordstream is 150 KB. The total is 195 KB, compared to gzip's 148 KB.
And I still haven't squeezed everything out of it. I'm considering using a so-called
universal code such as an Elias or Fibonacci code, which approximates a Huffman code for data with a
Zipf's law distribution (such as words in a largely isolating natural language such as English) but has a much shorter table.
EDIT: Coding the two novels' word order with the ternary code, one example of a universal code, produces data of 60 KB and 120 KB respectively.
Quote:
Do I get an e-cookie now? =)
the prequel to Pokémon Trozei; click image to accept cookie
A "cookie" is handed out to recognize someone's accomplishment. References:
Google 1 and
Google 2
With your link, anyone can get infinite cookie. Normally, there would be only one for tokumaru. Note that I would aswer just like him if I were here first.
you know, everytime I login on nesdev I get a cookie
Years later, I came back to huffword. I've since learned about a "canonical Huffman" (CH) code, which stores the code as number of words per bit length instead of as a tree. This gives a 7% smaller text than Golomb or gamma without too much more complexity. I managed to round-trip each paragraph through a CH encoder and decoder, though Python is nowhere near the fastest language at bit manip.
Right now, for the longer novel (431 KiB uncompressed), I get an estimated 112 KiB text, a 36 KiB dictionary (of 5,224 words plus a pointer to each word), and an estimated 8 KiB playback code + font data. It doesn't come anywhere near my original hope of getting it down to a 128 KiB UNROM, but then not even Zip gets it that small (160 KiB), though the memory-intensive BZip2 gets it down to 112 KiB total.
One concern is how fast I'll be able to decode this on a 6502. I'll have to go through about three layers before anything appears on the screen: CH decoding of word stream to get indices into a pointer table, chasing pointers to the beginning of each dictionary entry, CH decoding of individual dictionary entries, and finally putting the text on the screen.
Another concern is whether anyone will have the patience to sit through and read a book one page at a time, where each page has about 1 KB of text, on a display that's a lot chunkier than that of a modern smartphone or e-reader. (The active area of my VWF engine's display is roughly 48 characters by 24 lines.) But given that
this exists...
I read Frankenstein on a GBA using Pogoshell one time...
I can't imagine it would be all that slow compared to reading, considering that you can buffer the next page. If someone is a speed-reader, I guess there could be a small indicator sprite to show the load-status.
Also if you used 4 nametables, you could pre-load quite a bit of text and hope they don't read at a constant, really-fast speed, heheh. Likewise, you could buffer ahead several pages into WRAM and still be using the 2 usual nametables.
I'd be really interested in having a text compression program. But I'm sure the texts I would use would be more modest-length, not novels. Speed doesn't matter to me either, if the result is more interesting text, they can wait.
Memblers wrote:
I can't imagine it would be all that slow compared to reading, considering that you can buffer the next page.
If you're talking about decompressing the next page of text and buffering that to be rendered, I'd need to limit each page to 1024 characters, but that would still be doable. I was thinking of doing the decompression during a page-turning animation and then rendering it. But then I realized that
The Secret Garden (my primary test case lately) would probably be over 500 pages.
Quote:
If someone is a speed-reader
Or rapidly turning pages within a chapter to find something specific.
Quote:
Also if you used 4 nametables, you could pre-load quite a bit of text and hope they don't read at a constant, really-fast speed, heheh.
I'd need more than nametables for that. I'm using a proportional font, and thanks to my palette hack (left half of the screen white-black-white-black, right half white-white-black-black), I can fit a full screen of monochrome graphics into a shade under 8 KiB of CHR RAM per page. The only board with more CHR RAM than that is CPROM, and that has only 32 KiB of PRG ROM. The ideal mapper for this, if sticking to Nintendo boards, would be either AOROM modded such that the nametable selection bit also controls CHR A13, or perhaps SGROM with bigger CHR RAM.