Abbuc Hardware Contest 2008...

[Rybags]

That's one of the ideas I had in mind.

 

Have it do stuff like binary divide/multiply, in addition to being able to do other things like softsprites.

 

Actually, a big 128K or 256K ROM cartridge alone might well be useful in itself. It could act as a repository for sine tables, and div/mult tables.

 

The point of my idea, though, is something that would be low-cost, highly available, and instantly usable without modifying the host machine.

[cas]

That's one of the ideas I had in mind.

 

Have it do stuff like binary divide/multiply, in addition to being able to do other things like softsprites.

 

Actually, a big 128K or 256K ROM cartridge alone might well be useful in itself. It could act as a repository for sine tables, and div/mult tables.

 

The point of my idea, though, is something that would be low-cost, highly available, and instantly usable without modifying the host machine.

 

I personally would really like to see a 65816 + RAM in a Cartridge or on the system bus that can be used without modifying the atari, because then I can use it for all my Ataris without the need to modify all of them.

 

Many uses for such a cart came to my mind.

 

I do not like the idea of having a completely different CPU attached to the Atari (like PIC or ATMEL), because as a programmer, I do not want to learn another CPU language. A 6502 compatible CPU will attract more programmers.

 

Carsten

[Rybags]

I've looked at the Datasheets for a few PICs.

 

Moving from 6502 to a PIC would be a painfree process.

 

Learn one assembly language, transition isn't all that hard.

 

I started doing useful stuff on the 68000 fairly quickly - of course, it presented you with all those instructions you wished the 6502 had.

Then, I moved up again to IBM's mainframe System 370/390 Asm, which in itself is almost like a high-level language.

 

If such a cart was to be made, I don't think it's all that important what it used.

 

As a developer, a customer wouldn't necessarily be programming it anyway - it would likely have a standard set of libraries and subroutines which you just called as needed.

[xxl]

> I do not like the idea of having a completely different CPU attached to the Atari (like PIC or ATMEL), because as a programmer, I do not want to learn another CPU language. A 6502 compatible CPU will attract more programmers.

 

atmega... cost $2 and have more power then any 65xx processor including 16mhz 65816.

[cas]

> I do not like the idea of having a completely different CPU attached to the Atari (like PIC or ATMEL), because as a programmer, I do not want to learn another CPU language. A 6502 compatible CPU will attract more programmers.

 

atmega... cost $2 and have more power then any 65xx processor including 16mhz 65816.

 

I have looked at the ATMEGA and PICs before. Atari is my Fun Hobby, and for _me_ it would be fun to learn more 65816, because I can re-use that knowledge on some other machines I have. I will not spend time programming for ATMEL or PIC. Not for fun. And I guess nobody will pay me.

 

But that is just my view.

 

I rather spend 20 Euros more to have a less powerful 65816. If I want power, I buy a PS3 with a Cell Processor System. I want 65xx flavor.

 

Carsten

[+bob1200xl]

Yes, exactly.

 

One big issue is that we can't drive anything into the Atari from the cartridge - the internal CPU has to initiate everything. It would be nice, for example, if we could write to ANTIC or Pokey registers but it can't be done. So, you need new code in the Atari. It's easy to get the 6502 to load and run this code, however, since we are the cartridge and we get first crack at running code on the '02.

 

Looks like a major project ($) to get it all inside a regular cartridge case. I have about a thousand ET-Phone Home carts - a little surgery and we could extend out the back pretty well... make a little key for the interlocks on the 400/800.

 

What other ideas do you have? Might as well bolt it all on at once.

 

Bob

 

 

 

 

That's one of the ideas I had in mind.

 

Have it do stuff like binary divide/multiply, in addition to being able to do other things like softsprites.

 

Actually, a big 128K or 256K ROM cartridge alone might well be useful in itself. It could act as a repository for sine tables, and div/mult tables.

 

The point of my idea, though, is something that would be low-cost, highly available, and instantly usable without modifying the host machine.

[+bob1200xl]

If you stick to 'current technology', stuff that is already functional, then we can do 3x. (this is a 7.16mhx clock)

 

Extended, linear SRAM is pretty easy.

 

Flash memory/CF cards (OS, carts, HDD) is some work.

 

4.5x is doable. (this is also a 7.16mhz clock)

 

11.5x is hard - needs 4-layer boards and stuff.

 

A lot of this is dependent on our programmable hardware capabilities. The first two or three features can be done with hand-wired discrete logic and 22V10 GALs. 11.5x will take better 'wirez' than that, I expect.

 

For the purposes of this competition, wouldn't the cartridge concept be more useful? How are we going to install the internal mods all the way in Germany? They probably need PAL versions, don't cha think? Ugh...

 

Anyway, that is the order of difficulty in either case. The internal mod takes no s/w changes at all. The cart would require relocating existing code or writing new code.

 

What do you think?

 

Anybody?

 

Bob

 

 

 

 

 

Oh, yeah... that's what I'm talking about. Thanks.

 

So - you've been following this discussion? How would you suggest we proceed? A simple 2x hack? Do you think that would be enough to win?

 

Bob

 

I guess you are asking me?

 

If 2X is pretty straight-froward, I'd go for that as opposed to something that might get bogged down. Probably there are things that will be learned from the 2X that can be built upon later. Maybe the "MarkII" is 4.5X the next year. You can see from the emulator that 200% makes a very significant performance improvement.

 

"Drop In." Fewer connecting wires is definitely better. Works in XL's and XE's. If it is flexible, compatible, doable, installable, I think it might be a winner.

 

Now if it happens that the 4X gets done this year, and its 2X vs 4X (ceteris paribus), then the 4X will probably win. But the work has been going on for some time on the 4X and it's not there yet, AFAIK.

 

I'd go with simple -- I like "sure things." A "bird in the hand," etc. After you have mulled this over a bit, why don't you jot down a list of reasonable capabilities -- sort of a spec list.

 

FWIW,

Larry

[ndary]

If you stick to 'current technology', stuff that is already functional, then we can do 3x. (this is a 7.16mhx clock)

 

Extended, linear SRAM is pretty easy.

 

Flash memory/CF cards (OS, carts, HDD) is some work.

 

4.5x is doable. (this is also a 7.16mhz clock)

 

11.5x is hard - needs 4-layer boards and stuff.

 

A lot of this is dependent on our programmable hardware capabilities. The first two or three features can be done with hand-wired discrete logic and 22V10 GALs. 11.5x will take better 'wirez' than that, I expect.

 

For the purposes of this competition, wouldn't the cartridge concept be more useful? How are we going to install the internal mods all the way in Germany? They probably need PAL versions, don't cha think? Ugh...

 

Anyway, that is the order of difficulty in either case. The internal mod takes no s/w changes at all. The cart would require relocating existing code or writing new code.

 

What do you think?

 

Anybody?

 

Bob

 

4.5x is SRAM cartridge is winner in my opinion. how would we demonstrate its features?

lets say we relocate the code and we get it to work.. whats next?

 

what we need is a short demo running at x1 and 4.5x speed...

 

Ndary

[+Larry]

4.5x is SRAM cartridge is winner in my opinion. how would we demonstrate its features?

lets say we relocate the code and we get it to work.. whats next?

 

what we need is a short demo running at x1 and 4.5x speed...

 

Ndary

 

Under this option, we are talking about not just a "Math Cartridge" (for lack of a better description), but a full processing "slave" unit that would take instructions and data from the "master" Atari and process it and then send data back to the Atari for I/O? So SIO, hard drives, etc. would stay the same? The OS or some type of a device driver to handle the data transfers back/forth to the slave processor would need to be (re)written? Could cartridges (Action!, etc.) still be used via pass-thru? Would PBI/ECI devices (Black Box, etc.) be lilkely to still work? In short, what would we be likely to need to sacrifice with this device?

 

-Larry

[Heaven/TQA]

my 0.02$... i always wanted to have a 65816 but never got some of the turbo boards simply why? some of them were too expensive or needed hardware experience for expanding existing machines...

 

so i definitly would consider to have the cart version...as i am used to them with my turbofreezer xe cart and atari max cart. plug 'n play would be the best...

[Rybags]

If a PIC is used, it has it's own onboard memory.

 

I would envisage a situation where the following example occurs:

 

- Atari tells PIC to receive an array of data. PIC then waits and Atari sends data with successive store operations.

- Atari tells PIC to perform operation on array of data (mult, divide, shift, rotate, whatever). PIC performs operation. Atari goes off and does other stuff for a while.

- Atari queries as to PIC status. PIC returns "Ready" status.

- Atari tells PIC to retrieve completed result. Atari then reads data.

 

The tricky part is interfacing. We need 8 bits I/O for data - no getting away from that.

Another bit is required to sense the $D5xx CARTCTL line, so that the PIC knows when it is being talked to.

More bits required for addressing (maybe). It might be the case that the thing could operate via a single register, via a command/response type system - e.g. Atari sets command requests via write to $D500. Waits/does other stuff for relevant amount of time, then reads $D500 successively to get status and result/s of operation.

 

 

If we're talking "Math co-processor" ie- supplementing or replacing the function of the FP-ROM @$D800, then things get a little complicated.

Due to the fixed location of all the routines in the ROM, it would likely be a case of having to copy the entire OS to RAM, then applying patches in the code.

 

Personally, I see such a use as secondary - having a slave processor would be much more beneficial to "proper" games which can utilize the PIC to perform tasks which the 6502 is inherantly slow at.

Edited February 9, 2008 by Rybags

[+bob1200xl]

Nir:

 

As a cartridge, the hack can run patched BASIC object code that will offload most of the heavy routines to the 65816. Any BASIC program will then run much faster. This is not too difficult since we have the source to BASIC. Other carts and software will have to be modified or new code written in order to see any speed gains. We can hack the OS on the XL machines but not the 400/800. On the old systems we would be limited to programs like the BASIC supercharger, above, or the OS vectors in RAM.

 

There is a BASIC program that draws a wireframe sphere and then rotates it. I'd love to see that compared to the supercharger as a demo.

 

There would be two 8K segments, one at $8000-$9FFF and one at $A000-$BFFF. You could have cartridge code (for the 6502) in either or both, or 65816 SRAM (accessible by the 6502) in either or both, or 6502 RAM in either or both, or any combination of those three, dynamically switchable.

 

This is something people can play with and do their own thing. I can't predict where they will go with it. I know nothng about games but I'd bet you could make a pretty fancy game with it.

 

Bob

 

 

 

If you stick to 'current technology', stuff that is already functional, then we can do 3x. (this is a 7.16mhx clock)

 

Extended, linear SRAM is pretty easy.

 

Flash memory/CF cards (OS, carts, HDD) is some work.

 

4.5x is doable. (this is also a 7.16mhz clock)

 

11.5x is hard - needs 4-layer boards and stuff.

 

A lot of this is dependent on our programmable hardware capabilities. The first two or three features can be done with hand-wired discrete logic and 22V10 GALs. 11.5x will take better 'wirez' than that, I expect.

 

For the purposes of this competition, wouldn't the cartridge concept be more useful? How are we going to install the internal mods all the way in Germany? They probably need PAL versions, don't cha think? Ugh...

 

Anyway, that is the order of difficulty in either case. The internal mod takes no s/w changes at all. The cart would require relocating existing code or writing new code.

 

What do you think?

 

Anybody?

 

Bob

 

4.5x is SRAM cartridge is winner in my opinion. how would we demonstrate its features?

lets say we relocate the code and we get it to work.. whats next?

 

what we need is a short demo running at x1 and 4.5x speed...

 

Ndary

[+bob1200xl]

Yes. A full processing slave.

 

SIO would be unchanged on the 6502. If you wanted to 'put' a block of data to the 65816, you would enable 8K of 65816 memory in one of the two segments and just read/move data into the block. No OS changes are needed. To 'get' a block of data from the 65816, you just enable and write/move data. PBI devices would not be affected. Suppose you wanted to load a big dictionary into the 65816 SRAM. Enable the appropriate bank and point SIO at it. Call SIO and it will load it directly - one step. If you were doing a spell checker, the 65816 could search its memeory and return the result to the 6502. Or, the 65816 could do sorts for you. Or, whatever. You've got 512K on the 65816. ANTIC could use one (or both, via page flipping) segment for screen memory while the 65816 draws the images, 450% faster than the 6502. Heck, they can both draw on the screen! You draw the background and I'll draw the objects.

 

What you lose is cartridge pass-thru. You can, of course, just unplug your supercharger and plug in any cart you like. The Atari is not modified internally. But, you can't (it looks really complex to do) run an external cart. You can load any 8K or 16K cart into flash memory and run that, but without code changes, your supercharger is just an expensive flashcart. Bank switching is out. We could build in support for one or two bank switch schemes - maybe. No pass-thru.

 

Bob

 

I think I'll do them both. We can submit two, can't we? I've got all the internal stuff started for the 65816 anyway. Should be fairly quick.

 

 

4.5x is SRAM cartridge is winner in my opinion. how would we demonstrate its features?

lets say we relocate the code and we get it to work.. whats next?

 

what we need is a short demo running at x1 and 4.5x speed...

 

Ndary

 

Under this option, we are talking about not just a "Math Cartridge" (for lack of a better description), but a full processing "slave" unit that would take instructions and data from the "master" Atari and process it and then send data back to the Atari for I/O? So SIO, hard drives, etc. would stay the same? The OS or some type of a device driver to handle the data transfers back/forth to the slave processor would need to be (re)written? Could cartridges (Action!, etc.) still be used via pass-thru? Would PBI/ECI devices (Black Box, etc.) be lilkely to still work? In short, what would we be likely to need to sacrifice with this device?

 

-Larry

[+bob1200xl]

Well,,, this won't be so cheap, I'm afraid, but you won't need any hardware changes.

 

I don't know what those carts are but the supercharger will probably not play well with others...

 

Bob

 

 

(hey, I dunno - $150?)

 

my 0.02$... i always wanted to have a 65816 but never got some of the turbo boards simply why? some of them were too expensive or needed hardware experience for expanding existing machines...

 

so i definitly would consider to have the cart version...as i am used to them with my turbofreezer xe cart and atari max cart. plug 'n play would be the best...

[+bob1200xl]

I would think that you would patch the program calling the FP OS routines and point them at the 65816, instead. You can't patch the OS in an 800, for example.

 

There are already thousands of working 6502 routines that you can use in your Atari and many of us already know how to write more. Why would I want to build up my PIC skills, invest in a PIC development platform, etc? Is it really any better than a 65816?

 

Yes, that is essentially the process with a minor alteration.

 

- the Atari can store and retrieve data directly into the 65816 dataspace without 65816 intervention.

 

Interfacing isn't so bad. One $D5xx address to select an 8K bank of flash memory, one to select an 8K bank of 65816 SRAM, one for control bits. (write protect, HALT...)

 

Bob

 

 

 

 

If a PIC is used, it has it's own onboard memory.

 

I would envisage a situation where the following example occurs:

 

- Atari tells PIC to receive an array of data. PIC then waits and Atari sends data with successive store operations.

- Atari tells PIC to perform operation on array of data (mult, divide, shift, rotate, whatever). PIC performs operation. Atari goes off and does other stuff for a while.

- Atari queries as to PIC status. PIC returns "Ready" status.

- Atari tells PIC to retrieve completed result. Atari then reads data.

 

The tricky part is interfacing. We need 8 bits I/O for data - no getting away from that.

Another bit is required to sense the $D5xx CARTCTL line, so that the PIC knows when it is being talked to.

More bits required for addressing (maybe). It might be the case that the thing could operate via a single register, via a command/response type system - e.g. Atari sets command requests via write to $D500. Waits/does other stuff for relevant amount of time, then reads $D500 successively to get status and result/s of operation.

 

 

If we're talking "Math co-processor" ie- supplementing or replacing the function of the FP-ROM @$D800, then things get a little complicated.

Due to the fixed location of all the routines in the ROM, it would likely be a case of having to copy the entire OS to RAM, then applying patches in the code.

 

Personally, I see such a use as secondary - having a slave processor would be much more beneficial to "proper" games which can utilize the PIC to perform tasks which the 6502 is inherantly slow at.

[raster/c.p.u.]

Yes. A full processing slave...

 

Hi.

It's amazing! You're talking about our 3 years old secret project called "Cart816".

Your description of main characteristics is exact the same as in our plans:

- no modifications of Atari hw

- cartridge working as full processing slave

- 65c816 with own RAM and sharing data with Atari by bankswitching in areas $8000-9fff and $a000-bfff

- the power of this device could be cca +1000%, because 65c816 will be working at 14MHz in own RAM without Antic DMA and memory refresh cycles.

 

We have bought cpu 65c816 long ago already, also some versions of schemes we inspected. Main problem is complications with practical construction (too many bus signals and their switching), that's why we are working on other easier projects now.

So, we can say only: "Yes, your idea is right in our view!"

 

Greetings, Bob!k & Raster / c.p.u.

[Rybags]

A doubled-up PCB might be the way to go. Just sit the second one on the first, and use header pins to transfer signals between boards.

 

Still, I guess we are talking a small area to work with. There's always the option to go a non-standard cart size - how much clearance does the 400/800 have when you close the door?

[+bob1200xl]

Well, don't keep it a secret - let us know how it's progressing.

 

What kind of problems did you have with buss switching? Did you try it at lower speed?

 

Bob

 

 

 

Yes. A full processing slave...

 

Hi.

It's amazing! You're talking about our 3 years old secret project called "Cart816".

Your description of main characteristics is exact the same as in our plans:

- no modifications of Atari hw

- cartridge working as full processing slave

- 65c816 with own RAM and sharing data with Atari by bankswitching in areas $8000-9fff and $a000-bfff

- the power of this device could be cca +1000%, because 65c816 will be working at 14MHz in own RAM without Antic DMA and memory refresh cycles.

 

We have bought cpu 65c816 long ago already, also some versions of schemes we inspected. Main problem is complications with practical construction (too many bus signals and their switching), that's why we are working on other easier projects now.

So, we can say only: "Yes, your idea is right in our view!"

 

Greetings, Bob!k & Raster / c.p.u.

[+bob1200xl]

You would have to leave the cartridge door open on the 400/800.

 

I think I prefer a 50/50 setup - where half of the hardware is in the cart and half (or more) at the end of a flat cable. You could toss a lot of stuff in the external box that way. CF cards, for one.

 

How important is it to get it all in the cart?

 

Bob

 

 

A doubled-up PCB might be the way to go. Just sit the second one on the first, and use header pins to transfer signals between boards.

 

Still, I guess we are talking a small area to work with. There's always the option to go a non-standard cart size - how much clearance does the 400/800 have when you close the door?

[raster/c.p.u.]

Well, don't keep it a secret - let us know how it's progressing.

We kept it a secret because we are afraid of questions about project progressing.

We wanted to publish it someday after finishing.

 

What kind of problems did you have with buss switching?

As I said already, the problem is too many bus signals - there is need to switch more than 20

address+data bus signals between Atari cart slot and two memory chips

and between cpu 65c816 and these two memory chips.

So, problem is design and practical construction of pcb, we haven't managed it

and we stopped working on this device for the present.

(We are collecting experiences in our other hw projects meanwhile.)

[+Larry]

You would have to leave the cartridge door open on the 400/800.

 

I think I prefer a 50/50 setup - where half of the hardware is in the cart and half (or more) at the end of a flat cable. You could toss a lot of stuff in the external box that way. CF cards, for one.

 

How important is it to get it all in the cart?

 

Bob

 

So the cart would still be plug-in to its regular jack; then (like the MyIDE external flash cart is frequently used) there would be a short ribbon cable with a box on the end for "stuff."

(pic at) http://www.atarimax.com/myide/documentation/

 

That sounds like a good solution for the problem to me. The box could actually be a second cart? That would work for all models, and would be ideal for an XE or an external cart jack like the BB, MIO XE/cart adapter or the KMK-JZ HD interface. If this turns out to be the direction, connectors at both "carts" would be nice so that the individual user could tailor the cable length to his own needs. 40-pin IDE ribbon cable/connectors, maybe? Maybe 80-conductor cable for good signal separation?

 

-Larry

Edited February 13, 2008 by Larry

[+bob1200xl]

I don't see you being able to use an external cartridge with this at all. The BB and MIO are PBI devices (KMK-JZ?) which are not affected by the supercharger. You will have to load cartridge code into the flash memory and run from that if you want a cartridge. The whole point of this is to run code in the 65816 - you have to modify the existing programs, either in 6502 memory/ROM or flash memory. You cannot modify a hard cartridge, right?

 

I've run some pretty long cables on the cartridge interface, 12 inches or so...

 

Bob

 

 

 

You would have to leave the cartridge door open on the 400/800.

 

I think I prefer a 50/50 setup - where half of the hardware is in the cart and half (or more) at the end of a flat cable. You could toss a lot of stuff in the external box that way. CF cards, for one.

 

How important is it to get it all in the cart?

 

Bob

 

So the cart would still be plug-in to its regular jack; then (like the MyIDE external flash cart is frequently used) there would be a short ribbon cable with a box on the end for "stuff."

(pic at) http://www.atarimax.com/myide/documentation/

 

That sounds like a good solution for the problem to me. The box could actually be a second cart? That would work for all models, and would be ideal for an XE or an external cart jack like the BB, MIO XE/cart adapter or the KMK-JZ HD interface. If this turns out to be the direction, connectors at both "carts" would be nice so that the individual user could tailor the cable length to his own needs. 40-pin IDE ribbon cable/connectors, maybe? Maybe 80-conductor cable for good signal separation?

 

-Larry

[+Larry]

I don't see you being able to use an external cartridge with this at all. The BB and MIO are PBI devices (KMK-JZ?) which are not affected by the supercharger. You will have to load cartridge code into the flash memory and run from that if you want a cartridge. The whole point of this is to run code in the 65816 - you have to modify the existing programs, either in 6502 memory/ROM or flash memory. You cannot modify a hard cartridge, right?

 

I've run some pretty long cables on the cartridge interface, 12 inches or so...

 

Bob

 

So the cart would still be plug-in to its regular jack; then (like the MyIDE external flash cart is frequently used) there would be a short ribbon cable with a box on the end for "stuff."

(pic at) http://www.atarimax.com/myide/documentation/

 

That sounds like a good solution for the problem to me. The box could actually be a second cart? That would work for all models, and would be ideal for an XE or an external cart jack like the BB, MIO XE/cart adapter or the KMK-JZ HD interface. If this turns out to be the direction, connectors at both "carts" would be nice so that the individual user could tailor the cable length to his own needs. 40-pin IDE ribbon cable/connectors, maybe? Maybe 80-conductor cable for good signal separation?

-Larry

 

Yes, I understood "no external carts" from your earlier posts. When I said "the cart would still plug-in to its regular jack..." I was referring to the "Supercharger" cart. "Second cart" means 2nd part of the SC at the other end of the ribbon cable, using another cart shell for an inexpensive enclosure. [sC1]=====[sC2]. In the case of the hard drive interfaces on XE's, that means [sC1] would plug into the cartridge jack on the HD interface or XE adapter.

 

-Larry

[+bob1200xl]

Sorry... I am focused on the external cartridge question and read it into yours. The second half of the hardware would probably be a little larger than a cartridge and we may want external power for the remote, much like the MIO. There is no reason why we couldn't run multiple 65816s in the second chassis, you know. Call it an Atari Core 2 Duo. (oh, has that name been taken?) (how about Atari Core 4 Quad?)

 

Bob

 

If you wanted to run an external cart, it could mount in the remote, I suppose - as long as we could get in front of it and control who uses the buss. I still don't see much value in that since the idea is to run from the COP, not the 6502.

 

 

 

I don't see you being able to use an external cartridge with this at all. The BB and MIO are PBI devices (KMK-JZ?) which are not affected by the supercharger. You will have to load cartridge code into the flash memory and run from that if you want a cartridge. The whole point of this is to run code in the 65816 - you have to modify the existing programs, either in 6502 memory/ROM or flash memory. You cannot modify a hard cartridge, right?

 

I've run some pretty long cables on the cartridge interface, 12 inches or so...

 

Bob

 

So the cart would still be plug-in to its regular jack; then (like the MyIDE external flash cart is frequently used) there would be a short ribbon cable with a box on the end for "stuff."

(pic at) http://www.atarimax.com/myide/documentation/

 

That sounds like a good solution for the problem to me. The box could actually be a second cart? That would work for all models, and would be ideal for an XE or an external cart jack like the BB, MIO XE/cart adapter or the KMK-JZ HD interface. If this turns out to be the direction, connectors at both "carts" would be nice so that the individual user could tailor the cable length to his own needs. 40-pin IDE ribbon cable/connectors, maybe? Maybe 80-conductor cable for good signal separation?

-Larry

 

Yes, I understood "no external carts" from your earlier posts. When I said "the cart would still plug-in to its regular jack..." I was referring to the "Supercharger" cart. "Second cart" means 2nd part of the SC at the other end of the ribbon cable, using another cart shell for an inexpensive enclosure. [sC1]=====[sC2]. In the case of the hard drive interfaces on XE's, that means [sC1] would plug into the cartridge jack on the HD interface or XE adapter.

 

-Larry

[Shawn Jefferson]

Yes. A full processing slave.

 

SIO would be unchanged on the 6502. If you wanted to 'put' a block of data to the 65816, you would enable 8K of 65816 memory in one of the two segments and just read/move data into the block. No OS changes are needed. To 'get' a block of data from the 65816, you just enable and write/move data.

 

I like this idea. Add a faster CPU (make it a 65816 so the programmers aren't learning something totally new) with some memory (1/4/8/16 MB?) into a cartridge. Allow the user to swap in any 8k bank into $A000 and/or $9000 (make them bankable seperately), and also allow the 6502 to access this memory as well. For games, I could see tons of benefits.

 

You could upload all your graphics data to the cartridge, and then during the VBI tell your cartridge 65816 CPU to move on-screen objects (even PMG!) and then ANTIC could display from somewhere in the $9000-BFFF range, use a charset or PMG area in that range. It could be used like a Blitter chip, or sort of a video co-processor. The great thing is that the utility of such a thing is totally up to the programmer.

 

Is this just pie-in-the-sky though? Is it possible to design such a thing that will fit in a cartridge and be powered from the atari? I'm not really a hardware guy, but I imagine you'd have to have a way to "lock" the memory when each CPU is using it. Also, on the software side, you'd have to have some sort of "default" bootstrap code for the 65816 to run until code is put into it's memory by the 6502 and it's told to run something. Hmmm, how would that work best I wonder? Maybe by generating an interrupt on the 65816 after setting it's interrupt vectors or something? interesting... I'd like to see this made and get into the hands of some programmers!

 

I'd throw out all the ideas about CF cards, IDE drives, etc.. Try to fit it in one cartridge (or maybe a slightly larger cartridge). I'd even throw out flash memory. Make it strictly a co-processor board with it's own memory. Nothing else... keep it simple and cheaper. I think that's enough to create some really interesting possibilities. I don't like the thought of running a cable from a cartridge to an external box with additional gear in it... that's just me though. If it can't be done any other way though...

Edited February 26, 2008 by Shawn Jefferson