7.16mhz 1200XL

[Mathy]

Hello Tezz

 

.... my trip around Europe in mid October.

Will you be in (or near) Germany on the 25th of October? If yes, why not visite the yearly meeting of the members of the ABBUC in Herten?

 

Greetings

 

Mathy

[Tezz]

Hello Tezz

 

.... my trip around Europe in mid October.

Will you be in (or near) Germany on the 25th of October? If yes, why not visite the yearly meeting of the members of the ABBUC in Herten?

 

Greetings

 

Mathy

Hi Mathy, I will be in Hamburg and Munich in October for a week but unfortunately I'll be heading back home around the 9th October as it's a road trip and a few days to get back to work. I was hoping that there was a meeting happening when I was there. That's a shame I'll just miss that one later in the month. Edited September 9, 2008 by Tezz

[+David_P]

Not that I'm anxious, but I just bought another 800xl on Ebay for this upgrade; that will make 2x 65816 and 2x 6502 800xls.

[+bob1200xl]

Why not a 1200XL?

 

On e-bay, there is a 1200XL that some guys have bid up to $1.25! That's disgusting!

 

Someone else bought one for $185? That's a little too much!

 

Bunch of 600XLs floating around, too.

 

Are you going to hook them up as a multi-processor?

 

Bob

 

 

 

Not that I'm anxious, but I just bought another 800xl on Ebay for this upgrade; that will make 2x 65816 and 2x 6502 800xls.

[+David_P]

Why not a 1200xl? There weren't any on when I looked. And I'm not looking at multi-processor; rather, tis way I'll have one stock 800xl, one with the CSS switchable XE/XL and 400/800 OSes, one with the Sweet16 from FTE (with 256K RAM), and finally, the "new kid on the block" with the 7.16 65816.

 

Plus the stock 800. Plus the XEGM.

 

So, as you can tell, I've started downsizing...

 

 

 

Why not a 1200XL?

 

On e-bay, there is a 1200XL that some guys have bid up to $1.25! That's disgusting!

 

Someone else bought one for $185? That's a little too much!

 

Bunch of 600XLs floating around, too.

 

Are you going to hook them up as a multi-processor?

 

Bob

 

 

 

Not that I'm anxious, but I just bought another 800xl on Ebay for this upgrade; that will make 2x 65816 and 2x 6502 800xls.

[ijor]

Hi drac030

 

@ijor: it would be of course good to use a POKEY timer to generate this timeout, but I think that multiplying the delay by increasing the number of cycles the delay loop runs is simpler.

 

Yes, and probably is good enough. But it's always better to use some kind of hardware timer. Consider that in the future some accelerators might be disabled at runtime, or even run with a variable speed. Right, it doesn't seem something too realistic right now, but you never now.

 

...and you do not need to worry if POKEY timers are not used by something else, if IRQ is on etc. (SDX SIO works with IRQ disabled).

 

Nobody can be using Pokey timers when calling SIO, at least not for the Pokey channels that SIO is going to use. If it does, then you are going to break them anyway when messing with the Pokey divisors. And if you are running with interrupts disabled, then even better. All you have to do is to fire the timer and poll Pokey interrupt status. No need to actually generate an interrupt.

 

VCOUNT is another possibility, and certainly simpler. The only minor problem is its two scan lines resolution will give your delay a granularity of ~128 us. Meaning you will delay ~64us more in the average. Not big deal I guess.

Edited September 11, 2008 by ijor

[atariksi]

Leaderboard does not load/run. The others move too fast to play with the exception of Tetris (seems the same) and Chess (the pieces move faster but I have no way to tell how the decision time is affected).

 

Bob

 

 

Bob,

 

Here is a ZIP file with few games on an ATR files... can you test then on the XL7 machine?

is Colusus chess calculate moves faster?, Does Mercenary Game draws the wireframes graphics faster?, is the Writeframes graphics in Assult force move faster?, does snooker or leaderboard golf games improove its performace?

 

Games_to_Test_on_XL7.zip

 

It's probably worth investing some more time and doing some sort of AND operation with one of the PORTB bits in order to enable/disable the 7.16Mhz clock verses 1.79Mhz clock when in RAM mode so that the acceleration can be software disabled/enabled. Thus, you would maintain compatibility with almost 100% of the software (assuming acceleration is disabled by default). As we know, most of the great software for Atari is already written, tested, and working. If PORTB is already overused, you can overload the ROM enable/disable bit with the acceleration enable/disable as to use the acceleration to its full potential, you would want the ROM to be in RAM anyways. And the software enable/disable would mean that no one has to rip out the acceleration to restore the Atari back to normalcy. Once enabling the acceleration, you could do the WSYNC type of affect to align the cycles before actually enabling acceleration (if not too much work). Just my 2cents on how to make it more useful.

[peteym5]

I have been reading back through the pages trying to get some information regarding the memory that can be plugged into such a board. I think a 512KB 32-pin SRAM, and maybe sockets for more be good. As for the Rambo/XE style bank switching, probably have to do some wiring between the board on the PIA chip. Not absolutely sure its necessary to wire up separate Antic access because so few programs really made use of it. If a 65816 CPU has a 24 bit address bus anyway, you can just keep the display memory in the 1st 64k, and have programming in the memory beyond that.

[Rybags]

I reckon leave PortB alone - it's been bastardised enough, and using a bit for speed switching is wasteful in comparison to being able to have more RAM.

 

The machine is going to be modded anyway - if speed switching is needed, just leave it to the user to flip a mechanical switch.

 

Of course there's the other alternative - use something like an obscure $D7xx address.

[atariksi]

Hi drac030

 

@ijor: it would be of course good to use a POKEY timer to generate this timeout, but I think that multiplying the delay by increasing the number of cycles the delay loop runs is simpler.

 

Yes, and probably is good enough. But it's always better to use some kind of hardware timer. Consider that in the future some accelerators might be disabled at runtime, or even run with a variable speed. Right, it doesn't seem something too realistic right now, but you never now.

 

...and you do not need to worry if POKEY timers are not used by something else, if IRQ is on etc. (SDX SIO works with IRQ disabled).

 

Nobody can be using Pokey timers when calling SIO, at least not for the Pokey channels that SIO is going to use. If it does, then you are going to break them anyway when messing with the Pokey divisors. And if you are running with interrupts disabled, then even better. All you have to do is to fire the timer and poll Pokey interrupt status. No need to actually generate an interrupt.

 

VCOUNT is another possibility, and certainly simpler. The only minor problem is its two scan lines resolution will give your delay a granularity of ~128 us. Meaning you will delay ~64us more in the average. Not big deal I guess.

 

It's better to have the ability to disable/enable the acceleration than to rewrite the tons of code in the thousands of working applications. Some applications rely on the 1.79Mhz cycles to time display related things-- can't use the POKEY timers there. Heck, using the self-test ROM bit and OS ROM bit together in PORTB would make the self-test bit more useful! If the self-test runs fast, it means the accelerator is installed.

[atariksi]

I reckon leave PortB alone - it's been bastardised enough, and using a bit for speed switching is wasteful in comparison to being able to have more RAM.

 

The machine is going to be modded anyway - if speed switching is needed, just leave it to the user to flip a mechanical switch.

 

Of course there's the other alternative - use something like an obscure $D7xx address.

 

I was thinking of a simplest solution. Certain combinations of ROMs enable/disable are not that used (especially in standard XL/XE series) like enabling self-test ROM and disabling OS ROM. There are bits for BASIC ROM, OS ROM, and self-test ROM and that gives 8 combinations.

[ijor]

It's probably worth investing some more time and doing some sort of AND operation with one of the PORTB bits in order to enable/disable the 7.16Mhz clock verses 1.79Mhz clock when in RAM mode so that the acceleration can be software disabled/enabled. Thus, you would maintain compatibility with almost 100% of the software (assuming acceleration is disabled by default)...And the software enable/disable would mean that no one has to rip out the acceleration to restore the Atari back to normalcy.

 

A software disable/enable switch is not a bad idea at all. But this is by no means the same as a hardware switch.

 

Setting the clock back to 1.79 MHz doesn't restore full compatibility. The faster CPU is a CMOS part, it is not 100% compatible with the NMOS part. Plus just the fact that you add a software switch it means an incompatiblity by itself (although not too significant).

 

It's better to have the ability to disable/enable the acceleration than to rewrite the tons of code in the thousands of working applications. Some applications rely on the 1.79Mhz cycles to time display related things-- can't use the POKEY timers there

 

Hmm, I think you are misunderstanding the point. The point there was about how to make the new Sparta DOS (which is being rewritten anyways) to be compatible with this and other accelerators.

[Rybags]

In any case, it's not the best idea to use delay loops for timing purposes.

 

Best case scenario - Antic DMA turned off, you have 114-9=105 cycles free for the 6502.

 

Worse case scenario - Widescreen, PMGs enabled, LMS DList instruction, you have about 8 cycles free for the 6502.

 

So, depending on screen architecture, a loop which has nested DEX/DEY can have enormous fluctuations in how long it takes to execute, regardless of 1.79 or 7.1 MHz mode.

 

So, I agree with the idea of Pokey Timers or VCount. And of course, there's WSync as well - so you have an error factor of +- 1 scanline (given that an arbitrary WSync strobe can cause anything from 1-113 cycles delay).

[mos6507]

I reckon leave PortB alone - it's been bastardised enough, and using a bit for speed switching is wasteful in comparison to being able to have more RAM.

 

The machine is going to be modded anyway - if speed switching is needed, just leave it to the user to flip a mechanical switch.

 

Of course there's the other alternative - use something like an obscure $D7xx address.

 

Stack on another PIA. Then you have plenty more bits to work with.

[Rybags]

Doesn't the CPLD act as a memory controller anyway?

 

In theory, you should be able to just set aside a small address area and use that for internal control.

[drac030]

@ijor, rybags: this is convincing. Sure nobody should use any POKEY register when calling SIO, because the ROM OS zeroes all of them upon completion (despite the fact that only two of them are used as baudrate generator). In meantime I also did some experiments with VCOUNT which proved that it should work - so I don't know, why I was so convinced that it would not. Maybe I tried it and did some simple mistake, then misinterpreted the results.

[STGAC]

Not a lot of room left in that CPLD...

 

I have considered control registers and the best I can come up with is to use one of the extended memory banks. So, you would read/write to $FFxxxx to set or reset bits, for example. (this assumes that you guys aren't going to want 16mb of linear memory) No existing code should be doing this - a 6502 can't even execute the instruction.

 

Killing the 7.16mhz clock is not a trivial exercise, by the way.

 

Bob

 

 

Doesn't the CPLD act as a memory controller anyway?

 

In theory, you should be able to just set aside a small address area and use that for internal control.

[drac030]

I have considered control registers and the best I can come up with is to use one of the extended memory banks. So, you would read/write to $FFxxxx to set or reset bits, for example. (this assumes that you guys aren't going to want 16mb of linear memory) No existing code should be doing this - a 6502 can't even execute the instruction.

 

So this http://drac030.krap.pl/xlos-04032007.arc is an non-existing code, apparently.

 

The last 64K bank ($FFxxxx) is reserved for I/O, but few locations are already defined by other accelerators:

 

$FF00XX - MMU

$FF01XX - RTC

$FF02XX - VIA

$FF03XX - $FF04XX - reserved

$FF05XX - $FF07XX - general purpose

$FFD000 - $FFDFFF - hardware register shadow

 

Also, $F00000-$F7FFFF is reserved for ROM.

 

I typed it from the HyperSpeed XL/XE instruction: http://www.digital-force.net/projects/hype...rspeed_doc3.pdf The F7 accelerator complies to this, and so does the "non-existing" code.

[+bob1200xl]

Well, I would assume that anyone running such code would have one of the other accelerators, so what would be the point? The objective in using a control register that cannot be reached by existing 6502 code is to minimize conflicts.

 

The project that you refer to is a very ambitious undertaking, on a completely different plane than the XL7. I keep stuff pretty simple because it all has to fit in my head.

 

Bob

 

 

 

I have considered control registers and the best I can come up with is to use one of the extended memory banks. So, you would read/write to $FFxxxx to set or reset bits, for example. (this assumes that you guys aren't going to want 16mb of linear memory) No existing code should be doing this - a 6502 can't even execute the instruction.

 

So this http://drac030.krap.pl/xlos-04032007.arc is an non-existing code, apparently.

 

The last 64K bank ($FFxxxx) is reserved for I/O, but few locations are already defined by other accelerators:

 

$FF00XX - MMU

$FF01XX - RTC

$FF02XX - VIA

$FF03XX - $FF04XX - reserved

$FF05XX - $FF07XX - general purpose

$FFD000 - $FFDFFF - hardware register shadow

 

Also, $F00000-$F7FFFF is reserved for ROM.

 

I typed it from the HyperSpeed XL/XE instruction: http://www.digital-force.net/projects/hype...rspeed_doc3.pdf The F7 accelerator complies to this, and so does the "non-existing" code.

[potatohead]

IMHO, simple is good.

 

We are more likely to see more modified machines, and that's key really. If there is a base, then it will see better / more development. With that comes solutions to some of the problems mentioned. This is just like existing hardware and it's problems.

 

A more complex project may not see that acceptance, though it may also see more software!

 

Seems to me it's quite easy to just have a machine for the existing body of software, then have the accellerated one for new stuff. If that modified machine sees a coupla killer dev projects, it's gonna make sense to continue to build on it right?

 

There are gonna be tweaks to a lot of stuff. Might as well do those with the simple device in mind and leverage that to get a larger installed user base.

 

just my .02

[atariksi]

>A software disable/enable switch is not a bad idea at all. But this is by no means the same as a hardware switch.

 

>Setting the clock back to 1.79 MHz doesn't restore full compatibility. The faster CPU is a CMOS part, it is not 100% compatible with the NMOS part. Plus just the fact that you add a software switch it means an incompatiblity by itself (although not too significant).

 

I stated almost 100%. I think a software switch is better since you can then program for both speeds and not need someone to drill a hole in their machine to add a switch (and add more jumpers). Also, you should be able to use the same routine at two different speeds. So, if the new pac-man eats the power pill, the monsters can run away faster from the pac-man or chase the pac-man faster in some level using the same code as the slow version, but under control.

 

What's the difference in speed between NMOS vs. CMOS or are you talking about some instructions don't work?

 

>>It's better to have the ability to disable/enable the acceleration than to rewrite the tons of code in the thousands of working applications. Some applications rely on the 1.79Mhz cycles to time display related things-- can't use the POKEY timers there

 

>Hmm, I think you are misunderstanding the point. The point there was about how to make the new Sparta DOS (which is being rewritten anyways) to be compatible with this and other accelerators.

 

It would be less rewriting-- at least you can switch speeds like they do with Happy mode after the boot-up process.

[atariksi]

In any case, it's not the best idea to use delay loops for timing purposes.

 

Best case scenario - Antic DMA turned off, you have 114-9=105 cycles free for the 6502.

 

Worse case scenario - Widescreen, PMGs enabled, LMS DList instruction, you have about 8 cycles free for the 6502.

 

So, depending on screen architecture, a loop which has nested DEX/DEY can have enormous fluctuations in how long it takes to execute, regardless of 1.79 or 7.1 MHz mode.

 

So, I agree with the idea of Pokey Timers or VCount. And of course, there's WSync as well - so you have an error factor of +- 1 scanline (given that an arbitrary WSync strobe can cause anything from 1-113 cycles delay).

 

It can't have fluctuations if you keep track of everything. For example, if you know you're in a VBI, you don't have to worry about ANTIC DMA stealing cycles. I don't know how you calculated your free 8 cycles. I think for the applications that do the loops arbitrarily, they don't need the exactness-- just a worst case scenario.

 

Also, there's the POT counters for 1 scanline accuracy, but best would be if the programmer knew what speed mode he was in so he can use the delay loops as well as timer methods.

[peteym5]

I think a hardware switch be simpler to build myself. With a software switch, you probably need to make a custom IC. I would prefer using the PORTB on the PIA to emulate the Rambo/XE style bank switching. That is using an actual 65816. I can see problems with games that were not designed to run from a VBI.

 

However adding compatibility for Rambo/XE bank switching will be for those that like running Ramdisk or those 130XE demos. I am pretty sure a better, faster Ramdisk program can be created for a 65816 CPU. Would be interesting to see what kind of demos get written also. Anyone writing software for these will probably just use the 65816 linear memory anyway. We have proven that more can be done during DLIs. For those of use that are making retro games will be interested in seeing the demand for games for these upgraded machines. Most of us prefer to put games on a cartridge so we have a chance to make some profit on them. Probably can make something that can extract to the high speed memory.

[STGAC]

I want to point out that Rambo/XE works the same on the XL7 - you just need faster logic. There are no compatibility issues.

 

Bob

 

I think a hardware switch be simpler to build myself. With a software switch, you probably need to make a custom IC. I would prefer using the PORTB on the PIA to emulate the Rambo/XE style bank switching. That is using an actual 65816. I can see problems with games that were not designed to run from a VBI.

 

However adding compatibility for Rambo/XE bank switching will be for those that like running Ramdisk or those 130XE demos. I am pretty sure a better, faster Ramdisk program can be created for a 65816 CPU. Would be interesting to see what kind of demos get written also. Anyone writing software for these will probably just use the 65816 linear memory anyway. We have proven that more can be done during DLIs. For those of use that are making retro games will be interested in seeing the demand for games for these upgraded machines. Most of us prefer to put games on a cartridge so we have a chance to make some profit on them. Probably can make something that can extract to the high speed memory.

[peteym5]

I want to point out that Rambo/XE works the same on the XL7 - you just need faster logic. There are no compatibility issues.

 

Bob

 

Thankyou for the information, was not entirely sure from reading back through this thread. You know every time someone comes up with an upgrade or proposes an upgrade, always have those who panic about compatibility or conflicts with other devices. Even if the upgrade locates itself in unused areas of the hardware area ($D1xx, $D6xx, $D7xx, plus all the 'repeats'). This CPU upgrade doesn't seem to affect anything other than running it faster.