7.16mhz 1200XL

[+Larry]

(snip...)

The F7 accelerator complies to this, and so does the "non-existing" code.

 

Hi drac030-

 

Speaking of other Atari accelerators...

 

Are you aware of any change(s) in the general availability of the F7 or Warp4 accelerators?

 

My last info was that the F7 is not likely to be commercially available and the Warp4 had memory access issues. Perhaps something has changed?

 

-Larry

[potatohead]

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.

 

This is exactly what I like about it. Once done, a fair amount of stuff is gonna work straight away. The rest can be addressed in software, giving people a leg up on projects. This is true for other mods of this kind, but they are more complex, meaning fewer people are likely to do them, thus leaving the software matter moot.

[peteym5]

If I am not mistaken, drac030 is involved with the F7 board and should be the one to update us with the current status of that project. I wonder if it functions as if a 65816 cpu is directly replacing a 6502 internally can we do faster DLIs, VBIs, and other interrupts.

[guus.assmann]

I have not read all of the forgoing.... I wonder if a freezer would still work with this?

 

Sending it to the ABBUC contest does mean that the schematics and so on should be made available to the generalpublic.

 

Also for this, I'm willing to develop a PCB. And publish all data for this.

 

It should be possible to create a switch, setting for "standard" and "accellerated"

Making a backup-battery for the Ram is no problem, as long as static ram is used.

Disabling or removing the D-Ram will be good for power consumption.

[peteym5]

I'm willing to develop a PCB. And publish all data for this.

 

It should be possible to create a switch, setting for "standard" and "accellerated"

Making a backup-battery for the Ram is no problem, as long as static ram is used.

Disabling or removing the D-Ram will be good for power consumption.

 

Although I voted YES, I am not good at writing software. Also, I would much rather build it myself.

 

But in regard to this, I can offer something that may be usefull. I can develop a PCB.

I've done this for the Freezer XL/XE.

And I can build and test prototypes at very low cost. (The only machines I don't have, are the 400/800 and a 1200XL. I would like to have a 1200XL very much)

Apart from good development software for PCB's and drawing of schematic diagrams, I also have a good Oscilloscope and programming equipment for Gal and many other programmable stuff.

Some parts are also available, most TTL-logis and even a bunch of 65C816 processors.

There's one issue though, I live in the PAL part of the world. This makes testing NTSC a bit harder....

 

 

Hey read your post here and for the enhanced cartridge. I also suggested the ideal of combining the FRAM video circuit with a 65816 processor on a single PCB. Any additional IC chips could use memory locations outside the Ataris main 64k area and will avoid any conflicts all together.

[Mathy]

Hello peteym5

 

... in unused areas of the hardware area ($D1xx, $D6xx, $D7xx, plus all the 'repeats').

$D1xx and $D6xx are used by the BlackBox and MIO. And probably every other halfway decent device that connects to the parallel bus.

 

Greetings

 

Mathy

[peteym5]

Yeah, know about the BlackBox issue. VBXE will be using similar locations, along with the COVOX thing. There should be some agreements and standardizations on what uses what locations. Maybe do splits of certain pages, have some new devices use the upper half of a page, like D080-D0FF, D180-D2FF, etc, piggyback on the same page like the Dual Pokey does. That is for mapping new stuff inside the main 64k area. Like I say a 65816 opens up a 24bit address bus and have lots of room for addresses for extra hardware.

 

 

 

Anybody have game design ideals for a 65816 CPU? Remember it still uses the Antic/GTIA, but can probably do better with DLIs allowing the player/missiles graphics to be split up and have more colors. Can do more "Soft Sprites" also. Keep in mind limits of 4 player on a single line, maybe 8 showing in alternate frames. I know its possible to have the same player in 2 positions, but more complicated to set up with lots of moving objects going around the screen. Even though you run at 4x speed, you still need to leave some free time for the game logic.

[Rybags]

Soft sprites is where this thing will shine.

 

If you do PMG splitting, then you have the headache of still having to keep them sufficiently apart horizontally. You still have to alter the GRAF, POS and possibly the COLOR register.

 

In reality, you might manage to reuse 1 or 2 players in a given vertical position. And, you commit virtually all cycles on those lines to a Kernal to do it.

 

On the other hand, you could restore/redraw a reasonably sized soft-sprite in maybe 3-5 scanlines duration rather than 12-20.

 

 

The other area that should open up is for digital SFX. Think Space Harrier like voiceovers using DLIs or Pokey Timers, with significant savings in overhead.

[atariksi]

Yeah, know about the BlackBox issue. VBXE will be using similar locations, along with the COVOX thing. There should be some agreements and standardizations on what uses what locations. Maybe do splits of certain pages, have some new devices use the upper half of a page, like D080-D0FF, D180-D2FF, etc, piggyback on the same page like the Dual Pokey does. That is for mapping new stuff inside the main 64k area. Like I say a 65816 opens up a 24bit address bus and have lots of room for addresses for extra hardware.

 

You can also look at what devices cannot possibly co-exist. I would still go for the PORTB OS ROM enable/disable bit as an overload for the acceleration enable/disable (as simplest solution). When OS ROM is enabled, acceleration is disabled (so boot-up is normal). When OS ROM is disabled and/or being used in RAM, acceleration is enabled and ROM (now in RAM) is also accelerated.

 

>Anybody have game design ideals for a 65816 CPU? Remember it still uses the Antic/GTIA, but can probably do better with DLIs allowing the player/missiles graphics to be split up and have more colors. Can do more "Soft Sprites" also. Keep in mind limits of 4 player on a single line, maybe 8 showing in alternate frames. I know its possible to have the same player in 2 positions, but more complicated to set up with lots of moving objects going around the screen. Even though you run at 4x speed, you still need to leave some free time for the game logic.

 

I think alternate frames of sprites works good only if the color differences are not too big. I think in Joust the birds start blinking when you have many of them in the same horizontal region. I guess it shows that 30Hz (interlaced) is not enough for temporal dithering if the color differences are big. So it looks good for Graphics 9 pictures and not so hot for Commodore 64 whose colors have greater deltas between them.

 

What do you define as a soft-sprite-- drawing each pixel or custom chars?

[Rybags]

Using the OS in/out state as the turbo trigger has it's merits, but then again it means you have to supply an OS substitute any time you want to run quicker.

 

But, there are workarounds for that problem. In an Asm program, all you need to do is have a deferred VBI that swaps the OS out at the end of the VBlank.

And, you'd need to handle IRQ/NMIs yourself, but you could do as bodge job and swap the OS back in, so you'd only need a "front-end" setup to handle the interrupts.

 

Another possibility, although a bit of a kludge: Use the Cassette Motor Control line on the PIA as the speed control.

[peteym5]

"Soft Sprites" are like graphics drawn onto a bitmapped screen rather than over lays. Can also use redefined characters on character mapped screens also. Similar to blitting, but all done in software. I personally do not consider them true sprites because they are defendant on the background colors and need something to restore the background before moving them around. I refer to them as "Graphs" or "Grafs" with the stuff I make so they don't get confused with player/missile graphics. I prefer using player/missile graphics unless there are needs to move more stuff around.

[Heaven/TQA]

well... you can multiplex more hardware sprites as in general a quick engine is needed for

 

- sorting the "virtual" sprites by their y-pos

- determinate the DLI zone (each zone holding 8 hardware sprites (4 players/4 missles)

- erase old gfx data, move and draw new gfx data

 

and as this is depending on simple "speed" a 65816 could handle more per frame?

[Rybags]

Purely RAM-based code, working on RAM-based data - I'd guess you'll have a net speed increase very close to 400%

 

ie - take the net number of cycles you normally have available after such overheads as DMA/Refresh, OS part of the VBlank etc. Multiply that by 4.

 

So, in an hypothetical scenario where you have the equivalent of 1.25 MHz worth of cycles, an accelerated machine should be close to 5 MHz.

[Heaven/TQA]

well...that is not so bad....

[tebe]

65816 (1.79 Mhz) is faster then 6502 (1.79 Mhz) near 1/3, if you use new 16-bit command

Edited September 14, 2008 by tebe

[Tezz]

as previously done with DLI's, could you possibly do some tests multiplexing the PMG's to get a rough idea of what's likely possible. I'm not a fan of soft sprites with the overhead of memory required but the gains mentioned will certainly make a difference to what's possible with soft sprite routines and I guess anyone installing this upgrade will likely have extended memory also. It'd be nice to see what's what with regard to muliplexing the PMG's, that's really one of the main things that interests me from the perspective of creating future games with this installed.

[Heaven/TQA]

Tezz, you should define multiplex... in one scanline? for what kind of engine? how do the sprite move? or will it be like on c64 that you don't break the "hardware rule" 4 sprites per line?

[peteym5]

I have got a multiplexer to divide up DLI zones every 24 pixels, a little larger than the tallest sprite I drawn. If a sprite is crossing 2 DLI zones, it just considers that player "In Use" in 2 zones and sets the same color, player position, and width. With this 65816, it probably can get away with 8 pixel high DLI zones or smaller. The limit depends on the Antic mode, character modes will be 8 pixels per zone. The "In Use" table is something I came up for Tempest Xtreem which is a small table of bytes equal to the number of zones. It turns bits on for which players are used in each zone and if a player was used, it simply uses the next one. The starting sprite to check rotates between each VBI so if it goes over 4 sprites, different ones will show in alternate frames. Don't usually notice them like blinking unless it gets to 7 or more in a zone. Smaller zones do reduce the blinking. There are little tricks that have been done like rotating with odd numbers and such. I am sure some really neat things can be done with a faster 16bit cpu.

[Heaven/TQA]

Pete... when Tempest finished I would like to see your multiplexor so I can compare it with mine... sounds interesting... my one has dynamic DLI zones similar approach like the c64 ones... so "crossing" is not possible...but mine does "reject" virtual sprites when maximum of hardware sprites per scanline is reached.

 

I never implemented "konami"-style and ringbuffers for rotating (the "flickering through sprites").

 

so actually this is much CPU load driven so the 65816 can help here...

[Tezz]

Hi Heaven, yes I mean in one scanline. It's like the method you described above that interests me exactly like the ringbuffer which was a common method used on the early 90's consoles too the "flickering" multiplex, a tightly written engine could possibly have more freedom in practice I think with the 816. I think that the flickering is a minor side effect with what you can do with it personally. The final (not demo) Crownland uses a similar engine.

 

Pete, do you have some source examples of your work you could share?

[atariksi]

Using the OS in/out state as the turbo trigger has it's merits, but then again it means you have to supply an OS substitute any time you want to run quicker.

 

But, there are workarounds for that problem. In an Asm program, all you need to do is have a deferred VBI that swaps the OS out at the end of the VBlank.

And, you'd need to handle IRQ/NMIs yourself, but you could do as bodge job and swap the OS back in, so you'd only need a "front-end" setup to handle the interrupts.

 

Another possibility, although a bit of a kludge: Use the Cassette Motor Control line on the PIA as the speed control.

 

Wouldn't you need a OS substitute anyway to keep backward compatibility for booting up disks in turbo mode?

 

And as a start, if you shadowed the OS, you wouldn't have to handle the IRQ/NMI yourself in turbo mode.

[atariksi]

65816 (1.79 Mhz) is faster then 6502 (1.79 Mhz) near 1/3, if you use new 16-bit command

 

But are there any differences in compatibility mode of the 65816? I think it would be significant to keep as much of the older software running the same in non-turbo mode. For example, if I have the following, how many cycles would it take on a 65816 in non-turbo mode of 1.79Mhz (6502 cycles in parentheses):

 

1536: LDA 54283 (4 cycles)

1539: LDX #9 (2 cycles)

1541: STA 53265,X (4 cycles)

1544: DEX (2 cycles)

1545: BNE 1541 (2 cycles)

[Rybags]

No real need to boot up in turbo mode if it's a software speed-switchable system.

 

You gain nothing with disk I/O having a quicker CPU (although of course, compression systems would benefit greatly).

 

My comment on the "OS State" was in reference to the earlier suggestion of sharing the OS bit and having it as the control method to go into turbo mode.

I'm not fanciful about the idea as it then means you lose a lot of versatility so far as being able to arbitrarily jump in and out of fast mode.

[Rybags]

But are there any differences in compatibility mode of the 65816? I think it would be significant to keep as much of the older software running the same in non-turbo mode. For example, if I have the following, how many cycles would it take on a 65816 in non-turbo mode of 1.79Mhz (6502 cycles in parentheses):

 

Isn't it the same in normal 8-bit mode? I thought it was only in the extended mode of the 65816 that you got the extra throughput per cycle.

 

Re compatibility - I think most (all?) of the undocumented 6502 opcodes no longer work (?)

 

 

Put it this way - lots of stuff will probably break, have glitches or otherwise need fixing. But, it's not the end of the world.

If Atari800Win+ was expanded to support emulating this expansion, work could be done in a pre-emptive manner to make transition for people easier, so that when you installed one, there would be ready made fixes for anything that had problems.

[atariksi]

If the 6X mode was your Radar, wouldn't it be better to go for the 7X (12.53Mhz) multiplier and use like 80ns RAM?

 

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)?