exxos's Atari, Amiga & retro forum

I'm still getting the odd read error (and possibly write error), but it's intermittent. I'm wondering if it's due to the Pico being too fast and reading the bus before the data lines are stable. (The address lines are latched first, which triggers selection, followed by the data going onto the bus. If it's too quick then the data lines may not yet be stable.)

So, I've added a short for-loop setting a volatile variable with the loop counter. The volatile variable means that not only is it not cached but the compiler shouldn't optimise the loop out. At the moment I've got the CPU looping for 100 iterations. We'll have to see if it helps.

Hmm... Maybe that's fixed it. I've done quite a bit of copying both from the Gotek and between disks and between directories on the virtual disks and so far there doesn't seem to be any corruption.

I think that I may move on to fixing the format function. It currently causes the machine to hang waiting for something.

Still no corruption and I've filled the A: drive to ~40% and no problems so far. This suggests that it works.

So, the next task is to write to config file reading code.

At the moment I have the names of the image files etc. hard coded in the "read_config.c" source code, which is not very useful.

My thoughts are that if the config file specifies a file which doesn't exist then the system should create a blank virtual drive file containing the drive information, as the field formatter would produce. Thankfully on of the documents on a virtual floppy it details what this should be for each disk type.

Some good progress @stephen_usher , I found it amusing that you had to slow the PICO down.

PhilC wrote: 23 Jan 2023 17:31 Some good progress @stephen_usher , I found it amusing that you had to slow the PICO down.

It's mostly just twiddling its thumbs. But yeah, I have to give the 8086 time to write the data onto the data bus after it's finished latching the address. Such is the fun of a multiplexed address/data bus.

Tonight I got the config file working. It even creates a blank image with the correct headers if the file doesn't exist.

Of course, if the FORMAT program doesn't check to see what type of disk it is by reading the information block and just assumes 10MB when writing a 20MB drive then I can't help that... especially when the BIOS reads the block size as double the number of sectors to that which the FORMAT assumed.

So, now I have to clean up the code and to the error stuff to report to the host if things go wrong, such as the SD card going away. I think I'll also implement LED flash codes for when the system can't start, such as if the config file has a syntax error or the SD card can't be read as there's no way to get text out of it. I could be obtuse and flash the panic text as Morse Code. ;-)

I've still not worked out why the low-level formatting isn't working though.

OK, I didn't go for Morse Code in the end, but did implement blink error codes.

They turned out useful when I tried the card stand-alone without it being connected to the Pi. For the dev board I'm powering the SD card from the Pico's VSYS pin, which is also connected to the Apricot via a diode so that the USB power can't try to power the whole machine. Unfortunately the voltage drop over the diode is too great for the SD card and it doesn't work. The Pico is fine though and my code flashed it's error codes for card can't be mounted, can't find current directory and config file error. So, a good test.

The "production" card powers the SD card directly from the Apricot system and that works fine (I shorted the diode leads).

stephen_usher wrote: 24 Jan 2023 21:59 OK, I didn't go for Morse Code in the end, but did implement blink error codes.

They turned out useful when I tried the card stand-alone without it being connected to the Pi. For the dev board I'm powering the SD card from the Pico's VSYS pin, which is also connected to the Apricot via a diode so that the USB power can't try to power the whole machine. Unfortunately the voltage drop over the diode is too great for the SD card and it doesn't work. The Pico is fine though and my code flashed it's error codes for card can't be mounted, can't find current directory and config file error. So, a good test.

The "production" card powers the SD card directly from the Apricot system and that works fine (I shorted the diode leads).

Damn that diode! Good find :)

I had been wondering about the voltage drop and whether the 3.3V regulator on the SD card board would work at the lower voltage. Well, I have my answer. :-) The input from the Apricot is about 4.8V and the other side of the diode it's about 4.0V. This is probably why people suggest to use 3.3V SD card reader boards with the Pico as they can be powered from the Pico's 3.3V output. However they are harder to come by and more expensive than the ones targeting Arduinos.

Anyway, too tired to do anything tonight, but I have thoughts about how to implement the error stuff if the SD card goes away. I've already implemented the stuff which deals with the case of the SD card not being there to begin with to allow the machine to continue on without any drives.