Mini 850 Clone?

[flashjazzcat]

PBI runs at bus speed, so you'll have a theoretical max of ... 360KB/s ? (somebody pls correct me)

Unless a PBI device somehow manages DMA, you're relying on 6502 instructions to read data from a port and store it in memory, and the most you'll then manage is about 80KB/s in a tight loop. The 6502 takes a dozen or so cycles just to loop around reading a register storing the data in RAM.

[+Stephen]

One more reason to not use SIO for this, is we can have simultaneous data transfer and saving to disk. Another nice side effect, is not hearing the constant high pitch whine from the R: driver.

[Gunstar]

Unless a PBI device somehow manages DMA, you're relying on 6502 instructions to read data from a port and store it in memory, and the most you'll then manage is about 80KB/s in a tight loop. The 6502 takes a dozen or so cycles just to loop around reading a register storing the data in RAM.

Even though I'm way out of my league here, I can confirm (which is sort of like the moron confirming the genius is smart, when it comes to this stuff) that number from my research of the Multi i/o and BB speeds as they mention 50-80KB/s average, depending on the drive. So if I'm not totally mixed up on my translation math, which I may be, isn't that about 819Kbps? which would still make it a lot faster than 126Kbps speeds over the SIO with zero divisor...

Edited November 1, 2018 by Gunstar

[flashjazzcat]

Even though I'm way out of my league here, I can confirm that number from my research of the Multi i/o and BB speeds as they mention 50-80KB/s average, depending on the drive. So if I'm not totally mixed up on my translation math, which I may be, isn't that about 819Kbps? which would still make it a lot faster than 126Kbps speeds over the SIO with zero divisor...

The maximum bandwidth of the CPU in the looping scenario I described is ~640Kb/s. Naturally this is a lot more than 127Kb/s (POKEY divisor 0). There's zero contention about the fact that parallel IO between the CPU and the peripheral is going to be magnitudes quicker than SIO. The CPU is the governing factor with current IDE/SCSI solutions, which is why the RAPIDISK driver for the U1MB/SIDE can roughly double the speed of communication with the hard disk (when a 20MHz CPU is present; the increase would be a lot greater were it not for the fact transfers are still hampered by the speed of base memory).

[+Nezgar]

...the Multi i/o and BB speeds as they mention 50-80KB/s average, depending on the drive.

You can remove drive constraints by just benchmarking the MIO RAMdisk, which I believe is just mapping/banking 2KB at a time into the PBI memory area via DMA. You can then go as fast you can copy bytes from one memory location to another.

 

I should pull out my MIO and do a RWTEST again, I forget the speed, but 80KB/s sounds right.

[flashjazzcat]

The FMS and ANTIC DMA will impact your RWTEST speeds regardless of the device tested. SDX when testing an IDE HDD with 512 byte sectors hits 60-64KB/s reads, ANTIC DMA enabled, and dependant on PAL/NTSC. The CPU is fast enough to have to wait a bit for the drive to become ready (especially during writes), but the rest of the time, it's a straight read port/store in buffer operation, which is faster than copying RAM from one place to another. Any DOS incapable of handling native 512 byte HDD sectors (i.e. anything which isn't SDX) will be marginally slower again.

[Mathy]

Hello Gunstar

 

I do believe he is looking into both ways, one central box or each with their own and even talk of an 800 just used as a hub too, with it's 4-joystick ports if he goes the controller port route. And yes, even though the PBI and cartridge ports might be faster, he is concerned about blocking PBI and cart ports.

 

I never really liked the idea of using a computer as a central hub. A computer can do so much more. Plus the 800 might have 4 joystick ports, but the XL and XE don't have that many.

 

My idea would be to use a small box for each computer. That way the box is small and you don't need ports for computers you don't use. If you'd want to connect 4 or more computers together, you'd need 4 or more SIO ports. "One box per computer" would mean that you have two SIO connectors per box (if you don't want this to be the "end of the chain" device) and some port to interconnect all the boxes. The price per box would be lower than the price for "one box for all computers". And you might be able to connect up to 8, 16 or even 32 computers without 8, 16 or 32 SIO ports taking up space on the "one box for all computers". "One box for all computers" would also mean that you have to place the computers fairly close together. "One box per computer" would mean you could use for instance MIDI-cables to interconnect all boxes as a ring. This would be a big advantage when trying for instance to play a game together at a meeting. And maybe, just maybe, the "one box per computer" could mimic a MIDI or Multilink connection.

 

Sincerely

 

Mathy (who's been looking for an intelligent "one box per computer" for a long long time)

[ivop]

Why would you want to create a custom way to connect computers together when there's ethernet? Even if you don't want a full tcp/ip stack on each computer, you can still use ethernet for more low level protocols.

[Mathy]

Hello Ivo

 

Because I do NOT want to use ethernet all the time. We can have ethernet interfaces too. But not to connect Atari 8 bit computers that are in the same room.

 

Sincerely

 

Mathy

[+Nezgar]

The FMS and ANTIC DMA will impact your RWTEST speeds regardless of the device tested. SDX when testing an IDE HDD with 512 byte sectors hits 60-64KB/s reads, ANTIC DMA enabled, and dependant on PAL/NTSC. The CPU is fast enough to have to wait a bit for the drive to become ready (especially during writes), but the rest of the time, it's a straight read port/store in buffer operation, which is faster than copying RAM from one place to another. Any DOS incapable of handling native 512 byte HDD sectors (i.e. anything which isn't SDX) will be marginally slower again.

 

You're pretty spot on FJC! I set up the MIO to do some RWTEST testing on The Real Thing™ - original v1.1 ROM, 1023K RAMDisk only, 256Byte sectors. 800XL with Stock XL Rev 2 OS. here are the results:

 

SpartaDOS X 4.48 loaded from SIDE2, Screen ON:

 

SpartaDOS X 4.48 loaded from SIDE2, Screen OFF:

 

RealDOS v1.0a Build 0030, Screen ON:

 

RealDOS v1.0a Build 0030, Screen OFF:

 

SpartaDOS 3.2f I didn't capture. It was maybe only 2% slower than RealDOS. But... Wow, reading is 45-47% faster without screen DMA! Would be faster with 512B sectors, but not supported by MIO, at least with current drivers. And RealDOS has about a 11-13% edge over SDX.. but RealDOS / Sparta 3.2 are much more lean than SDX...

[Dropcheck]

Hello guys (m/f)

 

 

That reminded me of Rudolf Cornelissen's IOCOMP V3. (You have to scroll down a bit) Yes, it's a very crude design, but based on the 850 and can work stand alone. Some of its features might be incorporated into the new device, although the Motorola MC6802 should be replaced with something more modern or more "Atari". And the device only has 8kB of RAM....

 

Sincerely

 

Mathy

 

PS I never used the device, but it should be here somewhere (probably in a box in the attic).

 

I was looking at the file offered for download. From what I can tell it contains a manual (in German, but hey I've got Google translator ) and three files that look like they might be some kind of rudimentary Eagle board files. Having a time finding a program to pull them up in for viewing. But no .bin file or source that I can find.

[ivop]

You can view them with "edit.com" from his smARTWORX package:

 

I suppose if you scroll around, take some screenshot and stitch them with the gimp, you'll get a pretty decent image. I'll see what I can do.

 

[Mathy]

Hello Lenore

 

It's Dutch.

 

Sincerely

 

Mathy

[Dropcheck]

Hello Lenore

 

It's Dutch.

 

Sincerely

 

Mathy

 

Sorry.......

[toddtmw]

I have some notes so far about taking the SDrive-MAX (ATMega32) and adapting it up to the Mega2560... It would give all the SD card goodness there is now, plus two serial ports with full flow control, parallel port, and if I'm feeling jaunty I may also add in the hardware for a WD1772 to control real floppies. I've been toying with an All-in-one SIO peripheral so long, and never thought about developing on an arduino until the SDrive thingy.. So, all the pieces are finally coming together for me.. Except time..

 

Please let me know when you have this working!!!!

[ivop]

Here's iocompv3.pcb :

 

[ivop]

Plus the silkscreen:

 

[_The Doctor__]

no second side? all those hole to hole jumpers can be placed on the back, In fact the whole thing could be shrunk down. Nice project.

[ivop]

And the wires:

 

 

BTW this is the last image. This should be enough to trace the circuit

Edited November 3, 2018 by ivop

[Mathy]

Hello Lenore

 

Sorry.......

 

Well, it might explain why Google Translate translates some things the wrong way.

 

IIRC he told me his buddy and him entered the code by hand. I've checked the mails on my iMac. The oldest one is from 2005. My conversation with Rudolf was probably before that. 2005 was probably the year that I bought my first non-Atari computer. Meaning all I can tell you is what I remember.

 

Sincerely

 

Mathy

Edited November 3, 2018 by Mathy

[Kyle22]

Wouldn't it only require motor control to shut off the incoming bytes from the modem and either proceed or interrupt to stop the computer from sending to the modem?

 

Why is this so difficult?

 

Edit: This is completely within concurrent mode.

 

No need to drop out of concurrent mode, just use motor control to tri-state SIO as the R:Verter does when SIO disk (or P:) access is needed.

 

 

Kick up the baud rate as the USDoubler does, why couldn't we get 19.2 out of this?

 

It seems very plausible to me.

 

Motor control halts incoming data when either the buffer is full or there is other SIO traffic. The R:Handler would also halt outgoing data as well so as not to interfere with the SIO transaction.

Edited November 10, 2018 by Kyle22

[Dropcheck]

I thought someone said here they knew a guy who might have the P:R firmware. Mytek?

 

Maybe I need Previgen more than I thought.

[_The Doctor__]

all that brain fixing stuff is so expensive we'd have to cut the pills in half to share... but your too far away... and so it goes.

[+mytek]

I thought someone said here they knew a guy who might have the P:R firmware. Mytek?

 

Maybe I need Previgen more than I thought.

 

Unfortunately he isn't answering my emails. Fell off the map for a bit I'm afraid. Last time this happened he was MIA for over a decade, so hopefully he'll show up way sooner this time around.

[ivop]

 

I was looking at the file offered for download. From what I can tell it contains a manual (in German, but hey I've got Google translator ) and three files that look like they might be some kind of rudimentary Eagle board files. Having a time finding a program to pull them up in for viewing. But no .bin file or source that I can find.

 

Now that I extracted the PCB layers, are you planning on tracing the circuit? If not, or if you don't have the time yet, I volunteer to do it myself. I'm looking for a bite sized project and this seems manageable with a clear end goal.