206 replies to this topic

[Thelen]

Can anyone tell me how the data of the Sio port is being send etc?? I want to make a disk drive emulator.

thanx,

THELEN

[Gunstar]

This may seem stupid or patronizing, but just on an outside chance that your unaware...You do realize that such emulators exist? As well as info on the custom SIO2PC/SIO21050 cable projects?

[Curt Vendel]

Well, you have a lot of avenue's available to you already with emulators and other projects from the past, but hey, I never talk anyone out of trying to come up with something better and who knows, maybe something will and everyone benefits, so here ya go:
http://www.atari-his...es/SIOspecs.pdf

Curt

[candle]

I know how old this thread is, but..
I had once printed this document, and would really get it again, is it possible?
there are many broken links inside atari museum i'm affride

[Fröhn]

http://ftp.pigwa.net...../Tech%20Info/

[candle]

Thanks Fröhn!
it seems i underestimate that server

[atariksi]

candle, on Tue Feb 3, 2009 9:19 PM, said:

I know how old this thread is, but..
I had once printed this document, and would really get it again, is it possible?
there are many broken links inside atari museum i'm affride

I took the hard way and hooked up the PC parallel port in between disk drive and Atari 800 SIO line and logged the signals into a file at various baud rates and then figured out everything from there...
But it worked out better as I found out some things not in the documents. And the Clock In/Out signals are still not completely documented.

[candle]

this is true, and since i'm going to put ft232b (ft232r when i get it) in bit-bang mode, i would really appreciate any help that You could provide
havig to couple with rs232, or even worse - emulated rs232 protocol, when bit-bang mode (even synchronous one, with separate clock in and clock out) is possible is (IMHO) waste of time, and resources

[candle]

i wrote little program to test mode 000 of sio (skctl=3) - using start as clock signal and select as data in i was able to clock in any data into serin register

data is as follows:
1 start bit (0)
8 bit of data lsb first
1 stop bit - level is not relevant

here is the source and executalbe, one needs mads to compile this

if anyone would bother to write executable loader working in mode 0 it would be of great help - my knowledge to atari system is very limited
took few hours of searching throught various sources to get this working on real atari

[Rybags]

Quick and easy way to get a Gr. 0 screen.

Store $FF in location $340 (ICHID). That makes CIO think that IOCB #0 is closed, whether it is or not (we need it CLOSEd so we can OPEN it again).

Do a CIO OPEN of "E:" for IOCB #0

  LDX #0; X=00 use IOCB #0
  LDA #$FF
  STA $340; make CIO think IOCB #0 is closed
  LDA #<DEVNAME
  STA $344
  LDA #>DEVNAME
  STA $345; DEVNAME contains text value of "E:"
  LDA #$C
  STA $34A
  STX $34B; AUX bytes = $C and 00.  $C = Open for Input and Output
  LDA #3
  STA $342; Command byte 3 = OPEN
  JSR $E456; perform call to CIO
  BMI ERROR; flags reflect Y (status/error code) from CIO
;
; status will be returned in Y Register, should be 01,
; any error condition Y should be >=$80
;
  JMP CONTINUE; get on with rest of program
DEVNAME .BYTE "E:",$9B
;
; Device name must be delimited by Return character ($9B)
;

You can use PUT character to do screen output, or you can simply store to the screen directly.
SAVMSC ($58,59) is the screen address pointer.


One thing I don't get. You say you're using Start/Select. The keys? Your source code seems to make no reference to them.

Edited by Rybags, Fri Feb 6, 2009 10:45 PM.

[Rybags]

Suppose I should include a PUT CHARCTER call...

There is a built-in PUT CHARACTER method for any device, done so probably because BASIC was developed in parallel to the OS and function calls weren't yet established.

To output a single character (contained in A):

  LDX #0; using IOCB #0
  TAY; save A
  LDA #0
  STA $348
  STA $349; set Buffer Length to zero = only output what's in A
  LDA #$B; 11=PUT CHARACTERS
  TYA
  JSR $E456
  BMI ERROR

[candle]

i did say that i'm using start and select keys, because i've connected them do sio lines - clock (pin 1) and data in (pin 3) respectivly - they are my clock and data lines for sio communication and this makes me a device
as for cio - i did my own put line, cls and int2hex just because i didn't want to use it - i don't know if this is reliable since vblank is off and irqs are off - as i said - i don't know about system calls
it might be bad habit to do this as i did, but it was the quick and dirty one to get thing done

the point of this experiment was to explore possibility of using externally clocked sio transmission to send data to and receive from atari - and it is possible.
for me next step would be to write little windows application sending and receiving sio frames using lpt port (simpler for me, as i have most of the code ready), and then go to lt232 chip most of you knows as rs232 to usb bridge

i would still need loader for executables on atari side though

[Rybags]

PMSL. I had a feeling it might have been something like that.

Wouldn't it have just been easier to use a joystick or something? Or a second Atari.

For SIO, unless you're using some insane bitrate, it's fine to just leave all the normal IRQs and VBI enabled.
The system will disable DLIs by default, since they can vary enormously in size.

All you need to do is set the CRITIC flag non-zero (store 1 in $42). That'll tell the system to not run the Stage 2 VBlank.

You also seem to be using a polling method inside a loop - you can if you want just modify the SERIN IRQ vector and use that instead.

[atariksi]

candle, on Wed Feb 4, 2009 5:45 AM, said:

this is true, and since i'm going to put ft232b (ft232r when i get it) in bit-bang mode, i would really appreciate any help that You could provide
havig to couple with rs232, or even worse - emulated rs232 protocol, when bit-bang mode (even synchronous one, with separate clock in and clock out) is possible is (IMHO) waste of time, and resources

One thing I found out in experimenting with the SIO was that 18078 to 19886 bauds are all tolerable for the standard 19.2Kbs Atari 1050 disk drive simulation.

If you want to simulate the entire RS232 with its various settings of parity, 7-bit, etc., you are better off directly polling bit 4 of 53275 at a fixed frequency using a timer IRQ except when RS232 settings correspond to what the Atari SIO hardware supports.

[ijor]

atariksi, on Tue Feb 3, 2009 10:29 PM, said:

I took the hard way and hooked up the PC parallel port in between disk drive and Atari 800 SIO line and logged the signals into a file at various baud rates and then figured out everything from there...
But it worked out better as I found out some things not in the documents. And the Clock In/Out signals are still not completely documented.

Exactly which undocumented issues you found?

[candle]

Rybags: well, i have a goal of 87kbytes per second, calculate the bitrate for yourself, this would require 20 clocks per byte, and it might be a dream, but i think that with this type of communication this dream might become true
important question is how fast - following the sio protocol or not is smaller issue here - i can get the byte i sent put at specific memory location
all i need is loader, which would go as fast as possible
irq - for that speed, you need to calulate interrupt latency, add the time needed for stack operations and rti instruction - it might be not fast enought
ideally i would do first byte by polling the irqst regiester, and then just get remaining bytes as fast as possible
i don't know the limit of clock speed i can feed to pokey, but i think its well worth futher exploration
and what PMSL means?

atariksi: you get me wrong, i want to use ft232 in bit-bang mode - giving me full control of eight bi-directional data lines, so i don't have to deal with any protocol at all

[Rybags]

I highly doubt you'll get anywhere 87 KB per second.

Some simple maths can tell us how quickly I/O occurs. Every byte has "0" start bit, 8 data, 1 stop bit. Sadly, no way around that, you get it regardless of clocked or unclocked mode.
Of course, there is the bit-bang mode where you read the port directly, but I think you'd hit the wall there before you'd hit the upper limit that Pokey can do on it's own.

So, let's call it 87,000 bytes/second for the reason of calculating. That's 870,000 bits per second. Only 2 machine cycles per bit (actually slightly more).
I don't know how quickly Pokey can deal with incoming serial data, but only giving it 2 cycles per bit might be asking a little too much.

Now the CPU side... 87,000 IRQs per second equals 5.5769 per scanline on a PAL system. In a best-case situation, you can have 105 cycles for the CPU per scanline (ie screen DMA disabled in Antic). That's only 18 cycles per byte received.

That wipes out IRQs completely. Polling... well, the way I'd go is:
Disable all other IRQ sources... that means that SERIN becomes the only potential IRQ type. You can then poll IRQs by LDX IRQST; INX; BEQ WAIT
That's 9 cycles per iteration of your wait loop (minimum), and that doesn't include resetting the IRQ status or actually storing the byte in RAM.

I'd forget about 87 K/Second. We've exceeded what the CPU can handle. Possibly pushed Pokey too hard too. And this is before we even consider the limits of the external circuitry.

I have no idea what's the fastest SIO speed anyone has managed. I think ~ 57 kbps (kilobits/second) is the fastest in commonly available disk drives. However, I think there might be products that take it closer to 80 kbps.

Assuming we don't run into problems with the external circuitry not handling it, once you want to go above that, you'd probably want to disable screen DMA to give yourself more free cycles. And, use polling rather than putting up with the overhead of servicing IRQs.

[HiassofT]

Rybags, on Sun Feb 8, 2009 1:04 AM, said:

I highly doubt you'll get anywhere 87 KB per second.

ACK.

First, I'm not sure how Pokey could handle this rate. And not only the Pokey, but also the serial connection (there are capacitors from the signal lines to ground, and it's just standard 5V, not at least +/-9 to 12 V as in standard RS232, and also not a current loop like in RS485).

Next thing: you wrote that you'd like to do bit banging with an USB device. Are you sure that it's possible to push some 1.5 mega transactions through an USB bus? I really doubt that. I haven't checked the specs, but I'd assume the device doesn't use USB2.0 (only USB1.1) and even with USB2.0 I'd guess you won't be able to do more than 10k-100k transactions per second.

Quote

Now the CPU side... 87,000 IRQs per second equals 5.5769 per scanline on a PAL system. In a best-case situation, you can have 105 cycles for the CPU per scanline (ie screen DMA disabled in Antic). That's only 18 cycles per byte received.

Sijmen and I did some tests with MyIDE, and were able to transmit up to 60-80k (bytes) per second. It depended on the harddrive/CF card used and there were still a few cycles left to play sampled audio. I'd have to dig out my results, but this was highly optimized code and we were pushing things to the limit.

So: You could get up to 100k (bytes) per second in polling mode, but then the Atari isn't able to do anything more.

Quote

I have no idea what's the fastest SIO speed anyone has managed. I think ~ 57 kbps (kilobits/second) is the fastest in commonly available disk drives. However, I think there might be products that take it closer to 80 kbps.

I did some tests last night (independently from this thread) using a 16C950 card in my PC, hacking AtariSIO and testing with my highspeed SIO code (which uses polled mode):

I got reliable transfers up to 80-87 kbit/sec (pokey divisor 4 and 3). It's even possible to go up to 110kbit (pokey divisor 1), but then you have to disable the VBI (or replace it with a shorter one, like for example "Copy 2000 V2.41" does).

I also ran a few tests with screen DMA enabled/disabled, but that didn't make any difference. When looking at the received data it was clear that a byte was missed when the standard VBI kicked in (and that was with CRITIC=1 and IRQs disabled, of course).

so long,

Hias

[Rybags]

What do you mean by Pokey Divisor 4,3 and 1 ?

[candle]

he mean what you would put to audf4 to get that speed in mode 2x or 1x of sio (skctl value)

hias:
i have never seen so much ignorance in my entire life!
device (ft232) is capable of doing 3mbit serial rs232-ttl compatible link, in bit-bang mode your speed is 16x this, but this doesnt mean that you can do 48mbit transmission, because this is usb 2.0 full-speed device (12mbits), but you didn't bother to check that out

for your knowledge in other application i'm doing over 1mbit right now using lpt port, and this is nothing compared to what i could

and i never said atari have to do anything more for the time of transmission...
anyway - what should it do? display "loading" or blue screen with cursor on it?

i'll write no more until i get link set up

[Rybags]

I don't think your device is the problem.

The Atari is where you'll experience the bottleneck, almost 100% certain of that.

I'd advise - start small, aim for something like 60 kbps. Get your code nice and compact, then start ramping the speed up.

[ijor]

candle, on Sat Feb 7, 2009 8:11 PM, said:

hias:
i have never seen so much ignorance in my entire life!

Was that necessary?

Hias is one of the world top Atari experts. He is among the people that most contributed to the Atari community, both with software and hardware. Furthermore, unlike other experts, he is extremely friendly, polite and modest.

He might be wrong or he might be not, that's not the main point. There is no need to use that kind of language.

[candle]

got byte send at close to 1mbit ratio confirmed

this is code for sending one byte

//---------------------------------------------------------------------------
void SPI_DOut(byte b)
{
		__asm   {
		mov	 al,b;
		ror	 al,2;
		mov	 b,al;
		}
		ClrPortBit(BasePort,6);
		SetPortBit(BasePort,0);
		SPI_Delay();
		ClrPortBit(BasePort,0);
		for (int i=0;i<8;i++) {
				z=PortIn(BasePort);
				__asm   {
				mov	 ah,z;
				and	 ah,191;
				mov	 al,b;
				and	 al,64;
				or	  ah,al;
				mov	 z,ah;
				}
				PortOut(BasePort,z);
				SetPortBit(BasePort,0);
				SPI_Delay();
				ClrPortBit(BasePort,0);
				__asm   {
				mov	 al,b;
				ror	 al,1;
				mov	 b,al;
				}
		}
		SetPortBit(BasePort,6);
		SetPortBit(BasePort,0);
		SPI_Delay();
		ClrPortBit(BasePort,0);
}
//---------------------------------------------------------------------------
//---------------------------------------------------------------------------
void SPI_Delay()
{
// empty call for delay
}

as for hardware - i'm using spi-flash programmer that you may find on my web page (www.spiflash.org)

[candle]

ijor: thats maybe true, and i appologise, but the point is one should not make judges based on information ones didn't bother to check

i'm trying to do something here, seeking for help, not for doubts

Edited by candle, Sat Feb 7, 2009 8:23 PM.

[Rybags]

Since you've already tried hooking your Start/Select keys direct to Pokey, are you going to try running your device hooked directly as well?

It would be interesting to find out just what the upper limit of SIO is... and you'd most likely achieve it in such an unhindered setup.