[3.11] JiffyDOS load on IEC drive when alone on IEC bus ends with ?LOAD ERROR

[rgc2000]

Use a JiffyDOS Kernel ROM, disable all 1541 virtual drives and keep IEC drive enabled with device ID 11. Execute LOAD "$",11 and you will get a ?LOAD ERROR message and a list with only one line.

If you try the same command with a virtual 1541 drive enabled (eg. on device 8) you will get no error. No matter if you are using regular or JiffyDOS 1541 ROM

This means that the IEC drive may not be acknowledging some ATN command as expected as an unaddressed device should only acknowledge the fist ATN byte and the "all devices" commands UNTALK and UNLISTEN.

@GideonZ we may be running here on a similar issue as the bad UNLISTEN / UNTALK ack you found on regular IEC protocol. But once again I don't have the tools to see what's going on the IEC bus.

[rgc2000]

I am still trying to understand what's wrong with in IEC code concerning this issue. I have found a blog by Paul Gardner-Stephen talking about the Mega65 and the JiffyDOS IEC protocol. The is an interesting logical chronogram showing the line states in a command sent under ATN with a JiffyDOS capable device. Timings are not yet available on the blog.

I have highlighted in green what all listeners have to do. In blue what the JiffyDOS addressed listener must do. In red something that I don't understand: are the listeners supposed to set ATN line to 0 while answering to the primary device who set ATN to 0 first ? The software IEC is doing everything as expected, I just don't have the timings to check if it's not too fast but I have played with the code to delay some actions and I does not solve the issue. But the software IEC does never set ATN to 0. He's never the primary except for Ulticopy but this part of the code is not involved in IEC drive transmissions (MASTER_START label in iec_code.iec)

[cybern0id]

I'm not sure if my findings are applicable or even helpful so please ignore if not, however I've just tried this with my PAL SX-64 and U1541-II (non plus version) and don't have any issues.

My SX-64 has an internal IEC drive with JiffyDOS ROM for both drive and main ROM (switchable between original and JD) and JD is also set for the virtual drive ROM. I have the U1541-II virtual drive set to device 8 and internal IEC drive set to device 10 (using device ID switcher). Disabling the U1541-II virtual drive has no effect on the use of JiffyDOS on real hardware, either when IEC is left at device 10 or switched back to default device 8.

[GideonZ]

@cybern0id You will probably see the problem appearing when you disconnect the internal drive from the bus. The problem description explicitly states that this happens when the SoftIEC module is alone on the bus.

[rgc2000]

I forgot to mention that I have done the same test with a real 1541 hardware drive on the IEC daisy chain and the conclusions are the same. As long as you have a 1541 drive on IEC bus (real or virtual) you don't get the ?LOAD ERROR issue. This means that somewhere in protocol the 1541 drive is pulling down at least one line as expected by the JiffyDOS ROM in the C64 but the software IEC interface does not.

I have started to read the assembly code of the 1541 ROM and JiffyDOS ROM to find what they do that software IEC doesn't. I think that having an oscilloscope with high sampling rate and enough memory would help much better than reading the code.

Now I know that the ATN line is not set down by the 1541 drive. So this is not the issue. It's somewhere in DATA and/or CLK line. So far I have found a small difference in 1541 ROM where 1541 sets DATA low after C64 set CLK low at the begin of ATN sequence while software IEC sets the DATA low after ATN low. But this does not solve the issue.

[cybern0id]

Another misunderstanding by me. I blame late nights and lack of sleep. I assumed the report was in relation to a real 1541 on real IEC bus. I can confirm I get the same behaviour (?LOAD ERROR) with my setup, including when disconnecting the internal real IEC drive.

[rgc2000]

Don't worry, It's benefic to have someone else testing the same issue. This can help to look at the setup differently. Specially when I am stuck with no more ideas.

[markusC64]

It happens that I have a 8 channel logic analyzer (24 MHz sampling rate) - value 15 € (yes, really, they do not cost more). So if you send me a configuration to use and a prepared test program that does the test, I can record the required data.

[GideonZ]

I can use the built-in trace function of the ultimate64 for this purpose. It also traces the CPU address and data, which helps to understand in what state the routines are.

[rgc2000]

@markusC64 , that's very nice. Running firmware 3.11, the Ultimate configuration is : no cartridge ROM, JiffyDOS Kernel ROM. Software IEC drive enabled on device 11, Drive A enabled on device 8 (standard 1541 ROM), Drive B disabled. Printer enabled (but this does not matter if disabled). For IEC drive select a root directory with only one or two files in it (to limit the transfert and sampling time).

You will have to connect you probes to IEC pins ATN, CLK and DATA (and GND of course as the reference ground voltage), better to open the cartridge to access the pins behind the connector. Take care not to short them. In doubt connect all pins.

You can use ATN high to low as a trigger to start the capture. Execute LOAD"$",11 Stop and save the capture Disable Drive A (F5 action Menu, Driva A, turn off) Prepare for capture (trigger) Execute LOAD"$",11. (this one should end with ?LOAD ERROR) Stop and save the capture

Don't load anything else than "$" as the involved protocol could be different. Then you can share the capture files, just tell me how I can read them. Each capture should last a few seconds only (maybe 2 seconds if dir content is short).

[rgc2000]

I can use the built-in trace function of the ultimate64 for this purpose. It also traces the CPU address and data, which helps to understand in what state the routines are.

Oh, is this a standard feature of the Ultimate 64 firmware ? Of course it would be very useful but I know that you are very busy on other topics @GideonZ

[markusC64]

Oh, is this a standard feature of the Ultimate 64 firmware ?

Yes, it is. on the U64 it is F5, Developer, Debug Stream. Having Debug stream address configured, of cause. Edit: In F2, Stream Settings.

[markusC64]

I can use the built-in trace function of the ultimate64 for this purpose. It also traces the CPU address and data, which helps to understand in what state the routines are.

That's good and bad at the same time. If it would also possible to trace the 15x1 with iec bus data, you would be able to use it with serial bus mode "DIN<->Ultimate". Which might (!) help to find why Commodore +4 PAL and Jiffydos Floppy has problems... best observable with 1581. But that's another topic, I just wanted to have mentioned that floppy processor + iec bus also makes sense.

[rgc2000]

@markusC64 you can use the build-in IEC trace feature if you have an Ultimate64. It also suffers the same JiffyDOS issue as 1541Ultimate-II(+). It may be easier to use than your logical analyzer. Any help will be much appreciated.

[markusC64]

Here you're. load_dir_1541_iecdev_enabled.zip

You should be anble to open the file with https://support.saleae.com/logic-software/legacy-software/older-software-releases#logic-1-x-download-links this software works in demo mode (because no hardware found) without installation on windows. But Mac version is avaible, too. And a linux version.

Edit: I have used my U2+L for the IEC device.

[markusC64]

Oh well, a screenshot - of cause you can scrool and zoom with the software.

[rgc2000]

Ok thank you I am able to open and load the trace. It's very usable. Which one was this trace ? With Drive A enabled ? I need both captures. With and without drive A enabled.

[markusC64]

Great. I've thought it would be better to wait if you can open it before making the other capture.

The above one is the one with drive a (that is 1541) enabled. I'll make the other capture after dinner.

[markusC64]

load_dir_no1541_iecdev_enabled.zip

[markusC64]

FYI: I prepared my /Temp both times with 2 files named "foo" resp. "bar". 10 PRINT"FOO" resp. 10 PRINT"BAR" is their content. So both captures should be comparable.

[rgc2000]

Thank you very much @markusC64 . I can see a significant issue in the protocol. When a second ATN is sent by the ATN less than 150ms after the end of the previous ATN, the second one is ignored by the IEC drive. I suspect the interrupt handler for ATN in the IEC processor to be disabled and that's why it does not detect the edge of the second ATN.

When the 1541 drive is enabled the second ATN (A one byte command, maybe an UNLISTEN or UNTALK) is acknowledged by the 1541.

Now that I know where to search I may be able to solve this.

[rgc2000]

I have now a working solution and no more ?LOAD ERROR but I need to dig a little more to check if there is not a side effect.

The main issue is caused by the SET IRQ_EN=0 at the beginning of JIFFY_RX routine in iec_code.iec : At the beginning of the test the C64 sends a LISTEN + OPEN#0 command to device 11 with data "$" followed by an UNLISTEN. This is the filename (directory) to read from device. At the end, after the TALK sequence, the C64 sends LISTEN + CLOSE#0 with no data followed by an UNLISTEN. The iec_code expects data after a LISTEN and enters the JIFFY_RX routine as JIFFY has been detected. As IRQ are disabled, the UNLISTEN is ignored. The C64 is not happy and you get ?LOAD ERROR

Now that IRQ are enabled, I have an issue in EOI detection. As a workaround I am using the UNLISTEN as EOI since JiffyDOS ROM is always sending UNLISTEN at the end of the data. This is what I have to dig.

[rgc2000]

I am unable to detect EOI in JiffyDOS mode. This makes me crazy as it seems not to respect the very strict JiffyDOS RX timing.

@markusC64 can I ask you to record a new capture ? Enable JiffyDOS ROM and drive A. IEC drive ID is 11. Execute command:

LOAD"AAAAA",11

With AAAAA a non existent file so you will get ?FILE NOT FOUND ERROR

What I want to see is how EOI is encoded in AAAAA string.

I definitely need to buy one of those logic analyzers.

[markusC64]

load_aaaaa_1541_iecdev_enabled.zip

Edit For simplification, I have switched to using the U64 first hardware. But with external logic analyzer. Should make no difference.

[rgc2000]

Once again, thank you so much @markusC64 . This confirms that my JiffyDOC documentation and understanding is OK. EOI is visible at the end go the last A byte with CLK up for longer than other A. My source code is the problem, the test of CLK is always returning true and it detects EOI for each byte. The iec_code syntax is simple but I have missed something.

I have rewritten this part and now everything is OK. All commands under ATN are received and OEI is detected in JiffyDOS mode. I will release soon a pull request with the iec_code.iec fixing the ?LOAD ERROR issue

[markusC64]

Great. I think I'll test that with my Commodore Plus 4 PAL and Jiffydos. This combination is known for its high timing requirements. So high that even commodore floppies are making problems. But sd2iec is working very well.

BTW: I am pretty sure there is a problem in the hyperspeed implementation for the IEC device. I have to leave open where it is, Hyperspeed kernal and/or the firmware of the ultimate. Just need to find an easy reproducer, so that we can test, analyze and repair.

Another BTW: Do you happen to know the C64 kernal very good? I have tried to make a kernal with Jiffydos and hyperspeed. Basics are working, but Jiffydos commands on the hyperspeed address are making problems.

[rgc2000]

Fix has been committed to my git branch and a pull request has been opened. @markusC64, tell me if you prefer to compile the firmware yourself or if you want me to provide you the binaries if you want to test (I have only tested 1541u2 and 1541u2+ firmwares).

The timings for JiffyDOS RX has been taken from sd2iec source code. I have not touched the code for JiffyDOS TX or JiffyLOAD burst mode as they seem to work fine now.

I am not very skilled on C64 Kernal. I use the commented listing to understand what's inside for standard and JiffyDOS ROMs. But a lot of time has passed since I was a teenage asm developer on C64. I have no experience on Commodore Plus 4. Maybe I can take a look to tell you if I can help.

[markusC64]

I just have made a build for U2, U2+, U2+L and U64 with my and with your changes.

But I need to make yet another build. You may understand I need a build where the "N" command consumes some time. The "speed test" from 64er has a division by zero error because Tome of "N" is measured as zero. I think it is a good idea to see how the ultimate performanes compared to other jiffydos devices.

[markusC64]

Works fine for me. +4 is to be tested.

Saving a program has very good performance compared to a S-Jifyfdos 1541. Loading a Ptrogram, too. The same applies to writing a SEQ file and creating a REL file.

But reading a SEQ file has poor performance. The test takes 12.2 seconds on the mentioned 1541, but 19.4 seconds on the IEC device. That is surprising.

[rgc2000]

I will take a look to the JIFFY_TX routine. I know that @GideonZ has a tendency to insert more than necessary delays into his IEC code. Probably to keep the system compatible with as most configurations as possible. I will compare the timings with the sd2iec code and also with JiffyDOS ROM if possible. Then @GideonZ will decide if the gain deserves the changes to be merged to master branch.

[rgc2000]

Hi @markusC64

Can you check JiffyDOS performances with this version of iec_code.iec ? Delays have been reduced specially in the JIFFY_LOAD section code. I don't know if SEQ reading uses JIFFY_LOAD burst TX or standard byte per byte TX. The standard JIFFY TX has no extra delays that could explain the poor performances.

You may notice no difference in timing but tell me is there is any error in data load.

iec_code.zip

[markusC64]

For testing the speed, I am using this program:

speed-test.zip

Note before you start the program, you have to make POKE 186,11 or whatever your ID of the IEC Device is.

This program still works fine, getting the same speed as before.

To be sure that there is no error in data load, I decided it is best to give the device a task that takes 25 minutes or so. The complete time data reading and writing. And finally let my PC compare the data with the expected data.

[markusC64]

No error in this 25 minutes consuming test. One Megabyte of data has been read by the IEC device and written to 880 files. Which are written correctly. So I conclude no error obserable.

[rgc2000]

Great, lowering the delays did not broke the protocol. Values have been extracted from the sd2iec jiffydos source code. Can anyone make a test by an NTSC C64 ?