One of the main unfinished aspects of the C65 ROM is the IEC serial interface. From memory, it is basically copied from the C128, and massaged for the C65's different hardware. However, it is not particularly well adapted for the 3.5MHz mode, and had some quite nasty timing bugs. Those bugs are amplified on the MEGA65, where the CPU can run at 1MHz, 2MHz, 3.5MHz or 40.5MHz. The core problem, as I recall, is that it counts rasters to determine some of the delays, and if a raster happens to tick over soon into one of those delays, it can cause a very much smaller delay than intended.
Getting this kind of code 100% can be a bit of a pain, because its one of those situations where software is trying to pretend to be hardware: i.e., offer precise and reliable timing characteristics. The code also takes a lot of space in the ROM. So it would be nice if we can resolve this.
It would also be great to have the MEGA65 support JiffyDOS out of the box, without the need for a (currently non-existent) C65 ROM that contains JiffyDOS. We do have an open implementation of the JiffyDOS protocol in the OpenROMs project, but it would still take more space in the ROM.
Another nice benefit, is that it would make it much easier to write software for the MEGA65 that doesn't use the ROM, as talking to IEC serial peripherals will basically use a few POKEs in place of a few JSRs.
So given all the above, I wondered about the plausibility of implementing the IEC serial protocol directly in VHDL, and providing a simple set of registers for controlling this. It sounds simple, but as with everything with the IEC serial protocol, things are never quite as simple as one might hope.
The first step was to create iec_serial.vhdl, and begin implementing various IEC serial operations, and build this in a little toy bitstream that has only the IEC interface and serial UART communications, so that I can manipulate it easily from my Linux machine. This also has the benefit that I can synthesise a bitstream much, much faster, in about 5 to 10 minutes, instead of around an hour. I am looking at upgrading FPGA build machine I have access to, but until then, this is a massive advantage.
Here is my initally planned memory map for the IEC serial hardware accelerator. It's likely to change a bit, but you get the general idea:
$D697 -- IRC control
$D697.7 AUTOIEC:IRQFLAG Interrupt flag. Set if any IRQ event is triggered.
$D697.6 AUTOIEC:IRQRX Set if a byte has been received from a listener.
$D697.5 AUTOIEC:IRQREADY Set if ready to process a command
$D697.4 AUTOIEC:IRQTO Set if a protocol timeout has occurred, e.g., device not found.
$D697.3 AUTOIEC:IRQEN Enable interrupts if set
$D697.2 AUTOIEC:IRQRXEN Enable RX interrupt source if set
$D697.1 AUTOIEC:IRQREADYEN Enable TX interrupt source if set
$D697.0 AUTOIEC:IRQTOEN Enable timeout interrupt source if set
$D698 - IEC serial interface status (when reading)
$D698.7 AUTOIEC:STNODEV Device not present
$D698.6 AUTOIEC:STNOEOF End of file
$D698.5 AUTOIEC:STSRQ State of SRQ line
$D698.4 AUTOIEC:STVERIFY Verify error occurred
$D698.3 AUTOIEC:STC State of CLK line
$D698.2 AUTOIEC:STD Sate of DATA line
$D698.1 AUTOIEC:STTO Timeout occurred
$D698.0 AUTOIEC:STDDIR Data direction when timeout occurred.
$D698 - IEC serial interface command (when writing)
The list of commands I will support will likely vary, but are currently in two main groups: Commands for debugging/bitbashing the IEC bus, and actual IEC operations:
Bit-bashing / Debug operations:
$41 (capital A) - Set ATN line to +5V
$61 (lower-case A) - Set ATN line to 0V
$43 (capital C) - Set CLK line to +5V
$63 (lower-case C) - Set CLK line to 0V
$44 (capital D) - Set DATA line to +5V
$64 (lower-case D) - Set DATA line to 0V
$53 (capital S) - Set SRQ line to +5V
$73 (lower-case S) - Set SRQ line to 0V
$52 (capital R) - Set RESET line to +5V
$72 (lower-case R) - Set RESET line to 0V
Those are all already implemented. The remaining commands are the IEC operations:
$00 - Abort any currently running command
$30 - Send data byte with ATN asserted (i.e., ATN at 0V)
$31 - Send normal data byte
$32 - Receive byte
$33 - Send EOI without sending a byte
$34 - Send a byte with EOI
$35 - Turn-around from talk to listen
Only $00 and $30 are implemented so far, and I'm currently debugging $30 at the moment. But more on that after we have discussed the other registers...
$D699 - Data byte (read for received byte, write to set byte to transmit)
$D69A - IEC serial peripheral device information (fully writeable)
$D69A.7 AUTOIEC:DIPRESENT Device is present
$D69A.5-6 AUTOIEC:DIPROT Device protocol (00=1541,01=C128/C65 FAST, 10 = JiffyDOS(tm), 11=both
$D69A.4 AUTOIEC:DIATN Device is currently held under attention
$D69A.0-3 AUTOIEC:DIDEVNUM Lower 4 bits of currently selected device number
The device information register is writeable, so that if for some reason you want to use a different protocol than is automatically detected, you can. The auto-detection of C128 fast, and JiffyDOS protocols differ in various ways, and are quite interesting topics. Both come into play when sending a byte under attention, which is also the first command that I have been working on.
The C128 fast serial protocol detection works by having the controller send a $FF byte using the SRQ line as the clock, before sending the first bit under attention. The device doesn't acknowledge this immediately, but rather just remembers it. It then knows that it is free to send bytes to the computer using the fast serial protocol.
Well, that's how it works when the controller initiates communications. If a disk drive has been asked to TALK, then when the controller releases the ATN line, and before sending any bits of data, it does much the same in the other direction, except this time, the byte will be $00, because the device is holding the DATA line at 0V.
JiffyDOS works differently: The detection is done at much the same time, i.e., during the sending of a byte under attention. However, instead of doing the SRQ thing, it instead delays for a few hundred micro-seconds when sending the 7th bit, and checks to see if the device pulls the data line to 0V. If it does, then it supports JiffyDOS.
A device can of course, support both, and I'm going to support both in this thing.
Now, to debug all this, I need a convenient way to see what is going on. I have only a two-channel oscilloscope, but have 4 lines I need to monitor. Also, monitoring the lines externally doesn't let us see whether the controller or a device is holding a line at 0V.
To solve this, I am adding a temporary debug BRAM to the IEC controller that logs the state of the four lines as output by the controller, and also the SRQ, DATA and CLK pins as input. This means that we can tell if the controller has released a line, but a device is holding it at 0V, but not the other way around. We also track the state of the RESET line. It also tracks the state in the IEC controller state machine, so that I can easily visualise exactly what is going wrong and where.
I have set this up so that it takes a sample slightly faster than 1MHz, as this is the fastest that my controller of a device will change the lines. Thus a 4KB BRAM gets us about 4ms, which is longer than a single byte transfer. If necessary, I can add extra BRAMs to test longer transactions.
I have this more or less working now, and now need to make a tool to read this data out, and visualise it. My hacky test bitstream framework isn't particularly fast, so I might have to think about ways I can speed it up from the ~20 bytes per second of debug RAM it is currently accessable at with the various overheads of what I hacked together. But we'll start by just seeing how it goes.
Probably what would be most useful is to render a PNG image showing the waveform of all the signals, and indicating whether it is a device or the controller (or controller + device) that is holding each line at 0V.
With a bit of hacking, I have this working, generating PNG files of the traces for me:
Red indicates that the controller has pulled a line low (or both are pulling it low), while blue indicates that a device is pulling a line low. Black means neither is pulling the signal low. The yellow lines indicate the voltage visible on each line. The numbers underneath indicate which state the state machine was in at the time. This makes it really easy to match the events back to the VHDL.
Clearly I have some problems here, because RESET and ATN are both being asserted to 0V, as are in fact CLK and DATA. I think there are some problems with the polarity sense of some or all of the lines, which I'll confirm with a multi-meter.
I'm away for a couple of days, so don't have a MEGA65 or 1541 with me here. I'd like to continue testing the controller however. So the best option for that is to implement a 1541 in VHDL, and use that to test with. VHDL simulation is slow, however, so I'd like to skip the bulk of the initialisation stuff that the 1541 ROM does. So I'm looking at a disassembly of the 1541 ROM to see how I might be able to patch it to achieve this.
So let's trace through:
1541 reset vector points to $EAA0.
$EAA7 - $EB21 performs various tests of the ROMs and RAM. We can skip those, and go directly to $EB22. This is good, because those tests will take quite a large number of cycles.
$EB22 - $EB39 sets up CIA registers, so we need to keep that.
$EB3A - EB4A sets the device number from the pads/jumpers, so we need to keep that.
$EB4B - $EBD4 sets up pointer tables, we need to keep that. However, along the way, it calls $F259 to initialise the disk controller. I'm suspecting that that might be a bit slow. We'll take a look at that in a moment.
$EBD5 - $EBE3 sets the initial DOS status to 73, and releases the CLK, DATA and ATNA lines. So we should keep that. But, hang on a minute -- what is the ATNA line? Does this mean that a 1541 can assert ATN ? (the C64, or MEGA65 for that matter, can't read it, however, so this is just an interesting curiosity).
$EBE4 then calls $E780 to see if we need to boot a system routine. Not quite sure what that means either yet. We'll add it to our list of things to investigate.
$EBE7 is the next instruction, and this routine is labeled "Idle loop. Wait for something to do." This seems to be the place we want to get to, for the ROM to start responding to commands.
So let's look at those routines at $F259 and $E780 to check for any nasty surprises.
$F259 is the controller initialisation, when then bleeds into checking the job queue, and doing the next thing. It looks like it has to execute perhaps a hundred or so instructions. It then exits via $F99C which can take a while if the drive is active, but looks to be fairly benign if the drive is idle.
$E780 lets a 1541 load a file from disk into its own RAM and execute it on power on. I never knew that this was possible, without a computer commanding it via the & DOS command. However, apparently, if you power a 1541 on with CLK and DATA both grounded, it will do exactly that. Anyway, for our purposes we don't need that. We just need to make sure that it _doesn't_ happen, as it will just waste a lot of cycles. So we need to make sure that within the first few cycles of simulation, CLK and DATA are released high.
Now, in terms of read sense of the CLK and DATA lines, we can tell this from the ROM as well: Both are inverted, i.e., reading a bit value of 0 means that the line is at 5V. Clock is on port $1800 bit 2, and data on bit 0 of the same port.
So I think that's everything we need to know right now.
Based on the above, if I patch the 1541 ROM to have NOP instructions ($EA) in $EAA7 - $EB21, that should save the bulk of boot time, before the drive is ready to listen.
Now, in terms of implementing the 1541 in my VHDL test framework, I already have a partly implemented 1541 that was intended for use as a soft virtual 1541 in the MEGA65 (which I still intend to do). So it's probably best to just finish that off. It already has ROMs and RAMs mapped, and a dummy CPU, and 6522 CIA chips from another open-source project. The good thing is that for the CPU, I don't need to implement all opcodes just yet, just the ones used in the 1541 ROM. Doing it this way will also bring us closer to having the internal virtual 1541 implemented.
I've implemented a bunch of the instructions, and the CPU on the 1541 progresses, but ends up in a loop reporting a drive error. Now, when the 1541 boots up, it does declare the "error" 73 that contains the drive identification string. That looks to be what is happening here, because I can see the call to ERRTS0, that declares a drive error with track and sector both set to zero, which is what happens with the initial "error" 73.
However, because I haven't yet patched out the drive ROM and RAM tests, it takes a long time to reach that point. So I'll patch those out first, and then re-run the test to see whether it sets the error and gets to the main loop of the drive routine.
Ok, so we reach the code to set error 73 after 456 instructions. However, it never finds the error message. I'm guessing this is because the ($nn,X) addressing mode might be broken.
I fixed those problems, and now after 2954 instructions it finds the tokenised error 73 message at $E718. The 1541 ROM saves space by not storing the error messages as plain text, but rather has bytes that represent some of the common words that occur in the error messages. This means that it's a bit more complicated to trace the code through
From there it gets to $E73D, and then starts to detokenise and output the error message. The message gets written out using some STA ($A5),Y instructions, which should make it fairly easy to trace through, and verify that the 6502 CPU is working correctly for this part.
Let's trace those instructions:
Instr#:2968 PC: $E763, A:43, X:00, Y:03, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:2983 PC: $E763, A:42, X:00, Y:04, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:2998 PC: $E763, A:4D, X:00, Y:05, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3013 PC: $E763, A:20, X:00, Y:06, SP:3D NVxBDIZC=00100111, Decoding i_sta, mode = m_inny
Instr#:3028 PC: $E763, A:44, X:00, Y:07, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3043 PC: $E763, A:4F, X:00, Y:08, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3058 PC: $E763, A:53, X:00, Y:09, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3073 PC: $E763, A:20, X:00, Y:0A, SP:3D NVxBDIZC=00100111, Decoding i_sta, mode = m_inny
Instr#:3088 PC: $E763, A:56, X:00, Y:0B, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3103 PC: $E763, A:32, X:00, Y:0C, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3118 PC: $E763, A:2E, X:00, Y:0D, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3133 PC: $E763, A:36, X:00, Y:0E, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3148 PC: $E763, A:20, X:00, Y:0F, SP:3D NVxBDIZC=00100111, Decoding i_sta, mode = m_inny
Instr#:3163 PC: $E763, A:31, X:00, Y:10, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3178 PC: $E763, A:35, X:00, Y:11, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3193 PC: $E763, A:34, X:00, Y:12, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3208 PC: $E763, A:31, X:00, Y:13, SP:3D NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3217 PC: $E6E5, A:2C, X:00, Y:14, SP:43 NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3235 PC: $E6B8, A:30, X:00, Y:15, SP:3F NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3241 PC: $E6B8, A:30, X:00, Y:16, SP:41 NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3245 PC: $E6EF, A:2C, X:00, Y:17, SP:43 NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3263 PC: $E6B8, A:30, X:00, Y:18, SP:3F NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
Instr#:3269 PC: $E6B8, A:30, X:00, Y:19, SP:41 NVxBDIZC=00100101, Decoding i_sta, mode = m_inny
In other words, it writes out CBM DOS V2.6 1541,00,00. So far, so good!
From there, it heads back to $EBDA, and then to $EBE7, which is the idle loop for the 1541:
Instr#:3291 PC: $EBE7, A:00, X:00, Y:19, SP:45 NVxBDIZC=00100110, Decoding i_cli, mode = m_impl
So let's get back to why we were doing all this: I am trying to make hardware-accelerated IEC bus control for the MEGA65, and to debug that, its handy to have a IEC bus client device in VHDL, so that I can debug it all under simulation, cycle by cycle.
Now that the CPU gets far enough, we need to wire-in the 6522 VIA IO chips of the 1541, so that we can actually connect it to the bus of our hardware-accelerated IEC controller. Let's look at how this is done on the 1541:
This shows the connection of VIA1 at $1800 to the IEC bus:
Port B Bit 0 - DATA (input)
Port B Bit 1 - DATA (output)
Port B Bit 2 - CLK (input)
Port B Bit 3 - CLK (output)
Port B bit 4 - ATNA (output??)
Port B bit 7 - ATN (input)
CA1 - ATN (input)
Well, the first thing I noticed here, is that the 1541 seems to be able to assert the ATN line, which I never knew was possible. This is for one of the early board revisions, and this capability might have been removed on later revisions.
Otherwise, it looks pretty sensible. ATN is tied to both PB7 and CA1, presumably so that ATN can be easily read on the data port, but can also trigger an interrupt via the CA1 line.
The CLK and DATA output lines will pull the IEC lines low when those signals are high, thanks to the 7406 inverters, or at least that's how it looks to me at first glance. Yes, looking at the 1541 ROM at $EBE8 we can see that to release all IEC lines, it ANDs $1800 with #$E5, i.e., clearing bits 1, 3 and 4.
So let's hook those all up, and add some debug logic to track the IEC bus state in simulation. One of the nice things about doing this in simulation, is that we can see who is pulling a line low at any given time, which really helps with protocol debugging.
After a few hours debugging all the plumbing, and getting all the inversions of signals along the way correct, the VHDL 1541 now correctly triggers an IRQ when the ATN line is pulled low by the controller. Things then go to pot, because I hadn't implemented interrupts properly, let alone the RTI instruction. So I better fix those, then see how it goes.
Okay, with that, we are now catching the ATN signal, and starting to receive a byte. The routine to handle an ATN request at $E85B is reached. So now to trace that through...
We get to $E884, which is the point where the ATN service routine calls the IEC read byte routine. Now we are getting to the juicy part, where we can get useful information about what is going.
We then get to ACP03 at $EA0B, which is the loop to receive each bit of the byte. This seems to go through correctly several times, before getting stuck. Looking closer, it looks like the IEC transmission is getting out of sync with the receiver quite badly. This is why simulation is good, because I can now tweak my IEC trace generator program to parse the output of the simulation file, and draw me a nice trace of the signals -- and because under simulation we know who is pulling a line low, we can see _exactly_ what is going on, and going wrong.
I've opted for a textual output instead, partly because I can have it tell me more of the story that way. I have it interleave information about the state of the bus line, including who is pulling which lines low, as well as the IEC bus state in the IEC controller, as well as where the 1541 ROM is currently executing. This gives a great deal of transparency as to what is going on. This is what we are seeing at the moment:
+12117.426 : ATN=0, DATA=1, CLK=1
+0.025 : ATN=0, DATA=1, CLK=0(C64)
iec_state = 122
iec_state = 123
$E85B 1541: Service ATN from C64
+295.341 : ATN=0, DATA=0(DRIVE), CLK=0(C64)
+0.074 : ATN=0, DATA=0(DRIVE), CLK=1
$E9C9 1541: ACPTR (Serial bus receive byte,pc)
+93.064 : ATN=0, DATA=1, CLK=1
iec_state = 128
iec_state = 129
+0.099 : ATN=0, DATA=1, CLK=0(C64)
iec_state = 131
+4.370 : ATN=0, DATA=0(C64), CLK=0(C64)
iec_state = 132
iec_state = 133
+14.988 : ATN=0, DATA=0(C64), CLK=1
iec_state = 135
+20.001 : ATN=0, DATA=1, CLK=0(C64)
iec_state = 137
+5.012 : ATN=0, DATA=0(C64), CLK=0(C64)
iec_state = 139
+14.988 : ATN=0, DATA=0(C64), CLK=1
$EA0B 1541: Receive bit of serial bus byte
iec_state = 141
+20.001 : ATN=0, DATA=1, CLK=0(C64)
iec_state = 143
+5.012 : ATN=0, DATA=0(C64), CLK=0(C64)
$EA1A 1541: Got bit of serial bus byte
iec_state = 145
+14.988 : ATN=0, DATA=0(C64), CLK=1
iec_state = 147
The +numbers are the time in micro-seconds since the last change to the bus lines.
What we can see from the above, is that the controller (marked as "C64") is waggling the data lines sending data bits, before the 1541 is ready to receive the first bit of data.
The problem is that we are releasing CLK too fast after seeing a drive pull DATA low. The timing diagrams don't claim that any particular delay is required here, but clearly it is required. Looking at the C64's ROM disassembly, it uses a 1ms delay. So we have to wait at least 1ms before releasing CLK. That will be easy to fix.
I've fixed a bunch of problems there, but am finding that the 20usec for each half of the clock for a bit seems to be too fast for bytes sent under ATN to the 1541. The loop in the 1541 is from $EA0B to $EA28.
First, it clears the EOI flag (5 cycles), then reads from $1800 to check the CLK line (minimum 8 cycles), then it grabs and stashes the bit (12 cycles). Then it checks the state of the ATN line (19 cycles), does a de-bounced read of the clock line (16 cycles), decrements the bit counter and branches back to the top (8 cycles).
In other words, the 1541 ROM requires at least 5 + 8 + 12 + 19 + 16 + 8 = 68 cycles to read a bit under ATN. That's way more than the 20 + 20 = 40 listed in the reference guide. This totally explains why its missing bits.
70 usec would seem to be the bare minimum that we should try, to allow for some clock drift between host and device. And, with that, I do now get the byte sent completely, and acknowledged by the drive. That's great!
Now, does the drive receive the byte that I think I sent to it? The completed byte gets loaded from location $85 at $EA2B, so I can see that in my VHDL simultion as well. I am writing $28 to call device 8 to attention. However, what gets loaded from $85 is not $28. Instead, we seem to load $AB.
Hmm.. $AB = 10101011 in binary, which doesn't really look like any real relation of $28. The bits get stored using an ROR $85 instruction at $EA18. Indeed I am seeing that sequence of bits that makes $AB get received and stashed. So the CPU looks to be doing the right thing. Am I sending the right bits? Yes, it looks like I am. So it must be something funny in my quickly cobbled together 6502 for the drive. I'm suspecting the LSR A instruction as a likely culprit. Yup: Spotted a stupid error: The carry flag was being set from bit 0 of the last memory access, rather than bit 0 of the accumulator. With that fixed, the VHDL 1541 correctly receives the byte $28 that I sent to it :)
Okay, so we are now at the point where we can send bytes under attention. Or rather, at least one byte under attention. I'm thinking I will continue the testing by asking the VHDL 1541 to send the contents of the error channel, i.e., to talk on channel 15. This will require sending multiple bytes under ATN, as well as doing a turn-around to listener for the controller, and then receiving bytes from the IEC bus. Specifically, we have to send $48 then $6F under ATN, do a turn-around to listen, and then read bytes from the IEC bus.
Actually, it needs to be $4B then $6F, because the VHDL 1541 doesn't have its "dip switches" set to device 8 by default, but rather device 11. With that, I can confirm that the 1541 is indeed seeing that it needs to talk, and having its secondary address set using my nice little program that parses the VHDL simulation output, to show what the simulation is trying to do, and what the 1541 is doing, by peeking at its program counter. This is what I see as output now (with the boring bit-by-bit stuff cut out for brevity):
+0.006 : ATN=1, DATA=1, CLK=1
$EBE7 1541: Enter IDLE loop
iec_state = 100
...
iec_state = 120
+12117.426 : ATN=0, DATA=1, CLK=0(C64)
iec_state = 121
$E85B 1541: Service ATN from C64
+295.366 : ATN=0, DATA=0(DRIVE), CLK=0(C64)
iec_state = 122
+724.587 : ATN=0, DATA=0(DRIVE), CLK=1
iec_state = 124
$E9C9 1541: ACPTR (Serial bus receive byte)
...
$EA2B 1541: ACP03A+17 Got all 8 bits
$E89F 1541: Received TALK command for device
$E9C9 1541: ACPTR (Serial bus receive byte)
$E9CD 1541: ACP00A (wait for CLK to go to 5V)
...
$E9CD 1541: ACP00A (wait for CLK to go to 5V)
iec_state = 100
...
iec_state = 122
+2603.796 : ATN=0, DATA=0(DRIVE), CLK=1
iec_state = 124
+50.643 : ATN=0, DATA=1, CLK=1
iec_state = 125
$E9DF 1541: ACP00 (saw CLK get released)
...
+54.767 : ATN=0, DATA=0(DRIVE), CLK=0(C64)
$EA2B 1541: ACP03A+17 Got all 8 bits
$E8BE 1541: Received secondary address
So next step is to implement the turn-around from talker to listener, and add that to the test, ready for actually reading data.
The IEC turn-around is a special jiggle of the CLK and DATA lines so that the two devices talking switch who is the sender.
At the start, the computer is holding CLK low, and the device is holding DATA low. Then the computer pulls DATA low as well, and then soon after releases CLK. The device being asked to talk then pulls CLK low, and then soon after releases DATA. At this point, DATA is being held low by the computer, to say that it's not yet ready to receive a byte of data, and the device doing the talking is also holding CLK low to say that it doesn't yet have data ready to send. But before all that, we have to release ATN and wait at least 20usec.
In short, it's really not that complicated, even though at first glance it sounds a bit byzantine. And indeed the implementation is quite simple:
-- TURNAROUND FROM TALKER TO LISTENER
-- Wait 20 usec, release ATN, wait 20usec
-- Computer pulls DATA low and releases CLK.
-- Device then pulls CLK low and releases DATA.
when 200 => micro_wait(20);
when 201 => a('1'); micro_wait(20);
when 202 => d('0'); c('1'); micro_wait(20);
when 203 => milli_wait(64); wait_clk_low <= '1';
when 204 =>
if iec_clk_i = '0' then
report "IEC: TURNAROUND complete";
iec_state <= iec_state + 2;
else
-- Timeout
report "IEC: TURNAROUND TIMEOUT: Device failed to turn-aruond to talker wihtin 64ms";
iec_state_reached <= to_unsigned(iec_state,12);
iec_state <= 0;
iec_devinfo <= x"00";
iec_status(1) <= '1'; -- TIMEOUT OCCURRED ...
iec_status(0) <= '1'; -- ... WHILE WE WERE TALKING
iec_busy <= '0';
-- Release all IEC lines
a('1');
d('1');
end if;
when 205 =>
-- Device is present
iec_devinfo(7) <= '1';
iec_busy <= '0';
-- Device is now talking
iec_dev_listening <= '0';
-- We are no longer under attention
iec_under_attention <= '0';
iec_devinfo(4) <= '1';
iec_state_reached <= to_unsigned(iec_state,12);
iec_state <= 0;
After this, when I run a test using it, we see that the 1541 is ready and waiting to send a byte:
...
+54.347 : ATN=0, DATA=0(DRIVE), CLK=0(C64)
$EA2B 1541: ACP03A+17 Got all 8 bits
$E8BE 1541: Received secondary address
iec_state = 200
iec_state = 201
+2638.711 : ATN=1, DATA=0(DRIVE), CLK=0(C64)
iec_state = 202
+20.001 : ATN=1, DATA=0(C64+DRIVE), CLK=1
$E8F1 1541: TURNAROUND (Serial bus wants to become talker)
iec_state = 203
+30.149 : ATN=1, DATA=0(C64), CLK=1
+19.235 : ATN=1, DATA=0(C64), CLK=0(DRIVE)
iec_state = 204
iec_state = 206
$E909 1541: TALK (Serial bus wants to send a byte)
+125.534 : ATN=1, DATA=0(C64), CLK=1
The bold parts in the trace above tell the story:
1. We start with ATN asserted (=0V) at the end of sending the secondary address, which the 1541 correctly receives.
2. Then the computer releases the ATN line (ATN=1).
3. The computer then waits 20usec and asserts DATA to 0V, and releases the CLK line. DATA was already asserted by the drive, so now both are asserting it (this ability to see who is pulling a line low is only possible under simulation like this, and is tremendously helpful).
4. The drive then stops pulling DATA low, leaving the computer with sole control of it, and then pulls the CLK line low -- it is now the talker, and the computer is now the listener.
5. Shortly thereafter, the 1541 drive reaches the code where it is ready to send the first byte.
I am expecting that first byte to be the digit 7 (=$37 in PETSCII), i.e., the first digit of the drive status message on boot. But we won't know for sure, until we implement IEC byte reception in our controller. But that's going to have to wait for the next blog post.
No comments:
Post a Comment