8 Bit boot sequence question

[danwinslow]

I am writing a small program to allow an 8 bit to boot off of a single board computer. The initial boot load seems to go ok, but at the end of that sequence I get some commands with a device of $4F and a command of $40. Here is a (commented) log snip of the sequence at the end :

 

processing header 31 52 4f 0 d2 //this is the regular boot sequence running

// a 'read sector' for d1: sector 4F

send data frame, 128 bytes checksum fc

MSR 0

processing header 31 52 50 0 d3 // next sector...etc.

send data frame, 128 bytes checksum 49

MSR 30

processing header 31 52 51 0 d4

send data frame, 128 bytes checksum 1d

MSR 0

processing header 31 52 52 0 d5

send data frame, 128 bytes checksum 2a

MSR 0

processing header 31 52 69 1 ed

send data frame, 128 bytes checksum 8d

MSR 30

processing header 31 52 6a 1 ee

send data frame, 128 bytes checksum 0 // boot sequence over now

MSR 30

processing header 4f 40 4f 4f 2e // and I get this ?

unhandled device code : 0x4f

MSR 30

processing header 4f 40 4f 4f 2e

unhandled device code : 0x4f

MSR 30

processing header 4f 40 4f 4f 2e

unhandled device code : 0x4f

MSR 30

processing header 4f 40 4f 4f 2e

unhandled device code : 0x4f

MSR 30

processing header 4f 40 4f 4f 2e

unhandled device code : 0x4f

MSR 30

processing header 4f 40 4f 4f 2e

unhandled device code : 0x4f

 

 

So does anyone have any idea what the command of ' 4f 40 4f 4f 2e' is? I can't find a device or command that matches those numbers.

Edited May 24, 2005 by danwinslow

[mr-atari]

I am writing a small program to allow an 8 bit to boot off of a single board computer. The initial boot load seems to go ok, but at the end of that sequence I get some commands with a device of $4F and a command of $40. Here is a (commented) log snip of the sequence at the end :

 

It's the XL-upgraded SIO protocol. 4F is a poll 3 command: "are you there?"

 

The device should answer back and download its (relocate-able) driver.

 

For as I know it's a delevopment upgrade, not applied in (new) devices.

 

Read the 1200XL addendum for explanation of these new command.

 

Cheers,

Sijmen.

[danwinslow]

Thanks, Sijmen

 

Are you aware of any links on the web for information concerning this expanded SIO protocol?

[Bryan]

Here you go.

XLupdate.zip

[danwinslow]

Thanks, Bryan. There doesn't seem to be much information on how to respond negatively; I mean, I have no handler to upload. The 130xe seems to hang around waiting for something on its type 3 poll; it takes quite a while, and does get evenatually past it after doing 2 type 3's and 2 type 4's. I expected to be able to nak it or error it and it would give up but it doesn't seem to pay attention to the naks/errors.

[ijor]

Ignore then completely, all Atari peripherals do. There is nothing you can do to make the boot faster. That's the reason that XL-XE take longer to boot than older ones.

[Bryan]

It seems to me that this is the sort of thing you shouldn't respond to unless you have a handler to upload. I looked at the firmware specs for the XF551, and it doesn't list that it responds to it either. How long is the timeout period during all this? Is this part of the normal "flatulence" noise heard after a DOS.SYS load?

 

-Bry

[danwinslow]

No..lol flatulence...its a quiet wait. It seems to be waiting inordinately long, say 15-20 seconds or so between each of 3 or so tries. I responded to the initial status query ( command $53 ) with a very long timeout period, I wonder if that is affecting it.

[ijor]

its a quiet wait. It seems to be waiting inordinately long, say 15-20 seconds or so between each of 3 or so tries.

 

Hmm, then it looks like you did something wrong.

 

I responded to the initial status query ( command $53 ) with a very long timeout period, I wonder if that is affecting it.

 

No, it is normal for a drive to reply with a long timeout. This timeout is (normally) used only for the format command, which does take a while. And the timeout is only for the Complete sequence, not for the Ack/Nak one. SIO has a fixed short timeout for the latter.

[danwinslow]

Ok, thanks to you guys, got this worked out. The correct response is not a NAK or an error, but nothing at all. Me NAKing the type 3 poll was confusing the poor thing. If no response at all is received it times out quickly, although it does cycle through 20 or so type 3 and type 4 polls, but if not responded to they go quickly, so the delay all in all is just the standard extra bit of time for an XL boot and the contented farting noise.

 

Most of this you guys had already told me, but yknow.

 

Thanks!

Edited May 25, 2005 by danwinslow

[ijor]

SIO is a one-to-many bus. There is a master, the computer; and there are slaves, the peripherals. It is like the army (or at the school, if you want). You are supposed to talk only when you have been told so. Otherwise remain absolutely silent.

 

Ignore everything unless the device id is same as yours and the checksum is ok.

[danwinslow]

OK, new topic without burning up a new thread :

 

Booting off of a MACH37A.ATR file ( MachDos c3.7a ), I get a wierd sequence when switching out to dos from basic ( via the DOS command ) :

 

*snip*

processing header 31 50 0 2c ad

write sector 11264 on device 0 (D1:) sector size 128

receive_data_frame got 128 bytes

MSR 0

sio_recv_waiting()=>28

processing header 31 50 0 2c ad

write sector 11264 on device 0 (D1:) sector size 128

checksum in receive_data_frame not ok, 0 != 109

*snip*

 

This looks like an attempt to write sector 11264.....? Is this a hard drive check maybe?

[ijor]

Doesn't seem to be a hard disk check. I would expect it would try a read and not a write.

 

Several drive enhancements use this style of command for reading/writing to their extended buffer, or for setting drive configuration. From the ones I remember, the $2C00 range doesn't seem to valid for anyone except perhaps for the Happy 810.

 

Not sure about the H810, think it's a valid sector. But I wouldn't expect the program to attempt that write before making sure it's indeed a Happy. Did you receive an 'H' command, or a similar read command before?

 

A few points are not clear from your snip. Why it tries that write twice? Why you got a checksum error on the second attempt? Why you accepted the command at all? You should NAK any attempt to read or write an invalid sector in the first place.

 

A possible explanation is that the second time the software is switching to a high SIO speed. That could explain the checksum error. And if you didn't NAK the first time but insted you replied with Error at the end, this could be expected.

[danwinslow]

Yes, I woudl expect a read too on a disk check. Thats an interesting suggestion about writing internal buffers, a bogus sector would be a good way to do that. It tries the write twice because my response confused it I think. The checksum error I am not sure about....it could be because if it really trying to write an internal command buffer I may not be pulling the right count off of the bus.

I accepted the command on purpose to see what would happen in order to get debugging data points. Certainly a stock 810/1050 would NAK this...

Edited May 26, 2005 by danwinslow