What kind of 65816 do you want?

[adam242]

Running XRAM021 at 14mhz.

 

 

XRAM14.WMV

 

 

 

10 minutes ago, this XL14 was in my 1200XL.

 

No soldering.

 

No wires.

 

 

 

Looks great!

 

I'd like to see a video of an XL14 machine running a CPU-intensive game like Rescue on Fractalus, Mercenary or Flight Simulator II.

 

I've got a feeling either this or a Rapidus (maybe both) will find their way into one (or two) of my machines.

[+bob1200xl]

Actually, they don't look any different, really. Very few games run faster- probably because they use VBI for timings. You really don't want them to. Unplayable. In something like the GUI, you do gain speed and responsiveness. Not on games.

 

Bob

[Theoryman]

So, what happened to this?

 

--

[+bob1200xl]

Still a WIP. I am ready to order PCB version 4. I expect it to be close to optimum.

 

Version 3 in a 1200XL:

 

 

 

[ravard]

Very cool. Glad to hear it is still in the pipeline.

 

ravard

[+bob1200xl]

I spent a lot of time fooling around with the linear memory, in particular the setup time for the data bus that drives A16-A18. At 14mhz you only have 35ns to get it all latched. There is a lot of load on the data bus from PBI devices, carts and such so I finally gave up and am adding a buffer between the CPU/memory and the Atari chips. That should resolve bus issues with linear memory.

 

I take over the cartridge slot when it powers on, disabling any carts plugged in and forcing RD5 high so the OS will see my internal boot cart. This was a lot harder than you would expect it to be. You can't assume what a cart may be doing to RD5 - some carts toggle it at high speed.

 

Bob

[Rybags]

Weird that they'd do that - my thought was the only funny business in that regard was from carts that can swap out and carts that can selectively disable writes to RAM in the $8000-$BFFF address area.

[Theoryman]

If I might ask, what is your memory map?

 

The standard 64K address space is Segment 0. Like conventional memory on a PC.

Atari Pokey Banked memory maps in/out of Segment 0. This equates to Expanded Memory on a PC

Map fast RAM into segments 01-FE as available. Map flash ROM into segment FF. Fast RAM and Flash ROM would have to be on the daughter board. This equates to Extended Memory on a PC

 

My plan is/was original Atari 64K maps as segment 0 with wait states as needed to hold speed to 1.79MHz. With proper decode logic and upgrading the DRAM on the Atari to faster chips, it should be possible to allow ANTIC to access Segment 0 and the Expanded Memory at 1.79MHz while allowing the 65816 to Access Segment 0 and the Expanded Memory at 3.58MHz with wait states added to do hardware accesses at 1.79MHz. ANTIC has no access to Extended Memory.

 

CPU clock speed, while using Segments 1-FF should be independent of ANTIC.

 

With additional decode logic, the 65816 should be able to continue processing in Segments 1-FF without being halted by ANTIC.

 

This will require some clever OS work, especially in interrupt coding.

 

--

[+bob1200xl]

The RD5 signal is connected to the TRIG3 line on GTIA. There are no R/C filters on RD5 so it may be toggled at high speed. A 'normal' cart just ties RD5 to +5v. A cart with logic in it may do any kind of thing with RD5. Added to that, the switching level on the TRIG3 input is not TTL.

 

Bob

 

 

Weird that they'd do that - my thought was the only funny business in that regard was from carts that can swap out and carts that can selectively disable writes to RAM in the $8000-$BFFF address area.

[+bob1200xl]

I use battery-backed SRAM for data storage (NVSRAM) and high-speed SRAM for system memory. Any access to SRAM runs at the clock frequency selected in the config register, 1.79, 7.16, or 14.32mhz. This includes the whole memory space from $000000 to $07FFFF. If you access the NVSRAM, you are limited to 7.16mhz. Any other access, HALT, I/O, CART, and such, runs at 1.79mhz.

 

Everything is on one board that plugs into the CPU socket and cables to the MMU.

 

The DRAM is removed and disabled.

 

You can't run the CPU while HALT is active unless you build an interface between ANTIC and the CPU/SRAM. That's a lot of hardware.

 

No OS changes are needed. IRQs and such work OK at high speed, for the most part.

 

Bob

 

 

 

If I might ask, what is your memory map?

 

The standard 64K address space is Segment 0. Like conventional memory on a PC.

Atari Pokey Banked memory maps in/out of Segment 0. This equates to Expanded Memory on a PC

Map fast RAM into segments 01-FE as available. Map flash ROM into segment FF. Fast RAM and Flash ROM would have to be on the daughter board. This equates to Extended Memory on a PC

 

My plan is/was original Atari 64K maps as segment 0 with wait states as needed to hold speed to 1.79MHz. With proper decode logic and upgrading the DRAM on the Atari to faster chips, it should be possible to allow ANTIC to access Segment 0 and the Expanded Memory at 1.79MHz while allowing the 65816 to Access Segment 0 and the Expanded Memory at 3.58MHz with wait states added to do hardware accesses at 1.79MHz. ANTIC has no access to Extended Memory.

 

CPU clock speed, while using Segments 1-FF should be independent of ANTIC.

 

With additional decode logic, the 65816 should be able to continue processing in Segments 1-FF without being halted by ANTIC.

 

This will require some clever OS work, especially in interrupt coding.

 

--

[Theoryman]

Interesting. Different plan than mine.

 

Get it working and I'd be interested in a copy

 

--

[kenames99]

how is the project coming along Bob?

[+bob1200xl]

I'm waiting for the new boards. Almost done. It will be a race to see if I run out of gates in the CPLD before I run out of I/O pins.

 

It is a long process because you never know if a failure is a hardware problem or a compatibility issue. One, you can fix, the other, not. A lot of guessing...

 

 

Bob

[+mytek]

I'm bumping this. Its been quite awhile since an update was done on the project status, and I am very curious about how the new boards are working out.

 

So if I understand this right, only two things are tied into the motherboard. XL14 plugs into the CPU socket and there is a cable coming from the MMU socket? And all of the original RAM and support chips can be pulled?

 

- Michael

[+mytek]

I use battery-backed SRAM for data storage (NVSRAM) and high-speed SRAM for system memory. Any access to SRAM runs at the clock frequency selected in the config register, 1.79, 7.16, or 14.32mhz. This includes the whole memory space from $000000 to $07FFFF. If you access the NVSRAM, you are limited to 7.16mhz. Any other access, HALT, I/O, CART, and such, runs at 1.79mhz.

 

Everything is on one board that plugs into the CPU socket and cables to the MMU.

 

The DRAM is removed and disabled.

 

You can't run the CPU while HALT is active unless you build an interface between ANTIC and the CPU/SRAM. That's a lot of hardware.

 

No OS changes are needed. IRQs and such work OK at high speed, for the most part.

 

Bob

 

This confirms how I remembered the board hooking into the system (sometimes it's good to read the whole thread from the start ).

 

I saw this working at Bob's house a couple of months ago and it is most impressive. But if I recall correctly, there were still a few glitches from time to time that could be seen in the video. Just wondering if that got resolved. The XL14 as it's called, would be great to install into a mostly virgin system, but not so good if you already have an Ultimate 1 meg since both boards take over the MMU functions. Although if Bob gets this into its final form, much of what the Ultimate does can be done on the XL14 as well, just missing the RTC. Of course I might have overlooked something else, having only a rudimentary knowledge of the Ultimate 1 meg at this time.

 

Anyway here's hoping that this gets Bob's attention, and he chimes in with the latest news on this project.

 

- Michael

 

EDIT: Oh yeah before I forget, the XL14 does not appear to be compatible with the XE line (unless that has changed).

Edited January 28, 2016 by mytekcontrols

[+bob1200xl]

It's very difficult to verify the XL14 operation. On a stock system, running 'standard' hardware and carts, it seems to be OK. I say 'seems' because I don't have a design criteria for the XLs. Even if I did, the ICs jump on and off the bus at odd times. The high speed and low impedance of the CPLD outputs does not play well with the original chips. Newer chips in upgrades that folks have made aren't happy, either.

 

I have two versions of the XL14. Each has its merits, each has its failings.

 

If you do a motherboard, make it 4-layer.

 

Bob

[+mytek]

It's very difficult to verify the XL14 operation. On a stock system, running 'standard' hardware and carts, it seems to be OK. I say 'seems' because I don't have a design criteria for the XLs. Even if I did, the ICs jump on and off the bus at odd times. The high speed and low impedance of the CPLD outputs does not play well with the original chips. Newer chips in upgrades that folks have made aren't happy, either.

 

I have two versions of the XL14. Each has its merits, each has its failings.

 

If you do a motherboard, make it 4-layer.

 

Bob

 

Thanks for the update Bob

 

And yes definitely a 4-layer motherboard is a must.

 

Just curious about one thing. What makes the XL14 incompatible with the XE's? Gotta be FREDDIE, but can't this be bypassed?

 

- Michael

[+bob1200xl]

The OS, CPU and MMU are all the same - don't know why it would not work. Has someone tried this?

 

Bob

[+mytek]

The OS, CPU and MMU are all the same - don't know why it would not work. Has someone tried this?

 

Bob

 

I'm just going by what you put in the first post...

 

Or, you can suggest needed additions to make this more useful. I'm adding what I would want - but I'm just one guy.

 

No:

 

XEs

 

6502.

 

Video stuff.

 

More SRAM memory, DRAM or the like.

 

I refer to this project as the XL14. It has run in an 800XL, a 600XL(!), and a 1200XL.

Unless I'm reading this wrong, it appears that that was a NO on XE's.

 

 

So speaking of the OS, does the XL14 require one to be on the Atari motherboard, or instead can it be only resident in the battery-backed SRAM, like how the U1Meg is set-up? And would this apply to BASIC as well?

 

- Michael

 

EDIT: Since the BASIC on the XEGS's is a part of the single OS ROM chip, likely it would work from the SRAM as well. Although probably need special configuration in the XL14 to accommodate XE variances.

Edited January 29, 2016 by mytekcontrols

[Kyle22]

BASIC (and Missile Command) are only in the same ROM as the OS in the XEGS.

 

It can be done in others, but the XEGS is the only one that was made that way. (I did it to a 1200XL with a few jumpers and MMU swap).

[+mytek]

BASIC (and Missile Command) are only in the same ROM as the OS in the XEGS.

 

It can be done in others, but the XEGS is the only one that was made that way. (I did it to a 1200XL with a few jumpers and MMU swap).

 

Hi Kyle,

 

Yeah I caught myself on that one. I know the XE version of U1Meg can be configured for this variance between the 65/130XE and the XEGS, so I was wondering if Bob planned to have this level of adaptability in the XL14 memory configuration.

 

- Michael

 

EDIT: But I'm talking off the top of my head, since I have yet to get my U1Meg installed and try it out. But if my uniformed brain is right, I think it's handled as Cart Slots in memory, so probably doesn't matter what's in there so long as it conforms to the available slot size.

 

EDIT2: So here is what I am trying to determine. I have a project in the works, and would like to verify that if I implemented independent ribbon style header connectors in place of the normal MMU and XEGS OS sockets on the motherboard, and socketed the CPU, that either the XL14 or the U1Meg would Plug 'n' Play with this set-up. In both cases the OS and BASIC would need to be resident in the SRAM. So far based on the info I've gotten, it appears that this would be doable.

Edited January 29, 2016 by mytekcontrols

[+bob1200xl]

The idea behind the XL14 boot process is to power on into the stock OS chip, have the hardware take over the system by forcing diagnostic mode, set the default configuration, and load a menu. From that menu, you choose your memory configuration, clock speed, OS, and anything else available (disk management stuff, for one). In order for this to work unconditionally, you must boot with the stock OS. Otherwise, the system will not come up if the SRAM is corrupted.

 

If the SRAM OS image is damaged (or, you loaded a new BOOTCODE with a bug in it), the system will come up at 1.79Mhz in the stock ROM OS. From there, you can load new BOOTCODE - no jumpers to move, no standing on your head.

 

The XL14 can implement an internal 8K cartridge.

 

How can the OS be in SRAM? How does it get there in the first place? You have to have some OS in ROM, somewhere.

 

Bob

[+mytek]

The idea behind the XL14 boot process is to power on into the stock OS chip, have the hardware take over the system by forcing diagnostic mode, set the default configuration, and load a menu. From that menu, you choose your memory configuration, clock speed, OS, and anything else available (disk management stuff, for one). In order for this to work unconditionally, you must boot with the stock OS. Otherwise, the system will not come up if the SRAM is corrupted.

 

If the SRAM OS image is damaged (or, you loaded a new BOOTCODE with a bug in it), the system will come up at 1.79Mhz in the stock ROM OS. From there, you can load new BOOTCODE - no jumpers to move, no standing on your head.

 

The XL14 can implement an internal 8K cartridge.

 

How can the OS be in SRAM? How does it get there in the first place? You have to have some OS in ROM, somewhere.

 

Bob

 

Here is Lotharek's latest version of the Ultimate 1 Meg upgrade (LINK)

 

Installation

 

The connector on the left connects (plugs in via ribbon cable) directly in place of the OS ROM, the connector on the right connects (plugs in via ribbon cable) directly in place of the MMU. There are 4 required soldered connections for RW, PHI2, HALT and RESET. Installation done.

 

With the U1Meg there is no longer any OS ROM chip. This function is now served by the U1Meg's Battery-Backed SRAM, and supports up to 4 OS ROM Slots. Now I don't know about the inner workings, but it appears to be that there is some kind of non-volatile boot code and configuration area on the board.

 

And here is a short description of the Ultimate 1 Meg upgrade by Candle...

 

How it works?

 

Since solderless approach was the main driving force behind this, some portions of PIA and GTIA chips had to be simulated within the CPLD chip.

 

When PORTB write is detected, hardware checks if internal shadow of PBCTL (D303) allows writes, and if so, value from Data bus is written to PORTB shadow. In the parallel, last value of PORTB shadow registers is stored into internal MMU CONTROL register to preserve current status of system rom, basic, self-test and missile command rom chips mappings, thus allowing flawless access to whole extended memory array.

 

Since there is internal SDX module care had to be taken for GTIA TRIG3 register.

 

 

 

Normally RD5 line from cartridge port is connected both to MMU chip and GTIA TRIG3 lines and since the goal was to incorporate this extension without the need of cutting any traces on motherboard, this register had to be shadowed (OS checks for TRIG3 status on every NMI, if there is a change on state of this line, OS assumes that cartridge was put in/removed and to prevent failures goes into endless loop).

 

With this shadow of TRIG3 register system can be fooled, and enabling or disabling "external" (to SDX module) cartridges can be done.

 

Lastly, there is configuration register which is used for configuring the extension according to configuration data stored in NVRAM - user can choose which OS ROM should be booted on power-on, what memory size machine should have and if SDX and RTC modules should be enabled.

 

Every time RESET button is pressed, Ultimate1MB BIOS kicks in, and checks if HELP key is pressed. If so, then interactive menu pops up, enabling user to change current configuration. Otherwise, checksum is calculated from the bytes read from NVRAM, if this matches checksum read from NVRAM, then configuration is assumed as valid one, and written into configuration registers. Then normal boot follows.

 

With the XL14 you have completely achieved the "solder-less" upgrade. And perhaps there might also be a way to completely eliminate the need for an OS ROM on the motherboard as is done with the U1Meg. If not, no biggie because your board certainly brings a lot of power in the 65816 accelerator side of things.

 

- Michael

Edited January 29, 2016 by mytekcontrols

[flashjazzcat]

With the U1Meg there is no longer any OS ROM chip. This function is now served by the U1Meg's Battery-Backed SRAM, and supports up to 4 OS ROM Slots. Now I don't know about the inner workings, but it appears to be that there is some kind of non-volatile boot code and configuration area on the board.

The only non-volatile RAM is in the DS1305 RTC chip, which holds the time/date and configuration settings. The OS ROMs are in the 512KB flash ROM chip on the board, which also contains the BIOS, etc.

[Kyle22]

I don't think it matters because the U1Meg looks (to the computer) as if your selected OS is a chip plugged in the OS ROM socket.