7.16mhz 1200XL

[+bob1200xl]

What's in a name? You could just label it as a 7.16mhz XL accelerator.

 

Bob

 

 

Pepax and Bob, what do you suggest?

 

I will try to change the entry names.

[+bob1200xl]

M/l programs like DiskDisassembler running under DOS 2.0 run faster even without a RAM OS. For example:

 

Disassembling itself in stock 1200XL - 12:10.

Disassembling itself in an XL7 with a ROM OS - 7:10

Disassembling itself in an XL7 after running 'Ramaster' (puts the OS into RAM) - 3:30.

 

No changes to any of the software is necessary - runs right out of the box!

 

Do you have any s/w routines that you would like me to try?

 

Bob

 

 

 

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.

[dmlloyd]

Do you have any s/w routines that you would like me to try?

 

How about.. Galaxian

[Rybags]

I reckon Fractalus would be an interesting one.

 

You might have to run "Behind Jaggi Lines" though - I suspect Rescue on Fractalus from disk probably plays around with PORTB settings.

[+bob1200xl]

SD3.2D, SDX 4.20 and 4.21 all work in high speed/low speed SIO on the XL7. As long as you are using the serial clock gererator and not bit-banging, (like they seem to do in the 810 and 1050) you're OK. If you're trying to count cycles, you're probably going to croak.

 

Bob

 

 

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.

[+David_P]

Bob: You'd better stop posting. I'm sure all the drool is going to short out my PC keyboard...

[+bob1200xl]

Drooling is good...

 

Once ABBUC get done fooling around with it, we can start beta-testing a few of these things. Get some boards made. Nail down all the loose ends.

 

It's really no more difficult to install than a RAMBO, Happy, or such.

 

Bob

 

 

 

Bob: You'd better stop posting. I'm sure all the drool is going to short out my PC keyboard...

[+bob1200xl]

Hmmmm... "Rescue" does not load from a commercial disk on the XL7 - OK on a stock 1200XL. Reads about six sectors and sits there. 15 seconds later, the screen flashes colored blocks all over and says 'LOAD ERROR'.

 

I suspect that protection schemes are not going to like the XL7.

 

Have any plain code you'd like me to run?

 

Bob

 

 

 

I reckon Fractalus would be an interesting one.

 

You might have to run "Behind Jaggi Lines" though - I suspect Rescue on Fractalus from disk probably plays around with PORTB settings.

[peteym5]

Something we all have to remember about these games is most time themselves off of the VBI, so it does not matter how fast the computer is, most games will not run faster or better. Some might not work at all because they use 'illegal' 6502 opcodes. If you want a faster game, you have to write one from scratch to take advantage of the 65816 cpu. Awhile back I was expermenting with faster line drawing routines for a graphics 15 screen for Tempest Xtreem, drew the Web in less than 1/10th sec. I could have ramped it further, but I had memory constrictions. One could adapt such a routine for very smooth running vectored based games for a fast CPU.

[Rybags]

The commercial RoF uses it's own SIO, so it could well be that's the problem.

 

Here's an ATR of a pirated one I've got. Maybe it will work. If not, there might be a simple XEX version floating around somewhere.

 

The reason I suggested this game is I'm pretty sure it does movement in VBI time but renders as quickly as the CPU allows.

 

Rescue_On_Fractulus.zip

[ataridano]

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

 

I had not heard that about the use of linear memory, I've learned the hard way in the past that stability is more valuable than any other upgrade or feature that you can have. Speaking of memory upgrades, I was thinking today, if I get one of these for my 600XL, would it be a 64k machine? (remember that they only came with 16k) Stupid question maybe, but I figured I'd ask it anyway

[Heaven/TQA]

RoFl will be interesting to compare with the SuperCPU hacked version of the C64 sister. Check out one of the C=hacking issues where it describes what needs in the code were changed to make it run on SuperCPU, same with Stunt Car Racer.

[+Allan]

 

Here's a SuperCPU hacked game of Karateka to give you an idea of what might be possible with Bob's updrade.

 

Allan

[+bob1200xl]

Yes, it would be 64K.

 

There are two kinds of 'stability': ramdom, intermittent failures and repeatable incompatibilities. The first flavor is not acceptable. The second may be worked around or at least lived with. The linear memory issue is the second type, I'm sure.

 

What we know works, works all the time - what we know does not work, never works.

 

Bob

 

 

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

 

I had not heard that about the use of linear memory, I've learned the hard way in the past that stability is more valuable than any other upgrade or feature that you can have. Speaking of memory upgrades, I was thinking today, if I get one of these for my 600XL, would it be a 64k machine? (remember that they only came with 16k) Stupid question maybe, but I figured I'd ask it anyway

[ClausB]

Not to be greedy but...

 

How much faster could it be made to go? Which component limits the design to 7 MHz (besides the clock)?

[ijor]

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

 

This is one of the possible, even expected, problems when you mix new and old technology.

 

The best solution is probably isolating the data bus at both sides. Use a bigger CPLD, bridging the data bus in an out of the board. And while you do that, the same CPLD can latch the upper address bits.

 

Note that the problem is not just crashing, but actually bus contention. The bus contention is probably happening all the time, but is only critical when using linear address.

 

Not to be greedy but...How much faster could it be made to go? Which component limits the design to 7 MHz (besides the clock)?

 

The faster 65816 speed-grade is 14MHz, beyond that you would need an FPGA soft-core. The faster you go, the more critical the interface issues. The problem described above, which affects linear address only at 7 MHz, it would affect normal operation at 14 MHz.

 

Using an FPGA would be problematic because current generations are not 5V tolerant. You would need either older ones, or use voltage level translation. You probably would need to buffer the buses either way, so voltage level translation might come for free.

 

SD3.2D, SDX 4.20 and 4.21 all work in high speed/low speed SIO on the XL7. As long as you are using the serial clock gererator and not bit-banging, (like they seem to do in the 810 and 1050) you're OK. If you're trying to count cycles, you're probably going to croak.

 

There are a couple of cycle based delays on the SIO ROM. As long as it is run from ROM, it won't matter because it won't run faster. But it might still probably work from RAM. I'll need to check, but I think these delays are not very critical.

[dmlloyd]

Not to be greedy but...

 

How much faster could it be made to go? Which component limits the design to 7 MHz (besides the clock)?

 

According to some of the accounts at 6502.org, they've clocked the various modern 65xx parts quite a bit above their rating with no stability problems. I'm 100% sure you could run a 14MHz 65C816 at 14.31818 MHz without a problem.

[+bob1200xl]

I could have figured that you would go straight to this one, Claus... It has been at the top of my list, also.

 

Basically, there is too long a path to resolve the hardware state in 35ns or less. A 14mhz clock allows you the first half of the cycle to decide if you're going to RAM (at 14mhz) or ROM and I/O (at 1.79mhz). This amounts to 35ns. This path is from the CPU, down to the Atari PAL, thru the PAL, back to the CPLD, and thru the CPLD. Even by using 10ns parts in the PAL and CPLD, we lose that race once in a while - way too often to call it 'usable'. The state is latched at 35ns - half-way into the 70ns clock.

 

It looks OK on a scope except for that little critter that flicks out towards 35ns...

 

I have considered using an odd clock value - one that is not a multiple of 2 of the Atari clock. Something like 52.5ns (3x17.5) of setup and 35ns (2x17.5) of execution, giving you the potential to run six times faster. Might be doable... by someone else - not on my Radar.

 

Otherwise, consider a RAM-only processor, or one that could talk to everybody at 14mhz. (the limit of the 65816 itself) Everybody being FRAM(s) in a cartridge along with a 14mhz CPU. Not much to it - not many decisions to make - select FRAM or SRAM? That's about it. Everything else is s/w. Run like crazy!

 

Question: if you set up multiple FRAMs with the same starting parameters at the beginning of each video frame, (like all start at address $0000) couldn't you load/start them concurrently? No reason to load each one by itself, is there? Only the data for each memory has to be done individually? There is no protocol, per se. The CPU talks - the FRAMs better be listening.

 

Not to be greedy but...

 

How much faster could it be made to go? Which component limits the design to 7 MHz (besides the clock)?

[Mathy]

Hello guys

 

You could have both the XE style memory expansion and linear RAM. Just have some hardware check for PB4 and PB5 to go low. If both are high, you use linear memory, if either or both go low, you use the XE style memory expansion. That way, even older software that uses XE style memory expansions can be used. For those memory expansions that don't have separate ANTIC banking, a switch could be added, so that PB4 (or was that PB5? The pin that controles ANTIC's access to the expanded RAM) isn't checked (for dertermining whether linear or XE style expansion should be used).

 

Greetings

 

Mathy

[+bob1200xl]

Well, at least your version loads and runs...

 

The screen doesn't seem to update any faster and it seems to swap screens at inappropriate times. This behavior does not occur with a 1200XL running a 65816 at 1.79mhz.

 

I don't see the XL7 as a platform to run existing games at high speed. Any m/l games that want to run bigger/better/faster will have to be written specifically for the XL7, I expect. BASIC games may run much faster, as will BASIC and m/l code that does not sync to the screen (DLIs, timers and such).

 

Even if they run faster - who wants to play them that way?

 

*** I would strongly suggest that anyone interested in an XL7 plan on getting an XL system just for that purpose. ***

 

Bob

 

 

 

The commercial RoF uses it's own SIO, so it could well be that's the problem.

 

Here's an ATR of a pirated one I've got. Maybe it will work. If not, there might be a simple XEX version floating around somewhere.

 

The reason I suggested this game is I'm pretty sure it does movement in VBI time but renders as quickly as the CPU allows.

 

Rescue_On_Fractulus.zip

[ijor]

Basically, there is too long a path to resolve the hardware state in 35ns or less. A 14mhz clock allows you the first half of the cycle to decide if you're going to RAM (at 14mhz) or ROM and I/O (at 1.79mhz). This amounts to 35ns. This path is from the CPU, down to the Atari PAL, thru the PAL, back to the CPLD, and thru the CPLD. Even by using 10ns parts in the PAL and CPLD, we lose that race once in a while - way too often to call it 'usable'. The state is latched at 35ns - half-way into the 70ns clock.

 

Can't you skip the PAL? Can't you bring the relevant signals directly to the CPLD?

[ClausB]

Basically, there is too long a path to resolve the hardware state in 35ns or less.

 

Question: if you set up multiple FRAMs with the same starting parameters at the beginning of each video frame, (like all start at address $0000) couldn't you load/start them concurrently? No reason to load each one by itself, is there? Only the data for each memory has to be done individually? There is no protocol, per se. The CPU talks - the FRAMs better be listening.

Thanks, Bob, for the explanation.

 

Yes, I had intended for the multiple serial FRAM design to use them in parallel. That is, hook them all up to the same serial clock and the same select signal. Each FRAM's serial input would come from a different data bit (say D7 and D6 for a dual FRAM) and each serial output would be a different luma bit. Then they could be loaded by the CPU concurrently (2 bits at a time for a dual FRAM), using the SPI protocol.

[+bob1200xl]

Yes, you could pull all the PAL functions up into the new board but it would all have to be in a single CPLD. It would make the mod more complex and add 'external' wiring but it would still be compatible with the XL7.

 

Good project for someone - not on my radar.

 

Bob

 

 

 

Basically, there is too long a path to resolve the hardware state in 35ns or less. A 14mhz clock allows you the first half of the cycle to decide if you're going to RAM (at 14mhz) or ROM and I/O (at 1.79mhz). This amounts to 35ns. This path is from the CPU, down to the Atari PAL, thru the PAL, back to the CPLD, and thru the CPLD. Even by using 10ns parts in the PAL and CPLD, we lose that race once in a while - way too often to call it 'usable'. The state is latched at 35ns - half-way into the 70ns clock.

 

Can't you skip the PAL? Can't you bring the relevant signals directly to the CPLD?

[+CharlieChaplin]

Well,

sounds too good to be true - running RAM based programs up to 300% faster... At the moment I can only think of a similar situation, where I compiled dozens of Atari Basic and other Basic programs with the TB XL compiler. By compiling, it is possible to make the programs up to seven times faster -theoretically! In practice most of the compiled programs were much too fast, unplayable, unusable or just un-controlable. I guess the same will happen with the 7,16Mhz accelerator and a lot of older A8 programs...

 

Hmm, in the past for almost every enhancement one could add a switch to switch back to "standard" or "non-enhanced" mode (and thus making the enhancement completely unavailable). I am not sure if this could be done with this enhancement also, adding a swich to switch back to a standard Atari. Afaik if one installs this enhancements one must remove the slow RAM on the motherboard and use only the "faster" RAM on the pcb of the 7,16 Mh accelerator. Think this would make it impossible to add such a "back-to-standard" switch... (in the worst case, this would mean, one requires another Atari to run certain programs that will not run with this enhancement).

 

There is a 65816 on the pcb, this of course means that all programs using illegal 6502 opcodes (there are quite some!) will not run with it (ok, the same problem occurs if one adds a 65C02 in favor of the 6502C). But there are also other issues with the 65816, so one will require a list of titles that are compatible or not and a homepage (or a good programmer / patcher / ...) that will upload patched versions of the incompatible titles for the 65816. As for the start, there is a long list on Draco`s site:

http://drac030.krap.pl/en-kompatybilnosc.php

but I know this is only the beginning and there are hundreds of A8 titles that are not on that list...

 

-Andreas Koch.

[ijor]

Hmm, in the past for almost every enhancement one could add a switch to switch back to "standard" or "non-enhanced" mode (and thus making the enhancement completely unavailable). I am not sure if this could be done with this enhancement also, adding a swich to switch back to a standard Atari. Afaik if one installs this enhancements one must remove the slow RAM on the motherboard and use only the "faster" RAM on the pcb of the 7,16 Mh accelerator. Think this would make it impossible to add such a "back-to-standard" switch...

 

The "faster" RAM can work slower as well. I see no reason why an enable/disable switch couldn't be implemented. You would need, of course, to put the older CPU in an additional socket on the XL7 board.

 

There are many possible "enhacements to this enhancement". But I agree with what Ken said earlier. Bob made something that is amazingly simple in relation to its power.

Edited September 6, 2008 by ijor