7.16mhz 1200XL

[ndary]

This upgrade mode looks very promissing and very usefull... easy to add and easy to use...

i think ABBUC entery name is misSleading to the potential of this device.

[Allas]

Is it necessary to remove the old memory to work with this hardware?

I have only 800XL with soldered memories.

[Mathy]

Hello Bob

 

The XE already has a 14.31318 MHz crystal. Why not use that (in the XE)? Or something that multiplies the system clock?

 

Greetings

 

Mathy

[pepax]

This upgrade mode looks very promissing and very usefull... easy to add and easy to use...

i think ABBUC entery name is misSleading to the potential of this device.

It's not the only misleading name in the list......

[dmlloyd]

A 65816 can address 16 megabytes without bank switching if you want a machine with more memory. Only issue is the software that requires Freddie style bank switching. You probably have to do some fancy wiring to make your machine backward compatible with software that uses 130XE bankswitching. Not a whole lot of software was released, some people probably just won't even bother with a Freddie.

 

Not to be pedantic, but I always feel the need to correct this misconception. Freddie has nothing to do with bank-switching whatsoever. All it does is clock generation, and some DRAM timing stuff.

 

That said, I think that if ever an '816 mod comes along that addresses more than 64k, it should do so in a manner compatible with XE bank switching. So bank 01 is the first 64k of extended RAM (the extra 64k that you'd get in a stock 130XE), and so on. This gives ANTIC the ability to access memory outside of bank 00 but still within the '816 address space, which I think is important.

[Bunsen]

Pepax and Bob, what do you suggest?

 

I will try to change the entry names.

[pepax]

Pepax and Bob, what do you suggest?

 

I will try to change the entry names.

 

IMHO all the names are so boring that it gives no entry any unfair advantage.

Only someone with physical access to all the items can rename/better describe them, I'm familiar with just one.

[mimo]

Thanks, yes I think you have covered it for me.

Basically as a games player this has no benefit to me.

It all sounds very cool though

 

Mimo

What does it do? Or, how does it do it?

 

What it does is run code in RAM much faster than a stock Atari. You don't have to change the program at all, you just need to execute it from RAM. David Ahl's Benchmark runs in 15 seconds under TBXL, for example. It does not speed up SIO transfers because they are done in hardware. It generally doesn't affect the audio because that is also hardware. Keyboard delay and repeat are normal. For things like BASIC, it is generally enough to just move the OS into RAM. This allows the FP code and the drawing routines to run at 7.16mhz. Graphics that took 1 minute to draw will now take 20 seconds.

 

How does it work? The circuit looks at the output from the Atari PAL at the start of every cycle. (this is the chip that selects the OS, cart, RAM, or I/O that we will access) If we are going to RAM from the CPU, the 7.16mhz clock is selected. Anything else slects the 1.79mhz clock.

 

Does that answer your question?

 

Bob

 

 

 

In layman's terms, what does it do?

[Rybags]

As a "games player", this upgrade is very relevant.

 

Think along the lines of 20-30 reasonably sized software sprites instead of ~ 10.

Not to mention the ability to do several colour changes per scanline with little trouble. Multiple H-positioning of hardware objects.

Digitized sound effects at 16 KHz with much less slowdown for other tasks.

Ability to perform calculations and 3D fill for games such as Carrier Command.

[+David_P]

And have you tried softloading Drac030's '816 ROM? Does it speed things up?

 

It is not intended to speed things up. It just allows new programs to fully utilize the 65C816 potential (i.e. the "native", 16-bit mode).

 

Sorry for the lack of precision on my part - I was wondering about the combination of the board with the OS - and hence the increase due to the faster CPU and, in certain instances, the faster routines in the OS (E: and floating point come to mind as places where you've optimized the OS).

 

Those two factors combined could do great things.

 

I'm also still hopeful that a revised / refined iteration might add RAM - though I suspect creating 130XE compatibility for the first additional 64K may be overly complex. On the other hand, I'm not sure what logic would be required to lock ANTIC into bank 0 while the CPU runs off to play in higher memory ranges.

 

Regardless, even with 64K I'd grab one in a heartbeat.

[ataridano]

That said, I think that if ever an '816 mod comes along that addresses more than 64k, it should do so in a manner compatible with XE bank switching. So bank 01 is the first 64k of extended RAM (the extra 64k that you'd get in a stock 130XE), and so on. This gives ANTIC the ability to access memory outside of bank 00 but still within the '816 address space, which I think is important.

 

I would think the reverse to be true. The 130XE is the only A8 to come with banked memory when new and so far this upgrade isn't even designed for the XE machines. While the XE bank switching scheme is slick, having a linear memory model would make life for the programmer much easier. Bob; the '816 can address more than 64k, without giving away too many details of your project, is there any technical reason that there couldn't be a couple more SRAMs wired to upper address space? It sounds like the goal of this project is to keep the hardware simple and I would think this to be the simplest way to address additional memory. On the other hand, if this complicates things, I think the boost in CPU speed is *much* more valuable than the additional memory (any more a swap file on a fast hard drive or ram drive is a good way around the 64k limit too).

[Rybags]

I'd think E: might speed up the scrolling a bit. Stuff like key rate would remain identical since it's VBlank dependant.

 

Bob: What happens from the low-down point of view, for example with program running from ROM with intermittent RAM access.

For convenience, let's call the 7 MHz machine ticks cycles 0,1,2,3. Cycle 0 corresponding to the commencement of normal machine cycles on a 1.78 MHz machine.

 

Say a program has data access as such: ROM, RAM, RAM, ROM on cycles 0, 0, 1, 2 (where we have the obvious wait-state after a ROM access).

Would the subsequent ROM access have wait-states inserted beforehand such that it always occurs on that 4 cycle boundary?

[DamageX]

There are 512KB 32-pin SRAMs that would plug right in there. I'm guessing a chip would just have to be added to latch the highest byte of the address. But making the extra fast RAM accessible also via the 130XE scheme would be a bear.

 

Anyway, it's nice to see this get built. Accelerators have been an often discussed fantasy but for a few exceptions.

Edited September 5, 2008 by DamageX

[STGAC]

That IS a 512K SRAM in there... why would the 130XE scheme be any more complex on this thing than on any other 1200XL? Just has to be fast, right?

 

Bob

 

 

 

There are 512KB 32-pin SRAMs that would plug right in there. I'm guessing a chip would just have to be added to latch the highest byte of the address. But making the extra fast RAM accessible also via the 130XE scheme would be a bear.

 

Anyway, it's nice to see this get built. Accelerators have been an often discussed fantasy but for a few exceptions.

[STGAC]

The linear memory requires a latch on the data buss to capture the upper 8 bits of the address. This works fine - most of the time. Under some unknown conditions, one of the other Atari chips gates data onto the buss and throws you out into nowhere-land. Doesn't happen very often, but it kills you. On a stock Atari, who cares if there is spurious data on the buss for the first 100ns or so...

 

I've built it with linear memory and it's really nice. You don't have to be in '816 mode to use it - just execute a long address load or store, even in 8-bit, 6502 emulation. But, the machine is less stable that way. Larry White has the linear memory machine, I think. (no, maybe not... I dunno)

 

For now, you could just RAMBO/320XE the thing if you want more memory. All the inputs are static except A14 and A15, which come from the CPU in plenty of time. Use very fast logic - a CPLD like the ATF750C at 10ns would work, I'm sure. You would have to bring PB0-PB7 up to the XL7 board - everything else is there.

 

Bob

 

 

 

That said, I think that if ever an '816 mod comes along that addresses more than 64k, it should do so in a manner compatible with XE bank switching. So bank 01 is the first 64k of extended RAM (the extra 64k that you'd get in a stock 130XE), and so on. This gives ANTIC the ability to access memory outside of bank 00 but still within the '816 address space, which I think is important.

 

I would think the reverse to be true. The 130XE is the only A8 to come with banked memory when new and so far this upgrade isn't even designed for the XE machines. While the XE bank switching scheme is slick, having a linear memory model would make life for the programmer much easier. Bob; the '816 can address more than 64k, without giving away too many details of your project, is there any technical reason that there couldn't be a couple more SRAMs wired to upper address space? It sounds like the goal of this project is to keep the hardware simple and I would think this to be the simplest way to address additional memory. On the other hand, if this complicates things, I think the boost in CPU speed is *much* more valuable than the additional memory (any more a swap file on a fast hard drive or ram drive is a good way around the 64k limit too).

[STGAC]

In your example, the cycles would be: 0,0,1,0. Non-RAM access always starts on cycle 0 and ends on cycle 0. Yes, the 'wait state' occurs before ROM access. (cycles 2 and 3 in your example) Repetitive ROM (non-RAM) accesses don't need alignment - you'll just stay on the 1.79mhz clock and start on cycle 0 for each access.

 

It should be evident that you won't see much difference in speed while you're running from ROMs. I considered using fast(er) Flash for ROMs. That may let us run at 3.58mhz.

 

Serial FRAMs, even in the cartridge, will probably run at 7.16mhz. Parallel FRAMs may or may not.

 

There are lots of things to try... so many toys, so little time.

 

 

Bob

 

 

 

I'd think E: might speed up the scrolling a bit. Stuff like key rate would remain identical since it's VBlank dependant.

 

Bob: What happens from the low-down point of view, for example with program running from ROM with intermittent RAM access.

For convenience, let's call the 7 MHz machine ticks cycles 0,1,2,3. Cycle 0 corresponding to the commencement of normal machine cycles on a 1.78 MHz machine.

 

Say a program has data access as such: ROM, RAM, RAM, ROM on cycles 0, 0, 1, 2 (where we have the obvious wait-state after a ROM access).

Would the subsequent ROM access have wait-states inserted beforehand such that it always occurs on that 4 cycle boundary?

[drac030]

And have you tried softloading Drac030's '816 ROM? Does it speed things up?

 

It is not intended to speed things up. It just allows new programs to fully utilize the 65C816 potential (i.e. the "native", 16-bit mode).

 

Sorry for the lack of precision on my part - I was wondering about the combination of the board with the OS - and hence the increase due to the faster CPU and, in certain instances, the faster routines in the OS (E: and floating point come to mind as places where you've optimized the OS).

 

These are somehow faster in the OS, yes. And I already have an idea how to accelerate E: more radically. As for the floating point, I think that ROM is clocked still at 1,77 MHz (or 1,79), so the speedup is not too significant. And this is good because otherwise SIO would not work, or could have some problems. For the same reason, I also expect problems in the SpartaDOS, which loads its SIO drivers into RAM. In Sparta X we already added loop calibration to tune the SIO delay loops in case the machine is accelerated.

 

As for the FP, Initially I wanted to use the Charles' Marslett FASTCHIP and speed it up with 65C816 instructions, but I dropped the idea after I have discovered, that FASTCHIP conflicts somehow with Turbo BASIC XL, so that TBXL operators "raise to power" and "LOG" do not work correctly.

[yorgle]

Forgive my ignorance on this stuff, folks, but would this increased processor speed lend anything to the idea of a practical 80 column display? I seem to recall talk about screen updating speed as an 80 column issue in other posts.

[Beetle]

My 512k SRAM upgrade (by BigBen/Mega-Hz) is battery backed and non-volatile for at least 5 weeks with nothing but a 0.47F goldcap as 'battery'. Its also switchable to write-protected.

 

If we exchange the OS EPROM against a battery backed SRAM chip with OS inside (and make write protect) -

Is it possible OS routines could always run in turbo mode? Well, i guess this would need a new designed Board with space for the OS-SRAM on the upgrade....

 

Looking forward to your upgrade Bob1200XL!

Edited September 5, 2008 by Beetle

[peteym5]

Forgive my ignorance on this stuff, folks, but would this increased processor speed lend anything to the idea of a practical 80 column display? I seem to recall talk about screen updating speed as an 80 column issue in other posts.

 

You could do 4x6 pixel characters much faster, but you are still limited to 320 pixels across. Access to the Atari video will be faster, but still can only update the registers at 1.79 mhz. The XEP80 won't gain any speed because it goes through the joystick port. One ideal is add that proposed FRAM thing to this board (Fram is something people were proposing to put on a cartridge). Maybe have a side bus running at 7.16mhz.

 

One issue is combining this thing with Videoboard XE, if this processor board goes over where the VBXE has to plug it, it would be harder to put both in at the same time.

[Tezz]

This upgrade has me particulary interested or rather I should say an XE equivelent would be to me. I've been hoping for a 816 upgrade to be utilised for a while. The potential (in 8 bit terms) is great and it's still essentially an enhanced Atari rather than an additional piece of add-on hardware such as the VBXE and so it seems to make more sense to me to want to install it and not feel like I'm turning it into something else.

[STGAC]

Well, not exactly. The cartridge will have the FRAM and pretty much work with either a stock machine or the XL7. The XL7 will be able to access the FRAM at a much higher speed, however. Even if we continue to run the FRAM itself at 1.79mhz, the XL7 could access it on just about every other cycle, where a stock Atari can only write to the FRAM every six cycles or so... (something like that) Should make screen updates much faster. No code or hardware changes needed in the video cartridge, either.

 

Bob

 

 

Forgive my ignorance on this stuff, folks, but would this increased processor speed lend anything to the idea of a practical 80 column display? I seem to recall talk about screen updating speed as an 80 column issue in other posts.

 

You could do 4x6 pixel characters much faster, but you are still limited to 320 pixels across. Access to the Atari video will be faster, but still can only update the registers at 1.79 mhz. The XEP80 won't gain any speed because it goes through the joystick port. One ideal is add that proposed FRAM thing to this board (Fram is something people were proposing to put on a cartridge). Maybe have a side bus running at 7.16mhz.

 

One issue is combining this thing with Videoboard XE, if this processor board goes over where the VBXE has to plug it, it would be harder to put both in at the same time.

[+David_P]

These are somehow faster in the OS, yes. And I already have an idea how to accelerate E: more radically. As for the floating point, I think that ROM is clocked still at 1,77 MHz (or 1,79), so the speedup is not too significant. And this is good because otherwise SIO would not work, or could have some problems. For the same reason, I also expect problems in the SpartaDOS, which loads its SIO drivers into RAM. In Sparta X we already added loop calibration to tune the SIO delay loops in case the machine is accelerated.

 

Ah, but you can always copy the ROM to RAM and enjoy the faster speed - though you are correct, it may be necessary to re-write SIO code to maintain compatibility.

 

 

And to Bob the Builder:

 

On the 130xe you can have Antic and CPU accessing different 16K banks; I would guess that implementing that feature when using the linear 65816 memory mode would be a challenge (particularly since the PIA bank switching would do nothing). An additional level of complexity in the circuit for minimal return (other than speeding up the Sea of Disks demo)...

[STGAC]

I have not considered a linear ANTIC memory expansion - not sure how it would work since ANTIC only has 15 address bits. ANTIC certainly isn't going to run any faster, no matter what memory it's accessing. You can have ANTIC accessing expanded memory in the same mode as it does on the 130XE while the CPU accesses linear memory and/or 130XE mode memory. Linear memory (where implemented) works all the time. Anytime the A16-23 register is loaded with a non-zero value, all the decodes for ROM, I/O and such are disabled. (actually, not enabled) This is so you can write to $03D301 or $04D400 and hit only RAM. In practice, you could have $D301 banking memory and still get to $024000 in linear memory. (you have to remember that the physical, linear RAM is the same as the physical, banked RAM)

 

In reality, if you activate linear RAM, some stuff crashes - as I described in another post.

 

I think SIO works OK. I'll try some SpartaDOS. I use DOS 2.0 - it works just fine.

 

Bob

 

 

These are somehow faster in the OS, yes. And I already have an idea how to accelerate E: more radically. As for the floating point, I think that ROM is clocked still at 1,77 MHz (or 1,79), so the speedup is not too significant. And this is good because otherwise SIO would not work, or could have some problems. For the same reason, I also expect problems in the SpartaDOS, which loads its SIO drivers into RAM. In Sparta X we already added loop calibration to tune the SIO delay loops in case the machine is accelerated.

 

Ah, but you can always copy the ROM to RAM and enjoy the faster speed - though you are correct, it may be necessary to re-write SIO code to maintain compatibility.

 

 

And to Bob the Builder:

 

On the 130xe you can have Antic and CPU accessing different 16K banks; I would guess that implementing that feature when using the linear 65816 memory mode would be a challenge (particularly since the PIA bank switching would do nothing). An additional level of complexity in the circuit for minimal return (other than speeding up the Sea of Disks demo)...

[+bob1200xl]

I was thinking of going to a 28mhz clock so we could do a little clock shaving - fine tune a little. As it stands, we could use the XE crystal if we needed to do so.

 

Hello Bob

 

The XE already has a 14.31318 MHz crystal. Why not use that (in the XE)? Or something that multiplies the system clock?

 

Greetings

 

Mathy