267 replies to this topic

[linville]

Boisy, I'm eager to see the schematic for that CPU adapter, especially that clock circuit.  Can you post a copy somewhere?

[boisy]

John,

I've uploaded a copy of the schematic to the gallery.  This was designed by Gary Becker, and we discussed it last night via Skype.

The circuit generates PHI1 and PHI2 from PHI0, and E and Q from a combination of /PHI_0 and RDY.  The RDY line is gated to basically halt the processor by stopping the clocks.

Comments would be appreciated.

[Rybags]

/RDY is available "on demand" by storing to the Wsync register on Antic.  Will this cause any problems?

[boisy]

Rybags, on Thu Jan 26, 2012 7:03 AM, said:

/RDY is available "on demand" by storing to the Wsync register on Antic.  Will this cause any problems?

Interesting.  So the 6502 can write to a register on the Antic and effectively halt itself?  If that's the case, how does it get unhalted?

[Rybags]

It's temporary, released towards the end of a scanline.

Nothing else generates it, so if it was a problem you could omit the connection from your design.  But it is very useful for synchronising video changes to a known position.

[boisy]

Rybags, got it.  I think I'll keep it for now since it seems useful.

[Shawn Jefferson]

Wsync is fundamental to the character of antic-i think you will want to keep it indeed.

[JamesD]

@boisy, and anyone else wanting to try this (boisy probably already remembers this) supposedly, the standard 6809s can only be safely halted around 13 clock cycles in a row or they can loose their register contents.
I don't know how many clock cycles the Antic may steal so I'd stick with the 6309 since it doesn't have that problem.
Frankly, I don't think I've ever read where someone verified the loss of register contents to be true but the 6309 is more powerful anyway.

Interesting project.  It would be nice to have both CPUs in the machine and to be able to select which one you want.

There were some articles in MICRO about a 6809 board for the Apple II.  The author of the article(s) found it was faster to send some math to the 6809 and recover the results than to do the math on the 6502.  I don't remember what kind of math the author was dealing with.

Edited by JamesD, Fri Jan 27, 2012 10:48 AM.

[netdude77479]

Let me introduce myself. My name is Gary Becker. I am helping Boisy in his XEGS project. I have a lot of experience with the 6502, but it has been a few years ago. I do not have any experience with Atari's Sally version. I also have experience with the 6809E. I generated the schematic Boisy posted. I am now working on adapting other signals. I understand Sally has a Halt input. The Halt signal on the 6809E will tristate the address and data bus during the last cycle of the current instruction. I found some information on the Antic chip that gave me some information about the Halt signal and how DMA is accomplished. It appears to me the Antic will expect to be able to grab the bus on the next CPU cycle after asserting the Halt signal. Is this correct? That is not the way the 6809E will do it. It could be easily be 5 or more cycles before the 6809E goes into halt mode. Another question is with the clocks. The PHI 1 and PHI 2 clocks are output from the Sally chip, but the Q and E clocks are inputs to the 6809. During halt mode, does the Sally chip tristate these clocks?

Sorry for having to ask so many questions on my very first post. I look forward to getting to know the Atari systems better.

[bob1200xl]

The 6502 starts each cycle with the 02 clock going low. The addresses set up and 02 goes high for the data transfer portion of the instruction. Then, it repeats.

ANTIC asserts HALT somewhere around the rise of 02. The 6502 tri-states at the next fall of 02. ANTIC releases HALT somewhere around the rise of 02. The 6502 enables at the next fall of 02. Basically, you disable the CPU with a latch - data on HALT, clock on 02.

Bob

[UNIXcoffee928]

boisy, on Mon Jan 23, 2012 8:33 PM, said:

...
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.

Hi, and welcome to the forum!

Keep the XEGS for later. What you need for the initial stages of this project is an original Atari 800, not an XL, but the 800 with the slots. It will greatly simplify your testing, since the original 800 uses a plug-in CPU card.

[boisy]

UNIXcoffee928, on Fri Jan 27, 2012 12:25 PM, said:

boisy, on Mon Jan 23, 2012 8:33 PM, said:

...
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.

Hi, and welcome to the forum!

Keep the XEGS for later. What you need for the initial stages of this project is an original Atari 800, not an XL, but the 800 with the slots. It will greatly simplify your testing, since the original 800 uses a plug-in CPU card.

You're the second person to indicate the XEGS probably wasn't the best first choice.

Other than the 800 having a plug-in CPU card, are there other reasons?  Differences in the processor?  I've invested time and $$$ into the XEGS and really don't mind taking on the harder aspects of this project.

[sloopy]

boisy, on Fri Jan 27, 2012 1:00 PM, said:

UNIXcoffee928, on Fri Jan 27, 2012 12:25 PM, said:

boisy, on Mon Jan 23, 2012 8:33 PM, said:

...
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.

Hi, and welcome to the forum!

Keep the XEGS for later. What you need for the initial stages of this project is an original Atari 800, not an XL, but the 800 with the slots. It will greatly simplify your testing, since the original 800 uses a plug-in CPU card.

You're the second person to indicate the XEGS probably wasn't the best first choice.

Other than the 800 having a plug-in CPU card, are there other reasons?  Differences in the processor?  I've invested time and $$$ into the XEGS and really don't mind taking on the harder aspects of this project.

Most 800's use a plain NMOS 6502, not the Atari Modified 6502C... so it would make a nice setup where you would be able to make a single replacement card that would plug right in, as the ANTIC/GTIA are on this card also...

The XEGS probably isnt the best, but it doesnt really have any major disadvantage over a 130XE besides the ECI port... for the most part the basic system is the same between the 800XL/130XE/XEGS with the 800XL being the LCD, and the 130XE and XEGS expanding on it in two different ways...

sloopy.

[sloopy]

Also in this thread: http://www.atariage....ost__p__2453510

Mimo has made pics of the 800 CPU card, and the 'Personality' card (which is where the OS is...)

to give you an idea of what they look like...

sloopy.

[Rybags]

You can potentially have 97, possibly more, consecutive /Halt cycles.  As stated before, they take effect mid-instruction.

Re choice of machine, I don't think it matters that much.  If you use a ribbon cable to the CPU socket then swapping the board is just as easy.
The XEGS takes seconds to pull apart, and you can do away with the metal shielding to make access easier.

Additionally, if he goes and buys an 800, there's no guarantee it's going to be a plain 6502 variant.

[netdude77479]

bob1200xl, on Fri Jan 27, 2012 12:07 PM, said:

The 6502 starts each cycle with the 02 clock going low. The addresses set up and 02 goes high for the data transfer portion of the instruction. Then, it repeats.

ANTIC asserts HALT somewhere around the rise of 02. The 6502 tri-states at the next fall of 02. ANTIC releases HALT somewhere around the rise of 02. The 6502 enables at the next fall of 02. Basically, you disable the CPU with a latch - data on HALT, clock on 02.

Bob

Thanks for the info Bob.

I believe I understand the timing. The Halt signal on the 6809E will not work for this, but there is a tristate pin I can use. When you mentioned the rise and fall of 02, does that mean Sally continues to drive the clocks? Or do you mean 00. the input clock to Sally which is nearly identical to 02?

Gary

[bob1200xl]

Sally drives 02 all the time - it is the system clock, actually.

00 is skewed from 02 by about 50ns and is not used anywhere that I can see. 01 is only used for a voltage doubler circuit that feeds 10v to the GTIA color phasing pot. You can use any of the 1.79MHZ signals for that.

02 does all the heavy lifting.

Bob

netdude77479, on Fri Jan 27, 2012 7:59 PM, said:

bob1200xl, on Fri Jan 27, 2012 12:07 PM, said:

The 6502 starts each cycle with the 02 clock going low. The addresses set up and 02 goes high for the data transfer portion of the instruction. Then, it repeats.

ANTIC asserts HALT somewhere around the rise of 02. The 6502 tri-states at the next fall of 02. ANTIC releases HALT somewhere around the rise of 02. The 6502 enables at the next fall of 02. Basically, you disable the CPU with a latch - data on HALT, clock on 02.

Bob

Thanks for the info Bob.

I believe I understand the timing. The Halt signal on the 6809E will not work for this, but there is a tristate pin I can use. When you mentioned the rise and fall of 02, does that mean Sally continues to drive the clocks? Or do you mean 00. the input clock to Sally which is nearly identical to 02?

Gary

[bob1200xl]

I replaced the 65C02 with a 65C816 and just latched HALT on the fall of 02, killed the 02 clock only to the CPU and de-gated the bus. Worked fine.

Can you hold 02 down for long periods on the 6809E?

Bob

netdude77479, on Fri Jan 27, 2012 7:59 PM, said:

bob1200xl, on Fri Jan 27, 2012 12:07 PM, said:

The 6502 starts each cycle with the 02 clock going low. The addresses set up and 02 goes high for the data transfer portion of the instruction. Then, it repeats.

ANTIC asserts HALT somewhere around the rise of 02. The 6502 tri-states at the next fall of 02. ANTIC releases HALT somewhere around the rise of 02. The 6502 enables at the next fall of 02. Basically, you disable the CPU with a latch - data on HALT, clock on 02.

Bob

Thanks for the info Bob.

I believe I understand the timing. The Halt signal on the 6809E will not work for this, but there is a tristate pin I can use. When you mentioned the rise and fall of 02, does that mean Sally continues to drive the clocks? Or do you mean 00. the input clock to Sally which is nearly identical to 02?

Gary

[netdude77479]

Thanks again Bob.

01 and 02 driven from the circuit to the main board is not stopped. The Q and E clocks driven to the 6809E are stopped for the RDY signal. I believe the RDY is not needed. It might cause issues with the 6809E if RDY is asserted for long enought time. It looks like the Halt can be directly connected to the 6809E TSC (tristate) pin. This will tristate the address and data buses for a cycle or longer.

Gary

[Rybags]

If you can tristate it, then shouldn't that mean it's effectively suspended in similar manner to /RDY anyway?

Although with the 6502, /RDY isn't effective immediately, but if you were to implement it in some fashion the timing difference vs 6502 shouldn't matter since there's not really a codebase to support yet.

[netdude77479]

One use for the /RDY pin is to streach accesses to slow devices. During the time /RDY is asserted, the 6502 address, R/W, and data bus on writes is kept enabled. The 6809E does not have a /RDY pin, so my method of adding this feature was to stop the clock going to the 6809E. If I used the 6809E TSC, the buses would go away. The 6809E /HALT pin was not usable either. It only stops execution during the last cycle of the instruction.

Gary

[boisy]

An update...

I'm about three wires away from having the prototype completely wired up.  After that I will do a complete design review and continuity check before actually trying it out.

I've also converted the OSTest3 that Rybags posted to 6809 assembly.  I think I've made the translation right and am posting the output of the mamou assembler here as an attachment.  If anyone knows both the 6502 and 6809, please review.

[boisy]

Ok, I am at a loss on how to upload an assembly language source file on this forum.  I've spent the last 10 minutes monkeying around the website trying to figure it out.  I'm just going to post it here.


The Mamou Assembler Version 01.00      01/29/2012 11:23:46      Page 001


00001    F000                           org       $F000
00002                    
00003                    reset                    
00004    F000 1CAF                      andcc     #~$50               mask inter
00005    F002 10CE00FF                  lds       #$00FF              set stack
00006                    
00007    F006 5F                        clrb      
00008                    cleario                  
00009    F007 8ED000                    ldx       #$D000
00010    F00A 6F85                      clr       b,x
00011    F00C 8ED200                    ldx       #$D200
00012    F00F 6F85                      clr       b,x
00013    F011 8ED300                    ldx       #$D300
00014    F014 6F85                      clr       b,x
00015    F016 8ED400                    ldx       #$D400
00016    F019 6F85                      clr       b,x
00017    F01B 5C                        incb      
00018    F01C 26E9                      bne       cleario
00019    F01E 8603                      lda       #3
00020    F020 B7D20F                    sta       $D20F               set POKEY
00021                    
00022                    * delay POKEY (possibly not needed)
00023                    delay                    
00024    F023 1F01                      tfr       d,x
00025                    subloop                  
00026    F025 830001                    subd      #$0001
00027    F028 26FB                      bne       subloop
00028                    
00029                    * setup DLIST ptr
00030    F02A BEF062                    ldx       >dlist
00031    F02D EC84                      ldd       ,x
00032    F02F F7D402                    stb       $D402
00033    F032 B7D403                    sta       $D403
00034    F035 8622                      lda       #$22
00035    F037 B7D400                    sta       $D400               DMA mode n
00036    F03A 86F0                      lda       #$F0
00037    F03C B7D409                    sta       $D409               CHBase at
00038    F03F 86A0                      lda       #$A0
00039    F041 B7D200                    sta       $D200
00040    F044 86A1                      lda       #$A1
00041    F046 B7D202                    sta       $D202               set audf1
00042    F049 4F                        clra      
00043    F04A B7D01A                    sta       $D01A               color bord
00044    F04D 8682                      lda       #$82
00045    F04F B7D018                    sta       $D018               color back
00046    F052 86CA                      lda       #$CA
00047    F054 B7D017                    sta       $D017               PF1 color
00048                    
00049    F057 86A8                      lda       #$A8
00050    F059 B7D201                    sta       $D201
00051    F05C B7D203                    sta       $D203               set audc1
00052                    
00053    F05F 7EF05F     wait           jmp       wait                loop forev
00054                    
00055                    dlist                    
00056    F062 70707070                  fcb       $70,$70,$70,$70
00057    F066 42                        fcb       $42
00058    F067 F06F                      fdb       screen1
00059    F069 42                        fcb       $42
00060    F06A F06F                      fdb       screen1



The Mamou Assembler Version 01.00      01/29/2012 11:23:46      Page 002


00061    F06C 41                        fcb       $41
00062    F06D F062                      fdb       dlist
00063                    screen1                  
00064    F06F 00010203                  fcb       0,1,2,3,4,5,6,7,8,9
00065    F079 0A0B0C0D                  fcb       10,11,12,13,14,15,16,17,18,19
00066    F083 00010203                  fcb       0,1,2,3,4,5,6,7,8,9
00067    F08D 0A0B0C0D                  fcb       10,11,12,13,14,15,16,17,18,19
00068                    
00069                    
00070    FFDE                           org       $FFDE
00071    FFDE F000                      fdb       reset
00072                    

Assembler Summary:
- 0 errors, 0 warnings
- 72 lines (60 source, 10 blank, 2 comment)
- $0099 (153) bytes generated
- No output file

[boisy]

An update: I found a few errors in the assembly language above and have corrected them.  I've also verified that the code is in the correct offset in the $8000 sized ROM file that I'm uploading to the ROM emulator.

I've wired up the board, did final design checks and missed a few things, so fixed those up and gave it the big test... loaded up the translated 6809 code into the ROM emulator, plugged in the satellite board with the 6809E socketed, and...

Nothing.

Well, not quite.  I get a funky green screen but no sound or video like I do with the 6502C and the test ROM…

Remove the satellite board, put the 6502C back in, load the ROM emulator with the OSTest3 code and it comes up with the graphic and sound.  So everything is still working.  At least nothing is blown up or burnt.


At this point I'm not sure if the '09 is coming to life or not.  I don't have a scope, so I'm pretty much dead without one.  It's time I get one though.  This may be the impetus.

[Rybags]

Black screen should be the first sign of life since we write zeros to the I/O area.

But that's often the default (background usually starts black or brown) - you could change that e.g. with lda #$c6 / sta $d01a after the cleario loop ( $c6 = medium green)