Bad Apple for the Odyssey 2?

[8bitwidgets.com]

Hey everyone so I had a quick pass at @atari2600land about getting bad apple on the Odyssey 2.  If the 2600 could do it and the intellivision..  it seemed reasonable that the O2 could as well.  Bank Switching is the key to this being possible..  

 

The intellivision bad apple demo for example is around 430kb..  no intellivision rom could be that big..   but bank switching allows it.    However, I am no developer so I can't speak to how bank switching would work with the O2 or if it's even possible, but it seems like if the 2600 could manage it..  the O2 could.   

 

I don't know if bank switching is something that's ever been explored for the O2..   but I think it would be awesome to see bad apple on the O2!    It seems like if the 2600 could do it..  come on, we could do this!   

 

 

[+atari2600land]

Bankswitching doesn't go very far on the Odyssey 2 I'm afraid. The biggest game you can possibly get on Odyssey 2 is 16k, and that's with bankswitching.

[8bitwidgets.com]

Ah ok, i just wonder how the 2600 could manage it..  mind you i saw it on an emulator on youtube..  i can't say i've seen a video of a real 2600 running bad apple..   maybe because it was in emulation they could hack it..   the intellivision above was definitely real hardware, just using a multicart with bankswitching enabled..  

[Crazy Climber]

Bad Apple runs fine on an actual atari 2600. I ran it on mine with an UNO cart no problem.

[8bitwidgets.com]

55 minutes ago, Crazy Climber said:

I ran it on mine with an UNO cart no problem.

Cool I was going to try mine this weekend.  I have the Uno as well.  

 

 

4 hours ago, atari2600land said:

The biggest game you can possibly get on Odyssey 2 is 16k, and that's with bankswitching.

So what gives with O2 having a 16kb ceiling?  What defines this limit?  I'd think if the 2600 could manage it so could the O2.  Architecture? BIOS? 

[manopac]

On 3/3/2023 at 4:09 PM, atari2600land said:

Bankswitching doesn't go very far on the Odyssey 2 I'm afraid. The biggest game you can possibly get on Odyssey 2 is 16k, and that's with bankswitching.

so - this is not true 🙂 without any extra hardware the total an O2 game would be able to access is 12 KByte (4 banks, 3Kbyte per bank, 1Kbyte is "reserved" by the ROM which is hardwired into the Cartridge space), but even some original games for the Videopac+ use 16K using extra hardware for bankswitching on the cart (59+, 60+) - and one concept for doing this is what Soeren Gust was designing with the "MegaCART" long ago (so long ago that the webpage is not available anymore other than in the internet archive ...):

http://web.archive.org/web/20130613131556/http://soeren.informationstheater.de/g7000/megacart.html

with this you would be able to get 1 MByte for the Odyssey2 (not using a Voice, thats the only restriction ...)

 

The bad apple demo would not work for another reason - the O2 does not support a "Bitmap" in the classical sense ... thus not allowing you to show an "image" built of of "pixels" ...

(the Atari 2600 doesn't have that either, but here comes a design flaw of the O2 - the processor and the video beam are not in sync ... so the so called "racing the beam" that allows you to exactly switch colors always on the same position at the screen at the Atari 2600 is not possible on the O2 ... thus limiting programmers to basically what the hardware was intended to do without being able to do proper "tricks" ...)

 

So in theory to do the bad apple demo on the O2 you would need to build up each frame using just the standard elements that the system provides:

- built in characters (or parts of them) (12 single characters, 4 "blocks" of 4 characters)   (from the top of my head, not 100% sure the numbers are correct)

- sprites (4)

- the grid

- background color

if you manage to build up each frame from those elements (maybe with switching some elements at the end of the raster line) then it could be possible ... but the effort is enourmous ... and yes, you would need the "MegaCART" for it, as the code will look different for every frame of the demo, depending on how many frames you need and how complex each frame is, lots of code is needed for that ...

 

it might be possible to do on the Videopac+ (the never released Odyssey 3 in the US), as you can define bitmaps there (see background images for Videopac+ games) - not sure you can do it fast enough to show a different image every frame though - but worth a try 🙂

Edited March 4, 2023 by manopac

[8bitwidgets.com]

28 minutes ago, manopac said:

the O2 does not support a "Bitmap" in the classical sense

Ah ok thanks for explaining all that.  I didn't know a lot of this about the O2..  very interesting to learn this and while that's a bummer it can't be done (at least not without some insane dedication and effort..   at lease i now understand why it hasn't been done yet. 

[DanBoris]

3 hours ago, Caleb Garner said:

Ah ok thanks for explaining all that.  I didn't know a lot of this about the O2..  very interesting to learn this and while that's a bummer it can't be done (at least not without some insane dedication and effort..   at lease i now understand why it hasn't been done yet. 

Yeah, that's one of the big challenges with the O2, the only graphics elements where you have complete control are the 4, 8x8 1 color sprites. One of the reasons why there weren't many games ported to the O2 from other systems. 

[8bitwidgets.com]

3 hours ago, DanBoris said:

weren't many games ported

Interesting..  and to think it came out a year after the 2600..   I guess they thought their approach would be advantageous for some reason, perhaps production cost factors.  

[manopac]

Well - they just didn't think far enough from the initial point it made sense - the O2 had much better capabilities than the Atari 2600 in terms of elements it could display at once - games like Munchkin made Pac Man on the A2600 look really bad ... compared to the first Atari 2600 games, the O2 games just looked and played better ... but the Atari 2600 programmers soon found ways to get past the few "player/missiles" and other elements that was the "base set" of what the A2600 could do - so games on the A2600 got better really quickly (especially when Activision entered the scene ...), while O2 games stayed what they were (with few exceptions like Killer Bees) - and the fixed character set in the end also didnt really help the system as games started to look "the same" (with the guy walking always being taken from the characters and thus always being the same character in most games ...)    (just IMHO)

[8bitwidgets.com]

yea i mean in some ways as a potential programmer i kinda find the structure of it maybe easier to work with because you're working more with predefined elements rather..  but yea i can see how porting a game would be nearly impossible if you didn't have greater access to the graphics.  Yea i love the look and feel of O2..  and i can see how they simply designed with a different mindset.  

[+atari2600land]

I thought the biggest games were 16k because that's what they had to be. So how would one program a game >16k then?

[manopac]

Its nothing that can be done in Software only - again: Software only allows a max 12 KByte, for everything else hardware bankswitching is needed that can have different forms, ones of which is the one Soeren implemented in his MegaCART, others are what Videopac 31, 40, 55, 58, 59, 60 doing ... 

so if you REALLY want to get around the 12 KB Limit, you can - I wouldnt advise it though, as you would have to copy an existing bankswitching scheme (to use it in an emulator where it is supported), build your hardware to try it out properly and also find someone willing to manufacture carts from it then ...

[+Gemintronic]

Probably need something like the Raspberry Pi in an NES cart deal. 

 

Have a bare metal side that just draws the screen from shared RAM, gets inputs and outputs sound.  The actual game/animation would run on the Pi CPU itself.

[manopac]

thats pretty much what C7010 (Chess) and C7420 (Basic) are doing ... using the Videopac/O2 system just for displaying on the screen whatever the Z80 processor in the attachment comes up with ...

[+pboland]

22 hours ago, manopac said:

(the Atari 2600 doesn't have that either, but here comes a design flaw of the O2 - the processor and the video beam are not in sync ... so the so called "racing the beam" that allows you to exactly switch colors always on the same position at the screen at the Atari 2600 is not possible on the O2 ... thus limiting programmers to basically what the hardware was intended to do without being able to do proper "tricks" ...)

I'm not a programmer and I could be way off on this, but from what I've read over the years the fact that the Atari 2600 could "race the beam" was a happy accident with the hardware design. If that is the case, I think calling the O2 design "flawed" because it can not do this is kind of a stretch. Yes, in the end it gave the 2600 an advantage over the O2, but it was purely accidental (again, if I'm understanding how racing the beam was found in the hardware).

[manopac]

ok - lets not call it a flaw but a disadvantage   

[8bitwidgets.com]

5 hours ago, manopac said:

ok - lets not call it a flaw but a disadvantage

that is very dimplomatic of you    I agree disadvantage is a great way to phrase it.  

[DanBoris]

6 hours ago, pboland said:

I'm not a programmer and I could be way off on this, but from what I've read over the years the fact that the Atari 2600 could "race the beam" was a happy accident with the hardware design. If that is the case, I think calling the O2 design "flawed" because it can not do this is kind of a stretch. Yes, in the end it gave the 2600 an advantage over the O2, but it was purely accidental (again, if I'm understanding how racing the beam was found in the hardware).

 

I don't know if I would call "racing the beam" and accident. The system was intentionally designed to be flexible, and I am sure the engineers knew what was possible with it.

 

The O2 and 2600 were just two different design approaches. The 2600 was very flexible, but harder to program. The O2 lacked the flexibility but it was much easier to get things on the screen. The O2 could easily do a lot of moving objects as long as some of them were from the fixed set of shapes. KC Munchkin uses the 4 sprites for your characters and the enemies, but the dots are one of the fixed shapes. The other difference was the processor. The O2's 8048 was slower then the 6502 and probably would have had a hard time doing the real time video register updates that the 2600 requires. 

[+pboland]

1 hour ago, DanBoris said:

The O2 and 2600 were just two different design approaches. The 2600 was very flexible, but harder to program. The O2 lacked the flexibility but it was much easier to get things on the screen. The O2 could easily do a lot of moving objects as long as some of them were from the fixed set of shapes.

I agree.

 

1 hour ago, DanBoris said:

I don't know if I would call "racing the beam" and accident. The system was intentionally designed to be flexible, and I am sure the engineers knew what was possible with it.

Yes, it was designed to be flexible, but that doesn't mean the engineers that made the hardware knew every possible way to exploit said hardware. This happens all the time in manufacturing with most things. As an example, quoting from How Atari 2600's Crazy Hardware Changed Game Design:

 

- "The VCS' unique hardware limitations forced game designers to jump through all sorts of hoops to squeeze more complex game designs out of the VCS."

 

- "Eventually, use of these techniques allowed designers to create scenes on the VCS that were significantly more detailed than the hardware maker had ever imagined."

 

These two quotes seem to suggest that "racing the beam" at best was an "undocumented feature" of the hardware (i.e. It's a bug, but turned out to be a useful bug).

 

Yes, I know this is just one article and yes I understand it is just two quotes (I'm sure I can find more), but I've never seen anything that suggests the programmers were told of a feature that could make games more complex just by using a feature that was purposely design for such as beam chancing or racing. Don't get me wrong, I'm not saying these things to diminish the Atari 2600. It's by far the best system of it's time. I'm just saying that a little luck (and some very determined/great programmers) found something pretty cool with hardware that it really wasn't designed to do.

 

Here's non video game example of an undocumented feature in a product. Take the guitar. Eddie Van Halen is known for the finger tapping technique on the fret board of the guitar (made famous in his guitar solo piece "Eruption"). However, the guitar was never designed to be played in this manner. Yet today many guitar players use this technique all the time.

[DanBoris]

13 hours ago, pboland said:

I agree.

 

Yes, it was designed to be flexible, but that doesn't mean the engineers that made the hardware knew every possible way to exploit said hardware. This happens all the time in manufacturing with most things. As an example, quoting from How Atari 2600's Crazy Hardware Changed Game Design:

 

- "The VCS' unique hardware limitations forced game designers to jump through all sorts of hoops to squeeze more complex game designs out of the VCS."

 

- "Eventually, use of these techniques allowed designers to create scenes on the VCS that were significantly more detailed than the hardware maker had ever imagined."

 

These two quotes seem to suggest that "racing the beam" at best was an "undocumented feature" of the hardware (i.e. It's a bug, but turned out to be a useful bug).

 

Yes, I know this is just one article and yes I understand it is just two quotes (I'm sure I can find more), but I've never seen anything that suggests the programmers were told of a feature that could make games more complex just by using a feature that was purposely design for such as beam chancing or racing. Don't get me wrong, I'm not saying these things to diminish the Atari 2600. It's by far the best system of it's time. I'm just saying that a little luck (and some very determined/great programmers) found something pretty cool with hardware that it really wasn't designed to do.

 

Here's non video game example of an undocumented feature in a product. Take the guitar. Eddie Van Halen is known for the finger tapping technique on the fret board of the guitar (made famous in his guitar solo piece "Eruption"). However, the guitar was never designed to be played in this manner. Yet today many guitar players use this technique all the time.

 

This did get me thinking about the first game that "raced the beam". This definitely happened by 1978 with Breakout which does mid-line changes to the playfield to do the bricks. I think this may be a case of necessity if the mother of invention. The earliest games didn't need to push the limits of the hardware. But as time went on programmers started finding useful way to race the beam and get more out of the hardware. 

[johannesmutlu]

On 3/5/2023 at 1:55 AM, DanBoris said:

Yeah, that's one of the big challenges with the O2, the only graphics elements where you have complete control are the 4, 8x8 1 color sprites. One of the reasons why there weren't many games ported to the O2 from other systems. 

Well i do belive that a bad apple demo should be possible on the odyssey by using a more powerful cpu on  a cartride along with extra ram and rom trough the use of bankswitching (megapack???)

and to use that dot tile from it’s character set and built an image from it but placing that dot pattern next to each other,in order to avoid to use those other simplistic character sets such as the man and treas,so if we could just avoid those character sets and instead use that dot tile only instead we might create all sorts of images we want,not it might be true that the odyssey has no memory access in tile sets from the cartride,it could only access it’s own backed in tile sets,BUT if the cartride could just give commando signals to that system to tell it how to create images out of that availible dot tile and ignoir all other characters,we might get around this restriction,

bothe the trs80 and commodore pet lacked graphical capabilities,the only thing they had were text characters BUT by placing dots next to each other it became possible to create pseu graphics that way,so i just really can’t see why this could be done on the odyssey 2,am mean look at those ghosts and main character inside homebrewed mc pacman game (a hacked crazy chase game) those characters are not inside that character set of the odyssey 2,so i suppose those chosts and pac man itself were probably created with that availible dit tile,right??

i can’t see otherwise how those pacman characters were generated on the odyssey 2.

[DanBoris]

8 hours ago, johannesmutlu said:

Well i do belive that a bad apple demo should be possible on the odyssey by using a more powerful cpu on  a cartride along with extra ram and rom trough the use of bankswitching (megapack???)

and to use that dot tile from it’s character set and built an image from it but placing that dot pattern next to each other,in order to avoid to use those other simplistic character sets such as the man and treas,so if we could just avoid those character sets and instead use that dot tile only instead we might create all sorts of images we want,not it might be true that the odyssey has no memory access in tile sets from the cartride,it could only access it’s own backed in tile sets,BUT if the cartride could just give commando signals to that system to tell it how to create images out of that availible dot tile and ignoir all other characters,we might get around this restriction,

bothe the trs80 and commodore pet lacked graphical capabilities,the only thing they had were text characters BUT by placing dots next to each other it became possible to create pseu graphics that way,so i just really can’t see why this could be done on the odyssey 2,am mean look at those ghosts and main character inside homebrewed mc pacman game (a hacked crazy chase game) those characters are not inside that character set of the odyssey 2,so i suppose those chosts and pac man itself were probably created with that availible dit tile,right??

i can’t see otherwise how those pacman characters were generated on the odyssey 2.

The challenge with using the dot tile is that you are limited to how many you can put on the screen. You can have 12 that are individually controlled and then 4 groups of 4 that have to be displayed together. The question would be how many you can generate using mid-line or mid-screen register changes? In theory you could create a 28 pixel wide bitmapped display this way if you could change the registers fast enough. 

 

[johannesmutlu]

8 minutes ago, DanBoris said:

The challenge with using the dot tile is that you are limited to how many you can put on the screen. You can have 12 that are individually controlled and then 4 groups of 4 that have to be displayed together. The question would be how many you can generate using mid-line or mid-screen register changes? In theory you could create a 28 pixel wide bitmapped display this way if you could change the registers fast enough. 

 

Interesting,well i was thinking,since the O2 could display 60fps,we may could quickly alternate those background & sprite tiles per frame in order to display enough on screen,for example if frame 1 display’s the first 4 groups of sprite and could only display 12 dots atonce per frame,we could then display a different grof of 4 sprotes and 12 background tile dots on frame 2 etc,,

so in theory if we want to port for example a nes game such as pacman or donkeykong to the O2,we might could devide the screen into sections of 12 pixels and alternate between each one per frame,for 64 sprites,we should devide those sprites in groups of 4 and alternate between each 4 groups of sprites;sure in may could result in some flicker but it’s one way we may could,

however with such method it’s unlikely to create an bad apple at a high frame rate,maybe at 5fps or less but it would be still coolto see it happen non the less,

 

 

and lastly what would be really cool is if somebody could make an AI toolchain convertor to analize those tile patterns of let’s say mes games we want to port to the O2,wich not only could automatically devide each screen into sections of 12 pixels over 60fps as well as automatically deviding 64 sprites in groups of 4 sprites over 60fps,but could also automatically analize those tile sets to search for a closest match to see if some tiles from 64 character set from the O2 could be used instead and if it finds no closest match,that it then has to create that tile set from the availible dot pattern from the O2 ( for instance for numbers & letters,arrows plus and minus it could use those character sets from the O2 while for shapes such as hearths etc,,, it could use that dot tile instead and copy paste it to recreate that hearth etc,,, thus converting those analized tile sets into commando signals for the O2 at how and wich of the 64 tile sets to use and how to create certain tile patterns using the availible dot tile,in theory it shouldn’t be that hard to convert pac man into a O2 graphics format since those avaible lines could be use to create the level whose those circles could be used for eatible dots,those numbers could be use to display the high score and the dot pappern could be used trough copy pasting to create pac man and those ghosts,so depending on the complexity of nes games we want to port to the O2 as well as the required bankswitching the extra cpu and ram it might require (O2 chess module comes to mind), i think it shouldn’t be that per se hard to port certain nes games to the odyssey 2,

 

[+pboland]

14 hours ago, johannesmutlu said:

Interesting,well i was thinking,since the O2 could display 60fps,we may could quickly alternate those background & sprite tiles per frame in order to display enough on screen,for example if frame 1 display’s the first 4 groups of sprite and could only display 12 dots atonce per frame,we could then display a different grof of 4 sprotes and 12 background tile dots on frame 2 etc,,

so in theory if we want to port for example a nes game such as pacman or donkeykong to the O2,we might could devide the screen into sections of 12 pixels and alternate between each one per frame,for 64 sprites,we should devide those sprites in groups of 4 and alternate between each 4 groups of sprites;sure in may could result in some flicker but it’s one way we may could,

however with such method it’s unlikely to create an bad apple at a high frame rate,maybe at 5fps or less but it would be still coolto see it happen non the less,

 

 

and lastly what would be really cool is if somebody could make an AI toolchain convertor to analize those tile patterns of let’s say mes games we want to port to the O2,wich not only could automatically devide each screen into sections of 12 pixels over 60fps as well as automatically deviding 64 sprites in groups of 4 sprites over 60fps,but could also automatically analize those tile sets to search for a closest match to see if some tiles from 64 character set from the O2 could be used instead and if it finds no closest match,that it then has to create that tile set from the availible dot pattern from the O2 ( for instance for numbers & letters,arrows plus and minus it could use those character sets from the O2 while for shapes such as hearths etc,,, it could use that dot tile instead and copy paste it to recreate that hearth etc,,, thus converting those analized tile sets into commando signals for the O2 at how and wich of the 64 tile sets to use and how to create certain tile patterns using the availible dot tile,in theory it shouldn’t be that hard to convert pac man into a O2 graphics format since those avaible lines could be use to create the level whose those circles could be used for eatible dots,those numbers could be use to display the high score and the dot pappern could be used trough copy pasting to create pac man and those ghosts,so depending on the complexity of nes games we want to port to the O2 as well as the required bankswitching the extra cpu and ram it might require (O2 chess module comes to mind), i think it shouldn’t be that per se hard to port certain nes games to the odyssey 2,

 

Couple thoughts:

 

Character #27 is quite large even for a "dot". I'm not bashing your idea, I'm just pointing out something that I'm not sure is obvious.

 

My other thought is the idea of "porting" known games. Most of these games have been ported ad nauseam to almost all systems already. What's the point of making yet another port? Especially NES games. Maybe we should make controller adapters to plug in NES pads to the O2? My point is, you kind of loose the O2 experience with those kind of things. Again, don't get me wrong. I understand the idea of squeezing out as much as one can on a given platform, but to what point? Just a thought.