Hardware Idea

[danwinslow]

For all you talented hardware guru's out there :

 

I've often wanted a adaptor that would allow me to hook up any kind of small single board computer that has an IO pin breakout to the atari. Some way to map the pins into the memory space, and read and write to them. Boards like the Arduino's and the raspberry pi's, for instance. Seems like you could do an awful lot with an interface like that. SIO and so forth really is just too slow for anything other than emulated disk Drives.

 

Just a suggestion.

Edited February 10, 2014 by danwinslow

[foft]

I agree this would be neat. For simple projects you could start with the joystick ports. Just be careful because some new devices don't like 5v.

[+bob1200xl]

Do these things have an SPI interface? I am thinking on an SPI interface to directly talk to SD cards - maybe you could use that? (it's 3.3v at the card/device end)

 

What can you do with it?

 

Bob

[danwinslow]

I've thought about joystick ports too, and I know that somw folks have done for instance SPI on them.

 

But a general-purpose cartridge that would map 16 or 32 IO pins onto the atari memory space would just open up a lot of stuff. The main problem I can see is the 3.3v vs. 5v. I know it can be handled, but I don't have the hardware knowledge to really talk about it. There are probably other issues I am ignorant about as well.

 

What can be done? Well, for one you could take a SBC that had a USB port and an ethernet stack on it and interface it to the atari directly via a custom software layer. For instance, you could network mount atari drives. You'd have to write the code at both ends..although some of the boards support SPI on the IO pins and for that you'd just need to write the atari side. All kinds of cool control applications would open up via raspberry pi's and so forth.

 

Since you are writing the SBC side, you can boil down extremely complicated stuff like USB and Ethernet stacks into something very simple that the atari can just 'register' for. There's other solutions for some of these things : I myself am working on software from the dragoncart, which maps a cs8900a onto cartridge space, and there's a USB cart as well but the software stack to use these are relatively difficult to do on an Atari.

 

The whole point is the general purpose nature of it...who knows what people will come up with. With my limited knowledge, it seems like it would be fairly easy to do, but I may be wrong about that.

Edited February 10, 2014 by danwinslow

[fibrewire]

Does the AtariLab interface already provide a basic version of this? Or were you looking for something more advanced?

Edited February 10, 2014 by fibrewire

[danwinslow]

Yes, something way more advanced, with the pins mapped directly into memory. Not a joystick interface.

[Marius]

How can you think of something way more advanced, when you also write that you don't have the hardware knowledge to talk about.

 

The joystick port offers you a bi-directional 8bit wide I/O port. You can talk directly to pia, which is created in the first place for this kind of stuff.

 

With multiplexing you can extend (just like the multijoy interface does).

 

DMA is a whole different story. If you really want to go that path, study the basics of how IDE interfaces are working on A8 or cartridge technology. A simple, but very educational project is the original homebrew MyIDE.

 

Edit:

I can understand that what you want won't work through Joystick ports. But what you describe is not a simple project. I think the idea of looking at how IDE and Cart tech works is a good idea.

Edited February 11, 2014 by ProWizard

[Rybags]

A cheap alternative is something that hangs off the PBI bus. You can have I/O ports done by PIA, CIA, latches, whatever.

Possibilities are almost endless.

 

There were even magazine articles in the day describing cheap projects.

 

DMA... that's something that's lacking actually. Atari didn't bother to provide /HALT to the PBI which makes implementing it somewhat harder.

AFAIK, every single IDE implementation out there requires CPU intervention to transfer at the byte level, regardless of on cart, PBI/ECI or built into the machine.

[flashjazzcat]

Yes: no DMA on any existing IDE controller for the A8. You can read about DMA in the ATA specs, but that doesn't mean it can be employed on the Atari. We've hit the hard-limit of CPU bandwidth and even if you devote a whole 2KB PBI ROM bank to completely unrolling your loops, you still won't attain much better than the speed we manage at the moment.

[Marius]

I did not know that! I thought (when achieving speeds like 60KB/SEC) that it must have been DMA, but obviously it isn't...

[Rybags]

With full-blown DMA the limit would be whatever is decided to allocate from the remainder of cycles after screen DMA + Refresh from Antic.

 

A logical implementation would use some sort of bus-mastering control - have CPU/DMA access interleaved by settable ratio, or let the DMA take it all.

With DMA driven I/O, full screen video could be a walk in the park with little needed in the way of tricks to achieve it.

[HiassofT]

I don't quite understand what your exact goal is.

 

Currently there are (at least) two possibilities readily available on the Atari (BTW: don't worry about 3V/5V, you just need a bunch of level shifters, or even just a couple of FETs to do the voltage translation):

 

- Use the joystick port and do I/O purely in software. You won't get much above 10-100kHz due to the caps and inductors in the joystick port connection and some devices might not like the slowly rising edges

- Connect directly to the cartridge port or PBI. This is what the tomek cart does for example (if I understood the docs correctly). You can, for example, just hook up CCTL, PHI2 and a bunch of data lines to your controller board and you are done. But keep in mind that your controller than needs to be able to respond within some 200-300ns. Obviously you won't be able to handle this timing constraints if you are running a user space application under Linux on your Raspi, for example.

 

These are the two extremes, for all other applications you'll need some sort of application specific glue logic to implement a (software or hardware) handshake protocol. For example, if your controller can't respond within those 200-300ns you need something like a handshake line that tells the Atari if the controller has picked up your data.

 

If you want maximum speed you'll most certainly don't want to do this handshaking in software but in hardware. For example implementing a SPI port (not really complicated, The!Cart uses an SPI eeprom and I'm doing SPI completely in software - but shifting out single bits isn't exactly fast in software).

 

Once you've thought about timing/handshaking you must also think about available IOs. If your controller is really fast and has some 40 or 50 IOs, just hook it up to the PBI and do everything in software. But most controllers don't have such a high number of IOs, so you again have to think about some (software) protocol and, for example, transfer 16 bits of data in 2 8-bit packets.

 

There are various approaches to handle this, but there's no one-size-fits-all approach. It's highly application and controller specific.

 

To implement parts of the application specific glue logic in hardware the easiest way is to use a CPLD or small FPGA. You can then write your glue logic in VHDL and upload it to your CPLD/FPGA. If you want to go this route and have a Turbo Freezer 2011 you can to this easily with your freezer:

 

If you take your freezer apart you'll see that there are 2 PCBs inside. One PCB with a Xilinx XC95144XL CPLD and another one just with SRAM and flash. We designed the freezer so that it's modular and you can reuse the CPLD board for other stuff. These 2 PCBs connect with a 50-pin IDC header on the top which connects directly to the CPLD IOs (plus VCC/GND, but you have some 40 IOs available there). In case of the freezer the IOs are used for generating ram/flash control signals and carrying additional address lines (for bankswitching) - but if you reprogram the CPLD you can use them for anything you want.

 

If you look at the XL PBI adapter board you'll notice that there's space for another 50-pin header, carrying all PBI signals (we couldn't include this on the XE adapter board because space was too limited). You can use this header to plug in another CPLD board if you like.

 

Wolfram is currently doing this in a small side project, he used the CPLD board as the base for a new PCB, added several 7-segment displays and drives them with the CPLD.

 

so long,

 

Hias

[flashjazzcat]

I did not know that! I thought (when achieving speeds like 60KB/SEC) that it must have been DMA, but obviously it isn't...

This is why modern QD hard disk partitions are usually faster than RAMdisks (if the RAMdisk uses extended RAM in the $4000-$7FFF window and is, as a result, buffered - so it doesn't apply to the MIO RAMdisk). When the IDE driver reads bytes, it uses a loop something like:

 

Loop
	lda IDE_DATA
	sta (bufrlo),y
	iny
	bne Loop

This can be unrolled somewhat, and obviously bufrhi needs to be bumped and the loop executed a second time to read all 512 bytes. But the data transfer is approximately as fast as a typical move memory block routine, which (assuming self-modifying code), might involve loops like:

 

Loop
	lda $FFFF,x
	sta $FFFF,x
	inx
	bne Loop

Edited February 11, 2014 by flashjazzcat

[danwinslow]

How can you think of something way more advanced, when you also write that you don't have the hardware knowledge to talk about.

..snip..

But what you describe is not a simple project.

? I'm sorry, I'll try to only think of things that are simple. I never said this was a simple hardware idea. If you like the joystick deal, go for it.

 

Hiasoft, my exact goal is to provide a way to hook up io pins from an SBC and map them into the memory space of the atari. Thats it. I just think it would be interesting and useful. If it involves the PBI, fine. I don't care. I understand a lot about the software requirements for various drivers, I think part of the interest would be writing drivers on the SBC side.

Edited February 11, 2014 by danwinslow

[ricortes]

There's a lot of stuff that is interesting to me. Problem is a lot of stuff that seems interesting to me is singularly uninteresting to 99% of the general population. I don't mind doing stuff that is only interesting to myself, but I like it if it has broader acceptance.

 

Two part point. First part, is much of what you are asking has been done. Good examples would be Daryl Rictor and Grant Searle.

http://sbc.rictor.org/

 

Daryl has done a lot of interesting stuff. For instance he has a general 6502 SPI and 40 column display based on an AVR. Really, too numerous to mention, better to follow the link.

 

http://searle.hostei.com/grant/

 

Grant<I found him while educating myself on CP/M> took Daryl's AVR design and expanded it to 80 column. Looking at what is available, you could buy the latest greatest AVR and expand it to a ~640x200 bit mapped display.

 

Second point: As neat and wonderful as the work these guys do is, it apparently does not have broad appeal. There is still the core guys that have always found the nuts and bolts interesting, but the rest of the population just wants their iPhone and remote control.

 

I've made a fair amount of crap, 6551 in a cart, 8 bit D/A converter, multiple PIAs. No one other then myself cares and I am OK with that. If I have a couple of bucks to throw at something I find interesting, it's a hobby so it's OK. Most of the good stuff has been done with the Atari 8bit. If there is another application out there that hasn't been discovered yet, most people would prefer it to be built from parts that are readily available and current. Just as a for instance, my brother is into vintage cars and usually runs carburetors on them because FI is multiple thousands of dollars. Knowing this, I sometimes think a simple FI system running off a micro would be a neat hack. Problem is, if I showed up at my brother's house with an Atari computer under my arm and an FI throttle body, I know the look he would give me. I'll probably never get around to it and if I do, it had better be with something you can get all the parts from a supplier rather then thrift stores and eBay.

 

I hope you see my points. There are others who see what you are asking interesting and a worth while pursuit, just not a lot of them. There is also the tug of doing something popular and needed. Most of the 6502 stuff has been done and for future designs there is a bit of moving on that has to be done if for no reason other then 30 year old computers are getting rare. Last rain storm a pine tree fell on my 1972 BMW. Crushed the roof and smashed the windshield. There goes my free time this summer. The tug thing.

[Xuel]

Maybe not quite in the spirit of true DMA, but you can achieve similar results if you move the memory outside the Atari and use EXTSEL to disable the internal memory. When the device wants to DMA, it can simply ignore the address and data bus from the Atari. The 6502 and Antic should steer clear of the memory that the device is managing during this time. This is principle I used to develop my "Atari Beaglebone Expansion" which is really just external memory that can DMA from the Beaglebone's DDR.

 

Edited February 11, 2014 by Xuel

[danwinslow]

It was just a suggestion, guys. If nobody is interested, fine. I personally think it would be a handy item. I'd build it myself if I could, or I'd help finance someone who wanted to build one.

 

ricortes - yeah thats some interesting stuff. But saying something 'has been done' does not mean 'and therefore should never be done again'. Seeing that someone somewhere did a home project and got something to work is not the same as a professionally produced general purpose adaptor. But, like I said, if nobody is interested, fine. It was mostly just an idle thought that occurred to me.

[flashjazzcat]

Maybe not quite in the spirit of true DMA, but you can achieve similar results if you move the memory outside the Atari and use EXTSEL to disable the internal memory.

That should be sufficient incentive to stick 1MB of RAM on the next IDE adapter that comes out.

Edited February 11, 2014 by flashjazzcat

[Xuel]

That should be sufficient incentive to stick 1MB of RAM on the next IDE adapter that comes out.

 

Yeah, theoretically, such a device could completely replace the internal memory and thus be able to nearly instantly fill entire regions of memory with DMA. Contrast with all current IDE devices which rely on the 6502 to copy data from a register in the $DXXX region to the destination of the CIO operation.

[flashjazzcat]

Yeah, theoretically, such a device could completely replace the internal memory and thus be able to nearly instantly fill entire regions of memory with DMA. Contrast with all current IDE devices which rely on the 6502 to copy data from a register in the $DXXX region to the destination of the CIO operation.

I think Ultimate replaces the base 64K as well as the extra 1MB (might be wrong there, though).

[Marius]

I'm not sure Ultimate replaces base memory. I believe I also have to upgrade a 600XL to 64KB first...

[+CharlieChaplin]

Maybe not quite in the spirit of true DMA, but you can achieve similar results if you move the memory outside the Atari and use EXTSEL to disable the internal memory.

That should be sufficient incentive to stick 1MB of RAM on the next IDE adapter that comes out.

 

Hmmm,

 

looking at the wonderful designs of "RAM 320XL" and "RAM 320XE", I wonder if someone ever had the idea to create something like a "PBI / ECI - Cartridge" ? I mean a hardware upgrade similar to IDE+/IDE-2 but much smaller and much more compact and most of all *with a case*, that offers harddisk-ability, but without any rotating/moving hardware like IDE or SATA harddisks, just CF or SD cards instead. (YES, I know there is SIDE/SIDE-2 !)

 

To make the upgrade as small and compact as possible, there could be two separate versions, one for the XL-computers (PBI-Cart) and one for the XE-computers (ECI-Cart, uses ECI+Cart port and therefore comes with an additional ECI+Cart-port). If the upgrade would be small+compact enough, it could look very similar to RAM320XL or RAM320XE...

 

And err, since the RAM 320XL or the RAM 320XE could probably not be used together with this upgrade anymore (I guess), this PBI-Cart or ECI-Cart could also have some RAM enhancement (320k, 576k or 1088k RAM) onboard. But I am not sure if the PBI / ECI - Cart would still be very small+compact then (no gfx or snd upgrades for sure, to keep it as small+compact as possible)...

 

Again, I know there is already SIDE/SIDE-2, but what do you think of this idea ? Instead of SIO2SD something like PBI2SD or ECI2SD. (Okay, maybe I hi-jacked this topic again.) -Andreas Koch.

Edited February 11, 2014 by CharlieChaplin

[+David_P]

There was a Supra PBI experimenter's board that may help meet your needs. (I think Best may still have them in stock)

 

Or find a 1090xl...

[fibrewire]

Just as a for instance, my brother is into vintage cars and usually runs carburetors on them because FI is multiple thousands of dollars. Knowing this, I sometimes think a simple FI system running off a micro would be a neat hack. Problem is, if I showed up at my brother's house with an Atari computer under my arm and an FI throttle body, I know the look he would give me. I'll probably never get around to it and if I do, it had better be with something you can get all the parts from a supplier rather then thrift stores and eBay.

Started as a 2-stroke project and can now do the impossible - http://www.diyautotune.com

 

Where is this 6551 in a cart?

[flashjazzcat]

looking at the wonderful designs of "RAM 320XL" and "RAM 320XE", I wonder if someone ever had the idea to create something like a "PBI / ECI - Cartridge" ? I mean a hardware upgrade similar to IDE+/IDE-2 but much smaller and much more compact and most of all *with a case*, that offers harddisk-ability, but without any rotating/moving hardware like IDE or SATA harddisks, just CF or SD cards instead. (YES, I know there is SIDE/SIDE-2 !)

 

To make the upgrade as small and compact as possible, there could be two separate versions, one for the XL-computers (PBI-Cart) and one for the XE-computers (ECI-Cart, uses ECI+Cart port and therefore comes with an additional ECI+Cart-port). If the upgrade would be small+compact enough, it could look very similar to RAM320XL or RAM320XE...

 

And err, since the RAM 320XL or the RAM 320XE could probably not be used together with this upgrade anymore (I guess), this PBI-Cart or ECI-Cart could also have some RAM enhancement (320k, 576k or 1088k RAM) onboard. But I am not sure if the PBI / ECI - Cart would still be very small+compact then (no gfx or snd upgrades for sure, to keep it as small+compact as possible)...

+1 for a case and on-board RAM. IDE Plus is portable and self-contained, but SDX really needs extra RAM, and the lack of it on the adapter means the host machine still needs a RAM upgrade.