exxos's Atari, Amiga & retro forum

I think I'm going to refactor the code so that all WD1010-05 commands wait one iteration of the loop and set the "command in progress" flag in the status register. This means that code on the Apricot will have time to set up interrupts if it needs to and check the CIP flag. I think there are assumptions that operations won't complete instantly so my code has to pretend to be slow.

It's now not hanging... but it's not working either.

@stephen_usher i use the pick quite often for work. Don’t forget you have two cores and can also up the clock speed if needed.

I use one core for screen stuff and the other for the control stuff for instance.

PhilC wrote: 15 Dec 2022 19:56 @stephen_usher i use the pick quite often for work. Don’t forget you have two cores and can also up the clock speed if needed.

I use one core for screen stuff and the other for the control stuff for instance.

Yeah, that's what I'd like to do by micropython locks up if you use two threads and try to access the SD card, so I can only use one thread.

It shouldn't really matter as I'm supposedly holding the /IOWAIT pin low so the processor is halted until I'm ready.

However, there's a period between the bus being released by my program sending /IOWAIT high after its completed its operation, checking to see if the address has been unselected and then turning it back on again. Each iteration of the tight micropython loop (with the core fully overclocked to 240MHz) seems to be taking ~500ns. Then turning off the line again it taking over 8us, missing some pulses. This seems to be getting slower the larger my program is getting as I didn't seem to miss things when it was simpler.

I think that I may have reached the limit of what I can do with micropython natively. I may have to look at PIO assembler for this part as it's far-far quicker.

@stephen_usher i couldn’t get on with Python so I used C++ but using the arduino IDE rather than using vscode. Each core can be programmmed in its own window and it’s far more forgiving for spaces and indentation

PhilC wrote: 16 Dec 2022 08:22 @stephen_usher i couldn’t get on with Python so I used C++ but using the arduino IDE rather than using vscode. Each core can be programmmed in its own window and it’s far more forgiving for spaces and indentation

Yeah, Python is a pain. I seem to spend more time trying to work around the "features" of the language than the logic of the program.

Still, what it does have for it is a simple SD card over SPI interface, unlike the C SDK, and the code change iteration time is less. But given that I'm now hitting major speed and memory usage issues I may have to change to using C, which is far better suited to this sort of system programming than any object orientated language as it's almost high-level assembler.

Given that I've proved the circuit design at least, I going ahead with the PCB design.

The PCB will be able to be built as either a daughter board for my RAM card or with three extra chips and the correct connector installed, a stand-alone card for Apricot computers. It should work in all of the machines equally well.

First view of the layout.


There a large gap to the left of the Pico so as to be able to connect a microUSB cable.

Chips U4 to U7 are only needed if it's connected to the Apricot expansion header directly.

I think that this is going to be my final version. I'll push it to PCBWay later this morning...


The strange location of the 74AHCT chips on the left is to make the routing better.

Everything now packed away as I make ready for the Christmas break.

There was no point trying to get any further with the breadboard based Apricot HD simulator anyway as it got to the point were I never knew if it was a code change or a bad contact causing an issue and you just can't develop on that sort of system. Anyway, the new PCBs should be with me on my first day back at work (3rd Jan) and the small number of components I don't have (64 pin PCB socket & 0805 1uF caps) have been ordered from RS. This means I should be up and operational again first thing in the new year with a more stable platform.

After testing with the current code, to make sure that it breaks in the same way, I can then look at getting a Pico C build environment and re-writing the Pico code in C. Other than the far lower level nature of the C libraries for the Pico, it should be easier as the language is far better tuned for system programming than Python, and will use vastly less memory and CPU resources. I can also utilise the second core for purely host-side communication. Reading and writing to the SD card will then be fully asynchronous.