My Atari XEGS Project

[potatohead]

Does Level 1 have the ability to use bank switched RAM pages?

[boisy]

Does Level 1 have the ability to use bank switched RAM pages?

 

Not inherently, no. There is no support in the kernel for managing bank switching for processes. That's what Level 2 does.

 

Now, that said, there was an upgrade years ago for the CoCo 1 and 2 that I recall in Rainbow magazine. I think it was an internal RAM disk? I think it came in 256K or 512K configurations, and it had Level 1 drivers. What could happen in that case is the driver would mask interrupts then switch out a portion of the 64K address space, and map in the appropriate block from the ram disk, the do copies back and forth. Of course care would have to be taken to ensure that the driver was out of that area, as well as the area being copied to/from.

 

But that's the only example of bank switching that I can think of for Level 1.

[Rybags]

I checked your blog entry earlier, re PIA problems.

 

I guess you've probably worked it out, but you need to configure the data direction to properly control bank-switching.

Default is that all outputs are $FF which means OS ROM in, Basic out (PortB).

 

PortA is joysticks so you generally want them to be inputs.

 

To set each port for data direction config, write $38 into the PxCTL register, then write 1s to PORTx bits you want to be outputs.

Then set each port back to normal I/O by writing $3C into the PxCTL register.

 

Quick reminder about a the not well documented behaviour for PORTB banking:

 

bit 7 0 = Self-Test switched in, but only if OS Rom is also switched in

bit 6 0 = Missile Command @ $A000 but ony if Basic Rom is switched out

 

bit 1 0 = Basic switched in

bit 0 1 = OS Rom switched in, opposite behaviour for this bit vs all the others relating to Rom.

Edited February 28, 2012 by Rybags

[boisy]

I checked your blog entry earlier, re PIA problems.

 

I guess you've probably worked it out, but you need to configure the data direction to properly control bank-switching.

Default is that all outputs are $FF which means OS ROM in, Basic out (PortB).

 

PortA is joysticks so you generally want them to be inputs.

 

To set each port for data direction config, write $38 into the PxCTL register, then write 1s to PORTx bits you want to be outputs.

Then set each port back to normal I/O by writing $3C into the PxCTL register.

 

Quick reminder about a the not well documented behaviour for PORTB banking:

 

bit 7 0 = Self-Test switched in, but only if OS Rom is also switched in

bit 6 0 = Missile Command @ $A000 but ony if Basic Rom is switched out

 

bit 1 0 = Basic switched in

bit 0 1 = OS Rom switched in, opposite behaviour for this bit vs all the others relating to Rom.

 

Rybags,

 

Thanks. I am doing this and it's working. I've also documented these extra bits in the 'atari.d' definitions file that is part of the NitrOS-9 port.

[boisy]

A quick update... 57.6Kbps is now working and prototype boards came in today. Posted a new entry on the blog.

[UNIXcoffee928]

I've been actively following this project, and I think that what you are doing is extraordinary!

 

Would you consider a MC68008 project, once this project is fully functional?

 

A MC68008 would really be the missing link for the Atari 8-bit; since 68000 assembly code for the ST, Amiga, Mac, etc. could be used. No rush, of course, I'm just interested in hearing your perspective on such an endeavor, as an engineer.

 

*(For those of you who are unaware of the MC68008, there is a very good MC68008 small computer primer here.)

 

Thanks for your dedicated work; I am truly amazed at what you've accomplished so far!

[Rybags]

That'd be a good idea... I believe we could have a higher clock speed too since the 68K can operate with wait-states.

[sloopy]

Use a regular 68000, not the 68008... why put an artificial and unneeded limit on the thing before you even start?

 

and even better would be a 020 or 030... read the hardware ref's for them, and you will find out why they would be even easier to use...

 

 

sloopy.

[Rybags]

But will a 68000 work on an 8-bit data bus (including the built in RAM) ?

 

I guess the other limitation regardless is that ROM vectors have to appear over the top of low Ram.

Edited March 1, 2012 by Rybags

[andym00]

Would love to see a 68008 board for old 8bits, that'd be awesome, although half of me thinks it'd be ludicrous at the same time, but an A8 with 16MB of linear RAM would be a slightly mental device to say the least

I have to mention DTACK Grounded, for a wonderful tale of 68K fun and games and building 68K boards back in the day, ~81 onwards.. A great read, and there's some fascinating information buried away in there if you've got the time to read all the newsletters.. http://www.easy68k.com/paulrsm/dg/

[boisy]

I've been actively following this project, and I think that what you are doing is extraordinary!

 

Would you consider a MC68008 project, once this project is fully functional?

 

A MC68008 would really be the missing link for the Atari 8-bit; since 68000 assembly code for the ST, Amiga, Mac, etc. could be used. No rush, of course, I'm just interested in hearing your perspective on such an endeavor, as an engineer.

 

*(For those of you who are unaware of the MC68008, there is a very good MC68008 small computer primer here.)

 

Thanks for your dedicated work; I am truly amazed at what you've accomplished so far!

 

Thanks for the comments. Yeah, a 68K would be cool, but a little out of my league I'm afraid I think that the reason the Liber809 worked so well (and went so quick) was because of the very common characteristics between the 6502 and 6809 electrically. Aside from the HALT management and E clock generation chips on board, everything else was pretty much pin reassignments.

 

And the reason the NitrOS-9 port went so quick is because I'm intimately involved in that project and know the OS quite well.

 

Honestly, my next goal is to get the Liber809 on other 6502 platforms (Commodore 64, Apple II). There will probably have to be different adaptations of the board made for those. But hopefully the Liber809 can inspire others in the A8 community to do a 68K crossover board. We had a guy in the CoCo community once who did something like that called "The Rocket". It was a 68K processor upgrade for the CoCo 3. Sadly, he couldn't get funds to continue the project, and it went under.

Edited March 1, 2012 by boisy

[UNIXcoffee928]

Thanks for the comments. Yeah, a 68K would be cool, but a little out of my league I'm afraid ...

 

You're welcome. Ha, you're just being modest, maybe one day you'll have some time, and can look into it.

 

Use a regular 68000, not the 68008... why put an artificial and unneeded limit on the thing before you even start?

 

and even better would be a 020 or 030... read the hardware ref's for them, and you will find out why they would be even easier to use...

 

sloopy.

 

With /VMA & /VPA ? How would you do it?

Edited March 1, 2012 by UNIXcoffee928

[boisy]

The remaining parts came in and I finished the assembly during lunch and tried it out. Everything works. See the Liber809 blog for the latest post.

[visionik]

Awesome!

[boisy]

An update.... Gary and I have started planning for the subsequent run of the Liber809 boards. Obviously it will be a finished board with silk screen printing and a solder mask. To lessen part count, we're going to go with a PAL to subsume the logic that currently exists with the J/K flip flop, inverters and NAND gates. This should reduce power requirements as well and optimize the design for best performance.

 

One question: Sloopy suggested we place a 50 pin header on the board for PBI extensions. It adds a little space to the board and some complexity to the layout. Is this something that would make or break the selling of this board? I'm not opposed to placing it, but I do want to keep the design as simple as possible.

[random_rodder]

In addition to all of my CoCo stuff, I have an Atari 800XL, and would be interested in a board. However, I have no clue what the PBI extensions are...?

[venom4728a]

I am interested in one or two depending on price.

[Rybags]

Adding PBI won't make or break the project.

 

But it could greatly widen the market of potential users as some would like it just for the added PBI

 

You could have multiple config/price points:

- board with PBI, user swaps in their 6502, 6809 slot unpopulated

- board without PBI, user swaps in 6502, 6809 slot populated

- board with PBI + 6809, user swaps in 6502

 

A sticking point though is with the OS ROM slot. Not many people can force feed via the PC or build their own board with a pair of EProms.

[boisy]

Adding PBI won't make or break the project.

 

But it could greatly widen the market of potential users as some would like it just for the added PBI

 

You could have multiple config/price points:

- board with PBI, user swaps in their 6502, 6809 slot unpopulated

- board without PBI, user swaps in 6502, 6809 slot populated

- board with PBI + 6809, user swaps in 6502

 

A sticking point though is with the OS ROM slot. Not many people can force feed via the PC or build their own board with a pair of EProms.

 

And that's the crux here. Using the 6809 requires having a different ROM and that requires plugging and unplugging THAT, even though you can set jumpers to switch between CPUs.

 

Looking at the PBI here (http://en.wikipedia.org/wiki/Parallel_Bus_Interface), if we are to get the signals purely from the daughterboard, we wouldn't have access to pins 2, 41, 43, 44, 46, or 49. How would a PBI connector with an incomplete set of signals be received by potential buyers?

 

At this point, I would opt for simple: a single daughterboard that just had enough room for the 6809, the timing chip and the PAL. I would imagine many Atari users of the Liber809 would have a spare Atari to dedicate just for the 6809, so switching wouldn't be that big of a deal, especially in light of the ROM swap that would be needed.

[+Stephen]

It's quite easy to run multiple ROMs though - the same jumper that determines CPU could be used to swap out OSes.

[Rybags]

My preference would be to keep the cost down.

 

Also, not everybody has an XEGS anyway so not having PBI is no great loss. If enough people wanted PBI for their XEGS, that could be done as an entire seperate project not within the scope of this one.

 

I'd like to get onboard, but don't have lots of time to devote. My input would probably be the occasional game or utility conversion, it'd be interesting to translate stuff from 6502 - 6809.

 

If it comes down to a case of the board being 6809 only (no 6502) it wouldn't bother me too much. I'd be willing to dedicate one machine to that purpose and it's not as if it's irreversable anyway.

[JamesD]

And that's the crux here. Using the 6809 requires having a different ROM and that requires plugging and unplugging THAT, even though you can set jumpers to switch between CPUs.

 

Looking at the PBI here (http://en.wikipedia....l_Bus_Interface), if we are to get the signals purely from the daughterboard, we wouldn't have access to pins 2, 41, 43, 44, 46, or 49. How would a PBI connector with an incomplete set of signals be received by potential buyers?

 

At this point, I would opt for simple: a single daughterboard that just had enough room for the 6809, the timing chip and the PAL. I would imagine many Atari users of the Liber809 would have a spare Atari to dedicate just for the 6809, so switching wouldn't be that big of a deal, especially in light of the ROM swap that would be needed.

I don't think very many people will take advantage of a PBI. With all the small internal or cart based expansion options I don't see why you would need it for more than bragging rights.

 

FWIW, there isn't much point switching CPUs if you can't switch ROMs. If there isn't some sort of ROM switch option, you might as well make the board 6809 only and slightly cheaper.

 

If you look into switching ROMs, off the top of my head I see a couple options that would keep things reasonably simple.

 

1. Place a ROM (FLASH) on the Liber809 that can hold both OS's, run a connection to the chip select of the regular ROM socket for address decoding, and use one address line to select which ROM area to use. The address line would be switched with the same jumper that switches CPUs.

2. Add a connector to control an external ROM switcher when you switch CPUs.

 

I think the latter would be the better approach because it would be cheaper and have minimal impact on the design. If someone wants to switch ROMs they could build an adapter and just use the control signal from the Liber809.

[boisy]

I'm running into an issue with the latest version of the Liber809 firmware and I don't know what's causing it. I'm hoping a code review from others can help.

 

All files related to the project are now on GitHub: https://github.com/boisy/liber809

 

If you look at the atari/liber809.asm, that's the heart of the firmware: https://github.com/boisy/liber809/blob/master/atari/liber809.asm

 

The ROM is set to live in addresses $F400-$FFFF. $F400-$F7FF contains the 1K character set, and right after that, at $F800 is the display list. Following that is the code.

 

Two versions of the firmware are built: one that runs in ROM mode and another that puts the Atari in All-RAM mode.

 

If I run the ROM mode version of the ROM, the screen looks good. I can see the normal boot screen with the sign on and chars. Then the ROM starts acquiring data from the DriveWire server then eventually jumps to that code.

 

However, if I run the RAM mode version of the ROM, the screen is composed of alternating blue and white lines, as thought the screen is totally off. The code that requests data from the DriveWire server still works, and the code is acquired and jumped into as normal.

 

It almost appears to me that the display list is referenced fine from the ANTIC while it is ROM at $F800, but if it exists in RAM at $F800, the ANTIC has a problem with it.

 

If you look at the code there is a conditional called ALLRAM_MODE. It is set by the assembler on the command line and if set to 0, builds the ROM mode version. If set to 1, it builds the RAM mode version. You can see the code that is brought in as a result of the all RAM mode.

 

I would appreciate any ideas as to what might be happening. The code seems very solid but something is odd with the ANTIC access to the RAM.

[boisy]

Just a follow-up on my last post. I've since discovered that the behavior of the code changes depending on the processor put in the Liber809. Even 68B09Es with the same production number can act differently. I can only surmise that there must be some subtle timing or capacative characteristics that are slightly different between processors that we're hitting against here. Out of a batch of 15 68B09E's that I have, approximately 8 show the proper screen in RAM mode, while the remaining 7 behave differently, from either showing klutzy graphics on the screen but still working (the 6309 I have behaves this way), to not passing the ROM / RAM test and going to the "GoCrazy" routine in the code.

 

I've discussed this with Gary and he suggests getting more samples from the logic analyzer. One thing for certain though, we will be removing the 6502C socket from subsequent runs of the board and simply have the 6809E socket.

[+bob1200xl]

The ANTIC timing is a problem when you alter the clock relationships. I don't know what ANTIC looks like internally, but it does not latch data when it should. If you skew the clocks the wrong way, ANTIC pulls data from the ROM after the ROM it has been de-selected - gives you a flash of 1 line of $FF character data. It seems to get worse when you have a REFRESH cycle between two character set HALT cycles.

 

Run the timing of your logic analyzer up to 5ns and sync on !HALT. See if you can catch the data timing vs. the 02 clock while ANTIC is in control of the bus. Compare the ROM timings with the RAM timings?

 

Bob