What is the 7800 really capable of?

[Zap!]

Someone needs to make a 7800 homebrew of SMB to settle this.

[DracIsBack]

Someone needs to make a 7800 homebrew of SMB to settle this.

 

That speaks to the NES. Bring on SPACE HARRIER!

[Crazyace]

Someone needs to make a 7800 homebrew of SMB to settle this.

I'll make a demo when I finally finish with the 8 bit pacman demo

[Zap!]

Someone needs to make a 7800 homebrew of SMB to settle this.

I'll make a demo when I finally finish with the 8 bit pacman demo

Awesome, can't wait!

[A Sprite]

Could the 7800 handle a current title?

 

No, seriously. I'm looking at Geometry Wars: Galaxies (DS), numb thumb barely raised, waiting to unpause for another round...and all I can think about is sprite counts.

 

The 7800 is the only 8 bit that comes close to approaching that kind of blinding madness...

 

How close could it get?

 

Can the 7800 compete with X-BOX live?

[Godzilla]

I think scrapyard dog already answers the nes smb question. To me, the real question is, could the nes pull off anything close to 7800 robotron? I think the ol 78 is capable of much more than the nes.

[atarian63]

Oh, I don't know `bout that- the NES did pound the superior SMS in sales, didn't it? Don't forget how much effort into expanding the 2600's abilities there was, but the other systems from that time? Not much.

 

But the X-Box 360 under the control of the Tramiels likely couldn't have beaten the RCA Studio 2. So what chance did the 7800 have, even if (this occurred to me years later) the whole 1983 7800 idea wasn't doomed from day one?

Yep,

I have had a retail store for over 20 years,it amazes me that the best item seldom wins, the good enough or cheapest usually does.

[Crazyace]

Could the 7800 handle a current title?

 

No, seriously. I'm looking at Geometry Wars: Galaxies (DS), numb thumb barely raised, waiting to unpause for another round...and all I can think about is sprite counts.

 

The 7800 is the only 8 bit that comes close to approaching that kind of blinding madness...

 

How close could it get?

 

Can the 7800 compete with X-BOX live?

 

Not sure - it can try... but the DS is way more powerfull than the 7800 ( it's more powerfull than the Jaguar ) and it's throwing around the kind of particles that would make Jeff Minter proud

[vdub_bobby]

Thus the 7800 may technically be more powerful, but it's the NES that was practically more powerful.

Most of what you say is true, but the 7800 is most definitely NOT technically more powerful than the NES.

Not sure what gives you that idea. The 2600 isn't that hard to program for if you're making straight-up use of its facilities. It's only when you push it beyond its designed facilities that things get hard.

Oh please. The 2600 REQUIRES you to count cycles and chase the raster beam for every single game no matter how simple.

Edited December 3, 2008 by vdub_bobby

[DracIsBack]

Most of what you say is true, but the 7800 is most definitely NOT technically more powerful than the NES.

 

There have been some awesome discussions on pros and cons of graphic architectures of each here. Not sure why people try to degenerate into a simple "X is more powerful than Y" discussion.Maybe I'm too literal, but I always find these "is X more powerful than Y" the subject of marketing hooey. One 1.79 Mhz 6502 microprocessor against another 1.79 Mhz 6502? Major computational differences there.

[supercat]

Oh please. The 2600 REQUIRES you to count cycles and chase the raster beam for every single game no matter how simple.

 

True, but with modern emulation it's really not that hard. Often, rather than trying to count cycles I'll simply throw together a little kernel test and find out what things happen to early or too late, and then see if I can fix them. If there's too much stuff going on, it may be difficult or impossible to tweak the timing of a particular instruction without knocking some other timing out of tolerance. But if there isn't much going on, it's usually pretty easy.

[supercat]

One 1.79 Mhz 6502 microprocessor against another 1.79 Mhz 6502? Major computational differences there.

 

Even on the 2600, the video graphics circuitry takes a lot of load off the CPU (e.g. sprites automatically retrigger every line without CPU intervention). The differences in graphics circuitry matter far more than the similarities in CPU horsepower.

 

I don't think it's particularly meaningful to regard either the 7800 or the NES as "more powerful" than the other with regard to graphics; each can do things that the other simply cannot. The NES has circuitry to manage multi-color tile-mapped backgrounds. As a result, it can do a better job of displaying such backgrounds than can the 7800, so Super Mario Brothers can come out looking better than Scrapyard Dog. On the other hand, its abilities to display things other than the tiled background aren't as sophisticated, so Robotron can show more freely-moving objects than anything on the NES.

[Gorf]

Well the more I code with this machine the more I realize its got serious potential.

I think even enough to keep up oe even kick a few systems asses that came after it.

 

The problem is, this potential lies in what you are willing to throw out on the cartridge.

I maintain that if some one came up with a cart with a pokey and 8k of ram and the rest

normal rom, I think the 7800's Maria would really show off its true ability.

 

This is based soley on my current understanding of the 7800 but if that ram on the cart

is used as a character ROM, you can pull off a true frame buffer AND sprites with little

hammering on the cycles using the inderect(character) mode. For those of you that have

any knowledge of how a VIC-20 does high res mode, you know what I am thinking of

doing.

 

If only I could test the theory out. I just need either an emulator to recognize this new

cart format or build my own. Since I really dont want to build my own and I dont want

to update an exsisting emulator's source, it probably wont happen. This is assuming that

Maria can address the full 6502 address range.

 

This would allow for a screen buffer of 160 pixel wide by 192 high and enough

charachter space for all 10 digits and a few punctuations.

7680 bytes for the buffer. The rest if for digit characters for score.

 

It would be fantastic to be able to pull off circles and lines and maybe even a poly

or two ina frame buffer.

[Crazyace]

Why not develop for the Summer Games cart ( 16K ram ) and forget Pokey for the moment?

[Crazyace]

also there's no need to use indirect mode to get hires graphics?

 

Just set two sprites up per zone...

[Gorf]

also there's no need to use indirect mode to get hires graphics?

 

Just set two sprites up per zone...

 

 

 

You still need the same amount of RAM and I think the layout of inderect would

be easier to deal with as well.

[Crazyace]

If you only want hires graphics you dont really want the overhead of the character set fetch as well..

[supercat]

You still need the same amount of RAM and I think the layout of inderect would

be easier to deal with as well.

 

The right approach would be to have the cartridge map the memory differently for MARIA and CPU fetches. There are many ways this could be done; the simplest would be to have an 8K RAM chip appear at two spots in the memory map (probably $4000 and $6000) but feed the address pins through a multiplexer to 'shuffle' the addresses. Assume the goal is a 128x192 four-color screen (going the full 160 width would be possible, but more complicated). Addresses $4000-$5FFF would be read and written the RAM in normal fashion. When accessing RAM at $6000-$7FFF, however, bits 8-10 of the address would be swapped with bits 0-2, and bits 11-12 of the address would be swapped with bits 6-7.

 

There would be 24 zones of eight lines each, and each zone would have four sprites of eight bytes each. The sprite data for each zone would be fetched from (addresses given for the first byte of the top row of each sprite)

4000 4040 4080 40C0
4008 4048 4088 40C8
... five zones omitted (add 8 bytes per zone)
4038 4078 40B8 40F8
4800 4840 4880 48C0
... six zones omitted
4838 4878 48B8 48F8
5000 5040 5080 50C0
... six zones omitted
5038 5078 50B8 50F8

The entire screen would fit in $4000-$57FF; the RAM from $5800-$5FFF would be free for other purposes. While that organization of screen memory might seem pretty horrible to work with, the screen layout from $6000-$7FFF would be another matter. The first column of bytes would be mapped from $6000-$60BF, the second column from $6100-$61BF, etc. up to the last column at $7F00-$7FBF. How much nicer could things be?

 

Incidentally, if one skipped the swap of bits 11-12 with 6-7, one could still have the nice mapping at $6000-$7FFF, but the free areas of memory in the $4000-$5FFF range would be scattered as 64 bytes in 32 pages, rather than being a contiguous 2K block. The easiest way to understand what's going on is to realize that swapping bits 8-10 with 0-2 transposes rows and columns in each 8x8-byte area of the screen (i.e. each 8-byte by 8-row zone), and the swap of bits 11-12 with 6-7 transposes rows and columns of the 64x64-byte areas of the screen taken as chunks.

 

A layout like that would be far nicer than anything which could be done using indirect mode. I'm unaware of anything significant having been done using memory-map-shuffling tricks. The closest thing to that would be Rescue on Fractalus, which left A8 of the RAM chip disconnected (causing each rows of graphics data to be shown twice).

Edited December 5, 2008 by supercat

[A Sprite]

I think scrapyard dog already answers the nes smb question. To me, the real question is, could the nes pull off anything close to 7800 robotron? I think the ol 78 is capable of much more than the nes.

 

NES can throw out 128 sprites with a midscreen reload. The 8 sprites per scanline limit means it'll crash a few users, but the system itself should be fine.

[Gorf]

I think scrapyard dog already answers the nes smb question. To me, the real question is, could the nes pull off anything close to 7800 robotron? I think the ol 78 is capable of much more than the nes.

 

NES can throw out 128 sprites with a midscreen reload. The 8 sprites per scanline limit means it'll crash a few users, but the system itself should be fine.

 

 

It also throws out an inordinate amount of flicker long before you hit 128 sprites.

[Gorf]

You still need the same amount of RAM and I think the layout of inderect would

be easier to deal with as well.

 

The right approach would be to have the cartridge map the memory differently for MARIA and CPU fetches. There are many ways this could be done; the simplest would be to have an 8K RAM chip appear at two spots in the memory map (probably $4000 and $6000) but feed the address pins through a multiplexer to 'shuffle' the addresses. Assume the goal is a 128x192 four-color screen (going the full 160 width would be possible, but more complicated). Addresses $4000-$5FFF would be read and written the RAM in normal fashion. When accessing RAM at $6000-$7FFF, however, bits 8-10 of the address would be swapped with bits 0-2, and bits 11-12 of the address would be swapped with bits 6-7.

 

There would be 24 zones of eight lines each, and each zone would have four sprites of eight bytes each. The sprite data for each zone would be fetched from (addresses given for the first byte of the top row of each sprite)

4000 4040 4080 40C0
4008 4048 4088 40C8
... five zones omitted (add 8 bytes per zone)
4038 4078 40B8 40F8
4800 4840 4880 48C0
... six zones omitted
4838 4878 48B8 48F8
5000 5040 5080 50C0
... six zones omitted
5038 5078 50B8 50F8

The entire screen would fit in $4000-$57FF; the RAM from $5800-$5FFF would be free for other purposes. While that organization of screen memory might seem pretty horrible to work with, the screen layout from $6000-$7FFF would be another matter. The first column of bytes would be mapped from $6000-$60BF, the second column from $6100-$61BF, etc. up to the last column at $7F00-$7FBF. How much nicer could things be?

 

Incidentally, if one skipped the swap of bits 11-12 with 6-7, one could still have the nice mapping at $6000-$7FFF, but the free areas of memory in the $4000-$5FFF range would be scattered as 64 bytes in 32 pages, rather than being a contiguous 2K block. The easiest way to understand what's going on is to realize that swapping bits 8-10 with 0-2 transposes rows and columns in each 8x8-byte area of the screen (i.e. each 8-byte by 8-row zone), and the swap of bits 11-12 with 6-7 transposes rows and columns of the 64x64-byte areas of the screen taken as chunks.

 

A layout like that would be far nicer than anything which could be done using indirect mode. I'm unaware of anything significant having been done using memory-map-shuffling tricks. The closest thing to that would be Rescue on Fractalus, which left A8 of the RAM chip disconnected (causing each rows of graphics data to be shown twice).

 

Though Im sure your above idea hold great merit I think the design of the cart for that would be impractical.

I think it would be far less complicated using the inderect still. The logic decode would seemingly be less of

a bear. I will take your word for it that sprites might be faster, but I'd rather save those for the moving in

game characters. I think it would be also better suited to my static list as there is nothin to rebuild every

frame character map wise. I simply would need to alter memory in the character map area. Tables would

solve any layout issues and it would be as simple as a linear buffer.

 

Im thinking of the practical side of things like cost of the cart needed.

[Gorf]

If you only want hires graphics you dont really want the overhead of the character set fetch as well..

 

I'd want the rest of the ram area for a small numerical character set for

score numbers. In fact if I go with the screen size suggested by supercat

it would not even require as much ram and I could fit a full 64 ascii character

set in along with the screen buffer.

 

Gorf and Warbirds both use a character map based screen which comes out

to 128x192 so it would work out well. Actually I'd do a 148 x 192

 

Using 16 high zones:

37 characters wide x 12 zones high x 16 bytes each = 7104 bytes

leaving 1088 bytes / 16.

 

That would require 444 characters from the map for the screen buffer

and still leave you enough space for 68 characters for a full alpha

numeric character set w/punctuation .

[Crazyace]

If you only want hires graphics you dont really want the overhead of the character set fetch as well..

 

 

Using 16 high zones:

37 characters wide x 12 zones high x 16 bytes each = 7104 bytes

leaving 1088 bytes / 16.

 

That would require 444 characters from the map for the screen buffer

and still leave you enough space for 68 characters for a full alpha

numeric character set w/punctuation .

 

I dont know why you want to use characters though - that just wastes the dma time. Also holey dma is enabled by a15 so you wont need gaps in your hires screen.

 

If someone made a custom memory module - what would be really cool would be a double size X and Y read

[Gorf]

If you only want hires graphics you dont really want the overhead of the character set fetch as well..

 

 

Using 16 high zones:

37 characters wide x 12 zones high x 16 bytes each = 7104 bytes

leaving 1088 bytes / 16.

 

That would require 444 characters from the map for the screen buffer

and still leave you enough space for 68 characters for a full alpha

numeric character set w/punctuation .

 

I dont know why you want to use characters though - that just wastes the dma time. Also holey dma is enabled by a15 so you wont need gaps in your hires screen.

 

If someone made a custom memory module - what would be really cool would be a double size X and Y read

 

 

The more I think about it the more I realize, the sprites can be

anywhere, where with the charmap, you can only have one at a time.

 

I not sure why you would see any gaps.

[supercat]

Though Im sure your above idea hold great merit I think the design of the cart for that would be impractical.

 

Why? Using back-in-the-day technology, the memory-mapping I described would add one chip and five resistors (or two chips and no resistors).

 

You would have a bitmap screen the first four (160-mode four-color) pixels of which would be accessed at $6000; the four pixels to the right of that at $6100, $6200, etc. up to $7F00. The next row would be $6001, $6101, $6201, etc. I'm not sure what sprites have to do with anything, since those addresses are all for a bitmap screen.

 

I can't think what screen layout could possibly be easier to work with. To set a cursor position:

; gotoXY -- Set cursor X position as given in X register.  Y register holds Y position.
 lda offset_tbl,x; 0 0 0 0 1 1 1 1 2 2 2 2 ... (128 bytes)
 sta ptr+1 ; Assume (ptr)=0
 lda bitmask_tbl,x; Sequence of 03 0C 30 C0 (128 bytes)
 sta bitmask

; putPixel -- Store pixel value in accumulator ($00, $55, $AA, or $FF for color 0, 1, 2, or 3) at current point.
 eor (ptr),y
 and bitmask
 eor (ptr),y
 sta (ptr),y

; moveUp
 dey

; moveDown
 iny

; moveLeft
 asl bitmask
 rol bitmask
 bcc moveLeftDone
 rol bitmask
 dec ptr+1
moveLeftDone:

; moveRight
 lsr bitMask
 ror bitMask
 bcc moveRightDone
 ror bitMask
 inc ptr+1
moveRightDone:

As written, the code will do bad things if one goes outside the (0..127,0..191) coordinate range, but pixel plotting is quick and easy. None of the routines affect the X or Y register; the move routines don't even affect the accumulator. If one wants to bitblt a shape onto the screen, one can use a relatively nice loop. For example, to OR a vertical strip of data with a source bitmask shifted left 2 bits:

lp_O2L:
 lda (src1),y
 asl
 asl
 ora (dest),y
 sta (dest),y
 dey
 bpl lp_O2L

One would use 14 such loops (0, 2, 4, or 6 bits shifted left; 2, 4, or 6 bits shifted right; both sets using AND or OR).