267 replies to this topic

[boisy]

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

OStest3.bin

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


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

OStest1.bin did work, but I loaded it up after the computer was running.  I'm using a ROM emulator plugged into the ROM socket of the Atari, so I can change the ROM contents on the fly with a program running on my Mac.  It's a lot faster than burning ROMs

I'm away from the computer for the night, but will try this tomorrow and report results.  Again, thanks for the help.

[Rybags]

Can you get the required 6809 easily these days?

Lots of us have multiple machines so it'd be an interesting project.

[boisy]

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

Can you get the required 6809 easily these days?

Lots of us have multiple machines so it'd be an interesting project.

Yes, they're still obtainable, most notably the CMOS equivalent, the Hitachi 6309.  

Jameco has the 68B09E for $4.95 in quantities of 1-9.

[MrFish]

Early prototypes for the first Macintosh used the 6509E, which of course was eventually dropped in favor of the 68000.

[boisy]

MrFish, on Mon Jan 23, 2012 10:55 PM, said:

Early prototypes for the first Macintosh used the 6509E, which of course was eventually dropped in favor of the 68000.

'

You mean 6809E. Yes, that is my understanding also. It's a fun and powerful little chip.

[MrFish]

boisy, on Mon Jan 23, 2012 10:57 PM, said:

MrFish, on Mon Jan 23, 2012 10:55 PM, said:

Early prototypes for the first Macintosh used the 6509E, which of course was eventually dropped in favor of the 68000.

'

You mean 6809E. Yes, that is my understanding also. It's a fun and powerful little chip.

Ah, you're correct. I was confusing the two chips. Of course they were using a Motorola not an MOS. But yea, the same chip you're working with is what I meant.

[tf_hh]

Hi,

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

cleario
  sta $d000,x
  sta $d200,x
  sta $d300,x
  sta $d400,x
  dex
  bne cleario

Just a little note... this intialization routine will lookup on any XL/XE, if the code was run from ROM, because PB0 of PIA is set to zero and disables the operating system. Better include something like this:

cleario
  sta $d000,x
  sta $d200,x
  sta $d400,x
  cpx $#1
  beq cleario2
  sta $d300,x
cleario2:  dex
  bne cleario

Now $D301 will be skipped and ROM still be active...

[Rybags]

Not really.

The OS stores zeros and skips the last few too.  But, the decoding of PIA means it's replicated 64 times in the address range so every register cops multiple hits.

On top of that, the default state of PIA on powerup is all 1s on the PORTA/B bits, and the default mode is input on all bits, so the store zero isn't affecting it anyway.

[guus.assmann]

Why not also change the MMU chip?
If you want to, here's a backengineered source code.
This enables you to change the complete memory map.
Only the I/O is fixed in some way, as there's an LS138 decoding the individual addresses of the chips.

There should also be a complete cicuit diagram for the XEGS.
But it's really not very much different from the other XL and XE systems.

BR/
Guus

Attached Files

•  MMUXEGS_ORG.zip   1K   46 downloads

[Rybags]

I wonder if Phaeron would be willing to add 6809 to Altirra.  That'd make development a whole lot easier.

Still, I guess we have to find out if the thing actually works first.

[boisy]

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

OStest3.bin

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


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

Rybags,

Assembled OStest3.txt this morning with atasm running on my iMac, downloaded it to the ROM emulator and indeed the video does come up with the code shown as random garbage and the sound playing.  Thanks again.  This is a perfect smoke test for the 6809.

[boisy]

guus.assmann, on Tue Jan 24, 2012 5:00 AM, said:

Why not also change the MMU chip?
If you want to, here's a backengineered source code.
This enables you to change the complete memory map.
Only the I/O is fixed in some way, as there's an LS138 decoding the individual addresses of the chips.

There should also be a complete cicuit diagram for the XEGS.
But it's really not very much different from the other XL and XE systems.

BR/
Guus

Guus,

Thanks.  I'm inclined to not modify the board anymore than I have to.  NitrOS-9 can work around having the I/O in a different area.  It's not a problem, so I'm inclined to leave the devices mapped to where they are and focus on the 6809 adaptation and once that is proven out, the port of the operating system.

[Rybags]

I looked at the Datasheet - the 6809 seems to have a similar Phi0 / Phi2 relationship to the 6502.

Hopefully adaption might be as simple as a board to handle the pin reassignment.

I agree on a minimal modification approach.  What would be real cool would be a board with a socket for both CPUs with a jumper to select which is active.

[guus.assmann]

Hello Boisy,

Yes, I can understand the reasoning for this.
On the other hand, less changes to the NitrOS-9 might be nice as well.

A long time ago I had a processor card with both the (standard) 6502 and 6809 on it. And it could just be switched between the processors.
Both processors were almost piggy-backed.
After looking at the data-sheet for the 6809 (Again just now) I conclude that it is not very difficult to have both processors in the system.
The most difficult part, the /Halt, is already there. Keep one of the CPU's halted.
Just figure out the IRQ line and take care of the NMI. (Different reaction, specially combined with /Halt condition.)
If you choose this approach, it would also be possible to have two different memory configurations.
Just replace the MMU with a Pal22V10 and you're done. The extra inputs can be used to switch between two memory-maps.
I would start with fixing the clock generation part. The 6502 creates the Q1 and Q2 signals from Q0.
This is not present in the 6809. And the system needs a double frequency for the D-Ram's to function.
Generally, just inverting the Q0 to get Q1 and using Q0 for Q2 will usually work fine. (Mind the cautious way I expess this, it's not this simple on all Atari's.)

BR/
Guus

Edited by guus.assmann, Tue Jan 24, 2012 8:45 AM.

[flashjazzcat]

Where's the NitrOS source code in PC-readable format? The insipient A8 GUI might make a nice front-end for the kernel at some point in the future. I have one eye on multi-tasking / task-switching possibilities, although they're not high up the to-do list.

[boisy]

flashjazzcat, on Tue Jan 24, 2012 10:08 AM, said:

Where's the NitrOS source code in PC-readable format? The insipient A8 GUI might make a nice front-end for the kernel at some point in the future. I have one eye on multi-tasking / task-switching possibilities, although they're not high up the to-do list.

I would suggest starting here:  http://www.nitros9.org/

The source is in CVS up on Sourceforge and can be browsed easily.  Building is a whole other matter, however.

[boisy]

Rybags, on Tue Jan 24, 2012 7:34 AM, said:

I looked at the Datasheet - the 6809 seems to have a similar Phi0 / Phi2 relationship to the 6502.

Hopefully adaption might be as simple as a board to handle the pin reassignment.

I agree on a minimal modification approach.  What would be real cool would be a board with a socket for both CPUs with a jumper to select which is active.

Unfortunately a pin for pin swap is not enough.  We've started on a circuit currently design which will generate PHI1 and PHI2 from PHI0 (PHI1 appears to be the inverse of PHI0).

[flashjazzcat]

boisy, on Tue Jan 24, 2012 10:56 AM, said:

flashjazzcat, on Tue Jan 24, 2012 10:08 AM, said:

Where's the NitrOS source code in PC-readable format? The insipient A8 GUI might make a nice front-end for the kernel at some point in the future. I have one eye on multi-tasking / task-switching possibilities, although they're not high up the to-do list.

I would suggest starting here:  http://www.nitros9.org/

The source is in CVS up on Sourceforge and can be browsed easily.  Building is a whole other matter, however.

Yeah - I looked there but all I could find were DSK images.

[boisy]

flashjazzcat, on Tue Jan 24, 2012 12:06 PM, said:

boisy, on Tue Jan 24, 2012 10:56 AM, said:

flashjazzcat, on Tue Jan 24, 2012 10:08 AM, said:

Where's the NitrOS source code in PC-readable format? The insipient A8 GUI might make a nice front-end for the kernel at some point in the future. I have one eye on multi-tasking / task-switching possibilities, although they're not high up the to-do list.

I would suggest starting here:  http://www.nitros9.org/

The source is in CVS up on Sourceforge and can be browsed easily.  Building is a whole other matter, however.

Yeah - I looked there but all I could find were DSK images.

Try this: http://nitros9.cvs.s...ge.net/nitros9/

[flashjazzcat]

boisy, on Tue Jan 24, 2012 12:09 PM, said:

Try this: http://nitros9.cvs.s...ge.net/nitros9/

Thanks! I downloaded the same file earlier but it was 85 bytes long. That link worked, though.

[31336haxx0r]

Regarding the physical fitment of a 690x in a 650x system, I just know this from folklore but maybe there is truth to it: those guys at MOS who invented the 6502 created the 6501 first. It was a direct pin-to-pin compatible replacement for Motorola's 6800. Motorola sued them and won, forcing them to change the pin out a little bit, thus creating the 6502. Therefore it should be rather easy to adapt a 6809 for use in a 6502 system from the hardware point of view.

Edited by 31336haxx0r, Tue Jan 24, 2012 12:50 PM.

[tf_hh]

Hi,

Rybags, on Tue Jan 24, 2012 2:28 AM, said:

Not really.

The OS stores zeros and skips the last few too.  But, the decoding of PIA means it's replicated 64 times in the address range so every register cops multiple hits.

Ok, I miss that point. Thanks!

Regards, Juergen

[Mr SQL]

Hi Boisy,
welcome to the board, great to see another 6809 engineer from the 80's! I agree it's a tremendously powerful chip - so powerful Tandy, Dragon Data, et al. were inclined to leave it to power everything - no hardware based sprites or collision detection! It would be really interesting to see the 6809 equipped with the powerful sound and graphics accelerator hardware of  the Atari XE/XL.
I would imagine the 400/800 with their more exposed architecture would be easier models for this kind of mod. Looking forward to hearing about it!

[boisy]

A quick update.  Gary Becker is helping me with the hardware design.  We discussed his design for emitting PHI1 and PHI2 as well as generating the E and Q signals required by the 6809E.  I will be wiring up a prototype board over the next few days.  Will keep everyone informed of the progress.

[JohnBuell]

The CoCo guys at the last two VCFMW shows are big fans of NitrOS-9. I wonder what they'd think if the Atari machines across the aisle from them next year were running the same thing?

Edited by JohnBuell, Wed Jan 25, 2012 9:43 PM.