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.