Topic: SD2IEC (uIEC) update for Fast Serial

[Hydrophilic]

Well, I'm glad to hear that simple fix got CP/M to boot for you.  Why it stops working is hard to say.  CP/M will stop sending Read Sector commands and then send an INQUIRE STATUS right after the system is loaded but before A> prompt appears... but I don't think that is the problem because you said you got that far, and could even issue a DIR command...
 
You know, if you issue DIR without any parameters, like in your example, it will use the built-in DIR of CCP.COM that seems to have loaded okay.  You could try again an instead issue DIR [full] which should load the transient version of DIR.  It would be interesting to know if that works.  If it does, then the CCP.COM is at least able to load executibles.
 
Why other commands would not work is quite a mystery!  Do you do a disk swap after CP/M is loaded?  Maybe that is a problem.  I tested reading and writing on a D71 image of CP/M, but it was all on the same disk (no swapping).
 
Another idea, is maybe there is trouble with Write Sector?  When CP/M stops working, you can look in the lower right-hand corner and it should tell you if it is doing read (R) or write (W) operation, along with track and sector.  Note it tells the first track/sector number of the multi-sector command.  It seems CP/M will always issue multi-sector read/write commands.
 
Anyway, simple trying out CP/M is very difficult way to trouble-shoot.  You have more control if you use something like fast-serial test software I posted earlier.

[abraXxl]

The CP/M problems seem to be timing related. So I disabled the serial debug console. USART is interrupt driven so it might interfere with the critical timing in while operating on the IEC bus.

A D64 image booted and worked like a charm.

But I think my CP/M D71 image, I found years ago is defective. On Zimmers.net I only found a cpm.fast.d71 image. Pokefinder.org also revealed only D64 and D81 images. Has someone a prepared D71 image using the version from May 87. But D81 images do not work yet.

Attached is a patch against HEAD that seems to have no troubles with SRQ low, attached datasette and floating SRQ lines. I have also changed the indenting in a way that meets a bit more Unseen's(Ingo's) indenting style.

I compiled test versions with CONFIG_UART_DEBUG=n for LarsP layout using a AtMega 644 and 1284 and for uIEC and uIEC3. See attachment.

The settings for Vim are:
tabstop=2:shiftwidth=2:expandtab

It is tested again only with MMC2IEC in LarsP/PeterSieg PCB layout.

Feedback welcome. Many thanks hydrophilic for your effort.
@Hydrophilic/@Brain can you test it on the uIEC device?

EDIT: Firmware attachment removed, as it doesn't work with one built-in MMC2IEC. That I cannot debug easily currently.
But reports from other device types are still welcome.

[brain]

Since ZoomFloppy boards just arrived, time to test is at a premium, but I am excited about the opportunity to add fast serial support to mainline.

If you can specify the tests you would like, I will run them.  Yes, as you have noticed, UART messes things up at times.  But, you can work around that if needed.

I have the uIEC/64/datasette, and a 1571 and '81 here (need to dog them out of storage since we just moved), but no CP/M image. 

Jim

[dabone]

I have the uIEC/64/datasette, and a 1571 and '81 here (need to dog them out of storage since we just moved), but no CP/M image. 

 
 
http://www.zimmers.net/anonftp/pub/cbm/demodisks/c128/index.html
 
Later,
dabone

[brain]

As noted above:

But I think my CP/M D71 image, I found years ago is defective. On Zimmers.net I only found a cpm.fast.d71 image. Pokefinder.org also revealed only D64 and D81 images. Has someone a prepared D71 image using the version from May 87. But D81 images do not work yet.

So, I am skeptical the Zimmers image is appropriate to use.  I want to ensure I am performing a valid test.

Jim

[abraXxl]

If you can specify the tests you would like, I will run them.  Yes, as you have noticed, UART messes things up at times.  But, you can work around that if needed.

I have the uIEC/64/datasette, and a 1571 and '81 here (need to dog them out of storage since we just moved), but no CP/M image. 

Since I have only little knowledge of the inner workings of the sd2iec firmware I tried to find out under what circumstances the firmware hangs.

In the first patch from Hydrophilic for version 0.8.2 it hung when SRQ line is not connected, when I tried to load in C64 mode or on a C64, when a datasette is connected.

The last patch should fix these issues, at least it does for me. I tested on MMC2IEC with an AtMega1284. I have also a datasette that causes a that failure. Sometimes it still seem to hang when SRQ line is not connected, but that should not be the cause for uIEC devices, because AFAIK SRQ is connected here.

For uIEC would at least two of the three cases nice to know.

[Hydrophilic]

Wow, I'm glad you guys got the datasette / floating SRQ issue fixed without me.  Good thing cuz I'm busy with other stuff!  I think if you are going to implement 'disable fast-serial' flag, then you should also implement a new BCIS command added by 1581.  This is the 'U0>Bx' command where x is 0 or 1 to enable or disable fast serial.  Maybe they added that because of C64 / datasette problems?  Not in the 1571, and because I have no 1581, I can not test it.
 
Anyway, I've attached the .D71 CP/M image I used for testing.  Using uIEC and the code I posted, it will Boot, Read, and Write.  I hope it helps!

[abraXxl]

Hi again, I have been short on time the last weeks... Any progress here?

Did someone tested my patches? I don't think so. The datasette/SRQ issue still persists and no feedback

I debugged a bit further.
@Hydrophillic: It seems that it got stuck there, if SRQ is low or now connected:

Code: [Select]

    case BUS_ATNPROCESS: // E8D7
      set_atn_irq(1);

      if (iec_data.device_state == DEVICE_LISTEN) {
        if (iec_data.iecflags & FAST_SERIAL) {
        /* send fast-serial notify  ($816A) */
          uint8_t tmp;
          ATOMIC_BLOCK( ATOMIC_FORCEON ) {
            set_data(0); /* active listner, but not ready to receive */
            do { /* wait for first byte to start ($8199) */
              tmp = IEC_INPUT & (IEC_BIT_ATN | IEC_BIT_CLOCK);
            } while (tmp == IEC_BIT_ATN);
            if (tmp & IEC_BIT_ATN) {
              /* toggle SRQ line 8 times to set CIA register in host PC */
              for (srq_pulse_count=0; srq_pulse_count<8; ++srq_pulse_count) {
                set_srq(0);
                _delay_us(4);   // hardware delay, fudged
                set_srq(1);
                _delay_us(4);   // hardware delay, fudged
              }
            }
          }
        }
        if (IEC_ATN) {
          if (iec_listen_handler(cmd))
            break;
        } else { /* found ATN ... FIXME? */
          iec_data.device_state = DEVICE_IDLE;
          iec_data.bus_state = BUS_ATNACTIVE;
uart_putc('?');
          break;
        }
      } else if (iec_data.device_state == DEVICE_TALK) {
        set_data(1);
        delay_us(50);    // Implicit delay, fudged
        set_clock(0);
        delay_us(70);    // Implicit delay, estimated

        if (iec_talk_handler(cmd))
          break;

      }
      iec_data.bus_state = BUS_CLEANUP;
      break;
There were uart_putc('?'); is placed. The state machine got screwed up. I don't know why. I compared it with the 1571 ROM listing.

Hydrophilic: can you have a look? There is a comment I don't understand. Perhaps you can be a bit more verbose?

cya

[Hydrophilic]

Wow, I haven't even been thinking about it, since it works for me without any problem yet.  I thought you or Jim Brain had done something to fix the 'bad' SRQ issue... I'm been doing other Media Player related stuff (this was just a side quest)...
 
Anyway, thanks for pointing out where the problem occurs.  You know, I think this must be a side-effect of the real problem.  If you look at the code you posted, you should see it never tests the SRQ line (input), so it should not matter if SRQ is low or high or unconnected.  Of course it does change the SRQ line (output).
 
In other words, the state of the SRQ should not affect what the SD2IEC device does... at least not at this point... of course it is possibile that output generated is not timed correctly, therby causing the C128 or other fast-serial devices to get confused...  It works for me with C128 (obviously) and with C1571(s) connected.  One with JiffyDOS ROM and one with factory ROM.
 
So when you say you have problem when no SRQ is connected, do you mean your device is connected to a computer other than C128?  Like real C64 or VIC-20, etc. ?  This is a bit different case than when the SRQ is grounded due to datasette (which is my understanding, I have no datasette for testing).
 
The reason that is important is because if the problem is really SRQ output by SD2IEC not being correct, it should only affect fast-serial devices like C128 or C1581 and should not effect older devices like C64 or C1541.
 
So like I said, this section of code may just be a symptom of the real problem.
 
Anyway, let me try to describe more what the code is trying to do and offer some suggestions...
 
After the SD2IEC indicates fast serial, it checks that ATN is not active.  If this is true, it calls iec_listen_handler.
 
If this is false, it means that the host (C128 for example) had just previously sent an ATN command to Listen (we are trying to do the Listen command), but now ATN command is active again... maybe the host changed it's mind and wants to abort?  Anyway, this is the case where your UART_PUTC comes into play.
 
In this special case, the device state is set to DEVICE_IDLE (we abort the Listen command) and bus state is set to BUS_ATNACTIVE (so the main loop knows that ATN is active and bus processing is needed).  Finally we break out of the switch statement to go back through the main IEC loop.
 
In the comments I wrote "FIX ME?" because I am not sure this is exactly what the 1571 is doing in this case.  Now the 1571 does check the ATN state after sending the fast-serial notify and aborts if ATN is active.  Since you are having problems, we might assume the response I coded is wrong.
 
In that case, I don't know what the correct response should be.  One thing you could try is to ignore the ATN line and always call iec_listen_handler, just like the original SD2IEC code before I put in the fast-serial code.
 
To summarize, you can try changing this

Code: [Select]

        if (IEC_ATN) {
          if (iec_listen_handler(cmd))
            break;
        } else { /* found ATN ... FIXME? */
          iec_data.device_state = DEVICE_IDLE;
          iec_data.bus_state = BUS_ATNACTIVE;
uart_putc('?');
          break;
        }

into simply this

Code: [Select]

        if (iec_listen_handler(cmd))
            break;

Of course this deviates from the way the 1571 handles the bus, but it is so simple it might work!
 
The only other thing I can think to try would be changing the argument to delay_us() calls.  The 1571 initializes the CIA timer with a value of 6.  Due to the way the timers work, it means an underflow every 8 clock ticks.  Because the 1571 operates at 2MHz when doing fast-serial, this means each half of the SRQ output is 4 microseconds.  Hmmm, 4 is the value already in use!  So changing it might break things... but it is something you could try...
 
Edit
After posting this, I thought of something else that might be the problem... Maybe the device state should remain in Listen mode, but still break out of the switch statement to handle the ATN command.
 
So you could try changing this

Code: [Select]

        if (IEC_ATN) {
          if (iec_listen_handler(cmd))
            break;
        } else { /* found ATN ... FIXME? */
          iec_data.device_state = DEVICE_IDLE;
          iec_data.bus_state = BUS_ATNACTIVE;
uart_putc('?');
          break;
        }

into simply this

Code: [Select]

        if (IEC_ATN) {
          if (iec_listen_handler(cmd))
            break;
        } else { /* found ATN ... FIXME? */
          iec_data.bus_state = BUS_ATNACTIVE;
uart_putc('?');
          break;
        }

You should notice the only change is to remove

Code: [Select]

          iec_data.device_state = DEVICE_IDLE;

So the device state should remain in Listen mode (for now) and let the normal ATN processing occur.  Afterwords (assuming the host doesn't command otherwise), the Listen processing should resume.  I suggest you try this method before the more drastic method originally posted.
 
Anyway, good luck!

[abraXxl]

Well, I pulled a facepalm

The patch I first published works. I made a damn typo while cleaning it up and posting it here. Then I used that work as base for new improvements, which lead me me obviously wrong.

Code: [Select]

[...]
+#define FAST_SERIAL     (1<43)
That line in src/iec.c is really a bad idea ... It took a long time to find it.

The new working patch agianst git HEAD is attached. It now really works, if SRQ line is not connected or pulled where ever.
And again I could only test on MMC2IEC devices with LarsP Layout. I tested with a AtMega 644 and 1284 uCs.

One thing is still on the TODO list:
Hydrophilic implemented die Burst Command Instructions Set (BCIS) that in all cases uses SRQ+DATA to transfer data. How to handle certain U0>... commands if no SRQ is not connected or better when no fast serial detection impulses are received (from the sd2iec firmware side of view). Throw out an error? Currently a C128 throws DEVICE NOT PRESENT, if it tries do DLOAD a PRG via FAST-LOAD-UTILITY  and SRQ is not connected. This must be addressed. There many, many devices out there with no SRQ lines connected.
eg. What happens when a C64 without fast serial sends FAST-LOAD-UTILITY Command to a real 1571 or a 1571 in 1541 mode? What does the drive return? I currently have only a 1571 from C128DCR in my possessions so I can't test that from a C64. I have a printed ROM Listing of 1571 here, but reading it complete to find the right part is hard. I like to get some pointers and opinions where to look and how to handle that.
My idea is to respond to BURST-READ, BURST-WRITE and FAST-LOAD-UTILITY with DRIVE NOT READY or SYNTAX ERROR if iec_flags.bus_state indicates no FAST_SERIAL communication partner.

@Hydrophilic:
The code sequnce discussion in the last two postings should AFAIK be the following way.
EA59 (src/iec.c:check_atn() ) is called to restart the ICE bus loop. Now this is simulated.

Code: [Select]

        if (IEC_ATN) {
          if (iec_listen_handler(cmd))
            break;
        } else { /* found ATN - $EA59 */
          //iec_data.device_state = DEVICE_IDLE;
          iec_data.bus_state = BUS_FOUNDATN;
          break;
        }

Could you please give me some details about the parameters for fserial_in() and fserial_out() assembler routines in fastloader_ll.S
I guess what they do, but I have no good clue about the exact signature, incoming parameters and what is returned.

[Hydrophilic]

Your last code posting looks to be the same as I was saying earlier.  So it seems we are on the right track, or we're both off track.  Off track    I find that amusing for some reason...
 
I also wanted to comment about the other idea I mentioned... changing the fast-serial timing and/or moving the ATOMIC_BLOCK (disable IRQ) locations.  I had problems with fast-serial and my Media Player 128, so I tried this hoping it would fix the problem.  Well it made the uIEC slower, but did not fix the problem... turns out it was a problem with the C128 software... I've since reverted to the original version I posted here, and it works great.  In other words, once the real problem (C128 Software) was fixed, either SD2IEC version would work... the only difference was timing/IRQ changes I suggested make things slower...
 
Anyway, I'm glad you found and squashed the bug!
 
Regarding BCIS compatibility... any device (VIC-20, C64, C128) can send a BCIS command to a capable device (C1571/81, and probably FD-2000/4000/CMD-HD).  The 1571/81 will start executing the command and assume fast-serial communication.  So this means a stock C64 or VIC-20 will never see the response... and the drive will sit there waiting for a data handshake that will never come...
 
This is easy to test with C64 or VIC-20.  The only 'gotcha' is the 1571 will start in 1541 mode and will ignore most BCIS commands.  So with a C64 or VIC-20, issue the 'go 1571 mode' command first (U0>M1) and then you can send BCIS instructions.  The 1571 will start them, but unless you modified the VIC-20 / C64 for fast-serial, the communication will rapidly come to a halt.
 
Note there are a few BCIS commands that don't actually require any fast serial data to be transferred.  Inquire Status with the write (not read) flag active comes to mind.  Another example would be read/write sector with the 'no transfer' flag set.  (In this case, data comes from buffer# 0 in drive RAM).
 
Hopefully that makes sense, because then we come to the 1581.  Commodore re-desginated the same commands to have slightly different functionality.  Also the 1581 has no 1541 nor 1571 modes... so I think it always accepts BCIS commands (I don't have one to test).  I do know they added a new BCIS command U0>Bx (x=0 or 1) to allow fast-serial communication to be turned off.  I guess this is so C64 etc can use BCIS commands without the 'no transfer' hack... in fact, I think the 'no transfer' bit flag is one of the bits they changed the specifications for...
 
Then of course, how do FD-2000 or CMD-HD handle the commands?  I have no idea.  So somebody could spend a lot of time trying all these things out.  In the end, I fear there is no perfect solution.
 
So I guess if were to offer a suggestion, it would be two (he he).  There should probably be some global flag saved into EPROM to enable fast serial, like there is to enable JiffyDOS protocol.  But then the user could still enable/disable fast serial at run time with the U0>Bx command.
 
Edit
Silly me, I forgot about your request!
 
fserial_out takes two bytes as an argument: fast_flags, and value.  The 'value' is obviously the data to transmit.  The 'fast_flags' is a set (currently 2) of bit flags...
 
bit 1 is "don't check the CLK line" flag.  If this bit is set, the ML code transmits 'value' immediately without checking the CLK line.  I only put it in for debugging purposes and it is never set (alwyas clear) in the C code.
 
bit 0 is the 'desired CLK voltage' flag.  If the flag is set, the ML code waits for CLK to be high (+5V or 'released').  Otherwise, it waits for the CLK to be low (0V or 'active').  Once the CLK is detected in the desired state, 'value' is transmitted.
 
Anyway, the ML code also checks the ATN line and returns true (non-zero) if ATN is found active (0 volts).  It returns false (zero) otherwise.
 
So if bit 1 is clear (always unless you change the code), it will wait for the desired CLK value ('fast_flags' bit 0) or ATN to become active before it transmits the value and returns.  If ATN is detected active before it transmits, then it will return immediately without ever transmitting.
 
I love hardware!  It is so patient!  While debugging Media Player 128, I would often stop the player and examine the code for several minutes (approaching an hour) and then resume and the uIEC would happily continue.  Sorry, that doesn't really belong here   
 
fserial_in takes one argument: fast_flags.  This is again a collection of bit flags...
 
bit 1 is the 'toggle CLK line' flag.  If this bit is set, then bit 0 is ignored and the current state of the CLK is toggled.  This was experimental bit that is never used (always clear) in the C code.
 
bit 0 is the NOT CLK flag.  If this bit is set, then the ML will set CLK to active (0 volts); otherwise it will release CLK (+5 volts).
 
If you are wondering why the other routine uses CLK and this one uses NOT CLK (in comments I wrote ~CLOCK), it is because the ML code simply 'copies' the bit value to the hardware, and the fact that SD2IEC has inverters on the output lines but not on the input lines (very much like C64/C128 but unlike C1541/71).
 
Anyway, the function returns an unsigned 16-bit integer.  Any negative value indicates that ATN was found active.  Otherwise, the returned value is the byte (low 8 bits, high 8 bits all zero) that was received over the fast serial line.
 
I didn't mean to write an essay, but I guess I did.  Sorry about that!  Anyway, I hope some of it is helpful.

[Hydrophilic]

I was wondering if abraXl has made any progress and also noticed a few unanswered questions. 
 
It seems that if C64 issues a burst-load command to C1581 then it will start loading the file.  Of course without SRQ connected, the C64 will never know that data has arrived.  But you can sit in a loop and just keep toggling the CLK line and the C1581 will send the entire file.  There is no error.  If at any time in this process you read the error channel, you get "00 OK 00 00" and loading stops.
 
If you send burst-load to C1571 in 1541 mode, then the drive just ignores the command.  If you then read the error channel, you get "00 OK 00 00"
 
If you send burst-load to C1571 in 1571 mode, it acts similar to C1581.  That is it starts loading the file.  You can blindly toggle the CLK line and the entire file will "load".  At the end, the error channel will read "00 OK 00 00".  The difference between 1571 and 1581 is if you check the error channel before the file has fully loaded.  On the 1581, the load aborts.  On the 1571 the load aborts, but the drive light remains on until you send another command.
 
On a 1541, everything after U0 is ignored if it is not + or - (switch drive speed command) and the execute NMI is executed instead as if you commanded only "U0" (no parameters).  I've heard some versions of C1541 ROM will crash in this case.  But from my testing, it just reports "00 OK 00 00"
 
So in all these cases, there is no error message.  I don't know about other devices like CMD-HD or FD-2000.
 
I'm not saying SD2IEC should act like that.  Reporting 31, SYNTAX ERROR sounds reasonable to me.

[abraXxl]

Hi,

sorry for the long delay. I had situations here regarding job, live, etc ... which kept me busy.

I feel better in releasing soon to Unseen to get it into the mainline of sd2iec, but there are few issues left.

- Defined some defines CONFIG_BCIS and CONFIG_BCIS_NOLOCK, for conditionally compiling the fast serial code. The latter define is for easier debugging via serial console.
- fserial_in has to be reimplemented in C.
- fserial_out has already been reimplemented and tested in the current patch (attached), I also replaced some code in the iec_mainloop() with fserial_out which shrunk the code size on my devel system arround 200bytes.
- I want to subtitute the code regarding fast serial in _iec_getc() with a fserial_in()-call, like I did with the fserial_out() code above, maybe some of you have some quick ideas.
- I like to update the copyright headers.
- Currently I am in debugging some CP/M problems, there is some unfinished work for the define CONFIG_BCIS_STATUS_DUMP, which should dump the BCIS reply to the serial console, for easier debugging.

Comments are welcome.

:wq

EDIT1: patch against current git-HEAD

[tokra]

Can't wait for it to be released! I'm using the "original" patch by Hydrophilic on mc C128 with uIEC now and it's like upgrading from a 1541 to a 1571. My C128 is back to speed again! It seems like a shame to use Jiffy DOS when the C128 has Fast Serial by design. Also I don't want to re-mod my C128D which already has DolphinDOS 3 (parallel speeder).

Definitely one of the coolest advances in retro-computing lately :-)

[Franchute13]

Sorry for my English.

I would like to build a circuit to test this project.
Which diagram do you recommend?
What is the status of the project?

Greetings and thanks!

[Hydrophilic]

It is working fine in C128 and CP/M modes.  It seems there are some problems with C64 mode and datassette which abraXxl has been working to correct.  And last I heard, the Unseen (who maintains the whole SD2IEC project) was wanting a C version of the fast-serial code (which is currently written in assembly) before adding fast serial to the official distribution.  I haven't had the time to work on it for quite a while.
 
You can download the unofficial version here.  Besides the 64/datassette issue mentioned, you should also be aware this firmware is based on an older version so it does not support the newest GEOS driver.
 
I don't have a recommendation for a test circuit or diagram.  I simply compiled it and tested it with a real C128 in native mode and CP/M mode and C64 mode (I don't have a datassette, so I never had any problems).

[Franchute13]

Hey. Sorry for the delay.
I want to build this circuit but using the ATmega128

http://www.pitsch.de/stuff/mmc2iec/MMC2IEC_antabaka_LarsP_neu.gif

In the message I saw that talk about connecting the SRQ. What ATMega PIN should be used to connect the SRQ?
I do some other modification to the circuit?
Thank you!

[Hydrophilic]

The MMC does not support SRQ needed for fast serial because there are not enough I/O lines on the Atmega644.  The uIEC does have SRQ because it uses Atmega128 which has more lines.  So your plan should work, but I imagine you would need a different board layout.
 
Disclaimer: I'm pretty conpetent with CBM / MOS technocology, but am not an expert with Atmel products.  So the above may be only partly true.  For example, I programmed the uIEC to support fast serial so I know it has an SRQ line, but I am not 100% confident that it uses an Atmega128, only about 93% confident
 
Answers are free.  Gauranteed answers cost $10000000.99

[maraud]

I'll throw in the .99! 

[brain]

uIEC uses ATMega1281, which has the same pinout as ATMEGA128, with an additional IO pin.

Pinouts are in the source code.

Jim

[maraud]

Hydro, is there a way I can "patch" 10.3 firmware with what you did to add fast serial support or did it already make it into the code base.  I dont see mention of it in the readme.  Thx!

[Hydrophilic]

You'd have to manually edit the source files and recompile.  Not too difficult if you've done it before, but not something I would recommend for a novice.  I don't think fast serial made it into the code base; it seems the fast serial protocol is not very well understood, and consequently not been made official.  I might recompile it myself, but don't hold your breath.