267 replies to this topic

[boisy]

Hello all,

First, I should introduce myself.  My name is Boisy Pitre and I've been involved with the Tandy Color Computer (CoCo) and its community for some 30 years now.  I run Cloud-9 (www.cloud9tech.com) along with my friend, Mark Marlette, where we sell CoCo hardware and software, and lead several open source initiatives in the CoCo community, most notably the NitrOS-9 operating system.

I've always been interested in Atari computers as a kid, having had an Atari VCS back in 1980.During my teen years, I never got into the  home computer end of Atari, though I was keenly aware of the scene. Now that I'm a little older, I can indulge more than I could back then .

One of my more recent desires has been to obtain a 6502 based Atari computer such as an Atari 400/800 or 130XE, and replace its 6502 microprocessor with a 6809 (the same processor that is in the CoCo), then get NitrOS-9 running on that hardware.  An interesting amalgamation of technologies, if you will, but nevertheless something that has intrigued me.

To that end, I've obtained an Atari XEGS from eBay, along with a keyboard and a few cartridge based games.  I've taken the system apart and identified chips that will need to be replaced for this project (the SALLY (6502) and the 16K ROM)  Both have been desoldered and replaced with 40 and 28 pin sockets, respectively, and both chips were salvageable during the desoldering process.  They have been placed back in the freshly soldered sockets and the machine comes up just fine.

Along with working towards mating the 6809E electrically into the board, I need some advice on how to bring up the board to a known state once the processor is working.  My thought would be to make some interesting sounds through the sound chip and setup the video mode, but in order to do that, I need detailed information on the actual chips involved, their addresses, etc.  In order to do this, I think it would be important to obtain a disassembly of the 16K ROM, as well as find any cross-assembler 6502 tools that are useful.  Can anyone point me to a fully annotated disassembly of the contents of the XEGS ROM, as well as the tools of choice to do assembling?

Thanks, and I"m looking forward to being part of the Atari community.

[candle]

i belive there is no fully disassembled XEGS rom, besides, it has 32k not 16k
16k is OS, 8k for BASIC, and another 8k for MISSLE COMMAND
what you really need is master memory map, and this one you can find here
what intrest you the most, are hardware registers of ANTIC, POKEY, GTIA and PIA

[flashjazzcat]

Hello boisy, and welcome to the forum! This sure sounds like an interesting project. There was some talk a while ago about NitrOS in the GUI thread (IIRC), and also a separate topic about converting 6809 code to 6502 (again, if memory serves). Anyway, it's pretty much "of the moment".

Regarding OS source listings, I have a couple but I think they're modded versions. There'll be a definitive version around here somewhere - I recall a recent topic about it.

[Rybags]

For a bare bones test situation:

Store zeroes to the I/O registers each page $D000, $D200, $D300, $D400.

Setup the PIA ($D300) registers to default values.  This is important to get right since banking of ROM is controlled there.

Setup Pokey to active state by storing 3 in $D20F.

Having the XEGS OS isn't vital, it's a derivative of the others already out there.
Unsure if it lives in the top or bottom half of the 32K ROM - but the ordering of the 16K OS section of the ROM should be the part from $C000-$CFFF first, then the Self-Test 2K part that banks to $5000-$57FF then the 10K OS part that maps to $D800-$FFFF.

An easy way of early testing any custom OS might be to just put a "bootstrap ROM" as your OS that does minimum system initialisation.  Then use 16K cartridges that live from $8000-$BFFF to hold the main OS part although that would only leave you with 32K contiguous RAM in the low area.

[bob1200xl]

Hello, Boisy

Where are you located (in general)? There is a set of documentation that was available from Atari dealers that had schematics, OS source, and a good explanation of how everything works on the 8-bit. I believe that it is called the Technical Reference set. It is for the older 400/800 series, but it has most everything you need. Check with B&C ComputerVisions for a copy - or eBay...

Note that the newer (XL/XE) systems have a 6502C CPU, which has the hardware to tri-state the chip while the other processor (ANTIC) uses the bus. Many of the old 400/800 systems used just a plain 6502, so you may want to start there.

Welcome to the Club!

Bob

[boisy]

Wow, thanks for the awesome and quick replies.  

candle, thanks for the link to the master memory map.  A lot of info is specific vectors for ROM routines that will not be relevant here.  What is important is the memory locations of the various hardware.  On the CoCo, all hardware is memory mapped at the high page ($FF00-$FFFF), leaving everything below as allocatable RAM.  In the case of the Atari, it appears that certain hardware take up discontiguous locations.  The GTIA is at $D000-$D0FF... it appears the other chips live around that area.  In any case, it's possible to tell NitrOS-9 which pages of memory are "allocated" from the get-go, so these areas would definitely be off-limits.

flashjazzcat, thanks and I'll be looking for those discussions.

Rybags, thanks for the hints on how to start.  My thought is get a series of steps outlined to at least get a sound played in 6502 assembly, verify that it works, then write the 6809 equivalent code.  I have an EPROM emulator that I can use to plug into the 28 pin ROM socket of the Atari and download code instantly.  Once I get the proper assembler and learn a bit of 6502 code I should be able to do this.

bob1200xl, I'm located in South Louisiana.  Thanks for the note about the tri-stating.  I'll consult my hardware guy to see how this will affect the daughterboard design.

So it looks like all I need is a good 6502 assembler to run on my Mac that generates 6502 code that I can quickly test on my ROM emulator, and get some code written up to do a quick test of the hardware.

[19Echo]

bob1200xl, on Mon Jan 23, 2012 4:04 PM, said:

I believe that it is called the Technical Reference set. It is for the older 400/800 series, but it has most everything you need.
Bob

Here you go

[boisy]

19Echo, on Mon Jan 23, 2012 4:30 PM, said:

bob1200xl, on Mon Jan 23, 2012 4:04 PM, said:

I believe that it is called the Technical Reference set. It is for the older 400/800 series, but it has most everything you need.
Bob

Here you go

Thanks much.  Is there an electronic, scanned version of this technical reference manual on the web?

[MrFish]

boisy, on Mon Jan 23, 2012 4:31 PM, said:

19Echo, on Mon Jan 23, 2012 4:30 PM, said:

bob1200xl, on Mon Jan 23, 2012 4:04 PM, said:

I believe that it is called the Technical Reference set. It is for the older 400/800 series, but it has most everything you need.
Bob

Here you go

Thanks much.  Is there an electronic, scanned version of this technical reference manual on the web?

Technical Reference Notes

[boisy]

Thanks.  This reference looks very valuable to my efforts.

Here's where I am at now.  I'm trying to find a suitable 6502 cross assembler (preferably written in C so I can compile it on my Mac) as well as an example source file.  From what I see, the 6502 reset vector is at $FFFC-$FFFD.  On the XEGS ROM, it appears this address points to $AAC2.  For my test assembly file, I would like to simply write minimal 6502 code that could generate a tone through the sound chip and branch forever while that sound is being emitted.  That code could reside anywhere in ROM (which appears to start at $8000).

The assemblers out there run the gamut... any preferences?

[boisy]

boisy, on Mon Jan 23, 2012 6:03 PM, said:

Thanks.  This reference looks very valuable to my efforts.

Here's where I am at now.  I'm trying to find a suitable 6502 cross assembler (preferably written in C so I can compile it on my Mac) as well as an example source file.  From what I see, the 6502 reset vector is at $FFFC-$FFFD.  On the XEGS ROM, it appears this address points to $AAC2.  For my test assembly file, I would like to simply write minimal 6502 code that could generate a tone through the sound chip and branch forever while that sound is being emitted.  That code could reside anywhere in ROM (which appears to start at $8000).

The assemblers out there run the gamut... any preferences?

Correction.  It appears that the reset vector has the least significant byte first ($AA $C2) so the actual address is $C2AA.  Is this correct?

I found an assembler called mxass which seems to fit the bill for now.  I'm generating a very simple object file that I can load into the ROM emulator.  Doesn't do any hardware initialization at the moment but sits in a tight loop.

I'll dig into the various chips to see what it takes to either get something on the screen or make a sound.

[Stephen]

boisy, on Mon Jan 23, 2012 6:31 PM, said:

Correction. It appears that the reset vector has the least significant byte first ($AA $C2) so the actual address is $C2AA. Is this correct? I found an assembler called mxass which seems to fit the bill for now. I'm generating a very simple object file that I can load into the ROM emulator. Doesn't do any hardware initialization at the moment but sits in a tight loop. I'll dig into the various chips to see what it takes to either get something on the screen or make a sound.

Yes - 6502 is little endian, so LSB first.  Good luck with this project - it sounds like quite an undertaking!

[Joey Z]

these two books may help:
http://www.atariarchives.org/dere/
http://www.atariarchives.org/mapping/

as well as some of the others at that same site:
http://www.atariarchives.org/

[sloopy]

Coo... then i wont have to pull my CoCo3 out to play with NitrOS :')

seems the basics of info you need have been covered, so good luck with this endevor, and if you need any testers let me know, i have seen the inside of an A8 before :')

sloopy.

[bbking67]

This is a cool project... actually Atari used 6809 in some of the arcade machines and i think they almost went with the 6809 in the 400/400... apparently motorola was the favorite, but MOS undercut everyone by some margin.

Just curious Boisy, why an XEGS and not a 130XE or 800XL?  I think the XEGS is a cool choice... but just curious what led you to that model.

There aren't any bad 8-bit Ataris...

Edited by bbking67, Mon Jan 23, 2012 8:03 PM.

[Rybags]

Looks like the 6809 has a /HALT pin which functions the same as ours.  As Bob said earlier, this is a must - the CPU not only needs to halt but also leave the buses alone entirely.

Some minimal code to play sound - easy.  Since you need to burn the Eprom for OS anyway you could put it there, or make a bootstrap OS and just run cartridges to save having to pull the computer apart every time you change something.
There's no PORTB setting here.  Normally you'd setup the data direction for output and PORTB to $FF but the powerup state has the OS swapped in, Basic out anyway.

  *= $FFFE
  .word reset
  *= $FF00
reset
  sei
  cld
  ldx #$FF
  txs  ; initialize 6502 mode and stack ptr
  inx
  txa
cleario
  sta $d000,x
  sta $d200,x
  sta $d300,x
  sta $d400,x
  dex
  bne cleario
  lda #3
  sta $d20f ; set Pokey to active
  ldx #$10
delay
  dex
  bne delay ; short delay for Pokey to start, probably not needed
  lda #$a0
  sta $d200
  lda #$a1
  sta $d202  ; set audf1 and audf2
  lda #$a8
  sta $d201
  sta $d203 ; set audc1 and audc2
wait
  jmp wait  ; loop forever

[boisy]

Rybags, on Mon Jan 23, 2012 8:13 PM, said:

Looks like the 6809 has a /HALT pin which functions the same as ours.  As Bob said earlier, this is a must - the CPU not only needs to halt but also leave the buses alone entirely.

Some minimal code to play sound - easy.  Since you need to burn the Eprom for OS anyway you could put it there, or make a bootstrap OS and just run cartridges to save having to pull the computer apart every time you change something.
There's no PORTB setting here.  Normally you'd setup the data direction for output and PORTB to $FF but the powerup state has the OS swapped in, Basic out anyway.

  *= $FFFE
  .word reset
  *= $FF00
reset
  sei
  cld
  ldx #$FF
  txs  ; initialize 6502 mode and stack ptr
  inx
  txa
cleario
  sta $d000,x
  sta $d200,x
  sta $d300,x
  sta $d400,x
  dex
  bne cleario
  lda #3
  sta $d20f ; set Pokey to active
  ldx #$10
delay
  dex
  bne delay ; short delay for Pokey to start, probably not needed
  lda #$a0
  sta $d200
  lda #$a1
  sta $d202  ; set audf1 and audf2
  lda #$a8
  sta $d201
  sta $d203 ; set audc1 and audc2
wait
  jmp wait  ; loop forever

RyBags,

Thanks for the code.  What I'm struggling with now is the assembler.

I've pulled down cc65 which has ca65/ld65 assembler and linker, but trying to get an object that can simply be loaded into the ROM emulator is a challenge.   I am unable to determine how to locate code at a specific offset in the output object file so it can simply be moved into ROM.

What assembler do you use to assemble the above code?

[boisy]

bbking67, on Mon Jan 23, 2012 7:51 PM, said:

This is a cool project... actually Atari used 6809 in some of the arcade machines and i think they almost went with the 6809 in the 400/400... apparently motorola was the favorite, but MOS undercut everyone by some margin.

Just curious Boisy, why an XEGS and not a 130XE or 800XL?  I think the XEGS is a cool choice... but just curious what led you to that model.

There aren't any bad 8-bit Ataris...

I chose the XEGS because it was a system recommended to me by someone. I liked the cool look of the case and thought it would be a great system to start with.  The 130XE was another one I considered, but the XEGS came up on eBay first for me.

[Rybags]

There's multiple assemblers available for the Atari.

PC-based tools is the current way to do things if you're in a hurry.

I use AtAsm but it's kinda aged, MADs is the big thing these days.

I could generate an Eprom-friendly version of that if you want - for the XEGS you need a 32K image.

[Rybags]

 OStest1.bin   32K   111 downloads

Here's a binary of that file.  For whatever reason the assembler generates $FF for empty areas (I guess that's Eprom-friendly in itself)

I've assumed the OS sits at the top of the 32K ROM, if it isn't then try this one, it has the OS at the bottom 16K:

 OStest2.bin   32K   97 downloads

[boisy]

Rybags, on Mon Jan 23, 2012 8:44 PM, said:

OStest1.bin

Here's a binary of that file.  For whatever reason the assembler generates $FF for empty areas (I guess that's Eprom-friendly in itself)

I've assumed the OS sits at the top of the 32K ROM, if it isn't then try this one, it has the OS at the bottom 16K:

OStest2.bin

OStest1.bin works!

Now to find a way to assemble this code.  Thanks so much.

Edited by boisy, Mon Jan 23, 2012 9:06 PM.

[Rybags]

Here's the AtAsm package:

 atasm106.zip   359.73K   101 downloads

Take note of the command-line paramaters.  You need to generate raw binaries, not files with headers.

In that mode, the assembler will create a file with all the empty space.

So just use *=$8000 at the start, with a single .byte 0 after.

Then put the OS stuff anywhere from $C000-$CFFF and $D800-$FFFF, remembering to put your vectors at $FFFA-$FFFF.

The block at $D000-$D7FF is remapped by the Atari to $5000-$57FF when the Self-Test ROM is switched in.

You can use .SET 6 directive in the Assembler to generate code as if at a different origin.

Anything from $8000-$BFFF is the ROM actually maps to $A000-$BFFF.  They are the Basic and Missile Command Roms.  Not sure what order they're in.  Identifying them should be easy though if you can read the ROM externally.  Missile Command should have about 2K worth of zeros at the start of it.

Edited by Rybags, Mon Jan 23, 2012 9:18 PM.

[boisy]

Rybags, on Mon Jan 23, 2012 9:16 PM, said:

Here's the AtAsm package:

atasm106.zip

Take note of the command-line paramaters.  You need to generate raw binaries, not files with headers.

In that mode, the assembler will create a file with all the empty space.

So just use *=$8000 at the start, with a single .byte 0 after.

Then put the OS stuff anywhere from $C000-$CFFF and $D800-$FFFF, remembering to put your vectors at $FFFA-$FFFF.

The block at $D000-$D7FF is remapped by the Atari to $5000-$57FF when the Self-Test ROM is switched in.

You can use .SET 6 directive in the Assembler to generate code as if at a different origin.

Anything from $8000-$BFFF is the ROM actually maps to $A000-$BFFF.  They are the Basic and Missile Command Roms.  Not sure what order they're in.  Identifying them should be easy though if you can read the ROM externally.  Missile Command should have about 2K worth of zeros at the start of it.

Fantastic.  I downloaded and compiled it on my Mac.  Then used this command line:

atasm test.asm -r

Generated a test.bin which, when dumped, has the code generated.  Very nice.  Thanks so much for getting this to me.

With this sound test working, the next step is to get the code translated into 6809, which is a no brainer.  Once we get the 6809 daughterboard circuit finalized, we can use the code to verify bringing up the CPU.

I've got to document this and get some rest.  Thanks again all for the great help!

[Rybags]

Are you sure that Ostest1 worked?

I just realised I had the IRQ vector set instead of the Reset one.

I'll get an update happening, this time with a little screen added too.

[Rybags]

 OStest3.bin   32K   82 downloads

Here's another, this time with screen.  There's no character set available so I just pointed to the program itself.


Source code -
 OStest3.txt   1.09K   100 downloads


Also, if you want to test out in emulation rather than burning Eproms each time, just generate a 16K file instead, use *=$C000 instead of *=$8000

Edited by Rybags, Mon Jan 23, 2012 9:44 PM.