Questions about Coleco graphics capacity?

[BladeJunker]

 

Oh, text mode... not 8x8, I guess. Perhaps I'll read the tutorial, then.

You wouldn't happen to have a picture of the system font I could look at for reference and pasting into mockups? I did find which characters are internalized in the tutorial so I can cut those from future character sets but I need something to match the umlauts and such to. I tried searching Colecovision ascii table but couldn't find a complete set and "Colecovision font" just gives me the logo font on the side of the console lol.

[retroillucid]

You wouldn't happen to have a picture of the system font I could look at for reference and pasting into mockups? I did find which characters are internalized in the tutorial so I can cut those from future character sets but I need something to match the umlauts and such to. I tried searching Colecovision ascii table but couldn't find a complete set and "Colecovision font" just gives me the logo font on the side of the console lol.

You can see system fonts when ColecoVision Presents: screen is display

[BladeJunker]

You can see system fonts when ColecoVision Presents: screen is display

I appreciate the idea but I was thinking something more like this. http://www.kreativekorp.com/software/fonts/samples/petme-2vic.png http://i.fonts2u.com/si/mp1_sinclair-zx-spectrum-es-regular_1.png

 

I thought about collecting a bunch of screenshots and stripping them out but was hoping someone might know where they are posted for viewing. Somebody somewhere must have tried displaying the Colecos entire ASCII table on screen at once.

[Kiwi]

ICVGM have the Colecovision font. I will provide a gif for the font graphics.

 

 

I made several different font set. The NES fontset with Guardian Legend lowercase letter. The fontset from Game Gear RPG Defender of the Oasis, and Computer Space/Pong FONT that mimics the 7 segments that the number are displayed.

 

In text mode, you can chose different colors. The colors are set in VDP register which only hold the text color and the border color, so it uses those 2 colors only. No color table is use in this mode.

 

I'm really enjoy looking at your pixel art mockups. It looks really cool!

Edited February 8, 2014 by Kiwi

[BladeJunker]

ICVGM have the Colecovision font. I will provide a gif for the font graphics.

 

fontset.png

 

I made several different font set. The NES fontset with Guardian Legend lowercase letter. The fontset from Game Gear RPG Defender of the Oasis, and Computer Space/Pong FONT that mimics the 7 segments that the number are displayed.

 

In text mode, you can chose different colors. The colors are set in VDP register which only hold the text color and the border color, so it uses those 2 colors only. No color table is use in this mode.

 

I'm really enjoy looking at your pixel art mockups. It looks really cool!

In ICVGM you say, I'm still learning my way around in that. Thanks for the font image.

 

Defenders of the Oasis, I should see if I can get a copy of that. I quite enjoyed Beyond Oasis but I read here Defenders isn't related lol. http://www.hardcoregaming101.net/oasis/oasis.htm#defenders

Who doesn't like a good font? 7 segments like for big font characters? Never tried Computer Space, I see it predates being in Rom form so no MAME. http://www.youtube.com/watch?v=b3BQsCCwo8w

 

So Text mode has color, I thought it might since the text games on TI-99/4A weren't B&W. I should read those PDFs more closely lol, been busy cleaning consoles to sell for my modern Coleco gamepad project and winter is bumming me out so my focus is lacking.

Been looking at ANSI and Chip8 games to see what kind of graphics can be made with basic system characters, they don't look great but they can serve other game needs like for example Dwarf Fortress and its heavy slant towards mostly CPU cost for its AI and simulation needs.

 

Glad you like the mockups, it seems like the Colecovision didn't get a chance to mature graphically like other consoles did with more years over more games so I've mostly concentrated on Graphic Mode 1 rather than going full tilt MSX/ADAM Graphic Mode 2 as much.

My one major complaint about Coleco graphics is mostly poor graphics contrast as things can blend together often, the colors are pale and subtle in brightness value difference so you really have to push hard to get as much contrast as possible with light and dark color pairs(Light Red+Dark Red) with White adding brightness and Black subtracting it.

[BladeJunker]

Well still plugging away at Text mode designs, its kind of like PETSCII in resolution but taller skinnier characters. Did someone make a Text mode editor, I looked around but I haven't found one yet? I'd imagine Text mode is more of an ADAM thing?

Tried to make a General Coleco ASCII extension set to go along the built in font which is like a little bit ANSI, ZX-81, C64, and Odyssey 2 wrapped in one . Helped to look up what the ANSI characters actually are to make the most of the 6X8 blocks, some fonts really butcher certain symbols. After skipping the already existing characters I looked over the DOS ANSI font and stripped out and augmented what I could to better suit generic ANSI rendering of graphics and text.

 

Came across the one color per pattern limitation which proved to be an obstacle at first. To get the Colecovision to approximate ANSI I broke down the list of specialized Char Sets to 5 variants of General, Art, Text, Custom, and ASCII. Mostly the different sets duplicate certain patterns more than others based on the task intended, General set is done(I think?) but still working on the others.

 

After news of color and closer examination of the tutorial I tried coloring the Mario Text mockup which came out similar to ZX Spectrum graphics with the basic addition of colors to the white channel but that kind of felt tacked on so I moved toward ANSI.

 

ANSI was hard to keep straight in drawing, in Text mode I couldn't pass off extra colors per block as sprite overlays. ^_^ It's actually the one mode I'd rather do natively in a Coleco specific editor. I'm certain I have more than a few tech betrayals despite my close inspections but the images should suffice for demonstration for now.

 

ASCII art was kind of coming out poor because of the low resolution and lack of color contrast, can't really do that vague Magic Picture gradient the 80 characters wide displays achieve better. Needed almost B&W type contrast to get the illusion of a cohesive image, had to go very posterized and iconic to get it to read, also tried the 'Line Segment' approach but the characters aren't well suited to it. :\

 

So any thoughts or mistakes I made please tell me, always appreciate knowledge and feedback. Its interesting tech but I just want to make sure I'm not doing things that don't actually work.

 

 

 

 

 

[Pixelboy]

Okay, Um, so... nobody told you that text mode only has two colors for the entire screen? That's the main reason nobody uses it.

[BladeJunker]

Okay, Um, so... nobody told you that text mode only has two colors for the entire screen? That's the main reason nobody uses it.

Lol, looking back at my journey to these mockups, not sure how that happened since Kiwi told me that very fact and some how after I misread the tutorial I went off on this tangent. Oh well most of what I wrote is still true except the color parts. ^_^ The good news is I don't have to make any more ASCII tables now, plus I have space for more characters now without the duplicate patterns.

 

I can roll with this though, probably I'll ditch the third dither shade since at 3X4 pixels blocks its quite spotty at that density, instead I'll do a solid & 50% dither combo instead for the 3rd block pattern set. It should likely look more ZX-81 like in graphics quality, I guess varying the 2 single colors could be interesting, like a Super Game Boy of sorts or maybe like the Dragon 32.

http://www.mojontwins.com/juegos_mojonos/nanako-in-classic-japanese-monster-castle-81/

 

http://www.revival-studios.com/?page=129

 

ASCII art is definitely not going to work well at all in 2 colors except for solid shapes and line segments outlines since I can hardly dither a font character.

 

What can I say, I've been feeling sick lately, probably didn't help my chronic idiocy.

[retroillucid]

Lol, looking back at my journey to these mockups, not sure how that happened since Kiwi told me that very fact and some how after I misread the tutorial I went off on this tangent. Oh well most of what I wrote is still true except the color parts. ^_^ The good news is I don't have to make any more ASCII tables now, plus I have space for more characters now without the duplicate patterns.

 

I can roll with this though, probably I'll ditch the third dither shade since at 3X4 pixels blocks its quite spotty at that density, instead I'll do a solid & 50% dither combo instead for the 3rd block pattern set. It should likely look more ZX-81 like in graphics quality, I guess varying the 2 single colors could be interesting, like a Super Game Boy of sorts or maybe like the Dragon 32.

http://www.mojontwins.com/juegos_mojonos/nanako-in-classic-japanese-monster-castle-81/

 

http://www.revival-studios.com/?page=129

 

ASCII art is definitely not going to work well at all in 2 colors except for solid shapes and line segments outlines since I can hardly dither a font character.

 

What can I say, I've been feeling sick lately, probably didn't help my chronic idiocy.

Your graphics looks great though!

You clearly have some talents

 

Can't wat to see more stuff in Mode2

[BladeJunker]

Okay I think I got Text mode straight now.

 

I guess one question is whether I can invoke a negative image of a character as in switching background and character colors using one pattern? I'm guessing if can invert it would be 'all or nothing' like needing 2 copies to have default and negative characters on the screen at the same time?

 

Pattern table changed some, more semigraphics and less specific icons, any more than 1X1 character it gets hard to justify the space for things that don't get used much. Kept the Giant humanoid and Tall guy just for scale difference in characters. Mashed some icons together and built my Big trees from semigraphics instead.

 

Color contrast and pixel density matters revealed themselves quickly with my choice of Cyan and Light Blue for my RTS revisement. Seems like White+Medium or Dark colors read well, as does any color in the palette on a Black background but combos of light and dark versions of the colors tends to make everything blend together too much when everything shares 2 colors and especially in regions of dithering. Still a nice amount of viable color choices one could toggle between till they found a preference.

 

To retroillucid on Graphic Mode2 mockups, just haven't picked a 'major' subject matter for that yet. Seems like that mode is more ideal for Super Game Module use and that thing is hard to get in a timely fashion, they seem like they are making them at the pace they can but the pre-order list grows as does the wait time with it.

[BladeJunker]

Okay I think I got Text mode straight now.

 

I guess one question is whether I can invoke a negative image of a character as in switching background and character colors using one pattern? I'm guessing if can invert it would be 'all or nothing' like needing 2 copies to have default and negative characters on the screen at the same time?

 

Pattern table changed some, more semigraphics and less specific icons, any more than 1X1 character it gets hard to justify the space for things that don't get used much. Kept the Giant humanoid and Tall guy just for scale difference in characters. Mashed some icons together and built my Big trees from semigraphics instead.

 

Color contrast and pixel density matters revealed themselves quickly with my choice of Cyan and Light Blue for my RTS revisement. Seems like White+Medium or Dark colors read well, as does any color in the palette on a Black background but combos of light and dark versions of the colors tends to make everything blend together too much when everything shares 2 colors and especially in regions of dithering. Still a nice amount of viable color choices one could toggle between till they found a preference.

 

To retroillucid on Graphic Mode2 mockups, just haven't picked a 'major' subject matter for that yet. Seems like that mode is more ideal for Super Game Module use and that thing is hard to get in a timely fashion, they seem like they are making them at the pace they can but the pre-order list grows as does the wait time with it.

[Pixelboy]

Okay I think I got Text mode straight now.

 

I guess one question is whether I can invoke a negative image of a character as in switching background and character colors using one pattern? I'm guessing if can invert it would be 'all or nothing' like needing 2 copies to have default and negative characters on the screen at the same time?

The VDP offers no such inversion feature. You've got 256 6x8 tiles, and that's it.

 

To retroillucid on Graphic Mode2 mockups, just haven't picked a 'major' subject matter for that yet. Seems like that mode is more ideal for Super Game Module use and that thing is hard to get in a timely fashion, they seem like they are making them at the pace they can but the pre-order list grows as does the wait time with it.

Huh, what? What does the SGM have to do with graphic mode 2? Almost all commercial CV games use this mode, and the SGM hadn't been invented yet when they went on sale 30 years ago. There's no valid reason to avoid this mode, unless you're the "I-prefer-the-underdog" kind of guy.

 

Your latest mockups are very nice, by the way. I wonder what Rogue would look like in text mode...

[BladeJunker]

The VDP offers no such inversion feature. You've got 256 6x8 tiles, and that's it.

Darn, had at least one semigraphics set needing that, have to make more cuts or not use certain pattern combos. Thanks, good to know.

 

Huh, what? What does the SGM have to do with graphic mode 2? Almost all commercial CV games use this mode, and the SGM hadn't been invented yet when they went on sale 30 years ago. There's no valid reason to avoid this mode, unless you're the "I-prefer-the-underdog" kind of guy.

No kidding, most of them. Prefer the underdog hmm, no I don't really 'need' the added challenges as less the better, just exploring all the modes. Well I guess I'll just go ahead with Mode2 exploration more so, I wonder what Mode1 is ideal for, Text mode has its obvious advantage? Maybe Mode 1 could support a color version of what I'm doing with Text mode limitations, with sprites it would be easier to approximate ANSI BBS game graphics from the 90s or something like PETSCII?

 

I actually had some era specific movie license concepts that were getting hard to fit ideally into Mode1. Was pushing around Videodrome in a Ghost Trick type side perspective, fewer but detailed sprites for a graphic adventure. http://www.mobygames.com/game/nintendo-ds/ghost-trick-phantom-detective/screenshots

Another one was Porky's, I've seen the unreleased version but I was thinking something more along the lines of a stealth/action game that utilizes all the characters in a Lost Vikings kind of way. Lastly I was thinking about something based on Heavy Metal the magazine rather than the movies as a possibility, figure most of the audience of the Colecovision would be old enough that a game could be made for an adult crowd rather than the watered down HM game Ritual made for mass market.

 

Your latest mockups are very nice, by the way. I wonder what Rogue would look like in text mode...

Well thanks. I think Rouge could play similar to the original, mostly it would be tighter and less visual distance with fewer actual characters on screen. Should work, have to use a straight DOS ANSI pattern table rather than my concept of ideal ANSI, when I started this the full pattern table used by such games did fit into the 256 character limit with room to spare.

[BladeJunker]

I have moved on to Graphic Mode 2 now but thought I post my last things on Text mode, just some conclusions on general use pattern tables.

 

With Semigraphics there is a limited number of combinations for 3X4 pixel blocks, I came up with 10 sets which is kind of like a crude codec of sorts with 5 basic lighting values through dither.

1&5 1&2 2&3 3&4

2&5 1&3 2&4

3&5 1&4

4&5

Had to sacrifice Math Operators and Symbols/Shapes for space, so it's basically language and graphics for that set. Thought about less dither shades but with only 2 colors in the mode every shade seemed useful.

 

Went back and did a Code page 437 table, one with full box graphics and another with just one set since it seems excessive the number they included. Still if anyone wants to try direct porting of ANSI games a full table is possible. Plenty of room left for any sort of generic game icons, I got tired of working out which would get the most use in an Odyssey2 manner, people, planes, tanks? ^_^ Also added a few basic semigraphics that looked like they were missing from the default 437 table.

 

Lastly a Text-centric pattern table, 2X2 character font, inverse copy of default font, and only a few symbols lost or combined for space needs. Managed to trim out redundant sections of the large font since certain parts repeat. Best used for text heavy pages like mock BBS or webpages, in-game newspapers, etc.

 

Thanks for everyone's help, retro hardware is eccentric to say the least.

[Pixelboy]

Well thanks. I think Rogue could play similar to the original, mostly it would be tighter and less visual distance with fewer actual characters on screen. Should work, have to use a straight DOS ANSI pattern table rather than my concept of ideal ANSI, when I started this the full pattern table used by such games did fit into the 256 character limit with room to spare.

Just for fun I made the mockup below. It looks pretty good in text mode, I think. The programmer could borrow a page from Pepper II and have an entire level spread out over 4 screens. There's probably enough room in VRAM to store a level, but the real problem is that Rogue requires a lot of RAM to store all the levels, because the player needs to backtrack to the surface once he finds the amulet in the deepest level.

[Kiwi]

Darn, had at least one semigraphics set needing that, have to make more cuts or not use certain pattern combos. Thanks, good to know.

 

No kidding, most of them. Prefer the underdog hmm, no I don't really 'need' the added challenges as less the better, just exploring all the modes. Well I guess I'll just go ahead with Mode2 exploration more so, I wonder what Mode1 is ideal for, Text mode has its obvious advantage? Maybe Mode 1 could support a color version of what I'm doing with Text mode limitations, with sprites it would be easier to approximate ANSI BBS game graphics from the 90s or something like PETSCII?

Mode 1, I believe is use for system with 4KB of VRAM. It only has 1 pattern table(256 tiles), half a sprite table(32 16x16 sprite pattern or 128 8x8 pattern), one screen data, and 32 bytes for color table that is grouped with 8 8x8 tiles, and of course 256 bytes for sprite aptitutes. ICVGM214 simulates mode 1. Setting up the register to use 4KB of VRAM, leaving 12KB of VRAM for data.

[Tony Cruise]

Just for fun I made the mockup below. It looks pretty good in text mode, I think. The programmer could borrow a page from Pepper II and have an entire level spread out over 4 screens. There's probably enough room in VRAM to store a level, but the real problem is that Rogue requires a lot of RAM to store all the levels, because the player needs to backtrack to the surface once he finds the amulet in the deepest level.

Rogue levels are procedural generated, so you don't need much ram to generate the shape/design of the rooms, just the state of items/enemies in the rooms.

[BladeJunker]

Just for fun I made the mockup below. It looks pretty good in text mode, I think. The programmer could borrow a page from Pepper II and have an entire level spread out over 4 screens. There's probably enough room in VRAM to store a level, but the real problem is that Rogue requires a lot of RAM to store all the levels, because the player needs to backtrack to the surface once he finds the amulet in the deepest level.

Oooh I like that, nice smiley face dude, I want to play it. There's bound to be a way, didn't Pitfall use a polynomial counter to create a bunch of levels in small amounts of memory that it could backtrack through, probably not exactly like Rogue used but a compromise must be possible?

[BladeJunker]

Mode 1, I believe is use for system with 4KB of VRAM. It only has 1 pattern table(256 tiles), half a sprite table(32 16x16 sprite pattern or 128 8x8 pattern), one screen data, and 32 bytes for color table that is grouped with 8 8x8 tiles, and of course 256 bytes for sprite aptitutes. ICVGM214 simulates mode 1. Setting up the register to use 4KB of VRAM, leaving 12KB of VRAM for data.

Oh okay, the smaller amount of sprite space is something I missed, I was too focused on the pattern tables and hadn't considered the sprite space difference between Mode 1 & 2. Well I guess if the game design was light on sprites or required more VRAM for data then Mode 1 is ideal. So more screens or levels would fit better in Mode1 than Mode 2?

 

I think Mode 1 could work for that color ANSI setup I spoke of since it deals with small repetitive pattern tables, not sure how I'd utilize the sprites effectively though. This does help me understand why so many games use Mode 2 now, that is 50% less sprites in Mode1. You've given me something to think about, I guess I'm not quite done with Mode 1 research yet.

[Pixelboy]

Rogue levels are procedural generated, so you don't need much ram to generate the shape/design of the rooms, just the state of items/enemies in the rooms.

Not quite. If there are any unexplored passageways or rooms left behind when the player moves to the next level, then those unexplored portions should be saved and restored as such when the player backtracks towards the surface. So it's not just a question of regenerating a level from a single randomizer seed number.

 

With the premise that a level is divided into 4 screens (like Pepper II) and with a screen surface of 40x20 tiles (2 lines are used for text and 2 more lines are used for edge buffering in my mockup, leaving 20 lines as level rendering space), I have calculated that it's possible to save an entire level layout in RAM using roughly 500 bytes. This doesn't include the position of objects and enemies, which would need to be allocated dynamically on top of those 500 bytes.

 

Under these conditions, and with a limit of 8 dungeon levels for a single game session, the unused portions of VRAM (in text mode) should offer more than enough space to cover Rogue's needs. The only difference is that you wouldn't be able to save your game like in the mainframe/DOS versions. You'd have to finish the game in one sitting. But that was never a problem with Gateway to Apshai, so it wouldn't be a problem with a ColecoVision version of Rogue either.

[digress]

Rogue or the much better "LARN"

 

http://en.wikipedia.org/wiki/Larn_(video_game)

 

used to literally overwrite the levels to disk as you left a level and went up or down. You could reset all levels at the start of the game then the original data files would be overwritten whenever you saved the game

Edited February 21, 2014 by digress

[Tony Cruise]

Not quite. If there are any unexplored passageways or rooms left behind when the player moves to the next level, then those unexplored portions should be saved and restored as such when the player backtracks towards the surface. So it's not just a question of regenerating a level from a single randomizer seed number.

 

With the premise that a level is divided into 4 screens (like Pepper II) and with a screen surface of 40x20 tiles (2 lines are used for text and 2 more lines are used for edge buffering in my mockup, leaving 20 lines as level rendering space), I have calculated that it's possible to save an entire level layout in RAM using roughly 500 bytes. This doesn't include the position of objects and enemies, which would need to be allocated dynamically on top of those 500 bytes.

 

Under these conditions, and with a limit of 8 dungeon levels for a single game session, the unused portions of VRAM (in text mode) should offer more than enough space to cover Rogue's needs. The only difference is that you wouldn't be able to save your game like in the mainframe/DOS versions. You'd have to finish the game in one sitting. But that was never a problem with Gateway to Apshai, so it wouldn't be a problem with a ColecoVision version of Rogue either.

The shape of the map i.e. room layout should be exactly the same in procedural generation so you only need to store the function starting value for each level and then a list of state items for each room, this can include how much you have explored on each level by storing path covered (which is not every square as each move uncovers multiple squares based on line of site and range). Also remember if you have things in lookup tables, if you don't need 256 values you don't need to use all of a byte to store state. But I do like the idea of using VRAM to store things, I should look at doing that more myself. It is surprising the amount of state information you can store in a bit pattern

My current game I am working on has 100 levels, that will only be using 16k of Rom (and no I am not keeping state between rooms, this is just showing how with proper tables and structure you can save a lot of space) without compression. So currently 169 bytes per level, which I could reduce to 144 if I wasn't being a little lazy.

[BladeJunker]

Darn I think I missed something, I didn't realize my color options would be limited like this with only one color per column. Is that how it always is since that is a game changer, I'll have to rethink the pattern arrangement if this is normal?

 

Trying out New Coleco's editor(Mode1) some to get acquainted more with it, I wonder if he's open to some additions to its functionality. I get the feeling he doesn't want to revisit it much.

 

Is the default Coleco font on a Rom or can it be altered, just curious?

 

Anyway just trying out a mostly PETSCII based pattern table, pure ANSI approach of no sprite use but more colorful than Text mode. How does one use multiple Char Sets in this editor, like Mode 1 having up 2 Char Sets and Mode 2 having up to 3 Char Sets?

 

Hmm, can't post Dat files directly so I made it a Rar.

 

Quick question about Multicolor mode, is the sprite space the same as it is in Mode 1 of 128X64 or is it less, I looked for a good hour but couldn't find it?

Petscii_Test01.rar

Petscii_Mode1.rar

[Pixelboy]

 

Darn I think I missed something, I didn't realize my color options would be limited like this with only one color per column. Is that how it always is since that is a game changer, I'll have to rethink the pattern arrangement if this is normal?

What "column" are you referring to?

 

Trying out New Coleco's editor(Mode1) some to get acquainted more with it, I wonder if he's open to some additions to its functionality. I get the feeling he doesn't want to revisit it much.

Daniel's not really around anymore...

 

Is the default Coleco font on a Rom or can it be altered, just curious?

The default ColecoVision text font is part of the BIOS, so it's ROM.

 

 

Anyway just trying out a mostly PETSCII based pattern table, pure ANSI approach of no sprite use but more colorful than Text mode. How does one use multiple Char Sets in this editor, like Mode 1 having up 2 Char Sets and Mode 2 having up to 3 Char Sets?

Mode 1 has 2 char sets? I beg to differ...

 

Quick question about Multicolor mode, is the sprite space the same as it is in Mode 1 of 128X64 or is it less, I looked for a good hour but couldn't find it?

Okay, now I have to ask: Is it really true that you can't define more than 32 sprite patterns in mode 1 on the CV? Because that's certainly news to me. I've never programmed anything on the CV using mode 1, but I have always assumed that the sprite pattern table was always capable of containing 64 sprites regardless of the graphic mode (excluding text mode, of course).

 

Also, can you define what you mean by "sprite space"? That kind of vocabulary is confusing because there are two distinct sprite tables in VRAM, namely the sprite pattern table and the sprite attribute table, and I don't know which table you're referring to when you use the term "sprite space".

 

Also, where does the "128x64" thing come from? I find your posts a little hard to follow, BladeJunker...

[Kiwi]

 

I think Mode 1 could work for that color ANSI setup I spoke of since it deals with small repetitive pattern tables, not sure how I'd utilize the sprites effectively though. This does help me understand why so many games use Mode 2 now, that is 50% less sprites in Mode1. You've given me something to think about, I guess I'm not quite done with Mode 1 research yet.

 

If you were working with system that has 4KB of VRAM, then you would have only half a sprite pattern table to work with. The video chip can be set in 16KB or 4KB mode. The video chip is used in other system like TI-99, SG-1000, and etc. I was thinking why would developer use mode 1 for the Colecovision. If it is set in 4KB mode in Colecovision, then you could use 12KB or VRAM or other stuff.

 

Anyway, the Colecovision BIOS routine "CALL MODE1" will preset information to the video register. Colecovision Mode 1 shared the similar memory map that MODE 2. I think the only difference is the color table, which is 32 bytes. Also, it allows full set of sprite pattern, 256x64. If it is in 4KB mode, then the sprite pattern is in half 128x64, which is 1KB. Sorry for the confusion.

 

Only 1 pattern table allowed in this mode.

Edited March 1, 2014 by Kiwi