ROM is not built in, but in de game cartridges only.

_________________
I trust my somewhat flawed English is comprehensible to all.

Looking into "Wikipedia" I have learned that 6507 only had 13 address pins for 8K of memory and was lacking the interrupt functions but otherwise was identical to 6502. A part of this 8K address space was mapped into the "game cartridge" where the "game application program" was resident.

To my understanding this must mean that the top of the address space,

???? - $1FFF

was ROM with reset vector either in $1FFC,$1FFD (as for 6502) or in $1FFE,$1FFF (no IRQ or NMI). Programming a game then means (re)programming the cartridge (what hardware is needed for this) while the operating system in ???? - $1FFF never is touched!

wstjohn's



therefore has no meaning. The top of the memory is $1FFF and the ROM in ???? - $1FFF is of no concern for the game developer, he only deals with the cartridge area in the lower part of the memory, $0000 - ????-1

Execution must then start in the operation system resident in ROM and the game starts with a JSR or a JMP statement to the cartridge entry when the the start-up sequence has terminated. As there is no IRQ the application program resident in the cartridge must then actively pass control to operating system services (user/TV interface) by JSR to system routines in ROM.

Is this correct?

As I understand it, the 6507 has a 16-bit internal address space and PC like a real 6502, it just lacks some of the address pins. So the ROM cartridge probably has aliases at 8k intervals all the way up to e000-ffff. In which case it
sort of makes sense to say that by convention you're going to write code whose ORG is in the top alias as that puts the vectors at the addresses
everyone expects.

gnb10 writes:



Makes sense! It then just that the 3 most significant address lines goes to "dead ends" and that the power-up vector definitely is is in $1FFC,$1FFD alias $FFFC,$FFFD while $1FFA,$1FFB alias $FFFA,$FFFB and $1FFE,$1FFF alias $FFFE,$FFFF just is "rubbish" used for nothing. But this does not change that there is a range in memory including $1FFC,$1FFD (alias $FFFC,$FFFD) that must not (cannot?) be touched by the programmer of the (game) application! Either it physically is in a "fixed" (unprogrammable)part of the cartridge or in a ROM chip resident in the console itself

raccon writes:



Well, if the ROM containing the system software physically is resident in the removable cartridge or in the console itself does not change much. But it seems strange that at a time when ROM was expensive one puts one copy in each cartridge increasing the hardware cost of these cartridges!?

I don't think there was any system software as such. Each cartridge will contain the game plus all the support code it needs, and the reset vector just points to wherever the author of that particular cartridge has put the startup code.
This makes the base console cheaper, at the expense of possibly making the cartridge more expensive if it forces the code size up past a chip size boundary.

gnb10 writes:



If this is how it is I would be interested to get a hex dump of such a cartridge for disassemble/analysis on simulator! I cannot believe that interface to the TV video and the joysticks can be made much simpler then the interface to a keyboard and a (video) monitor (like for example on a PET).

And how is such a cartridge programmed? Are there normal EPROMs inside? Pin-compatible with now available and manifactured EPROMs. Or at least programmable with now available Prommers?

umm, there's this thing called Google ..




http://www.io.com/~nickb/atari/

There is no built-in ROM on the Atari VCS. There is no built-in ROM on the Nintendo 8-bit, 16-bit, Super Nintendo, or Sega Genesis either.

Not EPROMS. Mask programmed ROMs.

Toshi

bogax found the page



The following memory mapping is specified there:

VIDEO $0000-$007F
RAM $0080-$00FF
VIDEO $0100-$017F
STACK $0180-$01FF
IO $0281-$0285

ROM $1000-$1FFF

The game "combat" has a reset vector pointing to the ROM start at $1000 and the initialisation done is:



Really not much but at least this has to be done. The hardware hardly needs any initialisation! The state of the joysticks can be read from an I/O port of the chip in $0281-$0285, only the data direction must be set.

Tmorita wrote:



But user wstjohn who wants to write new games would need some pin compatible EPROMS or get/make a suitable adapter!

For the benifit of "wstjohn" I put at the end of

http://www.geocities.com/matsr2007/

the source code of the Atari game "Combat" slightly modified to be compatible with the Kowalski assembler/simulator. This is certainly a good template for a Atari game. The hardware problem, to interface an Eprom, is then another story!

Well, my original problem ended up being my fault all along. I was hard coding a variable to memory location $FFAA (really $1FAA for the 6507), which is a ROM location. I did this to test the ability to access ROM memory from 16 bit pointers.
I eventually got the pointers to work in a real program (on all 3 emulators), but was having problems originally b/c I 'illegally' tried to set a variable to a hard coded ROM location.
So, everything seems to be working now, but I'm sure I will eventually encounter more problems. Thanks again to everyone for their help.