Date: 2003-06-09 11:56:11
Hi Marko, >> The WiNGs system uses ATN in funny ways, as I supose many fastloaders do >Those that do usually fail to work when there is more than one device >connected to the serial bus. Is WiNGs different in this respect? I don't have a SuperCPU so haven't verified it, but presumably it is also a problem. WiNGs cannot use serial printers, so imaging its because they don't have the re-programability that a drive does. From the WiNGs specs for their serial bus protocol. 1) probes all devices using M-R 2) loads specialised DOSs into each found drive 3) uses ATN for clocking and CLK for data I assume it does this because ATN is the IRQ on the drives, and so in a multi-tasking system things can take a variable time to be completed... this is one way to make sure that things can happen when you finally get around to it... Spec below for interest only.... I haven't gotten 64HDD to emulate it (Don't have SuperCPU, so would be beta testing in the dark....) but it doesn't seem to hard a standard to follow. - Nick ============================================================= JOS IEC driver details ---------------------- Before running the JOS kernel (which overwrites the C64's Kernal) this should happen: All drives on the bus are probed with M-R's or some other detection routine, to discover what kind of drive and so it can be loaded with the appropriate DOS. Actual drive numbers (8-12 or whatever), are discarded, and each drive is given a number depending on the order it was found. e.g. If you had a device 8 and device 10, they would get JOS device numbers 0 and 1. The JOS device number is given to the drive when it is loaded with it's DOS. Also the booter program tells the drive whether or not it was the one booted from. After all drives are loaded with their DOS, they must all be executed with M-E's one after the other and then wait for 1 or 2 seconds so as to be sure all the other drives get executed. Then they have to prepare the serial bus and get ready to wait for commands. The IEC protocol ---------------- All devices on the bus must follow this protocol. It does mean that serial printers can't be used, but if anyone is serious about printing on C64, they shouldn't be using the slow serial bus anyway! This protocol may be extended in the future to allow for 128's burst mode, but for now it's just going to be a 1 bit asynchronous protocol. I've made a special device selection protocol that's multitasking friendly and also allows for one other slower device to be used (A multitasking PC emulating a drive). All other devices must be ready for the selection protocol at all times. The selection protocol ---------------------- The protocol sends a 4 bit device number, 1 bit at a time, bit 0 first. The drive must wait for ATN to be set, and then read a bit from CLK. Then wait for ATN to be cleared, and read another bit from CLK. Repeat those two steps to get the other 2 bits. If the device number isn't the correct number for the drive, go back and do the whole lot again. If it's the correct number, wait for DATA to be clear and then continue. Here's the 1541 version of this: getdev .( lda #atni sta atup waitag lda #0 sta DBYTE ldx #4 nxbit lda inport sta DSAFE2 and #atni cmp atup bne nxbit lda atup eor #atni sta atup lsr DBYTE lda DSAFE2 and #clki beq noclk lda DBYTE ora #8 sta DBYTE noclk dex bne nxbit lda DBYTE cmp Devnum bne waitag wait4d lda inport and #dati bne wait4d rts .) JOS's IEC driver also pays attention to the DATA line on every bit. The slow device on the bus is in control of the DATA line and uses it for handshaking each bit. If JOS doesn't see any change on the DATA line in required time, it ignores the DATA line and assumes no slow devices are listening. Once the device has been selected, it must communicate with 1 bit protocol as shown in the 1541 source code. Other protocols (like 128 burst mode) may be added later. The following commands must be implemented: The code numbers for these commands are in iec.i65. SKIPDEV - Finished with this device. This is sent when JOS wants to select another device, when called the drive must wait for a device number again. PARTCHECK - Partition check. This is sent when JOS's IEC driver is started, so it can make /dev/drX.X files for mounting filesystems on. The drive must try to identify all of it's partitions, and respond with the following information: 1 byte - Sub device (this is sent back with every block read/write). 1 byte - Partition type. #define PTYPE_Unknown 0 #define PTYPE_1541 1 #define PTYPE_1571 2 #define PTYPE_1581 3 #define PTYPE_CMD 4 #define PTYPE_IDE64 5 I'm sure the list will be expanded on later... 1 byte - Flags #define PF_Removable 1 ; This is set if the partition has removable media (floppies and cd's) #define PF_Boot 2 ; This is set if this is the partition that jos was booted from. #define PF_Burst 4 ; Set if the drive supports burst (Unimplemented yet!) #define PF_BustHack 8 ; Set if the drive supports a hacked burst protocol (Unimplemented yet!) #define PF_CDROM 16 ; Set if the partition responds to CDROM commands. 4 bytes - Block offset from start of device. 4 bytes - Number of blocks Before sending each partitions information, you must send OK ($02). When there are no more partitions to come, send ERR ($03). Each partition the JOS driver receives, gets turned into a device file of the format: /dev/dr[devicenumber]:[partitionindevice] LIGHTON - Turn the drive light on! Send back - OK The light for a drive will always be on when there's still blocks that haven't been written to the disk. The drive is free to turn the light on when LIGHTON hasn't been sent, but when LIGHTON is sent, it must stay on until LIGHTOFF is sent. LIGHTOFF - Turn the light off. DISKCHANGE - Check if the disk has been changed. Send back OK, if disk has changed, ERR otherwise. JOS will check if the disk has been changed everytime the light is off, so it can tell if it needs to refresh the disk cache. RESET - Wait 3 seconds and then reset the drive. Send back OK. READBL256 - Read a 256 byte block. 1 byte subdevice number. 4 byte block number. Blocks aren't sent as Track/Sector pairs, but as block numbers, which makes it a lot more device independent, and means D64 images can be mounted as filesystems. It's upto the device to work out the actual T/S values. Send back OK, followed by 256 bytes for the block. Send ERR if there is an error. WRITEBL256 - Write a 256 byte block. 1 byte subdevice number. 4 byte block number. 256 bytes for the block. Send back OK, if the block wrote correctly, ERR otherwise. READBL512 - Read a 512 byte block. WRITEBL512 - Write a 512 byte block. 1 byte subdevice 4 Byte block number Same as above but for 512 byte blocks. Note that partition information is handled by the JOS IEC driver, all it does is add the block offsets it was given by the PARTCHECK command. So the DOS needs to be able to access the raw sectors. This is only a first draft of this, so I might have missed some stuff out, or not considered certain things. So if you have any questions, or any suggestions, please tell me! Jolse ================================================ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Your Engineering Solutions Provider http://www.orbeng.com.au/orbital/engineeringServices/engServices.htm - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PLEASE TAKE NOTE: The contents of this email (including any attachments) may be privileged and confidential. Any unauthorised use of the contents is expressly prohibited. If you have received this email in error, please advise us immediately (you can contact us by telephone on +61 8 9441 2311 by reverse charge) and then permanently delete this email together with any attachments. We appreciate your co-operation. Whilst Orbital endeavours to take reasonable care to ensure that this email and any attachments are free from viruses or other defects, Orbital does not represent or warrant that such is explicitly the case (C) 2003: Orbital Engine Company (Australia) PTY LTD and its affiliates Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.