On the one hand I wish Peter maintained his repo in something resembling a standard git way, on the other he is pretty responsive to bug reports. So, if I had to pick I’d take what we have.
1 Like
I just synced the repo with my fork and I’ll get a release out in a bit. Looked like there might have been a few other minor fixes too in there. Also sounds like based on the continued conversation over there, this will end up being the final release.
Hopefully having the fork for PicoCalc helps. It was bumpy at first trying to get the initial patch code for the first PicoCalc release from guu/Clockwork synced up and working properly with the newer version of the PicoMite code. While comments from the upstream repo are basically nonexistent, at least the changes do come in chunks organized around certain features or bugfixes. I’m not sure as a user that I’d want to ever try to keep up with the bleeding edge version that was just released though, since things change frequently and bugs are introduced and fixed quite rapidly. I’d think for actually using it to write code it would be much better to go with a stable version that was documented and a known quantity. The problem with the PicoCalc was that it released during an ongoing development cycle, and shipped with a much older version of the code that had its own issues, along with new issues because of the specific PicoCalc hardware that wasn’t fully supported. There are still a few things I’d like to clean up and do with the PicoCalc version, but hopefully one based on the final 6.00.02 version will be able to satisfy most people for a good long while until the next new main version is near ready for release.
For PicoCalc specifically, I’m probably going to have another version or two after the final mainline one, to pick up some additional things specific to PicoCalc like setting display brightness, the options issue on guthub, and probably a few other minor things and cleanup.
3 Likes
Sorry for the delay, RC26 release is up.
4 Likes
You’re due another coffee sir 
1 Like
Working well Michael yet one funny noticed immediately. Won’t accept my old 362Mhz clock yet will 360 and 364 !?, tried twice with power cycles snd yes flash was nuked beforehand. Peter might have fiddled in several areas 
Probably because the PLL can’t generate a 362MHz clock and previously you were getting something else but it wasn’t telling you. Check the code, it looks like it now checks if the clock speed requested can be generated before allowing it.
tp = checkstring(cmdline, (unsigned char *)"CPUSPEED");
if(tp) {
uint32_t speed=0;
if(CurrentLinePtr) error("Invalid in a program");
speed=getint(tp,MIN_CPU,MAX_CPU);
uint vco, postdiv1, postdiv2;
if (!check_sys_clock_khz(speed, &vco, &postdiv1, &postdiv2))error("Invalid clock speed");
Option.CPU_Speed=speed;
SaveOptions();
_excep_code = RESET_COMMAND;
SoftReset();
return;
}
1 Like
Yup looks like it…
What does the “P” do in the LCDPanel ILI9488P… option? My old firmware didn’t have a “P.” I don’t know if it has something to do with the screen displaying a brief “image noise” when turned on. But I can’t change the option either because the error message “LCD panel has already been configured” appears.
I think it might be for the display being used in Portrait rather than Landscape mode, but don’t quote me on that.
Best wishes,
Tom
As I understand it from TBS posts, the “P” variant was created to properly support 320x320 and H/W scrolling
There’s a V6.00.02 release version now.
I haven’t tested this extensively, but I don’t expect the bug fixes to really be noticable on the PicoCalc anyway. I was hoping to get the display backlight update function working from MMBasic before the final version dropped, but decided it was better to get the release out here sooner than delay it.
Any extra functionality for the PicoCalc between now and the next mainline version RCs will just be labeled like “V6.00.02_a”, as I had done for some of the previous RCs.
1 Like
Thanks for the quick release! Where are the original files unmodified by you? I didn’t see any mention of the final release on The Back Shed.
This was the original commit:
It seems to be a lot more than just what was mentioned in the thread on TheBackShed.
When I looked it over I found:
- a lot of changes for adding ST7796SP display type
- I2C communication changes, mostly seeming to do with timeouts, though none of which seem directly related to how the PicoCalc uses it
- some whitespace/formatting/style cleanup
- a possible bug fix related to catching an error when non-matching types were passed BYREF
I’d like to be able to delete OPTION SERIAL CONSOLE from my options but every time I type
OPTION SERIAL CONSOLE DISABLE, the system resets and it comes right back. I tried editing FileIO.c to change Option.SerialConsole from 1 to 0 and that does get rid of it from the options but then I can’t set the console to a serial port manually. Is there a way to eliminate the automatic setting and still allow me to set it manually?
These default settings were a carryover from the initial port from Clockwork. I’ve never tried doing this.
So are you trying to completely disable the USB-C port for serial output? (And why?) Removing the options in FileIO.c and building the firmware should do that, since that’s the only place they get set. I could make this change for a new build, but of course it would allow people to disable their USB-C for serial debugging, and render it useless for anything except charging. WIth WebMite serial output could still come through the TELNET CONSOLE, if it was turned on. (I’ve been using it for all my serial connection needs for a while now, since I don’t want to be bothered connecting cables, but I never considered disabling the serial console since I didn’t think it was hurting anything.) The part I’m not following is what happens when you try to set the serial port manually… What happens when you do that? What pins are you trying to use?
According to the manual, you can route the serial console through other pins with this command. I’m not even sure which pins might be available on the PicoCalc, but mabe some of the pins routed to the side of the case could be used.if they are not already used by the system. Does it give some kind of error? What happens when you use that command?
I can take a look at this, but I’ll need to scrounge up something to try to connect to other pins to see if the serial connection is being routed through them. I guess I could use my Flipper Zero, as I’ve used it for some other hardware in the past to connect to TX/RX pins on a device.
The forced option setting at startup is kind of a problem though. The official PicoMite and WebMite don’t automatically set many options at all, but the assumption is that people will run some BASIC code at startup and make all the conenctions they need manually. I’m assuming this is because the intended audience are hardware hackers and pretty much all have their own custom setups with different requirements for pinouts, etc. For the PicoCalc, if there were no default options like this, then on first use people wouldn’t have access to the serial console, and would likely be confused and assume their device was broken. There’s no way to “pre-load” the device with anything to force sane defaults (using the USB-C port for serial, as expected), as it can’t be assumed they have the SD inserted, or that it has any particular content on it, and the flash memory won’t have anything useful in it either after a new flash. So it would force people to type in a command to set up basic (and expected) serial functionality every time they flashed their device and lost options. This seems like a nightmare scenario for new users and a pain for everyone else. (I for one would not like to have to do this at every re-flash!)
So I’m not sure what the correct way to handle this is… If the default is not set at boot time, then I’m not sure there would be a way to ensure a default serial console exists on the USB-C port. But disabling it appears to require a reboot, which gets us caught in this cycle. Maybe on boot it could check for some new special override option in flash that would need to be set if someone really wanted to disable serial on USB-C. That option wouldn’t be set when flashing a device, but it could be manually set once things were set up and it would survive a reboot. But I’m not sure whether the boot options are even being set at a place in the code where flash is available to be read from so this theoretically new option could be checked… Might work, but I don’t think PicoMite does anything like this already, so it would have to be experimented with.
Looks like this may be useful for the PicoCalc if the displays are actually ST7796 rather than ILI9488 as it uses RGB565 so should be faster
2 Likes
Cool! I’ll have to try the new display settting – didn’t realize it might be compatible, and potentially faster. Unfortunately, it’s another one of those baked in options, but if it works I’ll put out a test build so others can try it. Not sure if I’ve seen any PicoCalc BASIC code examples around that use the graphical display and also show an FPS display for comparison. Do you know of any test code on TheBackShed that might work on the PicoCalc and could be used for evaluating display update speed?
timer=0: cls: ?timer
1 Like
Why ?. This is going to confuse some folk. Maybe V6.00.02_final then _final_a for your screen backlight mod ?.