Extended RAM bank?

[zezba9000]

Is there was a way to extend the 64 bytes of ram on the Odyssey 2?

Or does the C7051 cart have a ram extension bank? Didn't think so but was wondering.

 

Also anyone know if anything ever came of SDCC support for the MCS-48 / Intel 8048?

If not what is the best assembly dev tools to use?

[Mux]

It's got 32 bytes of internal ram and another 128 bytes of extra ram you can enable using one of the ports. Check out the O2 doc for more info..

[zezba9000]

It's got 32 bytes of internal ram and another 128 bytes of extra ram you can enable using one of the ports. Check out the O2 doc for more info..

Do you have a link to where I can find that doc?

Other places I've looked say it had 64 bytes of ram and one other place said 64 + 128.

Thanks.

[Mux]

You can find it here:

 

http://www.atarihq.com/danb/o2.shtml

 

It does state there are 64 bytes but some of them are taken up by the BIOS (collision bits for instance).

 

Hope this helps!

 

-Mux

[zezba9000]

You can find it here:

 

http://www.atarihq.com/danb/o2.shtml

 

It does state there are 64 bytes but some of them are taken up by the BIOS (collision bits for instance).

 

Hope this helps!

 

-Mux

So there 256 bytes for graphics. So correct me if I'm wrong but that external 256 bytes of ram could also be used as non-graphic storage for game loops but maybe its a little slower for the CPU to access?

 

What compiler options are there for the O2? Is there a C compiler. I saw people were looking at SDCC at one point but maybe assembly is the only option?

[LS_Dracon]

So there 256 bytes for graphics. So correct me if I'm wrong but that external 256 bytes of ram could also be used as non-graphic storage for game loops but maybe its a little slower for the CPU to access?

 

What compiler options are there for the O2? Is there a C compiler. I saw people were looking at SDCC at one point but maybe assembly is the only option?

 

No. the VDC RAM uses BITs not BYTEs, so if a particular registers uses only the first 4 bits, all other 4 "bits" doesn't exist on hardware.

The unused addresses are empty. In late 70's RAM was a precious resource.

What you can do, if you're not using GRID graphics, is disable them and use grid registers to load and store values. That's extra 16 bytes only.

Beware, not all registers are R/W, most of them are write only. I not sure exactly which ones you can read back.

 

There is a way to add extra RAM on a cart, but from what I know, it was never done before.

 

The internal RAM are 64 bytes, but the first 32 are used for processor :

16 bytes for registers (0-7 normal and 0-7 alternative)

16 bytes for Stack Pointer, you can use some of them if you know exactly what you're doing (subroutine levels deep and such)

 

Note the last 3 bytes is used for BIOS :

 

03Dh : Hold collision results

03Eh : Timer (count up to 60 then resets, 60 frames = 1 second, thus resets every second)

03Fh : Hold video status (not much usefull).

 

So you actually have 29 bytes free in the internal RAM.

 

I think for 8048 you're unique option is assembly.

Edited June 14, 2019 by LS_Dracon

[Mux]

Although I (personally) haven't used it, according to the doc there are 128 bytes external to the CPU.

 

Besides that RAM that is internal to the processor there are 128 bytes of RAMexternal to the processor. To enable the external ram set P14 low and P13 high. The memory can now be read and written to using the MOVX command.

 

Looking at the PCB, it's an external IC..

 

[zezba9000]

Although I (personally) haven't used it, according to the doc there are 128 bytes external to the CPU.

 

Besides that RAM that is internal to the processor there are 128 bytes of RAMexternal to the processor. To enable the external ram set P14 low and P13 high. The memory can now be read and written to using the MOVX command.

 

Looking at the PCB, it's an external IC..

 

 

 

 

No. the VDC RAM uses BITs not BYTEs, so if a particular registers uses only the first 4 bits, all other 4 "bits" doesn't exist on hardware.

The unused addresses are empty. In late 70's RAM was a precious resource.

What you can do, if you're not using GRID graphics, is disable them and use grid registers to load and store values. That's extra 16 bytes only.

Beware, not all registers are R/W, most of them are write only. I not sure exactly which ones you can read back.

 

There is a way to add extra RAM on a cart, but from what I know, it was never done before.

 

The internal RAM are 64 bytes, but the first 32 are used for processor :

16 bytes for registers (0-7 normal and 0-7 alternative)

16 bytes for Stack Pointer, you can use some of them if you know exactly what you're doing (subroutine levels deep and such)

 

Note the last 3 bytes is used for BIOS :

 

03Dh : Hold collision results

03Eh : Timer (count up to 60 then resets, 60 frames = 1 second, thus resets every second)

03Fh : Hold video status (not much usefull).

 

So you actually have 29 bytes free in the internal RAM.

 

I think for 8048 you're unique option is assembly.

Ok cool, so seems like the stack memory will be limited to around 32 bytes for execution?

Then if I can access the 128 bytes of external SRAM I can store other game resources there.

Correct me if I'm wrong but the graphics/audio controller is like the Atari 2600 and only has control registers or does it also read from the SRAM like a PPU/GPU?

Edited June 15, 2019 by zezba9000

[LS_Dracon]

Although I (personally) haven't used it, according to the doc there are 128 bytes external to the CPU.

 

Besides that RAM that is internal to the processor there are 128 bytes of RAMexternal to the processor. To enable the external ram set P14 low and P13 high. The memory can now be read and written to using the MOVX command.

 

 

 

Yes, I was talking about VDC RAM and internal RAM only. On top of that, you have 128 bytes of external RAM.

 

 

 

Ok cool, so seems like the stack memory will be limited to around 32 bytes for execution?

Then if I can access the 128 bytes of external SRAM I can store other game resources there.

Correct me if I'm wrong but the graphics/audio controller is like the Atari 2600 and only has control registers or does it also read from the SRAM like a PPU/GPU?

The external RAM is difficult to work with. When you set the processor to work with it, you can't access the graphic registers at same time.

It requires a special opcodes, and you can only write and read, you can't INC or DEC or ADD directly.

 

Yes, VDC (Video Display Controller) it is like Atari 2600, you just set the registers.

[zezba9000]

17 hours ago, LS_Dracon said:

Besides that RAM that is internal to the processor there are 128 bytes of RAMexternal to the processor. To enable the external ram set P14 low and P13 high. The memory can now be read and written to using the MOVX command....

...The external RAM is difficult to work with. When you set the processor to work with it, you can't access the graphic registers at same time.

It requires a special opcodes, and you can only write and read, you can't INC or DEC or ADD directly.

So I wonder how fast it is to switch to the external memory then copy it to the stack (CPU memory) for operations then store the result back then switch back to the VDC.

 

If thats to slow for a lot of stuff at least the 128 external bytes could be used to store information you don't always need access to. I mean they must have put the external ram in the console expecting people to use it for something.

Edited June 16, 2019 by zezba9000

[LS_Dracon]

The idea behind the external RAM is you don't need to deal with VDC registers directly, you set the processor to use external RAM, set all values you need there, and during VBlank you send these values to VDC (like a mirror). 

Naturally some values like GFX data for sprites need to be written directly to VDC or you will not have enough extra RAM to store everything.

Quote

If thats to slow for a lot of stuff at least the 128 external bytes could be used to store information you don't always need access to. I mean they must have put the external ram in the console expecting people to use it for something.

Forget speed when you're dealing with Odyssey2.

 

If you want more RAM and speed, look the design behind Harmony cart for Atari2600, it features a ARM processor you can code in C, and the Atari side is just pick the values from cart RAM and store to the registers. This way you can boost Odyssey 2 as well, as you can change stuffs "on the fly" (while screen is being drawn) and have almost no ROM limits.

 

[zezba9000]

5 hours ago, LS_Dracon said:

The idea behind the external RAM is you don't need to deal with VDC registers directly, you set the processor to use external RAM, set all values you need there, and during VBlank you send these values to VDC (like a mirror). 

Naturally some values like GFX data for sprites need to be written directly to VDC or you will not have enough extra RAM to store everything.

 

I'm missing something here because it sounds like you made a contradiction.

 

* You said you can't write to the VDC while the external memory is active via P13 & P14.

* How do you copy values from external memory to the VDC if you can't access them both at the same time?

 

What I'm getting here is the best approach is to process memory instructions on internal CPU ram (as it supports INC or DEC or ADD) then copy the result to the external using MOVX. However I don't know how you would "mirror" values to the VDC from external ram if you can't access the VDC while the external ram is enabled.

Edited June 16, 2019 by zezba9000

[LS_Dracon]

There is a mode you can read from external RAM and copy to VDC.

It's the P16 bit, according Dan Boris O2 DOC :

 

P16: Copy mode enable.
Setting this bit to 1 enables the RAM to VDC copy mode. To use this mode you must also set P13 and P14 to 0. In this mode all external reads come from the external ram and
all external writes go to the VDC. This allows data to be copied from the RAM to the VDC easily.

 

So : 

 

movx a,@R0  ;Copy from extra RAM

movx @R1,a ;Writes to VDC 

 

R0 = points to ExtRAM, R1 points to VDC.

Tricky

 

EDIT : VDC should be OFF, hence it is done during Vblank, usually.

Edited June 16, 2019 by LS_Dracon

[zezba9000]

Ok that makes a lot more sense.

[Mux]

WRT bits -vs- bytes.. It's still mapped as a byte but, as pointed out earlier, some bits don't physically exist. Usually they're marked with an 'x' or '-' or something similar. Think of it as having 4 wires on a bus rather than 8. The non-connected wires contain 'junk' as well, they're not connected.

 

The copy mode is supposed to help you speed up updating VDP registers although I don't really see the advantage as it's still a MOV instruction. I guess it helps you don't have to switch back and forth.

 

-Mux

[Todd W H]

You guys are smart.  I have always wanted to program a homebrew game for the Odyssey2.  I have seen some games programmed for the O2 that look amazing with today's know how in programming.   I want to push the system to its limits.  I have TWO questions?  Where can I learn to program for something like the the Atari VCS, Intellivision,  O2 etc?  What do I physically need at my home to accomplish this?  Any information would be greatly appreciated.   

[SSG]

On 3/4/2020 at 9:23 PM, Todd W H said:

You guys are smart.  I have always wanted to program a homebrew game for the Odyssey2.  I have seen some games programmed for the O2 that look amazing with today's know how in programming.   I want to push the system to its limits.  I have TWO questions?  Where can I learn to program for something like the the Atari VCS, Intellivision,  O2 etc?  What do I physically need at my home to accomplish this?  Any information would be greatly appreciated.   

batari basic for the Atari2600

[zezba9000]

On 3/4/2020 at 6:23 PM, Todd W H said:

You guys are smart.  I have always wanted to program a homebrew game for the Odyssey2.  I have seen some games programmed for the O2 that look amazing with today's know how in programming.   I want to push the system to its limits.  I have TWO questions?  Where can I learn to program for something like the the Atari VCS, Intellivision,  O2 etc?  What do I physically need at my home to accomplish this?  Any information would be greatly appreciated.   

Or CC65 compiler for Atari.

Edited March 6, 2020 by zezba9000

[DanBoris]

On 6/18/2019 at 4:42 PM, Mux said:

WRT bits -vs- bytes.. It's still mapped as a byte but, as pointed out earlier, some bits don't physically exist. Usually they're marked with an 'x' or '-' or something similar. Think of it as having 4 wires on a bus rather than 8. The non-connected wires contain 'junk' as well, they're not connected.

 

The copy mode is supposed to help you speed up updating VDP registers although I don't really see the advantage as it's still a MOV instruction. I guess it helps you don't have to switch back and forth.

 

-Mux

As you say, the savings comes from not having to switch back and forth. Since external RAM and the VDC cannot be on the bus at the same time, you would have to switch back and forth for every byte which saves a lot of instruction cycles. 

[johannesmutlu]

On 3/5/2020 at 3:23 AM, Todd W H said:

You guys are smart.  I have always wanted to program a homebrew game for the Odyssey2.  I have seen some games programmed for the O2 that look amazing with today's know how in programming.   I want to push the system to its limits.  I have TWO questions?  Where can I learn to program for something like the the Atari VCS, Intellivision,  O2 etc?  What do I physically need at my home to accomplish this?  Any information would be greatly appreciated.   

I really want to see a homebrew port of both pacman and donkeykong for the odyssey 2 as fauthful as possible to those original arcade versions of it,yes i know it’s waaay easier said then then and yes there are limitations,

but what if we could use extra rom and ram along with external bankswitching to over push the system over it’s limits,so for one thing we might could use the stock cpu for simulating 1bit pcm sound on that 1 channel sound by quickly changing it’s timers or volume levels if possible while the second cpu could be used for game logic,ai and communicate with the graphics chip as well to tell wich wich tille sets to use at wich groups and at wich positions on screen etc,,, for great graphics,

yes the odyssey does only allow you to use tile sets for both sprites and backgrounds out of it’s own 64 character set,BUT what if we could use that availible dot tile instead copy paste them wich each their own colors sothat we can create our own pseudo sprites and background tile sets that way (thuse generating commando signals to the odyssey 2 vdp chip,while for repeating tiles,it should send repeating commando signals to the vdp chip)

this way we could ignoire all other tile sets and place that dot tile next to each other to create our ones,

to see what i mean here i do got some ilustrations,

look at those ghosts in that hacked crazy chase game wich is now called mc pacman,

also kc mounchkin and crazy chase do show some unique sprites in it wich are not inside that restricted 64 character set of the odyssey 2 so i gonna assume those sprites were made with that availible dot tile being multiplied and grouped together,

This way we could get somewhat around those intended restricted limitations from those designers beyond the odyssey

[+pboland]

15 hours ago, johannesmutlu said:

I really want to see a homebrew port of both pacman and donkeykong for the odyssey 2 as fauthful as possible to those original arcade versions of it,yes i know it’s waaay easier said then then and yes there are limitations,

but what if we could use extra rom and ram along with external bankswitching to over push the system over it’s limits,so for one thing we might could use the stock cpu for simulating 1bit pcm sound on that 1 channel sound by quickly changing it’s timers or volume levels if possible while the second cpu could be used for game logic,ai and communicate with the graphics chip as well to tell wich wich tille sets to use at wich groups and at wich positions on screen etc,,, for great graphics,

yes the odyssey does only allow you to use tile sets for both sprites and backgrounds out of it’s own 64 character set,BUT what if we could use that availible dot tile instead copy paste them wich each their own colors sothat we can create our own pseudo sprites and background tile sets that way (thuse generating commando signals to the odyssey 2 vdp chip,while for repeating tiles,it should send repeating commando signals to the vdp chip)

this way we could ignoire all other tile sets and place that dot tile next to each other to create our ones,

to see what i mean here i do got some ilustrations,

look at those ghosts in that hacked crazy chase game wich is now called mc pacman,

also kc mounchkin and crazy chase do show some unique sprites in it wich are not inside that restricted 64 character set of the odyssey 2 so i gonna assume those sprites were made with that availible dot tile being multiplied and grouped together,

This way we could get somewhat around those intended restricted limitations from those designers beyond the odyssey

I've got a question. Have you tried to program the O2? I only ask because you seem to question the same thing in multiple threads. I know I've personally tried programming and I suck at it (so take that for what you will), but there are resources if you are willing to go down the path. I would suggest these:

 

http://atari2600land.com/odyssey2/odyssey2howtoprogram.html

 

and you might want to check out this forum:

 

https://videopac.nl/forum/index.php

 

By the way, it has already been stated in one of the other threads you asked about "sprites". You can have 4 (single color) custom sprites 8x8 pixels. And, no character #27 in not one pixel. "Sprites" and "Characters" are two separate things within the O2 (at least that's my understanding). There are NO custom "Characters" only custom "Sprites".  Again at least that is my understanding. I know you can put two characters together to get what looks like a custom graphic similar to a character/sprite. You can see this in the game Killer Bees. If I remember correctly the Bee guys are a combo of Character #08 & what ever the # is for the walking guy (which is actually two different characters for each direction, so four different guy characters).

 

I really think you are going to need to look into programming O2 for yourself. You are expecting someone to chime in and say "Here's how you trick the system and do all kinds of cool stuff", but it isn't going to happen. Mainly because if current O2 programmers had this information you would have already seen the game that did these tricks and it just doesn't exist (at least from what I've seen).

 

 

[johannesmutlu]

3 hours ago, pboland said:

I've got a question. Have you tried to program the O2? I only ask because you seem to question the same thing in multiple threads. I know I've personally tried programming and I suck at it (so take that for what you will), but there are resources if you are willing to go down the path. I would suggest these:

 

http://atari2600land.com/odyssey2/odyssey2howtoprogram.html

 

and you might want to check out this forum:

 

https://videopac.nl/forum/index.php

 

By the way, it has already been stated in one of the other threads you asked about "sprites". You can have 4 (single color) custom sprites 8x8 pixels. And, no character #27 in not one pixel. "Sprites" and "Characters" are two separate things within the O2 (at least that's my understanding). There are NO custom "Characters" only custom "Sprites".  Again at least that is my understanding. I know you can put two characters together to get what looks like a custom graphic similar to a character/sprite. You can see this in the game Killer Bees. If I remember correctly the Bee guys are a combo of Character #08 & what ever the # is for the walking guy (which is actually two different characters for each direction, so four different guy characters).

 

I really think you are going to need to look into programming O2 for yourself. You are expecting someone to chime in and say "Here's how you trick the system and do all kinds of cool stuff", but it isn't going to happen. Mainly because if current O2 programmers had this information you would have already seen the game that did these tricks and it just doesn't exist (at least from what I've seen).

 

 

Well i could actually feel that somebody would soon or later come up and notice that i didn’t asked about this stuff on this thread alone but on multiple thread about this as well,

but aside from that,and to ansure your question,well sadly i am not a programmer but i am certainly interested in each type of system and yes i am very curious what can be done with such limited hardware along with it’s own restrictions,and so am also curious wich tile sets were used in certain O2 games to create certain sprites wich also depends per game,but it is interesting non the less,frogger is a prime example of this,

BUT yes it is VERY STUPID that you only got more freedom with sprites then with BG characters WHAT WERE THEY THINKING🥵🥵🥵,if those restrictions could,ve been passed trough software and allow us to overlap BG tiles over each other then we could,ve create all kind of BG tile sets we want,but as far we can’t even do that either,

but then i got another question to you,

is it possible to ignoire those BG tiles and only use sprites instead? Why?

well maybe we could FAKE a background by using 4 x 8x8 sprites per frame sothat we could with 240 sprites VIRTUALLY on screen in the shapes we want,that means that we should beforehand devide the background into sections of 4 X 8x8 sprites and alternate between each section per frame to fake a constumized background on the O2,sure this method will cause alot of flicker but it’s atleast 1 way we might get around that,UNLESS the O2 doesn’t even allow you to alternate between sprites per frame either too, in such case then we are stuck in what we have to deal with,but again i will look at the document and will come with my conclusions and off course aslong i will understand the whole thing correctly,

also is there really no way to let the cpu control the vidp chip instead sothat we can do with those tile sets at what we want rather let the vdp chip restricting us at what we want???

HOWEVER if there was just a simple program wich let me costumize me own sprites with O2 tile sets as well as designign backgrounds by using those O2 tile sets and get stumbled those STUPID restrictions,then i can found out for MYSELF wich BG tile sets i can use to create certain shaped and what not,

also i do know that the videopax + is more powerful then the O2 but does it also give you more freedom to do what you want with those BG tiles for videopac + games??

it would be interesting to overlap certain BG tile sets with each other to create a tile set the way i want it,

i used pixelcut to cpy paste and combined certain tile sets with each other just to give the idea about the WHAT IF,i used BG tile 28 and 29 to vreate those platforms in donkeykong and those ladders while BG tile 31 is used to mimicking those barrels,either way,SHAME on those O2 designers to NOT even allow you to zoom in & out,rotate or mirror Bg tile sets,that would,ve gave use much more freedom in designign our BG graphics that way,why did they had to determine for use in what BG tile set we are allowed to use and what not ?,this is very disappointing🥲🥲

thanks anyway and let’s hope those fotoshopped picture with pixelcut app will spark ideas to homebrewers,not that i will expect much but still,,,

 

Edited January 24 by johannesmutlu

[DanBoris]

25 minutes ago, johannesmutlu said:

Well i could actually feel that somebody would soon or later come up and notice that i didn’t asked about this stuff on this thread alone but on multiple thread about this as well,

but aside from that,and to ansure your question,well sadly i am not a programmer but i am certainly interested in each type of system and yes i am very curious what can be done with such limited hardware along with it’s own restrictions,and so am also curious wich tile sets were used in certain O2 games to create certain sprites wich also depends per game,but it is interesting non the less,frogger is a prime example of this,

BUT yes it is VERY STUPID that you only got more freedom with sprites then with BG characters WHAT WERE THEY THINKING🥵🥵🥵,if those restrictions could,ve been passed trough software and allow us to overlap BG tiles over each other then we could,ve create all kind of BG tile sets we want,but as far we can’t even do that either,

but then i got another question to you,

is it possible to ignoire those BG tiles and only use sprites instead? Why?

It might be possible to update the sprites mid-screen, this is something someone would need to experiment with on the real hardware to see how far you could put it. 

 

25 minutes ago, johannesmutlu said:

well maybe we could FAKE a background by using 4 x 8x8 sprites per frame sothat we could with 240 sprites VIRTUALLY on screen in the shapes we want,that means that we should beforehand devide the background into sections of 4 X 8x8 sprites and alternate between each section per frame to fake a constumized background on the O2,sure this method will cause alot of flicker but it’s atleast 1 way we might get around that,UNLESS the O2 doesn’t even allow you to alternate between sprites per frame either too, in such case then we are stuck in what we have to deal with,but again i will look at the document and will come with my conclusions and off course aslong i will understand the whole thing correctly,

also is there really no way to let the cpu control the vidp chip instead sothat we can do with those tile sets at what we want rather let the vdp chip restricting us at what we want???

 

The CPU does control the VDP chip, but the VDP is totally responsible for controlling the video signal so you are limited to what it allows you to do. The character set is baked into the hardware of the chip, so there is no way for the CPU to override that. 

 

25 minutes ago, johannesmutlu said:

HOWEVER if there was just a simple program wich let me costumize me own sprites with O2 tile sets as well as designign backgrounds by using those O2 tile sets and get stumbled those STUPID restrictions,then i can found out for MYSELF wich BG tile sets i can use to create certain shaped and what not,

also i do know that the videopax + is more powerful then the O2 but does it also give you more freedom to do what you want with those BG tiles for videopac + games??

 

The Videopac+ simply adds a second video chip that generated background image that the original O2 graphics are overlayed on. The new videochip provides a 40x24 text mode with some redefinable characters. 

 

25 minutes ago, johannesmutlu said:

it would be interesting to overlap certain BG tile sets with each other to create a tile set the way i want it,

i used pixelcut to cpy paste and combined certain tile sets with each other just to give the idea about the WHAT IF,i used BG tile 28 and 29 to vreate those platforms in donkeykong and those ladders while BG tile 31 is used to mimicking those barrels,either way,SHAME on those O2 designers to NOT even allow you to zoom in & out,rotate or mirror Bg tile sets,that would,ve gave use much more freedom in designign our BG graphics that way,why did they had to determine for use in what BG tile set we are allowed to use and what not ?,this is very disappointing🥲🥲

thanks anyway and let’s hope those fotoshopped picture with pixelcut app will spark ideas to homebrewers,not that i will expect much but still,,,

 

 

 

It's easy to look back and criticize the design of the system, but it all comes down engineering tradeoffs when the system was being designed. I am sure the designers had specific goals in mind and designed a system simply to achieve those goals. The O2 came out in 1978 and was a major step up from anything Magnavox had done before. They had no idea what the videogame market would look like in just a few years so the limitations were probably not seen as a big deal. 

[johannesmutlu]

5 hours ago, DanBoris said:

It might be possible to update the sprites mid-screen, this is something someone would need to experiment with on the real hardware to see how far you could put it. 

 

 

The CPU does control the VDP chip, but the VDP is totally responsible for controlling the video signal so you are limited to what it allows you to do. The character set is baked into the hardware of the chip, so there is no way for the CPU to override that. 

 

 

The Videopac+ simply adds a second video chip that generated background image that the original O2 graphics are overlayed on. The new videochip provides a 40x24 text mode with some redefinable characters. 

 

 

It's easy to look back and criticize the design of the system, but it all comes down engineering tradeoffs when the system was being designed. I am sure the designers had specific goals in mind and designed a system simply to achieve those goals. The O2 came out in 1978 and was a major step up from anything Magnavox had done before. They had no idea what the videogame market would look like in just a few years so the limitations were probably not seen as a big deal. 

Well explained👍
And If someone will ever step up and figure out a way to do mid-screen sprite updates,that would be freaking AWESOME because it might could open up new unintended possibilities on the O2,so let’s hope😁

Edited January 24 by johannesmutlu